DORA 指标实施反模式：如何避免正确实施 DORA

本文提供了一系列讽刺的建议，揭示了在实施 DORA 指标时可能遇到的陷阱和误区。如果读者能够反其道而行之，就可能会在使用 DORA 指标的过程中掌握软件工程的卓越实践。原文: How (Not) to Implement DORA Metrics

免责声明：很多时候，团队都怀着最美好的愿望试图改进工作。然而，如果团队不遵循数据驱动方法，那么大多数努力都是无用的。问题在于，由于我们所构建的系统具有复杂的非线性性质，那么 HiPPO、"最大声原则"、"专家意见"或"直觉"等方法通常都会失败。

本文代表了作者多年来在多家公司和多个团队中的错误改进经验，所有提到的情况都基于真实事件，只不过通过略微夸张的简要概括来呈现。

场景设定：领导层决定改变。出于某种原因，决定从你开始。

领导层在你的目标上加了一个奇怪的词："DORA"，并希望你把团队的软件交付绩效提高一倍甚至两倍。这是什么意思？你的战略是什么？下面有几条（错误的）建议，告诉你如何度过难关。但首先...

关于 DORA 的"真相"

DevOps 研究与评估（DORA，DevOps Research and Assessment）是一个正在运行的研究项目，任务是告诉我们应该如何正确开发软件，以及应该向管理层展示哪些数字才能让他们满意。

但站在 DORA 背后的人没有告诉我们的是，他们是极限编程和持续交付的隐秘支持者，他们想推广这些理念，却不知道如何推广。

您是否试过向持怀疑态度的管理层解释为什么要投资于测试自动化或解决技术债务问题？要解释测试驱动开发（TDD）、结对编程和部署自动化等方法为何有效更是难上加难。

起初，他们试图写书，在博客上推广简洁代码、重构等。每个人都读这些书，但没人真正使用。现在，他们又找到了一种方法--DORA 模型。如果你开始使用，很快就会做这些事情。

为了让研究看起来更扎实，他们运用统计方法找到了人们使用的不同能力与所谓的组织绩效之间的相关性。他们坚持认为，如果提高了这些能力，也就提高了交付绩效和组织绩效。这种进步应该通过以下指标来衡量：

• 部署频率（DF，Deployment frequency）：组织多长时间将代码部署到生产环境一次？

• 变更前置时间（LTFC，Lead time for changes）：从提交代码到代码投入生产运行需要多长时间？

• 变更失败率（CFR，Change failure rate）：有多大比例的生产变更会导致服务质量下降并需要补救？

• 恢复时间（TTR，Time to restore）：当发生影响用户的服务事故或缺陷时，一般需要多长时间恢复服务？

是否觉得服务部署频率对公司股票价格的影响并不明显？是的......不是只有你一个会这么想。但事实就是这样，不过别紧张，毕竟我们不是在学习造飞机。

"生产力是使公司更接近其目标的行为。使公司更接近其目标的每一个行动都是富有成效的。每一个不能使公司更接近其目标的行动都不具有生产力"。

不知何故，DORA 的衡量标准发挥了作用。作为工程组织，它们让我们对目标有了很好的认识。没有目标，我们所做的一切努力都是无用功。

那么，既然你对领导层的意图有了更多了解，该如何避免实施 DORA 指标呢？我的意思是，它们并没有那么有用，不是吗？

以下是我关于如何不执行 DORA 指标的指南。

技巧 #1. 说你没有时间

作为工程经理，你最重要的责任之一就是团队绩效。如果业绩长期很低，那么很不幸，除了你之外，没有人应该受到责备。因此，从长远来看，改进措施应该是你的首要关注点。

然而在短期内，可能会有关键任务。找件事情，一个可以归结为公司必须做的任务，等等。态度要非常积极，支持但要坚定。说你支持度量标准、DORA、海豚、熊猫......不管是啥。不幸的是，你和团队现在没有时间。

好在如果你坚持这样做，就会积累越来越多的紧急任务。因此，很快你就不会再为找不到任务而烦恼了。

领导可能会让你休息，今年就把你忘了。毕竟，他们可以专注于其他团队。否则，这一轮你就输了。

技巧 #2. 等待所有工具准备就绪

