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

1. 制造业价值流

卡伦马丁(Karen Martin)和迈克奥斯特林(Mike Osterling)曾将价值流定义为“一个组织基于顾客需求而执行的一系列有序交付活动”或“设计、生产并向顾客提供产品或服务所需的一系列活动，其中包含信息流和物流的双重价值”。在制造过程中，价值流随处可见，它始于接收客户订单和向工厂发送原材料。

为了缩短和预测价值流中的交付周期，通常需要持续关注如何建立顺畅的工作流程，包括减少批量、减少在制品(WIP)数量、避免返工等。同时也要保证不良品不会转移到下游工作中心，基于全局目标不断优化整个系统。

2. 技术价值流

制造业中加速实物产品加工流程的原理和模式，同样可以应用于技术工作(以及所有的知识工作)。在DevOps中，我们通常将技术价值流定义为“将商业想法转化为向客户交付价值的技术驱动的服务所需的过程”。流程的输入是既定的业务目标、概念、想法和假设，从R&D部门接受工作并将其添加到待办事项列表开始。接受这份工作后，R&D团队会用敏捷或者迭代的开发过程，把那些想法变成用户故事和一些功能描述，然后编写程序代码来实现，再把代码检入版本控制库，然后每一个改动都会集成到软件系统中。

只有当应用程序或服务在生产环境中按预期正常运行，并为客户提供服务时，所有的工作才能产生价值。因此，我们不仅要快速交付，还要确保部署工作不会出现混乱和破坏性，如客户服务中断、性能下降或信息安全不规范。

3.关注部署前置时间

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

在第一阶段，工作主要包括设计和开发，这与精益产品开发有很多相似之处：两者都具有高度的可变性和不确定性，不仅需要创造性，而且有些工作可能不会重复，从而导致整体处理时间的不确定性。第二阶段的工作主要包括测试和运维，类似于精益制造。与前一阶段相比，它需要创造力和专业技能，努力实现可预测性和自动化，最大限度地减少可变性(如短且可预测的交付周期，接近零缺陷)，并满足业务目标。

我们不提倡在设计开发中串联做了大量工作后，就转入测试和运维阶段(比如使用大量基于瀑布模型的开发流程，致力于长生命周期的特色分支)。相反，我们的目标是采用测试、运维、设计开发同步的模式，从而产生更快的价值流和更高的质量。这种同步模式只有在工作任务是小批量的，并且质量被构建到价值流的每个部分时才能实现。

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

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

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

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

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

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

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

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

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