zhaoxuya520 DORA 交付效能度量
参考来源：Google DORA、Accelerate
适用场景
- 团队/工作流效能度量
- 季度/年度交付能力评估
- 改进决策的数据支持
- 项目复盘时的客观指标
不适用场景
- 单个任务的成败（用 milestone-gate）
- 短期波动判断（DORA 是趋势指标）
核心原则
不只看"是否按时完成"，要看"持续交付能力"
DORA 四指标是一组：
- 速度指标（部署频率 / 前置时间）
- 稳定性指标（失败率 / 恢复时间）
只看速度会忽略质量
只看稳定会牺牲速度
两者必须平衡
四大核心指标
1. 部署频率（Deployment Frequency）
含义：多频繁可以把变更部署到生产环境
AI 工作流场景：每个功能模块从完成到可部署的频率
测量：
- 每天/每周/每月部署次数
- 单位：次/天
效能等级：
Elite：每天多次（按需部署）
High：每周一次到每天一次
Medium：每月一次到每周一次
Low：每几个月一次
目标：每个模块完成即可部署，不积压
2. 变更前置时间（Lead Time for Changes）
含义：从代码提交到部署到生产的时间
AI 工作流场景：从任务开始到交付完成的总耗时
测量：
- commit → production 的时间分布
- 取 median 或 p90
效能等级：
Elite：< 1 天
High：1 天到 1 周
Medium：1 周到 1 个月
Low：> 1 个月
AI 工作流目标：
- M 级项目 < 3 小时
- L 级 < 8 小时
- XL 级 < 1 天
3. 变更失败率（Change Failure Rate）
含义：部署后导致问题需要紧急修复/回滚的比例
AI 工作流场景：交付后需要返工/回滚的比例
测量：
- 失败部署数 / 总部署数 × 100%
- 失败定义：服务降级、回滚、紧急修复
效能等级：
Elite：0~15%
High：16~30%
Medium：31~45%
Low：> 45%
目标：< 15%（门禁机制应该拦住大部分问题）
4. 恢复时间（Mean Time to Recovery / MTTR）
含义：服务出现故障到恢复正常的时间
AI 工作流场景：发现问题到修复完成的时间
测量：
- 从故障开始到完全恢复
- 取 median
效能等级：
Elite：< 1 小时
High：< 1 天
Medium：< 1 周
Low：> 1 周
AI 工作流目标：< 30 分钟
（AI 修复速度快，瓶颈在定位）
效能等级综合
所有 4 个指标都达标的层级：
Elite（精英）：
部署频率：按需多次
前置时间：< 1 天
失败率：0~15%
恢复时间：< 1 小时
High（高效）：
部署频率：日均到周均
前置时间：1 天~1 周
失败率：16~30%
恢复时间：< 1 天
Medium（中等）：
部署频率：周均到月均
前置时间：1 周~1 月
失败率：31~45%
恢复时间：< 1 周
Low（待改进）：
任一指标长期处于最低层
商业影响（来自 Accelerate）：
Elite 团队比 Low 团队：
- 50% 高的市场资本增长
- 2.5x 快的市场上市
数据收集
部署频率
来源：
- CI/CD 系统（GitHub Actions / Jenkins）的部署日志
- 容器/Kubernetes 的滚动更新记录
- Tag/Release 记录
AI 工作流：
- 每个功能模块完成的时间戳
- 工作流自动汇报"我完成了 X"的时间
前置时间
来源：
- Git commit 时间
- PR 合并时间
- 部署时间
AI 工作流：
- 任务进入 in_progress 的时间
- 任务进入 done 的时间
- 计算差值
失败率
来源：
- 部署失败的告警
- 回滚记录
- 紧急修复 commit
AI 工作流：
- 任务进入 rework 的次数
- 上线后的紧急修复次数
恢复时间
来源：
- 监控告警的开始/结束时间
- 故障单的处理时间
AI 工作流：
- 阻塞开始/解除时间
- 验收失败到修复完成
工作流程
1. 项目启动时：
- 确认要追踪的指标范围
- 设置基线（项目开始前的数据）
- 设置目标值
↓
2. 项目执行中：
- 自动收集每个事件的时间戳
- 不打扰执行流程
↓
3. 项目结束：
- 计算四大指标
- 与基线和目标对比
- 输出 DORA 报告
↓
4. 定期（季度）复盘：
- 对比多个项目的 DORA
- 识别改进方向
- 制定改进措施
DORA 报告模板
## DORA 效能报告 [项目名]
### 测量周期：[开始时间] ~ [结束时间]
### 四大指标
| 指标 | 当前值 | 基线 | 目标 | 等级 | 趋势 |
|------|--------|------|------|------|------|
| 部署频率 | 5 次/天 | 1 次/天 | 5+ 次/天 | Elite | ↑↑↑ |
| 前置时间 | 2.5 小时 | 8 小时 | < 3 小时 | Elite | ↑↑ |
| 失败率 | 12% | 25% | < 15% | Elite | ↑↑ |
| 恢复时间 | 25 分钟 | 2 小时 | < 30 分钟 | Elite | ↑↑↑ |
### 整体等级：Elite
### 关键发现
- 部署频率提升 5x（自动化 CI/CD 见效）
- 前置时间从 8h 降到 2.5h（并发编排起作用）
- 失败率减半（门禁机制有效）
- 恢复时间显著下降（监控告警完善）
### 改进建议
- 部署频率已 Elite，保持
- 前置时间还有空间，可以进一步优化联调环节
- 失败率从 12% 到 < 10% 是下个目标
- 恢复时间已优秀，不需要专门优化
### 下季度目标
- 部署频率：保持 5+ 次/天
- 前置时间：< 2 小时
- 失败率：< 10%
- 恢复时间：< 20 分钟
质量自检
□ 是否四个指标都测了（不能只看部署频率）
□ 是否设置了基线（不能凭空对比）
□ 是否设置了目标值（不能"越好越好"）
□ 数据来源是否客观（不是自己估算）
□ 报告是否有趋势分析（一次数据没意义）
□ 是否提出了具体改进建议
常见坑
- 只看速度指标——部署频率高但失败率也高，不是真效能
- 只看稳定性指标——失败率 0% 但一年才部署一次，不是好事
- 测量周期太短——一周数据不能下结论
- 没有基线——不知道是进步还是退步
- 指标 gaming——为了好看的数字牺牲实际质量
- 不行动——测了不改进，等于没测
- 指标用作 KPI 考核——会扭曲行为，DORA 是诊断工具不是 KPI
配套模板
templates/dora-report-template.md— DORA 报告模板templates/dora-tracking-template.md— 数据追踪表模板
与其他 skill 的协作
上游：
progress-tracking → 提供执行数据
milestone-gate → 提供门禁通过率
平行：
retrospective → 复盘时引用 DORA 数据
下游：
改进决策 → 影响下个项目的 wbs / orchestration / risk