谷歌的 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 团队和组织都不尽相同,因此收集这些指标数据的具体流程仍具有一定难度。