DevOps落地笔记-19|响应速度：天下武功，唯快不破

上一课时介绍一个团队应该具备什么样的能力，以及如何度量团队的交付效能。事实上，团队的能力在一定程度上反映了软件的交付能力；而响应速度则是企业能否快速占领市场的重要因素。试想一下，有两个企业都发现了市场上的机会，这个时候谁能够将机会变成产品发布到市场上，谁就赢得了先机。今天要介绍的主要内容就是响应速度，我们一起来学习，哪些因素会影响响应速度？如何度量团队的响应速度？

什么是响应速度

俗话说“天下武功，唯快不破”，《孙子兵法》中也提到“兵之情主速，乘人之不及”。这都是说在战争中，速度是取胜的关键。商场如战场，在如今数字化企业时代，软件的发布速度，问题的修复速度是企业制胜的法宝。

在软件开发过程中，响应速度包含多个方面。

& 软件发布：是指从软件立项到发布到生产环境，交付给用户使用的时间，是端到端发布的时间。代表了团队对市场机会的响应速度。

& 特性发布：是指从特性评审完成到集成测试、验收测试，再到发布到生产环境的时间。代表了团队对用户需求的响应速度。

& 缺陷发布：是指从发现缺陷/故障到定位，再到修复的时间。代表了团队对测试、运维的响应速度。

可以看出，提高响应速度的根本是缩短软件的交付周期。但作为软件开发人员，我们都知道通过缩短软件的交付周期来提高响应速度并不是一件容易的事。下面介绍下影响响应速度的因素有哪些。

影响响应速度的因素

软件开发是一项复杂的、交付最终价值的工作。复杂是指特性从需求开始需要经过多个阶段才能完成，特性的难易、大小也不一样。交付最终价值是指软件开发过程中的产出都是未产生价值的，要从全局层面进行度量和优化，而不是只局限在单个阶段的优化，比如测试阶段的效率提升未必缩短软件端到端的交付周期。那么，影响软件交付周期的因素有哪些？

资源利用率

资源利用率是指影响软件交付的相关资源在软件交付活动中所占时间的比例，比如团队成员、服务器设备、时间等。很多人认为，如果把所有人员、所有时间都充分利用起来，就能够缩短软件交付的周期。事实并非如此，原因是：

& 软件开发是一个顺序执行的操作，需要按照需求分析、设计、开发、测试、部署的阶段执行。每个阶段都依赖前面的阶段，这意味着即使投入再多的资源，交付周期也不可能无限制的缩短。

& 资源利用率越高，工作任务在队列中等待的时间就会越长，交付周期就会增长。就像高速公路一样，如果高速公路的路面都被利用上了，汽车就跑不起来了，高速公路就变成了停车场。如果一个同时处理多个任务，任务之间上下文的切换也会占用额外的时间。关键资源、关键人物被积压着长长的任务队列，慢慢就会成为整个交付的瓶颈。

任务的大小

任务的大小也是影响软件交付的因素，当任务的大小不一致，就会导致处理任务的时间不一样，就会产生等待。比如开发人员正在开发一个大的特性或是解决一个疑难杂症，在测试环节处理完任务后，没有任务具备测试条件，就不得不进入等待。在精益思想里提到，等待是一种浪费，会延长软件的交付周期。因此，在拆分需求的时候，尽可能地将任务拆分的均衡，减少等待的时间。

在制品数量

在前面的课时讲过通过看板方法可视化进行中的工作，以此控制在制品的数量。在制品数量越多，团队成员就会不断地进行任务切换，导致其他任务的等待和团队成员的利用率太高，造成瓶颈。可以通过限制在制品数量，一个完成再做下一个，可以实现频繁交付，缩短每个任务的交付周期。

自动化程度

自动化是影响响应速度的重要因素，减少手工操作，尽可能将一切自动化。包含编译构建、自动化扫描、自动化测试、自动化部署等。之前介绍的部署流水线就是将整个过程自动化的实践。在软件开发过程中，测试阶段是占用时间较长的阶段，应该尽可能地进行自动化测试，不仅包括集成测试、回归测试、功能测试和性能测试，甚至 UI 测试、UAT 测试都自动化实现。

度量响应速度的指标

前面提到，响应速度就是软件交付周期，提高响应速度，就是要缩短软件的交付周期。跟软件交付效率的度量有两种：价值交付效率和工程效率。下面分别介绍一下这两种度量。

价值交付效率

价值交付效率是以交付用户价值的度量。如用户的需求多久能发布，也就是上一课时提到的“前置时间”。在敏捷开发方法中，采用 Sprint（迭代）小批量的方式进行开发，每个迭代完成后，交付软件的增量。这里介绍一下“累积流图”。

& 累积流图。

累积流图是看板系统中的重要度量，是用来展示开发过程中各个阶段的在制品数量。能够根据不同的值分析当前存在的问题，还可以计算出平均前置时间，如下图所示。

在制品数量。

