2.10 DORA指标框架

概述与动机

DORA指标来自DevOps研究与评估项目，一项历时多年的研究工作，后来以Nicole Forsgren、Jez Humble与Gene Kim合著的《Accelerate》一书出版，调查了数万名工程专业人士，以找出哪些交付实践与组织绩效相关。结果得出四项指标，两两配对：部署频率与变更交付周期衡量速度；变更失败率与故障部署恢复时长（常简称为平均恢复时间，MTTR）衡量稳定性。让这个框架具有重要意义的研究发现是，顶尖表现者能够同时做到快速与稳定，推翻了速度与安全必然相互取舍的假设，而这一发现至今仍是本书对主题 1.2 配对原则最清晰的实例：一项被激励的速度指标，配上一道稳定性护栏，正是表现最好的组织实际在做的事。

本书在这一部分把DORA放在最后讲，这是刻意的安排，而不是把它当作本部分的组织框架。这种安排不是在否定这项研究，它依然是真正严谨、值得使用的。它反映的是一个具体而真实的局限：DORA衡量一条流水线移动得有多快、有多安全，但它对流水线中正在流动的究竟是什么保持沉默。一个团队可能拿出优秀的DORA数字，同时其实际产出已经悄悄地偏向了缺陷返工，或者让技术债务和安全工作的产能被挤占，这正是主题 2.1 至主题 2.4 的流动框架专门用来揭示、而DORA看不见的模式。按本主题所呈现的方式使用DORA：一种经过良好验证、范围较窄的流水线机制参考指标，而不是交付健康的全貌。

对大团队而言，DORA留存下来的真正价值是可比性。一项从流水线和事件数据中一致计算出来的指标，能让一个组织跨越许多在不同领域工作的团队比较交付能力，而不会陷入困扰大多数跨团队比较的鸡同鸭讲问题。企业组织仍然用它来为平台投资排定优先级；政府组织仍然用它以证据证明一项现代化项目在可衡量的意义上改善了交付机制。把这当作DORA恰当的、有边界的职责，并用本部分前面的流动框架各主题来回答那个更宽泛的问题：交付的究竟是不是正确的东西。

核心原则

DORA衡量的是流水线，而不是流经它的价值。 主题 2.1 直接点出了这个缺口；用流动分布（主题 2.3）来看DORA看不见的东西。
速度与稳定性要一起衡量，绝不能分开衡量。 一份只有一半、缺少另一半的DORA仪表盘，并不算真正在使用这个框架。
定义的一致性比原始数字本身更重要。 一个团队在一致定义的指标上从”中等”进步到”高”绩效，是一个真实的信号；用不同方式计算出来的两个团队互相比较，则不是。
DORA衡量的是系统，而不是个人。 把这些指标应用到具体工程师身上，会破坏框架的统计基础，并招致主题 1.2 所警告的那种操纵。
全部四项指标都是代理指标，而不是目标本身。 它们与组织绩效相关；追逐数字本身，脱离真正的交付改善，就违背了这个框架的初衷。

建议

从流水线埋点部署频率，只计入生产环境发布

部署频率衡量一个团队成功发布到生产环境的频次。只计入成功的生产环境部署，从CI/CD流水线数据自动埋点，绝不自我报告。要专门留意替代性操纵：把一项有意义的变更拆分成若干次微不足道的部署，纯粹为了推高计数，方法是把部署规模与频率并列跟踪：平均规模在缩小、计数却在上升，是这种情况正在发生的最清晰迹象。

从首次提交到生产环境部署埋点变更交付周期

变更交付周期衡量从一次代码变更的首次提交，到它成功部署至生产环境之间的时间。既报告中位数，也报告一个高百分位数，而不只是均值，遵循主题 1.6 关于偏态时间型数据的指导，并留意任一端点上的定义漂移，那会在没有任何真正改善的情况下让数字变得好看。

在跨团队比较之前，把变更失败率的定义写下来

变更失败率衡量导致需要补救、回滚、热修复或一次事件的部署所占的百分比。这是四项指标中最难被一致定义的，因为”失败”并非不言自明地客观。在比较团队之前先就一个书面定义达成一致；没有它，一个看起来公平的比较可能会严重误导人。留意那种没有任何底层流程变化支撑、却快得可疑的改善，这是定义被操纵、而不是真正进步的最清晰迹象。

从发现时刻起，而不是从部署事件起测量恢复时长

故障部署恢复时长衡量一次部署导致故障后，恢复服务所需的时间。把计时起点定在发现时刻，而不是部署事件本身，这样这个数字反映的才是真正的恢复延迟，而不是一个监控盲区。专门投资于自动化回滚能力，这是真正改善这项指标、而不是靠过早宣布事件已解决来改善它的最常见杠杆。

用流动指标而不是DORA来诊断一个数字为什么变动

