关于DevOps中的价值流及度量，70%的人都理解错了

精益中的一个基本概念叫价值流 。我们先在制造业的场景中定义它，再讨论如何将它应用到DevOps和技术价值流中。

 

1.  制造业价值流

 

 Karen Martin和Mike Osterling曾在 Value Stream Mapping 一书中把价值流定义为“ 一个组织基于客户的需求所执行的一系列有序的交付活动”，或者是“为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值”。 在制造业的流程中，价值流随处可见，它始于接收到客户订单并将原材料发往工厂。

 

为了缩短和预测价值流中的前置时间，通常需要持续地关注如何建立一套流畅的工作流程，包括减小批量尺寸、减少在制品（Work in Process，WIP）数量、避免返工等，同时还需要确保不会将次品传递到下游的工作中心，并持续不断地基于全局目标来优化整个系

统。

2.  技术价值流

 

在制造业中加速物理产品加工流程的原则和模式，同样可以应用到技术工作（及所有知识工作）中。在DevOps中，我们通常将技术价值流定义为“ 把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。流程的输入是既定的业务目标、概念、创意和假设，始于研发部门接受工作，并将它添加到待完成工作列表中。接受了工作之后，研发团队将运用敏捷或迭代的开发流程，将那些想法转化为用户故事以及某种功能性说明，然后通过编写程序代码实现，再将代码签入到版本控制库中，接下来每次变更都将集成到软件系统并进

行整体测试。

 

应用程序或服务只有在生产环境中按预期正常地运行，并为客户提供服务，所有的工作才产生价值。所以，我们不但要快速地交付，同时还要保证部署工作不会产生混乱和破坏，如中断客户服务、性能下降或者信息安全不合规等问题。

 

3 .  聚焦于部署前置时间

部署前置时间是价值流的一个子集。价值流始于工程师（包括开发、QA、IT运维和信息安全人员）向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。 工程师指的是在我们的价值流中的任何工作者，而不仅仅指开发人员。

 

在第一个阶段中，工作主要包括设计和开发，它和精益产品开发有很多相似之处：都具有高度的变化性和不确定性，不仅需要创意，某些工作还可能无法重来，这导致无法确定总体处理时间。

 

在第二个阶段中，工作主要包括测试和运维，它类似于精益制造。相比前一个阶段，它需要创造性和专业技能，力求可预见性和自动化，将可变性降到最低（如短的和可预测的前置时间，接近零缺陷），并满足业务目标。

 

我们并不提倡在设计、开发中串行地完成了大批量的工作后，再转入测试、运维阶段（如使用大批量、基于瀑布模型的开发流程，工作在长生命周期的特性分支上）。恰恰相反，我们的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步的模式才能实现。

3 . 1 定义前置时间和处理时间

在精益社区里， 前置时间与处理时间（有时候也被称为接触时间或者任务时间）  是度量价值流性能的两个常用指标。

 

前置时间在工单创建后开始计时，到工作完成时结束；

处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间。

部署工作的前置时间和处理时间

 

因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。

 

3 . 2 常见的场景：为期数月的部署前置时间

通常，部署前置时间动辄需要好几个月。在大型、复杂的企业里，使用着紧耦合的单体应用，少有集成测试的环境，测试和生产环境的前置时间很长，并且严重依赖于手动测试，或者需要各种审批流程，情况更是如此。

某部署前置时间为期三个多月的技术价值流

 

部署前置时间一旦变长，那么在价值流的每个阶段，几乎都需要“填坑”能手来补救。通常，很可能是在项目结束前，将开发团队的变更合并到一起后，才发现整个系统根本无法正常工作，有时甚至会出现代码都无法通过编译和测试的情况。每一个问题可能都需要几天甚至几周的时间来定位和修复，因此导致了极其糟糕的客户体验。

3 . 3 我们的目标：分钟级别的部署前置时间

在DevOps的理想情况下，开发人员能快速、持续地获得工作反馈，能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中（自己部署或者他人部署）。我们可以通过如下方式达到这个目标：向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题。

 

为了更容易地实现上述目标，还需要通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。这样即便失败了，也能在可控范围内，而不至于对全局产生影响。

通过上述方式，能有效地将前置时间缩短至分钟级别；即便在最坏的情况下，也不会超过小时级别。

前置时间为分钟级别的技术价值流

 

4   关注返工指标 ——%C/A

除了前置时间和处理时间外，技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比（%C/A）。该指标反映了价值流中的每个步骤的输出质量。要获取%C/A，可以询问下游客户他们有百分之多少的时间收到了‘真正有用的工作’，即他们可以专心做有用的工作，而不必修复错误信息、补充信息，或者澄清那些本该确定的信息。

 

参考资料《devops实践指南》

 

翰德恩洞见 ：

价值流及其相关度量的理论最早诞生于精益生产系统。因此，要理解DevOps的价值流及度量方式，我们也应该回到老祖宗-精益来理解价值流的原本理念。

 

本文介绍了DevOps价值流的度量：部署前置时间、处理时间、返工指标。前置时间才是客户能够体验到的时间，也是能够牵引团队做价值流全局优化而非局部优化的度量。有效地引入DevOps能够将部署前置时间逐步从“月级别”降低到“分钟级别”。