谷歌的 DevOps 研究与评估团队从事指标交易，即 DevOps 指标。但其最新的相关报告也警告不要过度使用这些指标。
DevOps 研究与评估小组（DORA）建议 IT 专业人员根据四个关键指标来评估团队绩效：部署频率，变更准备时间，变更失败率，失败部署恢复时间，即之前的平均服务恢复时间（MTTR）。自 2018 年谷歌收购 DORA 以来，初创公司和成熟的软件开发供应商（包括 Sleuth、Harness 和 Atlassian）都报告了针对工程经理的 DORA 指标。
尽管 DORA 仍在使用指标评估组织绩效，但是其今年的报告也警告了一些常见的陷阱，比如当DORA指标被视为一门精确的科学或者被不恰当地用于评估团队绩效时。
该报告也指出，衡量不是目的，只一味地固守绩效指标会导致无效行为。而投资于能力和学习才是取得成功的更好方法。
01 组织陷阱：滥用指标的危险
DORA 和谷歌云的开发人员倡导者 Nathen Harvey 表示，对于工程经理和高管来说，使用DORA指标结果作为目标并比较不同开发团队的性能是很自然的，但其实这是一个误区。
真正的领导者所做的不应该是庆祝最快交付的软件团队，而是进步最大的、接受持续改进理念的团队。
Harvey 补充说，改进是长期持续的，即使是优良的团队，也仍有进一步改进的空间。根据提供的应用程序的具体情况，公司内改中进展最慢的团队往往可能改进最大。他认为，将DORA指标与开发不同应用的团队（具有不同的限制条件、基础设施要求和用户体验）进行比较往往不会产生效果，甚至会有负面影响。
DORA DevOps 报告也呼吁软件开发团队要更加关注用户体验和团队福利。因为工程师们可能不知道他们是在为谁开发产品，也不理解为什么要开发这些功能，他们只是被告知需要不断开发更多产品。而职业倦怠在这类团队也时常出——尽管他们能够保证更快地完成，但他们可能没有完成正确的任务。根据该报告，以最终用户为中心构建软件的团队的组织绩效显然要比其他高出 40%。它指出，理想的方法是在部署速度、运行性能和用户体验之间取得平衡。
02 团队使用 DORA 指标自动化的经验
今年，Sleuth.io 和被 Harness 收购的 Propelo 都进一步采取了措施来利用 DORA 指标——不仅仅是报告这些指标，还允许它们触发自动工作流以执行最优实践。而Propelo 与 Harness DevOps 平台的融合意味着用户可以根据 DORA 指标自动触发 CI/CD 流水线中的操作。
Sleuth 也紧随其后，在上个月增加了 Sleuth Actions 和 Sleuth Automations。Sleuth Actions 是该供应商为实现 IT 流程自动化而开发的框架。它已得到扩展并更名为 Sleuth Automations，这是一套通过 Sleuth Automations Marketplace 提供的第三方系统预打包工作流，如 GitHub Actions。
哥伦比亚的企业支付平台提供商 Cobre 在大约一年前开始使用 Sleuth 报告 DORA 指标。它使用 Sleuth Automations 在更新滞后于 QA 和生产时触发 Slack 通知，并在不符合政策要求时自动阻止 GitHub Actions 中的拉取请求（PRs）。
对于这点，Cobre 的解决方案架构师 Juan Matheus 认为，如果有超过 20 个文件被修改，开发人员就无法合并 PR。因此，执行 DORA 推荐的做法是最优选择，即对软件进行小规模、频繁的更改，而不是大规模更新。这也有助于鼓励开发人员更快地将代码推向生产。
在今年的报告中，Cobre 发现了一个常见的瓶颈，即缓慢的代码审查。Cobre 的产品交付总监 Manuel Sanabria 表示，即使使用 Sleuth 这样的工具，在收集数据以衡量 DevOps 团队绩效的背后也有一个不断学习的过程。具体对于Cobre 来说，变更失败率和 MTTR 一直是个棘手的问题，因为他们不知道该收集哪些数据，也不知道如何将公司的 New Relic 可观察性工具中的原始数据转化为 DORA 指标。
Sleuth 的联合创始人兼首席执行官 Dylan Etkin 也承认Cobre所面临的困难。当一个团队选择使用自定义指标时，就需要像 Cobre 团队一样进行一些配置，以决定究竟什么是相关指标，并了解该指标是否能真正代表其团队或项目的失败。
事实上，DORA 也认为 MTTR 一直是一个棘手的统计指标，这就是为什么今年该指标被重新修订，并更名为 failed deployment recovery time。
不过，由于每个 DevOps 团队和组织都不尽相同，因此收集这些指标数据的具体流程仍具有一定难度。
 TypeError: Failed to fetch)