DORA 吞吐量指标（DF 和 LTFC）非常简单，易于收集。市场上有很多相关工具，甚至咖啡机都有可能为你收集所有指标。当然，可能需要采取一些措施来实现这一点。

DF 可从 Harness 等部署工具中获取。MR/commit 数据在 Gitlab 等工具中。需要将它们整合在一起，或者提取数据并在 Excel 表中手动连接。

你甚至可以手动操作。事实上，开始收集 DORA 指标时最好不要使用任何工具。这样你将获得更多理解和实践经验。

不过，你还是可以试试这一招。如果没有开箱即用的工具，建议等待。毕竟，你还有很多其他紧急任务要做。

技巧 #3. 永远不要改进代码

每个专业软件工程师都应该能够在第一次尝试时就写出 100% 正确的代码。对吗？

即使你在一个月后都无法识别自己的代码，也千万不要为了让代码更简单而多此一举。请记住，任何简化代码的尝试都会导致下一次有人试图修改代码时缩短 LTFC。

一个好主意是，改进代码时一定要征得产品经理的同意。他怎么知道你是否需要改进代码以使其更具可维护性？这难道不是你作为软件工程师的职业责任之一吗？这可能会让他非常困惑，并给你一个逃避的借口。

技巧 #4. 推动大量发布

要想每天多次按需部署到生产环境中，就需要不同的思维方式。

一种方法是一次性实现一个功能。开发一个功能，在几周内完成，推送一个 10,000 行的大型 MR 供代码审查，等待有胆量的人来审查，获得 LGTM，部署到 QA 环境，执行必要的测试，修复缺陷，最后推送到生产环境。

DORA 方法假定了一种不同的工作方式。开发人员应该分批交付任务。这意味着我们需要进行多次快速迭代：在一天左右的时间内编写修改代码，推送一个小的 MR，对其进行审核，将其部署到 QA 和生产部门（隐藏在特性标志下或通过抽象分支），并对其进行测试。

当功能准备就绪时，在 QA 环境中（甚至在生产环境中）开启该功能并进行端到端测试。当我们对功能的质量感到满意时，就会通过设置特性标志为客户启用该功能。DORA 指标更倾向于这种"持续交付"方法，因为在这种情况下，DF 和 LTFC 要好得多。

所以，一定要推动大型版本的发布。你可以说，对你来说，一次性开发出整个史诗，然后一次性进入 QA 阶段会更有效率。假设如果将功能拆分成许多小故事，所需的时间将是原来的两倍。

请记住，"持续交付"需要高度自动化和优秀的工程文化，如单元测试、重构、童子军规则等，所以要尽可能阻止它。

技巧 #5. 总是归咎于人为因素

爱德华-戴明曾经说过："一个糟糕的系统每次都会打败一个优秀的人"Walt88 Ch4。大多数改进机会都在于系统如何运作--规则、策略、协议、习惯等。

"一个坏的系统每次都会打败一个好的人"[E.Deming]

只要我们敢于分析过去的工作，通常就能获得这些数据。最简单的方法就是分析 LTFC 统计数据，找出最主要的制约因素。很可能会发现部署花费了太多时间。因此，可以实施部署自动化来加以改进。

很多时候，瓶颈在于异步代码审查。另一个好办法是分析任务的周期时间（从团队开始开发到部署到生产之间的时间），甚至不需要分析所有任务，只考虑每个月的异常值就会给我们带来很多启发。

下面是我们如何利用这一优势的一些建议。

首先，永远不要做回顾总结。或者尽量让回顾总结无用武之地。每隔一周安排一个小时，不要事先进行任何分析（LTFC 统计、异常任务分析等），不跟进。

其次，避免进行根因分析和以数据为导向的决策。只选最显而易见的，不做深入研究。对于任何问题，你总能找到"众所周知的解决方案--简洁、合理、错误"H.L. Mencken。如果发生了生产事故，建议实施端到端测试。如果发布很痛苦，那就决定减少发布频率。

"人类的每一个问题总有一个众所周知的解决方案--简洁、合理、错误"[H.L. Mencken]。

第三，任何根因分析都要尽量归结为人为因素。有人造成了这种情况，对吗？

技巧 #6. 只推广端到端测试策略

