你是否按照预期使用了DORA指标？谷歌表示你可能没有。
译自 The Wrong Way to Use DORA Metrics，作者 Nočnica Mellifera。
近年来，有许多声音支持使用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%，那么大概每个第二个月就会有一次事故吧。看起来表现最差的团队环境更加稳定。”
Thomas 的看法很有道理。每天有好几次事故怎么可能是“理想”的?虽然通过其他指标可以解释这一点 —— 高绩效团队中断时间也很短，意味着事故在一个小时内就能处理 —— 2023 年度 DevOps 状态报告在其导言中有一句适用于此处的话:
“最佳的比较是在同一应用程序上随时间进行的，而非在具有不同上下文的不同应用程序之间进行的。”
虽然从统计上说一个团队的发布节奏大幅增加是非常有意义的，但注意到你的发布频率是另一个不同组织中的团队的 10 倍则意义不大。能比过去的团队更快进步才是最重要的。
- 误解和误用
正如这篇 The New Stack 的文章所强调的，人们普遍误解 DORA 指标代表的意义。它们往往被视为最终目标，而不是底层流程和实践的指示器。这种误解可能导致一些表面上改善指标但对软件交付或团队福祉没有真正贡献的做法。
让我举一个极端的例子说明指标高于真正目标的问题。2020 年，Hacktoberfest 组织者提供了一个免费 T 恤，给任何提交了 4 个或更多拉取请求的人。这个活动本意是鼓励对开源项目做出新的贡献，但结果是，维护者收到了成千上万来自看过“如何轻松获得免费 T 恤”视频的人发来的无用拉取请求，给他们造成了极大困扰。通过设置一个简单的指标目标，组织者鼓励了无益而扰乱的行为，与他们的目标背道而驰。这个适得其反的激励情况是一个具体的例子，展示了坎贝尔定律: 当我们设置一个简单的指标目标时，实现指标的同时损害整个项目的行为非常诱人。
在使用DORA指标时，通常不应被明确视为腐败，但如果我们过于专注于指标目标，就会感受到扭曲它们的压力。在我的职业生涯中，我曾经看到过关于成千上万用户遇到故障并非真正的停机的长时间讨论。错误分类该事件的动机是担心报告的停机会对性能指标产生什么影响。
除了误报数字之外，误解的一个重大问题是，DORA指标本身并不能告诉您团队的健康状况。它们表明了良好的开发者体验，但是如果功能发布速度缓慢，如果业务目标没有实现，如果总体上产品团队无法完成他们需要完成的工作，那么所有的日常部署和超快速回滚都意味着很少。
那么，改善开发者体验的一个好目标是什么呢？开发者体验的最佳指标始终是开发人员对流程满意程度的自我报告。
仅关注DORA指标的定量方面可能会忽略技术组织的人的因素，如倦怠、生产力和工作满意度。这些方面对于可持续和有效的工作环境至关重要。
DORA指标不仅仅是数字；它们代表着一种文化。如果领导层无法传达和体现这些指标背后的原则，它们的实施可能会产生适得其反的效果。
正如Martin Thwaites在LinkedIn上的一篇文章中所说，DORA指标并不是真正重要的事情：
“始终考虑你想要这些指标改善的‘为什么’，因为我向你保证，付钱使用你的产品的人不关心一个团队在DORA指标排行榜的顶部还是底部。如果你的‘为什么’是你想成为DORA指标最好的，你可能会，而且我猜测，你在衡量错误的事情。”
在我早年使用应用性能管理和可观察性工具时，我记得有一个经典陷阱会导致未检测到的停机。当大量警报被设置为在响应时间下降时向所有工程师发出警报时，监控系统将无法捕捉到后端服务的重大故障。问题出在哪里？当数据库服务失败时，它会以错误消息的形式回应，这比实际响应要快得多。在停机期间，响应时间下降，导致所有仪表板都是绿色的。
这是一个关于如何追求少量简单测量可能导致失败的典型教训。正如上面所示，过度关注一小部分测量也可能导致优化以改善指标，而不会改善实际的性能。
在我的下一篇文章中，我们将讨论DORA指标如何可能有助于评估团队内平台工程的质量。
要加入一个试图为他们的团队构建更好的开发者体验的工程师和领导者团队，使用更简单、更快的方法让开发人员尝试新代码，请加入Signadot Slack并打个招呼吧！