从进入“开发线”到“完成线”之间的高度，代表了当前时间在制品的数量。随着时间地推移，这个高度的变化反映了在制品数量的变化。如果在某个时间点，这个高度突然增大，说明在该时间点出现了瓶颈，可能是工作项难度太大，出现了积压，或者新增了工作项。

前置时间。

从进入“开发线”到“完成线”之间的长度，代表了从开发启动到完成的周期，也反映了团队的交付能力。如果某个时间点，这个长度较长，说明在该时间点出现了瓶颈，可能是工作项出现了积压，或者工作项遇到困难。

工程效率

工程效率主要是指 DevOps 平台本身的能力。影响软件交付效率的因素有：编译效率、测试效率、部署效率等。下面依次介绍一下。

编译效率。

代码需要编译打包之后才能部署到测试环境和生产环境中，在没有打包之前，测试就只能等待打包完成。因此，测试阶段的执行是强依赖前面的编译打包过程，因此要提高编译效率。影响编译效率的因素有：

1.编译机的资源：代码编译需要 CPU 资源，每个编译机能够同时处理的编译任务是有限的，当有多个编译任务需要执行时，就会有任务处于等待队列中。为了最大化利用编译机资源，可以采用容器构建的方式。当有编译任务需要处理时，就启动一个 Docker 容器，编译完成后就销毁，将资源释放出来。

2.代码库的大小：代码库的大小和编译时长成正比。在之前的企业里，有一个代码库里面包含了 50 多个子模块，每构建一次都是一场噩梦，哪怕只修改了一行代码，也需要下载、编译整个代码库，整个过程就需要1个多小时，这样的编译时长如何能加快整体的交付速度。在微服务时代，每个服务都是一个单独的代码库，代码库的大小减少了，编译时长也自然会缩短，编译效率也就提高了。每次变更代码，也只需要回归这个服务就可以，不需要整体回归。

3.编译工具的设置：代码是通过编译工具来编译的，比如 Java 语言中的 Maven，Gradle。编译工具本身为了加快编译速度也会进行优化，因此要使用尽可能新的版本。另外，为了加快编译速度，可以开启依赖缓存，不用每次都从中央仓库下载依赖包。

DevOps 平台中应该记录每次编译的信息，包括代码库、开始编译时间、结束编译时间、编译结果、编译人等信息，在数据统计时，可以统计每天的编译次数、编译时长的中位数，编译成功率，针对编译时长较长的代码库进行优化。

& 测试效率。

在瀑布时代，测试周期少则数周，多则数月。在这么长的测试周期下，交付周期也不会太短。测试阶段又分为多个不同的阶段，如回归测试、功能测试和非功能测试等。每一种类型的测试用于满足不同的测试需求，测试所需要的时间也不一样。

1.回归测试：一般用于完成一轮产品回归所需时间的度量。当代码修改后，验证该变更有没有引入新的错误，或者有没有对既有功能产生影响所进行测试的时间。回归测试应该尽可能地自动化，这样才能满足日益增加地频繁发布。

2.功能测试：一般用于完成所有功能验证所需时间的度量。全量功能验证一般在发布之前执行一次，以验证所有功能都是正常的。功能测试也应该是自动化的，缩短发布前的测试时长。

3.非功能测试：一般用于完成非功能性测试所需时间的度量。根据产品要求，有些版本需要进行性能测试、压力测试、安全测试等，这些测试需要用专业的工具完成，通常模拟大数据量，高并发量的测试。非功能测试基本都是通过工具自动化完成。

DevOps 平台中应该记录每次测试的信息，包含测试的总体时长，测试的用例数，测试的成功率等信息，测试的总体时长是测试效率的直接度量，影响因素有执行的用例数和测试的成功率。用例数越多，执行的时间就会越长；成功率越低，需要返工的工作项越多，最终测试的时间就越长。

部署效率

部署效率是指从开始部署到部署完成需要的时间。部署频率是一个全局指标，部署效率决定了部署频率，如果部署效率很高，部署频率自然也会高。这里要注意，部署效率不应该以牺牲准确性为代价。如果部署失败率高而不下，反而会影响整体的部署频率。

在软件交付效率中，价值交付效率是最终目标，但价值交付效率的提升是以工程效率的提升为基础。俗话说“工欲善其事必先利其器”，就跟我们现在的交通工具与古代的交通工具相比，货物运输的效率是不是提高了呢。

总结

本课时主要介绍了影响软件交付的响应速度这个因素。在当前市场竞争日益激烈的时代，速度是企业制胜的法宝。我们首先分析了影响响应速度的几个因素，比如：资源利用率、任务的大小、在制品数量和自动化程度。了解了问题所在，通过优化这些因素来提升响应速度。接下来介绍流量度量响应速度的几个指标，从价值交付效率和工程效率两个方面分别介绍了几个关键的指标。效率的提升不会一蹴而就，是通过不断优化，持续改进来实现的，这也是使用度量指标来指导改进的目的。