您是否按预期使用 DORA 指标？ 谷歌说你可能不知道。
翻译自 No Nica Mellifera 的 The Wrong Way to Use Dora Metrics。 近年来，有许多声音支持使用 DORA 指标来衡量组织内开发人员支持的有效性：您的平台工程、运营和开发人员体验工作是否真的使开发人员更容易交付新功能和维护服务。 这五项指标（比2020年原始报告中的四项指标更全面）包括：部署频率— 您的组织成功将新版本推送到生产环境的频率。
更改提前期— 从提交到上线到上线投入生产所需的时间。
更改失败率— 导致生产环境失败的部署百分比。
服务恢复时间— 组织从生产环境中的故障中恢复所需的时间。
可靠性— 更广泛地评估可用性、延迟、性能和可扩展性等方面，以表示运营性能。
我同意，衡量这些指标对于了解您的团队是否能够有效地交付软件至关重要。 但重要的是要明确，这些指标旨在提供团队软件交付的指标，而不是对招聘或解雇团队领导等高风险决策做出决策的硬性指标。 虽然这个目标一直很明确，但最初的指标报告要求领导层判断一个团队是否“表现出色”，并强烈暗示表现更好的团队的DORA指标也会更好。 DORA指标是显示进展的有趣统计数据，或者是代表团队成败的关键统计数据，两者之间的冲突导致了对DORA指标的极端态度。 事实上，DORA 指标可以作为开发人员体验健康状况的有力预测指标，但与任何观察到的统计数据一样，信息可能会被滥用和误解。
应明确区分高风险和低风险指标。 这种区别不是我建议的，而是源自 Mordecai 关于该主题的精彩文章：“当指标风险较小并且留在团队中时，它们是有益的。 它们由受其影响的人提出、监控和采取行动。 这就是诊断或改进范式。
另一方面，当指标有风险时，它就是问责制范式。 在这里，指标和指标不一定用于改进或识别问题，而是用于确保人们正在做他们应该做的事情。 ”
虽然包括我自己在内的许多作者都鼓励领导层使用 DORA 指标来评估团队的开发速度和部署难易程度，但它们可能会被滥用，导致优化不佳甚至适得其反的动机。
当我在 Slack、Reddit 和 Discord 上的平台工程社区中分享关于如何衡量和计算 DORA 指标的最后一篇文章时，我经常收到强烈的反馈，例如“我讨厌 DORA 指标”。 更深**这种感觉，反馈来自太多指标被误用和误解的经历。 以下是滥用 DORA 指标或任何高度关注性能指标的方法的五种方法。
团队致力于实现绩效指标，而不是业务目标。
许多组织过分关注四个主要的 DORA 指标（部署频率、更改上线时间、更改失败率和服务恢复时间）。 这种关注的危险在于我们忽视了组织的目标。 这可能导致忽视其他关键方面，例如组织绩效、团队动态、可靠性、倦怠、生产力和工作满意度。 在Platform Engineering Slack的一次对话中，Bryan Ross说得好：“与我合作的许多团队都有很多显示结果的指标，但他们无法以'企业'的方式传达它们。 用Rod Tidwell的话来说，“给我看钱”！我们如何将 DORA 指标与财务收益（避免的成本、节省等）联系起来？ ”
为了正确使用 DORA 指标，我们必须始终将提高可靠性和开发人员速度的总体目标与整体业务目标联系起来，并展示改善开发人员体验如何还可以提高用户保留率、工作质量和整体生产力等方面。
使用 dora 作为团队之间的比较，而不是跨时间的比较。
软件行业不是同质的，跨团队比较 dora 指标是不合适的。 每个软件团队的理想发布节奏不会相同，单次停机的成本会有所不同，每个团队进行紧急修复的能力也会有所不同。 在讨论 Platform Engineering Slack 中的 DORA 指标时，Thomas 留下了一条很好的评论：“我对'变更失败率'感到非常困惑。 不超过 5% 的优秀企业和超过 64% 的优秀企业。 但是，表现最好的团队每天部署多次，而表现最差的团队每月只部署一次。 在我以前的工作中，我们每天发帖 50 次。 如果我们的更改失败率为 5%，我们将有 2 个5起事故！ 如果每个月只发布一次，变更失败率为50%，那么可能每隔一个月就会发生一次事故。 似乎表现最差的团队有一个更稳定的环境。 ”
托马斯说得有道理。 一天发生几次事故怎么可能是“理想”的？ 虽然这可以用其他指标来解释——高绩效团队也有短暂的中断，这意味着事件可以在一小时内得到处理——但 2023 年 DevOps 现状报告的引言中有一句话适用于这里：
最好的比较是随着时间的推移对同一应用程序进行的，而不是在具有不同上下文的不同应用程序之间进行的。 ”
虽然从统计学上讲，一个团队的发布节奏大幅增加是很有意义的，但注意到你的发布频率是另一个不同组织的团队的 10 倍，这没有多大意义。 能够比过去的团队进步得更快是很重要的。
误解和误用。
正如 The New Stack 的这篇文章所强调的那样，人们对 DORA 指标所代表的含义存在普遍的误解。 它们通常被视为最终目标，而不是基本流程和实践的指标。 这种误解可能导致表面上改善指标的做法，但实际上并没有真正有助于软件交付或团队福祉。 让我举一个极端的例子，说明指标高于实际目标的问题。 2020 年，Hacktoberfest 组织者向提交 4 个或更多拉取请求的任何人提供免费 T 恤。 该活动旨在鼓励对开源项目做出新的贡献，但结果是，维护者对数千个无用的拉取请求感到沮丧，这些请求来自那些看过“如何轻松获得免费 T 恤”的人。 通过设定一个简单的指标目标，组织者鼓励与他们的目标背道而驰的无益和破坏性行为。 这种适得其反的激励情况是坎贝尔定律的一个具体例子：当我们设定一个简单的指标目标时，很容易在损害整个项目的同时实现目标。 在使用 DORA 指标时，通常不应明确将其视为腐败，但如果我们过分关注指标目标，我们会感到扭曲它们的压力。 在我的职业生涯中，我看到过关于成千上万的用户经历停机时间的长时间讨论，而这并不是真正的停机时间。 对事件进行错误分类的动机是担心报告的停机时间对性能指标的影响。
除了误报数字之外，误解的一个大问题是 DORA 指标本身并不能告诉你团队的健康状况。 它们表明开发人员体验良好，但如果功能发布速度慢，如果业务目标未达到，并且产品团队通常无法完成他们需要做的事情，那么所有日常部署和超快速回滚都意义不大。
那么，改善开发人员体验的好目标是什么？ 开发人员体验的最佳指标始终是开发人员对流程的满意度的自我报告。
只关注 DORA 指标的定量方面可能会忽略技术组织的人为因素，例如倦怠、生产力和工作满意度。 这些方面对于可持续和有效的工作环境至关重要。
DORA 指标不仅仅是数字; 它们代表着一种文化。 如果领导层未能传达和体现这些指标背后的原则，它们的实施可能会适得其反。
正如Martin Thwaites在LinkedIn的一篇文章中所说，DORA指标并不是真正重要的事情：“总是想想你希望这些指标改进的'原因'，因为我向你保证，付费使用你的产品的人并不关心一个团队是在DORA指标排行榜的顶部还是底部。 如果你的“为什么”是你想在多拉指标上做到最好的，你可能会，我猜，你衡量错了。 ”
在我早年使用 App Performance Management 和 Observable*** 时，我记得一个经典的陷阱导致了未被发现的停机时间。 当设置了大量警报以在响应时间下降时提醒所有工程师时，监控系统将无法捕获后端服务的重大故障。 怎么了？ 当数据库服务失败时，它会以错误消息的形式进行响应，这比实际响应要快得多。 在停机期间，响应时间会下降，导致所有仪表板都变为绿色。
这是一个经典的教训，说明追求少量的简单测量如何导致失败。 如上所示，过多地关注一小部分度量也可能导致优化以改进指标，而不会提高实际性能。
在我的下一篇文章中，我们将讨论 DORA 指标如何有助于评估团队内的平台工程质量。
要加入一个由工程师和领导者组成的团队，试图为他们的团队构建更好的开发人员体验，并使用更简单、更快捷的方式让开发人员尝试新的东西**，请进入 Signadot Slack 并打个招呼！