2. DORA 四指标详解：部署频率、变更前置时间、变更失败率、故障恢复时间

DORA（DevOps Research and Assessment）团队经过多年实证研究，提炼出四个核心指标来量化软件交付与运维效能。这四个指标从速度（部署频率、变更前置时间）和稳定性（变更失败率、故障恢复时间）两个维度，共同构成团队效能评估的基础框架。本章将逐一拆解每个指标的定义、计算方式、理想区间及常见误区。

2.1 四指标全景概览

下表从核心关注点、度量单位、理想方向三个维度对四指标进行横向对比，帮助建立整体认知：

2.2 部署频率（Deployment Frequency）

部署频率衡量团队向生产环境发布代码或配置的频率。它是交付速度最直观的体现。

• 计算方式：在选定时间窗口（如一个月）内，成功部署到生产环境的次数。
• DORA 效能分组参考：
  • 精英（Elite）：按需部署（每日多次）
  • 高（High）：每日一次至每周一次
  • 中（Medium）：每周一次至每月一次
  • 低（Low）：每月一次至每半年一次
• 常见误区：只统计“上线”次数，忽略配置变更、数据库迁移、功能开关切换等非代码部署。建议将任何对生产环境产生影响的变更都纳入统计。

2.3 变更前置时间（Lead Time for Changes）

变更前置时间度量从代码提交（Commit）到该代码成功运行在生产环境（Deploy）所经过的总时间。它反映了从“想法”到“交付”的管道效率。

• 计算方式：生产部署时间戳 - 代码合并/提交时间戳。通常取中位数或百分位数（P50/P90）以消除极端值影响。
• DORA 效能分组参考：
  • 精英：小于 1 小时
  • 高：1 天至 1 周
  • 中：1 周至 1 个月
  • 低：1 个月至 6 个月
• 常见误区：仅计算 CI/CD 管道运行时间，忽略了代码审查、环境等待、人工审批等阻塞环节。真正的前置时间应包含所有等待队列时间。

2.4 变更失败率（Change Failure Rate）

变更失败率是衡量稳定性的核心指标，也是本课程联动建模的锚点。它定义为导致服务受损（如性能下降、功能不可用、回滚、热修复）的部署次数占总部署次数的比例。

• 计算方式：（导致故障的部署次数 / 总部署次数）× 100%。
• DORA 效能分组参考：
  • 精英：0% - 5%
  • 高：5% - 10%
  • 中：10% - 15%
  • 低：15% - 30%
• 常见误区：仅统计严重 P0 故障，忽略轻微性能退化、错误率上升、功能降级等“软失败”。建议将任何触发告警或需要人工介入的部署都标记为失败。

2.5 故障恢复时间（Time to Restore Service）

故障恢复时间衡量团队从故障中恢复服务的能力，体现了系统的韧性和可恢复性。DORA 强调“恢复时间”而非“修复时间”，因为恢复手段可以包括回滚、流量切换、功能降级等，不一定是代码修复。

• 计算方式：从故障告警触发（或用户首次报告）到服务完全恢复正常的时间。
• DORA 效能分组参考：
  • 精英：小于 1 小时
  • 高：1 小时至 1 天
  • 中：1 天至 1 周
  • 低：1 周至 1 个月
• 常见误区：只计算“代码修复”时间，忽略了故障发现、告警延迟、团队响应、环境准备等环节。建议使用MTTR（Mean Time to Recover）作为统计口径。

2.6 四指标联动关系图

下图展示了四个指标之间的内在联动关系，以及它们如何共同构成“速度-稳定性”平衡模型：

2.7 指标采集与数据建模要点

在实际建模前，需要明确每个指标的数据来源和采集粒度。下表总结了推荐的数据源和常见陷阱：