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

为了提升软件交付效能，你的团队或组织可能已经开始采取行动，引入敏捷方法、DevOps实践甚至还有架构重构。但你如何知道这些改进措施起了作用呢，或者它们压根就水土不服呢？简单来说，除了感性的工作体验外，你需要一些指标来度量交付效能。

唯快不破

提升交付效能的最重要的目标之一就是能"快起来"，那么如何定义"快"呢？我们更倾向于度量吞吐量，吞吐量是指单位时间内团队完成的工作量。

• 变更前置时间

Lead Time for Changes，变更前置时间指的是开始编码到部署所耗费的时间。如果变更前置时间过长，可能意味着开发或部署过程的某些环节出现了问题或阻碍。这是一个典型的吞吐量指标，更强调的是对于单个用户故事/用例需要花费多长时间才能获得实际反馈。

我之前受邀参与某个项目，当时团队的直观感受是进度滞后。通过度量变更前置时间，我们发现用户故事从进入"开发中"到"准备QA测试"(意味着开发同事已经完成了开发并按照验收标准进行了自行验证)的中位数时间是4.5天，这意味着近一半的用户故事在一个工作周内都不会得到有效的反馈，而在一周之后往往可以"惊喜"地发现实现方案有问题，需要返工。因此，我们把降低变更前置时间、增加吞吐量作为目标，帮助业务分析师和Tech Leader在保证 INVEST原则! 的情况下进一步拆分故事卡作为手段，在三周之后将变更前置时间的中位数降低到2.5天。虽然更细粒度的故事卡带来了更频繁的开卡、关卡活动，看似造成了更多的工作量，但由此带来的频繁交流和目标拉通，降低了返工的可能，使得项目进度逐渐恢复正常。

• 部署频率

Deployment Frequency，部署频率，我认为这是吐吞量的另一种度量方式，更频繁的部署往往意味着单次部署包含的变更更少，但对于某个特性来说，可以更快地获得产生价值，获得实际反馈。而且，同变更前置时间相比，部署频率往往更直接地意味着团队/组织在工程实践方面有着良好的理解和应用。

唯快不破，并非只强调快

我曾经在一家传统企业工作，在没有敏捷方法和工程实践加持的情况下，我们也做到了每周一次发布。但几乎每次发布后，随之而来的是紧急发布，以修复发布后出现的各种问题。在一次对客服中心的拜访中，我了解到客服部门对IT部门的每周发布并没有什么好感，因为每次发布后都如临大敌，客户投诉可能呼啸而至。因此，我们在追求“快”的同时，还得保住“稳”，否则频繁出现故障的使用体验，甚至会抵消快速创新的努力。

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

• 变更失败率

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

• 服务恢复耗时

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

为什么优先度量这些指标

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

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

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

从另一个角度来说，这四个指标距离客户的直观感受更接近，这意味着它们更能体现真实的价值。同样的情况可以参考应用监控，在《Practical Monitoring》一书中，作者极力推荐优先从用户视角建立监控指标，这比底层指标更容易得出结论：例如响应延迟，是用户是能感受到的，延迟升高了可能意味着出现问题，但CPU使用率用户是感受不到的，其增高也未必说明问题，可能有些应用运行在高负载CPU是常态。

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

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

诊断型指标

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

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

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

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
4. 《精益软件度量》，作者: 张松

文/ThoughtWorks周宇刚