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

2020 年 11 月 17 日

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

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



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


唯快不破


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


  • 变更前置时间


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


我之前受邀参与某个项目,当时团队的直观感受是进度滞后。通过度量变更前置时间,我们发现用户故事从进入"开发中"到"准备 QA 测试"(意味着开发同事已经完成了开发并按照验收标准进行了自行验证)的中位数时间是 4.5 天,这意味着近一半的用户故事在一个工作周内都不会得到有效的反馈,而在一周之后往往可以"惊喜"地发现实现方案有问题,需要返工。因此,我们把降低变更前置时间、增加吞吐量作为目标,帮助业务分析师和 Tech Leader 在保证 [INVEST 原则!](https://en.wikipedia.org/wiki/INVEST_(mnemonic)) 的情况下进一步拆分故事卡作为手段,在三周之后将变更前置时间的中位数降低到 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. 《精益软件度量》,作者: 张松


作者介绍


周宇刚,拥有 10 年的 JAVA EE 开发经验,在 ThoughtWorks 担任高级咨询师。在加入 ThoughtWorks 之前,在一家国内领先的航旅企业担任架构师,专注于持续交付实践和大型企业应用架构治理。


本文转载自 ThoughtWorks 洞见。


原文链接


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


2020 年 11 月 17 日 10:001016

评论

发布
暂无评论
发现更多内容

Redis学习笔记(有序集合)

编程随想曲

redis

火箭架构思维模型六元组 - 势 道 法 术 器 界

常平

架构 分布式 架构模式

功不唐捐

Janenesome

读书笔记 思考 坚持

如果想了解驱动开发,请不要错过这篇。

水滴

最佳实践 开发者 程序设计 测试驱动开发实战营

一位狂热崇拜亚里士多德的男士在酒吧试图勾搭一位女士

黄大路

小说 哲学

左值引用、右值引用、移动语义、完美转发,你知道的不知道的都在这里

程序喵大人

c c++ C#

RAII妙用之计算函数耗时

程序喵大人

c++ C#

c++11新特性,所有知识点都在这了!

程序喵大人

c++

数据产品经理|关于产品续费率的思考

黄大路

数据挖掘 数据分析 产品经理

c++11新特性之智能指针

程序喵大人

c++

你体验过 “心流时刻” 吗?

Janenesome

读书笔记 高效工作 碎碎念

良好的工作习惯——及时存档、备份

Sicolas Flamel

工作效率

c++11新特性之线程相关所有知识点

程序喵大人

c c++ C#

回"疫"录(12):一“罩”难求

小天同学

疫情 回忆录 现实纪录 纪实

医院陪护5天的四点感受

赵新龙

身心健康 医院

c++11新特性之模板的改进

程序喵大人

c c++ C#

你真的理解线程么?

Simon郎

Java 后端 多线程

带你吃透原型设计

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

程序员容易忽略的问题

Janenesome

读书笔记 程序员 编程习惯

Git clone过慢问题

JDoe

git

c++11新特性之std::function和lambda表达式

程序喵大人

c c++ C#

内存对齐

程序喵大人

c c++ C#

ITerm2 + Oh my ZSH + Powerlevel10k

JDoe

配置

C++11的类型推导详解

程序喵大人

c c++ C#

c++11新特性之列表初始化

程序喵大人

c c++ C#

也谈程序员的核心竞争力

我心依然

学习 程序员 竞争力 独立思考 清晰表达

错过了初恋,别错过WebFlux

稻草鸟人

stream Spring5 WebFlux Reactive

业务开发过程中的特殊逻辑

Janenesome

产品 碎碎念 开发

游戏夜读 | 如何制作互动剧?

game1night

用Go替代Python在生产环境中进行数据分析

良少

go 人工智能 大数据 数据分析 pandas

Java 为什么需要包装类

Rayjun

Java

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