效能不是看谁加班多
很多团队谈效能，最后变成比谁晚走、谁提的代码行数多。这其实量错了对象：真正该量的，是一个想法从提交代码到真正跑到用户面前，花了多久、顺不顺、出了事多快能恢复。
DORA 这套指标的思路，就是把抽象的「效能」拆成几个能从工具里直接采到的流动指标，让团队看见价值到底卡在哪。
效能度量的目的不是给人打分，而是找到流程里最慢、最脆的那一段。
本文核心知识点
- 部署频率多久能把一次改动送上线。
- 交付前置时间从提交到上线要多久。
- 变更失败率上线后出问题的比例。
- 恢复时间出故障后多久能恢复。
- 用在改进指标用来找瓶颈，不是考核个人。
DORA 四个指标在量什么
四个指标分成两组：一组量「快不快」，一组量「稳不稳」。单看快可能是带病狂奔，单看稳可能是不敢动，两个一起看才全面。
| 指标 | 含义 |
|---|---|
| 部署频率 | 单位时间成功上线多少次 |
| 交付前置时间 | 代码提交到上线要多久 |
| 变更失败率 | 上线后导致故障的比例 |
| 恢复时间 | 故障发生后多久恢复 |
频率高、前置短，说明流动顺；失败率低、恢复快，说明上线敢动也稳得住。
怎么把数据采上来
好消息是这些指标大多不用人肉统计，从流水线和版本管理工具里就能自动算出来。
# 指标从工具里取时间点
部署频率：统计流水线成功发布次数
前置时间：上线时间减去代码合并时间
变更失败率：导致回滚或事故的发布占比
恢复时间：故障开始到恢复的间隔
# 把这些时间点串起来，效能就可视化了。口径要先对齐：什么算一次「部署」、什么算一次「失败」，团队先达成一致再开数。
看懂瓶颈：慢在哪一段
拿到指标后，关键不是报一个总分，而是定位到底慢在哪一段。前置时间长，可能卡在评审排队，也可能卡在等待部署窗口。
| 现象 | 可能的瓶颈 |
|---|---|
| 前置时间长但频率低 | 改动攒成大批次才敢上 |
| 失败率高 | 测试与门禁没守住 |
| 恢复时间长 | 回滚和应急流程不熟 |
找到那一段，改进才有靶子，而不是笼统地喊「大家要更高效」。
用指标驱动改进，而不是考核人
效能度量一旦变成对个人的考核，数字就会开始失真——大家会想办法把指标做漂亮，而不是把流程做顺。
# 度量的正确用法
- 看团队层面的趋势，不追个人排名
- 把指标当改进线索，不是扣分项
- 改进后再量，看是否真的变快变稳
# 数字是仪表盘，不是鞭子。把指标用来卷人，它就会骗你；把它用来找瓶颈，它才会帮你。
常见误区：别被数字带偏
- 只追部署频率，一天发十几次却次次回滚，看似快实则乱。
- 把前置时间压到极短，却跳过了必要的测试与评审。
- 不同团队业务差异很大，直接比绝对值没有意义，看各自趋势更实在。
四个指标要组合着看，单独拎一个出来喊口号，很容易把团队带进沟里。
让效能持续变好
DORA 度量的最终目的，是让团队的交付流动随时间一点点变快、变稳，而不是一次性的体检。
- 指标自动采集，省去人肉统计的负担。
- 定期看趋势，定位并修掉最慢的那一段。
- 把改进落在流程上，而不是压在人身上。
当效能被持续度量、持续改进，团队就不必靠加班和焦虑来换交付速度。