谷歌的 DevOps 研究与评估团队从事指标交易，即 DevOps 指标。但其最新的相关报告也警告不要过度使用这些指标。
?
DevOps 研究与评估小组（DORA）建议 IT 专业人员根据四个关键指标来评估团队绩效：部署频率，变更准备时间，变更失败率，失败部署恢复时间，即之前的平均服务恢复时间（MTTR）。自 2018 年谷歌收购 DORA 以来，初创公司和成熟的软件开发供应商（包括 Sleuth、Harness 和 Atlassian）都报告了针对工程经理的 DORA 指标。
?
尽管 DORA 仍在使用指标评估组织绩效，但是其今年的报告也警告了一些常见的陷阱，比如当DORA指标被视为一门精确的科学或者被不恰当地用于评估团队绩效时。
?
该报告也指出，衡量不是目的，只一味地固守绩效指标会导致无效行为。而投资于能力和学习才是取得成功的更好方法。
?
DORA 和谷歌云的开发人员倡导者 Nathen Harvey 表示，对于工程经理和高管来说，使用DORA指标结果作为目标并比较不同开发团队的性能是很自然的，但其实这是一个误区。
?
真正的领导者所做的不应该是庆祝最快交付的软件团队，而是进步最大的、接受持续改进理念的团队。
?
Harvey 补充说，改进是长期持续的，即使是优良的团队，也仍有进一步改进的空间。根据提供的应用程序的具体情况，公司内改中进展最慢的团队往往可能改进最大。他认为，将DORA指标与开发不同应用的团队（具有不同的限制条件、基础设施要求和用户体验）进行比较往往不会产生效果，甚至会有负面影响。
?
DORA DevOps 报告也呼吁软件开发团队要更加关注用户体验和团队福利。因为工程师们可能不知道他们是在为谁开发产品，也不理解为什么要开发这些功能，他们只是被告知需要不断开发更多产品。而职业倦怠在这类团队也时常出——尽管他们能够保证更快地完成，但他们可能没有完成正确的任务。根据该报告，以最终用户为中心构建软件的团队的组织绩效显然要比其他高出 40%。它指出，理想的方法是在部署速度、运行性能和用户体验之间取得平衡。
?
今年，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 团队和组织都不尽相同，因此收集这些指标数据的具体流程仍具有一定难度。