第1章 敏捷、持续交付和三步法

本章将阐释精益制造的基础理论和三步工作法原则，从后者能衍生出各种DevOps行为。

我们侧重于这些理论和原则，它们记录了制造业、高可靠性企业、高信任管理模型等几十年的经验，DevOps实践正是基于这些经验衍生而来的。具体的原则和模式及其在技术价值流中的应用，会在本书的后续章节中陆续呈现。

1.1 制造业价值流

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

Karen Martin和Mike Osterling曾在Value Stream Mapping一书中把价值流定义为“一个组织基于客户的需求所执行的一系列有序的交付活动”，或者是“为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值”。

在制造业的流程中，价值流随处可见，它始于接收到客户订单并将原材料发往工厂。为了缩短和预测价值流中的前置时间，通常需要持续地关注如何建立一套流畅的工作流程，包括减小批量尺寸、减少在制品（Work in Process, WIP）数量、避免返工等，同时还需要确保不会将次品传递到下游的工作中心，并持续不断地基于全局目标来优化整个系统。

1.2 技术价值流

在制造业中加速物理产品加工流程的原则和模式，同样可以应用到技术工作（及所有知识工作）中。在DevOps中，我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。

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

接受了工作之后，研发团队将运用敏捷或迭代的开发流程，将那些想法转化为用户故事以及某种功能性说明，然后通过编写程序代码实现，再将代码签入到版本控制库中，接下来每次变更都将集成到软件系统并进行整体测试。

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

1.2.1 聚焦于部署前置时间

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

注1：从目前开始，工程师指的是在我们的价值流中的任何工作者，而不仅仅指开发人员。

在第一个阶段中，工作主要包括设计和开发，它和精益产品开发有很多相似之处：都具有高度的变化性和不确定性，不仅需要创意，某些工作还可能无法重来，这导致无法确定总体处理时间。在第二个阶段中，工作主要包括测试和运维，它类似于精益制造。相比前一个阶段，它需要创造性和专业技能，力求可预见性和自动化，将可变性降到最低（如短的和可预测的前置时间，接近零缺陷），并满足业务目标。

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

1．定义前置时间和处理时间

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

前置时间在工单创建后开始计时，到工作完成时结束；处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间（见图1-1）。

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

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

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

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

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

在DevOps的理想情况下，开发人员能快速、持续地获得工作反馈，能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中（自己部署或者他人部署）。

我们可以通过如下方式达到这个目标：向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题。

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

通过上述方式，能有效地将前置时间缩短至分钟级别；即便在最坏的情况下，也不会超过小时级别。其价值流图如图1-3所示。

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

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

1.3 三步工作法：DevOps的基础原则

《凤凰项目》把三步工作法作为基础的原则，并由此衍生出了DevOps的行为和模式（见图1-4）。

第一步，实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。

通过加快技术价值流的流速，缩短满足内部或者外部客户需求所需的前置时间，尤其是缩短代码部署到生产环境所需的时间，可以有效地提高工作质量和产量，并使企业具有更强的外部竞争力。

相关的实践包括持续构建、集成、测试和部署，按需进行环境搭建，限制在制品数量，构建能够安全地实施变更的系统和组织。

第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。该方法通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

及时发现并控制这些问题，直到拥有有效的对策，可以持续地缩短反馈周期和放大反馈环，这是所有现代流程优化方法的一个核心原则，能够创造出组织学习与改进的机会。

第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动地承担风险，不但能从成功中学习，也能从失败中学习。通过持续地缩短和放大反馈环，不仅能创造更安全的工作系统，也能承担更多的风险，并进行试验帮助自己比竞争对手改进得更快，从而在市场竞争中战胜他们。

作为第三步的一部分，我们能够让工作系统事半功倍，将局部优化转化为全局优化。另外，不管是谁参与了工作，所有经验都可以持续地积累，组织里的人都可以相互借鉴彼此的经验和智慧。

1.4 小结

本章描述了价值流的概念，同时还介绍了制造业价值流和技术价值流中的一个重要量度指标——前置时间，最后介绍了三步工作法（支撑DevOps的原则）的基本概念。

在后续的章节中，我们将更详细地描述三步工作法。第一步是流动原则，不管是在制造行业还是在信息技术产业，它都聚焦于在价值交付过程中建立快速的工作流。关于快速流动的更多实践，将会在本书的第三部分详细描述。