首页/开发/CI/CD 与发布速查/DORA 四项交付指标
质量门禁与回滚51 条

DORA 四项交付指标

DORA/Accelerate 研究提出的四个交付效能指标,分速度与稳定性两组:部署频率、变更前置时间、变更失败率、恢复时长;看趋势与短板而非单点数字。

CI/CD 与发布速查开发更新于 2026-10-13

DORA 四项指标是什么

DORA 研究(《Accelerate》)提出的四个交付效能指标,分速度与稳定性两组:部署频率、变更前置时间、变更失败率、恢复时长。用法上应看趋势与短板,而不是单点数字或横向排名;四项一起观察,只追速度会牺牲稳定性,只追稳定会拖慢反馈。数据来源尽量自动采集(流水线与事件系统),避免手工填报带来的美化与遗漏,采集口径要先定义清楚再开始。

基本信息

速度组部署频率、变更前置时间
稳定组变更失败率、恢复时长
数据来源流水线与事件系统自动采集
用法看趋势与瓶颈,避免用作单一考核
定位要求指标变化要能落到具体环节(排队、测试、审批)

口径速记

口径速记
部署频率      = 单位时间成功部署到生产的次数
变更前置时间  = 提交到在生产中运行的时长
变更失败率    = 需修复的部署 / 总部署
恢复时长      = 故障开始到恢复服务(含修复发布)

典型使用场景

  • 度量现状:先采集基线,理解四项指标当前的分布与波动。
  • 找瓶颈:部署频率低是审批还是自动化不足;前置时间长是排队还是测试慢。
  • 改进验证:流程改动后用指标验证效果,而不是凭感觉判断。
  • 稳定性治理:失败率与恢复时长暴露回滚通道与监控的短板。
  • 对齐方向:用统一口径与管理层沟通投入优先级。
  • 防误用:不把四项做成个人绩效排行,数据会被美化,诊断价值丧失。
四项一起看:只追速度会牺牲稳定性,只追稳定会拖慢反馈,速度与稳定性需要同时观察。
口径先定义再采集:前置时间从提交算还是从合入算、恢复时长是否包含修复发布,口径频繁变更会让趋势断裂。
指标用于改进而非考核:用作个人绩效会激励规避行为(拆小发布凑数、隐瞒失败),与改进初衷相反。

易错点

  • 口径频繁变更:趋势线断裂,无法纵向比较,改进效果无法验证。
  • 把指标当个人绩效:数据被美化,诊断价值丧失。
  • 只优化单项:部署频率上去但失败率同步上涨,四项要联动观察。
  • 手工填报数据:漏报与美化几乎必然,尽量自动采集。
  • 不拆前置时间构成:排队、评审、测试各占多少不清楚,改进没有着力点。

数据来源与参考

  • DORA《Accelerate State of DevOps Report》
  • Forsgren/Humble/Kim《Accelerate》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