四指标是什么
DORA 四项指标衡量软件交付效能：部署频率、变更前置时间、变更失败率、故障恢复时间。前两项反映吞吐能力，后两项反映稳定性；只看单项会跑偏——部署快但失败率高等于无效加速。指标来自 CI/CD 与事故记录的自动采集，手工填报的数字撑不起改进。
基本信息
| 部署频率 | 单位时间内成功部署到生产的次数 |
|---|---|
| 变更前置时间 | 代码合并到生产部署的时长，取中位数 |
| 变更失败率 | 引发故障或需要回滚的部署占比 |
| 故障恢复时间 | 从故障开始到服务恢复的时长，取中位数 |
| 数据来源 | 流水线记录、事故单、回滚记录，自动采集优先 |
| 对照组 | 吞吐指标与稳定指标要成对看，单升单降都是信号 |
口径与常见误用
| 指标 | 口径 | 误用 |
|---|---|---|
| 部署频率 | 成功进入生产的部署次数 | 拆小提交刷次数 |
| 前置时间 | 首次提交到上线 | 用发布单创建时间代替 |
| 失败率 | 造成故障或回滚的占比 | 事故不记录导致低估 |
| 恢复时间 | 故障到恢复的时长 | 抢修不计时长自欺欺人 |
典型使用场景
- 季度效能复盘：四条线一起看，定位吞吐与稳定的失衡点
- 平台改造前后对照：流水线或自动化投入的收益量化
- 瓶颈定位：前置时间长说明评审或排队环节积压
- 与业务指标联动：上线频率与业务迭代速度互相印证
- 团队对标：先统一口径再比，避免鸡同鸭讲
口径先定后比：同一团队跨期比较最有意义；团队间比较前先统一统计边界，否则数字没有可比性。
用指标考核个人会诱发博弈：拆小发布刷频率、抢修不记录缩短恢复时间，指标用于改进流程而非评判个人。
前置时间的起点是「首次提交」不是「发布单创建」：起点选错会把等待时间藏起来，改进方向随之跑偏。