查看任何回归缺陷事件，开始根因分析，让每个人都同意，如果有端到端测试涵盖这个确切场景，那就会在部署到生产之前就发现这个错误。这是一个很难被击败的坚实论据，因此通常都能奏效，而且这实际上是正确的。

"好的想法往往会在实践中失败，而在测试领域，有一个普遍存在的好想法往往会在实践中失败，那就是围绕端到端测试建立的测试策略"。[Wack]

诀窍在于端到端测试既慢又脆弱。因此，如果你试图用端到端测试覆盖所有可能的情况，那么很快你的团队就会被拖垮。每次部署都要花费数小时，每个人都会不惜一切代价批量部署或避免部署。DF 和 LTFC 将会下降，不过这正是我们所需要的，不是吗？

但也有一些注意事项。

首先，确保测试在共享的 QA 环境上运行。用它的团队越多越好，这样你甚至不用太费心，就能让测试变得不稳定。

其次，建议在端到端测试中包含尽可能多的不同服务，最好是来自不同团队的服务，或者最好是来自不同公司的服务。尽管每个团队肯定都工作得很好，而且他们很少破坏测试，但如果有许多团队参与其中，就会增加脆弱性。

第三，拒绝任何用低级测试（尤其是单元测试）替代高级测试的尝试。想象一下你有两个组件，一个组件通过外部 API 接受用户请求，进行一些处理后调用第二个组件。第二个组件处理请求并返回响应。

假设这些组件中有 10 个可能的执行路径。这意味着要测试整个系统，需要编写 10x10=100 个测试。你可以用第一个组件的 10 个单元测试、第二个组件的 10 个单元测试和几个"集成"测试来代替。但这样会减少测试的数量和执行时间，并提高稳定性！因此，请避免这样做。

技巧 #7. 追求 100% 的可靠性

质量的含义各不相同。可用性、延迟和耐用性等被称为可靠性指标。SRE 一书指出，试图达到 100% 的可靠性是没有意义的。首先，到了一定程度后，用户就不会在意了，因为可靠性对他们来说已经足够好了。其次，极端可靠性是有代价的。每多一个"9"，就需要付出成倍的努力。

干扰任何采用基于风险的可靠性方法的尝试。完全不要从客户角度来定义 SLO，或尽可能严格定义 SLO，始终以 99.99+% 为目标。

即使产品对延迟的要求较宽松，也要添加分布式缓存以优化延迟。坚持在 QA 环境和生产环境中使用金丝雀，并在每个步骤中进行手动验证。假装这样做是为了提高可用性（不收集任何统计数据也没关系），并可以将增加更改系统的难度。人们会尝试批量部署，以减少部署的频率。

技巧 #8. 忽略文档

R.Martin 认为，任何专业人士都应对自己的职业生涯负全责。你应该了解本行业的所有基础知识和最新进展。雇主是根据工作时间来支付工资的，而不是根据你学习基础知识的时间来支付工资。然而，许多雇主确实关心这一点，并尽可能帮助员工成长。这是一种恩惠，而不是一种义务CleanCoder。

所以，要尽可能动。他们雇用了你，对吗？现在他们应该关心你的学习之路了。与其阅读和学习新技术、新方法或新概念，不如坐下来放松一下，直到在工作中需要为止。掌握的知识越少越好。

尤其要避免阅读以下书籍：

• E.Goldratt 的 目标（超级不推荐）

• Gene Kim 的 凤凰项目、独角兽项目、DevOps 手册
  

• N. Forsgren 的 加速
  

• D. Reinertsen 的 The Principles of Product Development Flow
  

• D.Andersen 和 A. Zheglov 合著的 Fit for purpose
  

• M. Kleppman 撰写的 数据密集型应用系统设计
  

• M.Fowler 的 重构
  

• R. Martin 的 简洁代码、简洁架构、程序员的职业素养
  

• M. Skelton 的 高效能团队模式
  

• K. Leopold 的 实用看板
  

• D. Vacanti 所著的 可操作的敏捷可预测性指标
  

就是这样！这就能最好的避免执行 DORA 指标。

当然，如果你选择忽略上述提示，或者采取与提示完全相反的做法，那么可能会发现自己正走在利用 DORA 指标掌握卓越软件工程的道路上。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！