1. 技术价值流

精益生产体系中，有一个基本概念叫价值流，价值流是组织基于客户的需求执行的一系列有序的交付活动。

制造业用于加快产品加工流程的原则和模式，同样可以应用到技术行业。

在 DevOps ，通常把技术价值流定义为：

把业务构想，转化为向客户交付有价值的、由技术驱动的服务所需要的流程。

流程的输入是既定的业务目标、概念、创意和假设，从研发部门接受工作，并把输入添加到待完成工作列表中开始。

研发部门接受工作后，将用敏捷或迭代的开发流程，把输入转化为用户故事或其他形式的需求说明。

通过编写代码实现这些需求，把代码签入到版本控制库中，每次变更都要集成到软件系统中，并进行集成测试。

应用或服务，只有在生产环境中按预期正常地为客户提供服务，团队的工作才算是产生价值了。

在技术价值流中，团队不但要做到快速交付，还要保证部署工作不会出现失误的情况，比如客户服务中断、性能下降、安全性下降等问题。

部署指的是把项目进行打包、配置和发布的过程。

在 App 端，打包 App、把 App 发给测试人员，把 App 发布到市场、发布热更新补丁，都属于部署工作。

和后台比起来，App 端的部署要简单很多，因为后台有各种乱七八糟的配置，任何一个没配好都有可能导致服务起不来。

2. 部署前置时间

部署的前置时间，是价值流的一个子集，也是这篇文章讨论的重点。

技术价值流，从工程师向版本控制系统提交变更开始，以变更在生产环境中运行，为客户提供了价值，并生成有效的反馈和监控信息为止。

1. 第一阶段

   在技术价值流的第一阶段，工作主要包括设计和开发系统，这个阶段和精益产品开发有很多相似之处。

   比如都具有高度的易变性、不确定性，都需要创意，某些工作还可能无法重来，导致无法确定工作的总体处理事件。

2. 第二阶段

   技术价值流的第二阶段，工作主要包括测试和运维，这一阶段类似于精益制造。

   和第一阶段相比，第二阶段的工作，要有可预见性和自动化，减少易变的因素，并满足业务目标。

   减少易变因素，可通过短且可预测的前置时间、进行能降低缺陷率的改善。

DevOps 不提倡在第一阶段完成大量工作后，再把工作转入第二阶段。

而是提倡采用测试、运维、设计与开发同步的模式，产生更快的价值流和价值更高的产品。

只有当工作任务是小批量，并且把质量内建于价值流的各个部分时，这种同步的工作模式才能实现。

3. 前置时间和处理时间

在精益社区中，前置时间与处理时间是度量价值流性能的两个常用指标，处理时间有时也叫接触时间或任务时间。

前置时间在工单创建后开始计时，到工作完成时结束，处理时间从实际处理这个工作时才开始计时，不包含这个工作在任务队列中排队等待的时间。

因为客户能体验到前置时间，所以我们把重点放在缩短前置时间，而不是处理时间上。

处理时间与前置时间的比率，是非常重要的效率指标，为了实现快速流动且缩短前置时间，就必须缩短工作在队列中的等待时间。

有的开发团队在实践 DevOps 前发现，经常在项目开发完成前，把变更合并到一起后，发现整个系统根本无法正常工作，甚至连代码都无法编译。

而遇到的这些问题，需要几天甚至几个星期来定位和修复，这么长的前置时间，对客户而言是非常糟糕的体验。

在 DevOps 的理想情况下，开发人员能快速、持续地获得反馈，快速且独立地开发、集成和验证变更，而且能把代码部署到生产环境中。

而采用的手段有：

• 小批量

  向版本控制系统中，持续不断地提交小批量的代码变更，并使用自动化测试对代码进行测试，再把它部署到生产环境中。

  代码变更在生产环境中运行后，如果存在问题，就能快速发现并修复问题。

• 模块化

  除了小批量，还要通过模块化、高内聚、低耦合的方式优化软件的架构设计。

  这样即使部署失败，也不会影响到整个团队的开发工作。

除了前置时间和处理时间，价值流中第三个关键指标，就是完成时间和总花费时间的比率 %C/A（Completion / Accurate），该指标反映了价值流中每个步骤的输出质量。

想要获取 %C/A ，可以询问下游客户（比如开发人员的下游客户就是测试人员），他们有百分之多少的时间收到了“真正有用的工作”。

真正有用的工作，也就是不必修复错误信息、补充信息或澄清信息的工作。