当一项DORA指标发生变动时，这四个数字本身很少能解释原因。把周期时间分解（主题 2.6）、流动负载（主题 2.4）和流动分布（主题 2.3）用作DORA摘要数字下方的诊断层，并且绝不要在个人绩效评估中使用DORA指标，这是这个框架所暴露出的、破坏性最大的一种滥用。

权衡取舍：利与弊

方案	优点	缺点
完整的DORA框架，四项指标全部配对	经过研究验证，通过配对抵御操纵，能实现公平的跨团队比较	对交付的是什么类型的价值保持沉默；需要与流动框架并用才能看清这一点
把DORA作为本部分唯一的组织指标集	简单，大多数工程领导都熟悉	完全遗漏了价值构成问题，这正是本书在此处把它排在后面的原因
DORA与流动框架并用	流水线机制与价值构成都可见	需要同时维护两套指标词汇，而不是一套
把DORA应用到个人层面	对一些管理者而言感觉直接可操作	破坏框架的统计有效性；面临强烈的古德哈特定律风险

核心张力在于机制上的严谨与业务上的可读性之间。DORA的四项指标定义精确、经过研究验证，这使它们非常适合跨团队比较流水线绩效，但同样的这种精确性把范围窄窄地限定在流水线本身，对流经它的究竟是不是正确的工作只字不提。解决这种张力的办法，是把DORA保留为流水线健康状况的参考层，这正是主题 2.10 在本书结构中恰当的位置，同时用本部分前面的流动框架各主题来回答那个面向业务的价值构成问题，而不是试图让DORA去回答一个它从来就不是为之设计的问题。

与团队讨论的问题

我们是从流水线埋点全部四项DORA指标，还是其中一些是自我报告的估计值？ 一个建立在客观、经过研究验证的测量之上的框架，一旦某个数字变成了最佳猜测，就会失去大部分价值。审计每项指标真正的数据来源（主题 1.5）。
我们用DORA指标来比较的所有团队，是否共享相同的部署、变更与失败定义？ 用不同定义的团队之间的比较，并不算真正的比较，还可能对相对绩效产生不公平的判断。
我们组织中是否有人曾经在个人绩效评估中使用过DORA指标，无论正式还是非正式？ 这是这个框架破坏性最大的一种滥用，而且往往悄悄发生。直接去问，并做好准备接受一个不舒服但必要的答案。
我们的DORA数字会不会表现优秀，而我们的流动分布（主题 2.3）却已经悄悄偏向了返工或远离了功能开发？ 这正是DORA单独一项无法看见的缺口。把两组数字放在一起，检查它们讲述的故事是否一致。
当我们某一项DORA指标发生变动时，我们是否拥有能解释原因的流动指标诊断能力？ 一个DORA数字单独只能告诉你有什么东西变了，而不能告诉你是什么变了。检查你的团队能否用数据、而不只是靠猜测来回答”这个月交付周期为什么变长了”。
如果我们刻意去操纵每一项DORA指标，我们的四个数字会如何变化，我们会注意到吗？ 逐一走一遍部署频率、交付周期、变更失败率与恢复时长，这是把主题 1.2 的核心纪律应用到这个具体框架上的实践。

行业视角

初创公司。 对一个已经在频繁部署的小团队来说，DORA的速度指标通常来得很自然；更难的自律，是诚实地为变更失败率和恢复时长做埋点，而不是仅仅因为还没出过大问题就假定一切稳定。及早把DORA与哪怕只是非正式的流动项拆分（主题 2.2）配对，能避免围绕单纯的流水线速度建立起一种虚假的交付健康感。

小型企业。 大多数现代CI/CD和版本控制平台只需最少的设置，就能导出部署频率和交付周期数据；把部署与事件关联起来以计算变更失败率，通常需要更多的人工努力。先从两项速度指标做起，一旦有了可供关联的非正式事件日志，就加上稳定性跟踪。

企业。 在这个规模上，DORA留存下来的最大价值是为平台投资决策提供公平、一致的跨团队比较。在全组织范围内统一定义（主题 1.4），集中自动化埋点，并让每一份DORA报告都与一份流动分布视图配对，这样领导层才能同时看到流水线速度和价值构成，而不是只看其中一个。

政府。 DORA指标仍然为一项现代化项目提供了一种可辩护的、有研究支撑的方式，向监督机构证明交付机制得到了改善。四项指标一起报告，绝不只挑好看的那一半，并把它们与流动分布配对，这样报告也能回答那个更难、更重要的问题：更快的流水线实际交付的究竟是什么。

案例

企业。 一家大型电信公司的平台现代化项目在四十个产品团队中一致地为全部四项DORA指标做了埋点，并在十八个月内呈现出从低绩效到高绩效梯队的真实跃升：部署频率提高了约十倍，交付周期从数周缩短到数天，变更失败率保持平稳。一位董事会成员在审阅报告时，提出了一个DORA数字本身无法回答的问题：这种更快的交付中，有多少是新的客户价值，又有多少是返工。工程组织当时没有答案，直到下一季度采用了流动项分类，结果显示，即使在DORA速度数字改善的同时，功能开发工作在总产出中所占的份额实际上下降了，这一发现重塑了该项目下一年度的优先事项。

