首页/开发/代码质量与评审速查/DORA 四指标:交付效能度量
技术债与度量63 条

DORA 四指标:交付效能度量

DORA(DevOps 研究与评估)用四项指标刻画交付效能:部署频率、变更前置时间、变更失败率、故障恢复时间;指标用于团队效能与流程改进,不适合个人考核。

DORA 四指标是什么

DORA 用四项指标刻画交付效能:部署频率、变更前置时间、变更失败率、故障恢复时间。它衡量的是团队交付系统的能力,适合用于流程改进与趋势观察;用作个人考核会立刻失真,因为这些指标取决于协作方式,而不是某个人的产出。

基本信息

四项指标部署频率、变更前置时间、变更失败率、故障恢复时间
指标属性两项偏吞吐,两项偏稳定性
数据来源CI/CD 事件记录与事故记录
使用方式团队层面看趋势,不做个人排名
前提条件先对齐口径,再开始统计

典型使用场景

  • 季度回顾时评估交付流程改进效果
  • 定位瓶颈是在前置时间还是恢复速度
  • 改造流水线前后做对照
  • 与业务指标结合,说明工程投入的实际影响
  • 团队之间交流实践,而不是排名比较

采集提示

采集提示
部署频率:单位时间的部署次数(CI/CD 事件)
前置时间:提交到上线的时长(流水线时间戳)
变更失败率:引发故障或回滚的变更占比(事故标记)
恢复时间:故障发现到恢复的时长(事故记录)
# 口径先对齐:什么算一次部署、什么算一次事故

四指标读法

指标含义观察方向
部署频率单位时间的部署次数吞吐能力
前置时间提交到上线的时长流动效率
变更失败率引发故障的变更占比稳定性
恢复时间故障到恢复的时长响应能力
四项指标要成对看:只追部署频率会牺牲稳定性,只看失败率会让人不敢发布;两两组合才能看出真实的权衡关系。
用 DORA 做团队排名,指标会立刻被博弈:把大变更拆成多次小部署、把事故标注成别的问题,趋势从此失去参考价值。
指标之间要能相互解释:部署频率上升而前置时间没降,说明等待发生在评审或测试环节,而不是发布环节,改进方向也随之明确。

易错点

  • 用 DORA 做团队排名:指标被博弈,行为扭曲
  • 口径不统一:统计差异让趋势失真,横向对比没有意义
  • 只追部署频率:稳定性下降,故障成本转移到运维
  • 数据全靠人工填报:记录不完整,趋势断断续续

数据来源与参考

  • DORA(DevOps Research and Assessment)年度报告与研究(《Accelerate》)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