DORA 四项指标
DORA 四项指标来自 Google Cloud 的 DevOps 研究与《Accelerate》一书，用两组指标衡量软件交付效能：速度组是部署频率与变更前置时间，稳定性组是变更失败率与故障恢复时间。研究结论是这四项可以同时改善——高绩效团队并非用稳定性换取速度。指标应自动采集、按团队或服务看趋势，用于改进讨论，而不是个人排名。
基本信息
| 来源 | DORA 年度报告与《Accelerate》 |
|---|---|
| 速度组 | 部署频率、变更前置时间 |
| 稳定性组 | 变更失败率、故障恢复时间 |
| 采集方式 | 从流水线、版本库、事件系统自动采集 |
| 观察粒度 | 团队或服务维度看趋势 |
| 反模式 | 手工统计、个人排名、与奖金挂钩 |
典型使用场景
- 交付能力体检：四个指标一起看，判断短板在速度还是在稳定性
- 改进立项：前置时间长的团队先优化评审等待与流水线耗时
- 平台工程验收：自助平台上线前后对比指标，验证是否真的降低认知负荷
- 管理者沟通：用趋势与行业基线与业务方对齐交付预期
- 复盘联动：故障恢复时间恶化时，回到事件管理与演练环节找原因
采集与解读要点
采集与解读要点
部署频率：统计生产环境部署事件，不含测试环境
变更前置时间：代码提交合并到生产运行，看中位数与 P95
变更失败率：导致降级、回滚或热修的生产变更比例
故障恢复时间：影响产生到服务恢复，口径与事件管理一致
建议按季度看趋势，不纠结单周数字波动四项指标对照
| 指标 | 定义 | 维度 | 改善抓手 |
|---|---|---|---|
| 部署频率 | 单位时间部署到生产的次数 | 速度 | 减小批次、主干开发、部署自动化 |
| 变更前置时间 | 从代码提交到生产运行的时间 | 速度 | 缩短评审等待、并行测试、提高自动化程度 |
| 变更失败率 | 导致故障需修复的变更比例 | 稳定性 | 自动化测试、灰度发布、可回滚设计 |
| 故障恢复时间 | 故障发生后恢复服务的时长 | 稳定性 | 监控覆盖、一键回滚、演练与值班机制 |
用手工统计或只统计部分流水线，会让指标系统性偏乐观；采集应覆盖全部生产部署路径，包括紧急变更与手工操作。
行业基线与分档在 DORA 报告中逐年更新，可引用其报告口径；但报告结论是组织级相关性，不可直接当作个人 KPI。
四项指标之间会互相影响：只压部署频率不提自动化，变更失败率往往上升；同理，只提高单测覆盖率而不缩短流水线耗时，前置时间不会改善。
数据来源与可信度
指标可信度取决于采集链路：部署事件来自流水线记录，前置时间来自版本库提交时间与部署时间，失败率与恢复时间来自事件系统。三处时间戳要对齐时区与口径，否则同一件事在不同报表里会得出不同结论。上线初期可先人工核对一个月，确认自动采集与实际情况一致后再对外发布。
基数小的团队单周波动很大，指标宜按季度滚动窗口看趋势，并与业务指标一起解读，避免为了平滑曲线而频繁改口径。