软件交付效能度量——从吞吐量和稳定性开始

除了感性的工作体验外，我们还需要指标来度量改进措施是否对提升软件交付效能有帮助。过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点。从吞吐量和稳定性两个维度考量的四个关键指标是简单但有效的指标，建议优先度量。

那么，我们应该关注哪些“稳定性”指标呢p>

• 变更失败率

Change Fail Rate，变更失败率是指发生变更后出现故障的几率。理论上来说，当我们引入敏捷方法和DevOps实践快速迭代时，随着时间的推移和实践及工具的成熟，单次部署/发布包含的变更项会逐渐减少，由此变更失败率也会最终降低。因此，如果变更失败率居高不下，可能意味着在过程或工程实践中出现了某些问题或阻碍

• 服务恢复耗时

Time to restore service，服务恢复耗时是指当服务中断或降级后，需要花费多少时间将服务恢复正常。每次部署包含的变更多寡、技术债务堆积程度对该指标有一定影响，但将该指标放在这里有一些争议，因为在一些合作模式中，造成故障的部分原因或修复措施并不在交付团队的工作范围内（例如基础设施）。

为什么优先度量这些指标

读到这里，你可能会发现以上四个关键指标来自于一份业界知名的DevOps 告，为什么在度量交付效能的时候，要优先考虑DevOps指标呢p>

在19年4月的技术雷达中，是这样回答的：

研究人员证实，只需四个关键指标就能区分低绩效、中绩效和高绩效人员：前置时间、部署频率、平
均修复时间(MTTR)和变更失败率。的确，我们已经发现这四个关键指标是个简单却强大的工具，可帮助领导和团队专注于衡量并改进重要的环节。

最后则是从成本考虑，避免在一开始的时候就规划并实施一个大而全的度量体系，从而付出不必要的管理成本

度量需要投入团队的时间，项目管理人员的时间，质量保障人员的时 间，以及公司管理人员的时间，还可能会有工具和基础设施的投入。围绕 各种目标需要度量体系的设计和实施，体系的运转需要数据的收集、分析 和汇 ，这些环节做得不到位是不可能产生预期效果的，而要做到位，所 需的投入可能并不是一个可以忽略的小数目。因此，目标和指标的选择就 显得特别重要，试图实施一个大而全的度量体系，通常弊大于利。（《精益软件度量》，”度量不是什么“章节）

诊断型指标

如果说以上四个关键指标告诉我们的是交付效能的变化趋势，那么下一步，我们可以寻找更细粒度的指标来告诉我们如何进一步改进它们。

之前的四个关键指标更像体温计，它们可以快速地反映现在是否健康，但它们不能告诉我们病因。接下来我们需要的是验血 告， 告中有很多明细的指标，单个指标或许并不能说明什么，但若干异常指标的组合在一起往往可以帮助医生判断病灶，或许可以将这些明细指标称作”诊断型”指标。

常见的”诊断型”指标包括但不限于:

1. 平均构建时间
2. 测试覆盖率
3. 代码圈复杂度
4. 团队速率

以上这些(以及更多其他)指标从代码复杂度、测试策略、基础设施水平等更”底层”的维度解释交付效能健康或不健康的原因，它们可以帮助团队在做出进一步针对性的改进。

总结

1. 除了感性的工作体验外，我们还需要指标来度量改进措施是否对提升软件交付效能有帮助。
2. 过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点。
3. 从吞吐量和稳定性两个维度考量的四个关键指标是简单但有效的指标，建议优先度量。

参考

1. Accelerate: State of DevOps 2018 Strategies for a New Economy, By DevOps Research & Assessment
2. https://www.thoughtworks.com/cn/radar/techniques/four-key-metrics
3. Practical Monitoring, By (author) Mike Julian

文/ThoughtWorks周宇刚

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8988 人正在系统学习中