政府。 一个州政府的IT现代化办公室把DORA指标定为合同条件，用来比较几个竞争供应商团队的交付能力，这是对这个框架可比性的一次有效运用。一旦要求同时提供变更失败率，一个供应商的高部署频率就被揭示出与近乎其同行三倍的失败率相关，这一信息直接影响了该办公室的合同续约决定。该办公室后来在这些合同中又加入了流动分布要求，因为发现DORA数字最好的那家供应商，恰恰也是在合同明确要求的安全补救工作上投入产能份额最小的一家。

商业理由：动机、投资回报与总拥有成本

在恰当范围内把DORA用好所带来的回报，是对”我们的交付流水线是否正在变得更快、更安全”这一问题给出一个可辩护的、基于证据的答案，而这仍然是工程领域中能够较有把握回答的问题之一。这个答案能用真实数字为平台和工具投资辩护，并让领导层在公平、一致的基础上比较相互竞争的投资，一如既往。

总拥有成本在于把部署事件与事件记录关联起来以计算变更失败率和恢复时长所需的集成工作，这在一个庞大、异构的工具生态中并非小事。把DORA与本部分前面的流动框架各主题配对所增加的成本相对较小，因为流动项分类是叠加在现有工作之上的一种报告惯例，而不是一套平行的测量系统，而它带来的回报，恰恰是捕捉到上面那个电信案例所展示的价值构成盲区，完全值得这份不大的额外投入。

反模式与陷阱

把DORA当作交付健康的全貌： 这正是本主题的编排顺序所要防范的操纵向量。一个组织可能呈现出真正优秀的DORA数字，快速、频繁、稳定的部署，与此同时其实际交付的价值已经悄悄转向了返工或远离了功能开发，而DORA的四项指标单独永远不会揭示这种转变，因为它们从来就不是为衡量这个而设计的。护栏就是让每一份DORA报告都与流动分布（主题 2.3）配对，这样一条快速、稳定却交付了错误工作构成的流水线才会被看见，而不是被误认为是真正的交付健康。
只报告DORA的速度那一半： 违背了这个框架的核心发现，即速度与稳定性在顶尖表现者身上是同步变动的。
在个人绩效评估中使用DORA指标： 破坏框架的统计有效性，并招致强烈的操纵。
用不一致的定义比较团队： 产生看起来公平、实际上并不公平的比较。
用自我报告的DORA数字代替流水线埋点的数字： 引入了这个框架本应消除的那种偏差。
把DORA当作诊断工具而不是摘要工具： 使团队在没有底层流动指标层的情况下无法解释一个数字为什么变动。

成熟度模型

第一级，启动： DORA指标如果有被跟踪的话，也是自我报告的、定义不一致的，且从未与流动数据配对。
第二级，发展： 一些团队从流水线为DORA埋点，但定义各不相同，也没有流动分布作为对照。
第三级，标准化： 全部四项DORA指标都从流水线和事件数据中一致地埋点，采用共享定义，并常规地与流动分布一并展示。
第四级，管理： DORA与流动指标在组织的每个层级都作为标准配对一并审阅，且DORA从不用于个人评估。
第五级，协奏： 组织能够指出具体的案例，说明流动分布捕捉到了一个仅靠优秀DORA数字本会被掩盖的价值构成问题，并有意识地用这两个框架分别回答各自能回答的问题。

讨论思路

我们目前的四项DORA指标，老实说把我们放在绩效梯队的哪个位置？
我们的DORA数字会不会看起来优秀，而我们的流动分布却已经悄悄偏移？我们检查过吗？
有没有人曾经用一个DORA数字来评判个人，哪怕只是非正式地？
如果一个竞争对手公布了它的DORA数字，我们的数字相比之下会好看吗，而这种比较真的能告诉我们谁交付了更多真实价值吗？

要点回顾

DORA的四项指标，部署频率、交付周期、变更失败率与恢复时长，按设计把速度与稳定性配对，并且仍然经过真正的研究验证。
本书把DORA放在本部分最后，因为它衡量的是流水线，而不是流经它的价值；把它与流动分布（主题 2.3）配对才能得到更完整的图景。
本主题的核心操纵向量是把优秀的DORA数字误认为完整的交付健康；护栏始终是让DORA与流动分布一并报告。
绝不要在个人绩效评估中使用DORA指标；这个框架的有效性依赖于系统层面而非个人层面的测量。
当某一项DORA指标发生变动时，把流动指标用作底层诊断层。

参考文献与延伸阅读

Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Google Cloud. DevOps研究与评估项目。dora.dev。
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016.
Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.