持续交付2.0：业务引领的DevOps精要

本文选自 《持续交付2.0：业务引领的DevOps精要》 ，作者乔梁。

经典图书《持续交付》已出版8年，一直受到软件行业从业者的关注。书中的软件开发原则和实践也随着商业环境VUCA特性的明显增强而逐渐受到软件技术人员的认可。

VUCA是volatility（易变性）、uncertainty（不确定性）、complexity（复杂性）和ambiguity（模糊性）的首字母缩写。VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。在2001年9月11日恐怖袭击发生之后，这一概念和首字母缩写才真正被确定。随后，VUCA被战略性商业领袖们用来描述已成为“新常态”的、混乱的和快速变化的商业环境。

然而，在应用这些为达成持续交付目标所需的软件技术相关原则与实践时，我们会遇到很多难题。例如，业务压力太大，没有时间改进；开发和测试的时间被压缩得太少了，没有时间这么干；这么做的风险太高了，质量很难保障。而这些难题正是由于软件工程的发展惯性带来的，是到了改变的时候了。

1.1软件工程发展概述

“软件工程”这一学科出现于1968年，当时正值第一次软件危机。第一次软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。人们试图借鉴建筑工程领域的工程方法来解决这一问题，以实现“按预算准时交付所需功能的软件项目”的愿望。

1.1.1瀑布软件开发方法

瀑布软件开发模型由Dr. Winston W. Rovce在1970年发表的“Managing the development of large software systems”一文中首次提出，如图1-1所示。它将软件开发过程定义为多个阶段，每个阶段均有严格的输入和输出标准，项目管理者希望通过这种重计划、重流程、重文档的方式来解决软件危机。很多人将具有以上3个特征的软件开发方法统称为“重型软件开发方法”。

图1-1瀑布软件开发模型

在20世纪，瀑布软件开发模型的每个阶段都需要花费数月的时间。在写出第一行产品代码之前，甲乙双方需要花费大量精力确定需求范围，审核比《新华字典》厚得多的软件需求规格说明书。即便如此，双方还是要为“是否发生了需求范围的变更”“是否准时交付了软件”“交付的软件是否满足了预先设定的业务需求”而纠缠不清。

1.1.2敏捷软件开发方法

从20世纪80年代开始，微型计算机开始快速普及。20世纪90年代，人们对软件的需求迅速扩大。然而，Standish Group的Chaos Report 1994显示，软件交付项目的失败或交付困难的比率仍旧很高（成功率只有16.2%，受到挑战的项目占比52.7%，而失败率为31.1%）。此时，很多优秀的软件工作者不满意瀑布软件开发方法的交付成果，并在各自工作实践中总结了各种新的软件开发方法，例如我们现在经常听说的Scrum和极限编程，都是在那个时代涌现出来的软件开发方法。

2001年，17位软件大师齐聚加拿大的一个小镇——雪鸟（Snowbird），总结了当时涌现的这些轻量级软件开发方法所具备的特点，共同发表了“敏捷宣言”，提出敏捷软件开发方法应该遵循的十二原则，见附录A。与会人员一致同意，凡符合这一宣言所倡导的价值观且遵循十二开发原则的方法均可被认为是“敏捷软件开发方法”。因此，“敏捷软件开发方法”这一说法从其诞生开始就是一簇软件开发方法的代名词，而不是特指某一种软件开发方法。

敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。此时，很多团队已认识到，软件开发实际上是一个不断迭代学习的过程，即软件工程师需要快速学习并理解领域知识，并将其转化成数字世界的表达形式，通过与业务专家的交流讨论来学习并持续迭代这个过程。一个软件交付计划被划分成多个迭代，强调在每个迭代结束时应该得到可运行的软件，如图1-2所示。

图1-2迭代开发，多批次部署发布

与瀑布软件开发方法只在项目交付后期才能看到可运行的软件相比，敏捷软件开发方法在这方面有很大的进步。“持续集成”作为敏捷开发方法中的一个工程实践，率先被更广泛的IT组织所接受，即便那些没有采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作量，也排除了开发团队与质量保障团队之间的沟通障碍。

当时的主流软件需求仍旧是来自企业级定制软件开发。虽然敏捷开发方法使用的是迭代模型，但两次软件发布之间的间隔时间仍旧较长（通常是数月，甚至一年以上）。因此，业务人员与研发团队之间关于需求变更和研发效率的矛盾仍旧是主要矛盾。系统的部署发布工作在整个发布周期中所占用的时间和成本相对较小，部署和运维工作还不是突出矛盾。另外，部署活动通常由专门的技术运维团队执行，产品研发团队对其无感。

在这一时期，无论瀑布开发还是敏捷开发，在软件行业中最重要的关注点都是可交付的软件包本身，即如何快速地将软件需求变为可交付的软件包。

1.1.3DevOps运动

DevOps的萌芽源于2008年8月敏捷大会多伦多站的一个临时话题“敏捷基础设施（Agile Infrastructure）”。当时比利时独立IT咨询师Patrick Debois非常感兴趣，并且分享了关于“将敏捷实践应用于运维领域”。2009年10月，Patrick在比利时的根特组织了一个“DevOpsDays”社区会议，并正式启用了“DevOps”这个术语。

2010年“The Agile Admin”网站上发表的一篇题为“What is DevOps”（什么是DevOps）的文章中指出：“DevOps是一组概念集合的代称，虽然并非全部都是新概念，但它们已经催化为一种运动，并迅速在整个技术社区中传播。”同时，该文章也给出了其原始定义，即“DevOps是运维工程师和开发工程师参与整个服务生命周期（从设计到开发再到生产支持）的一组实践”，并提出，DevOps应该倡导运维人员更多地使用和开发人员使用的相同技术来进行系统运维工作。

DevOps在维基百科上的定义也在随着时间的推进而不断变化着。截止到2017年，其定义为：

DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。

事实上，到写作本书之时，业界对DevOps并没有统一的标准定义。正如“敏捷”一样，每一位从业者、每一个企业都有自己所理解的DevOps。有些人认为DevOps是敏捷的一个子集，有些人认为“敏捷做对了，就是DevOps”，还有人则将DevOps看作围绕自动化实施的一套实践，或多或少与敏捷有些关联性。

从历史时间点上来看，DevOps源于敏捷思想和实践在运维领域的应用，但当时的实操指导性不足，而近乎同期出版的《持续交付》一书使其更加具象化，在企业实践方面更具有可操作性。书中给出了一系列的原则、方法与实践，使DevOps运动的参与者有线索可循，例如持续交付中强烈倡导的“一切皆代码，自动化一切，部署流水线尽早反馈”等。

DevOps并非一个标准、一种模式或者一套固定方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。

既然DevOps是一种组织管理的发展趋势，那么它就是IT领域普适的。对于不同行业、不同企业中的IT组织，需要根据其所在行业的行业特点以及企业实际状况进行一系列的管理定制。

1.1.4持续交付1.0

2006年，Jez Humble、Chris Read和Dan North共同发表了一篇题为“The Deployment Production Line”（部署生产线）的文章。文中讨论了软件部署带来的生产效率问题，并首次提出“部署生产线”模式：

……测试和部署是软件开发过程中最困难且耗时的阶段。即使团队已经使用自动构建完成了代码的测试工作，也需要几天时间做生产部署的情况仍旧很常见……我们描述的原则和实践使你可以一键创建、配置和部署新的环境。

……通过多阶段自动化工作流程，测试和部署过程可以完全自动化。利用这种“部署生产线”，可以将已经过验证的代码快速部署到生产环境中，并且一旦发生问题，就可以轻松地回退到以前的版本。

该文章的3位作者当年均就职于ThoughtWorks公司，而该公司是敏捷软件开发方法的践行者、倡导者和推广者。该公司使用的软件开发方法也源自极限编程方法。作者通过各自的实践总结出了“部署流水线”模式的雏形，并且对如何使自动化部署活动更轻松给出了以下4条指导原则。

（1）每个构建阶段都应该交付可工作的软件，即对于中间产物的生成（例如搭建软件框架）不应该是一个单独的阶段。

（2）用同一个制品（artifacts）向不同类型的环境部署，即将其与运行时配置分开管理。

（3）自动化测试和部署，即根据测试目的，分成几个独立的质量关卡。

（4）这个部署生产线设计也应该随着你的应用程序的发展而不断演进。

2007年，ThoughtWorks公司的Dave Farley也发表了一篇题为“The Deployment Pipeline - Extending the range of Continuous Integration”（部署流水线——持续集成的延伸）的文章。文中指出，部署流水线就是通过自动化方式将多个质量验证关卡及其中的验证内容联系在一起，如图1-3所示。

图1-3Dave Farley在2007年定义的部署流水线

同年12月，ThoughtWorks在北京正式组建了产品研发团队，启动了以这种部署流水线为指导思想的软件持续发布管理 工具 的研发。当时Jez Humble是产品经理，我负责该产品的交付与业务分析。该产品的第一个版本发布于2008年7月，取名为Cruise（现名为GoCD）。其最重要的一个功能特性就是“部署流水线”（deployment pipeline）。而且很多特性设计（包括内置的制品仓库、多阶段之间的制品引用）也体现了“一次构建，多次使用”的原则。

在开发GoCD期间，Jez Humble和Dave Farley合著了《持续交付》（ Continuous Delivery

）一书，英文版于2010年正式出版，该书于2011年获得Jolt杰出大奖，中文版也于2011年在国内上市，这标志着“持续交付”这一术语的正式诞生。Jez Humble说：“持续交付是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。”本书将这一定义称为“持续交付1.0”。

在《持续交付》一书中，讲述了持续交付1.0所遵循的理念、原则和众多方法与实践，并在该书最后一章指出：“它不仅仅是一种新的软件交付方法论，而且对依赖软件的业务来说，是一个全新的范式

。”

持续交付1.0提供的很多原则及方法是DevOps运动的具体实操指引，它们可以为企业的IT团队将DevOps运动落地实施提供非常具体的指导，如图1-4所示。

图1-4持续交付将发布权交还给业务方

从所涉及的协作角色来看，敏捷开发更多地涉及产品需求方、软件开发工程师和软件测试工程师。在历史上，DevOps更多地涉及软件研发团队（包括开发工程师和测试工程师）与运维工程师，而持续交付1.0涉及产品需求方、软件研发团队和运维工程师，如图1-5所示。

图1-5相关概念在组织角色的主要触达点

1.2持续交付2.0

持续交付1.0关注于“从提交代码到产品发布”的过程，如图1-6所示，并且提供了一系列工作原则和优秀的实践方法，可以提升软件开发活动的效率。

图1-6持续交付1.0的关注点

但是，我在实际咨询过程中发现，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。可是，这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。这种“无用”的功能生产得越多，浪费就越大。我们是否可以找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就可以验证对业务无效呢？

1.2.1精益思想

2011年出版的《精益创业》一书给了我一些启示。其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品（Minimum Viable Product，MVP），这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。

Eric Rise在书中强调，精益创业就是一个“开发—测量—认知”的验证学习过程，如图1-7所示。也就是说，把创意快速转化为产品，衡量顾客的反馈，然后再决定是改弦更张，还是坚守不移。

该书主要关注于创业初始阶段，将精益思想贯穿于产品“从0到1”的过程。事实上，它也可以用于产品“从1到 n

”的过程中。

1996年，Womack、Jones和Roos在《精益思想》一书中指出，精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。

图1-7“开发—测量—认知”环

在精益管理理论中，“浪费”是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。并指出，业务生产中所有活动都可以归结为以下两种活动，也就是增加价值的活动和不增加价值的活动，而不增加价值的活动就是浪费。在被归类为“浪费”的活动中，又可以分为必要的非增值活动和纯粹的浪费。必要的非增值活动是指从客户的角度看虽没有价值，却可以避免（潜在的）更大的浪费或降低系统性风险的活动，如图1-8所示。

图1-8软件产品开发中的活动浪费

例如，生产流水线上的装配工作是增值活动，质量检查是必要的非增值活动，而因材料供应不足产生的生产等待以及因质量缺陷导致的返工都被认为是不必要的浪费。在软件产品服务的全生命周期中，也同样包含多种“浪费”，例如，无效果的功能特性、各生产环节中的等待（如图1-9所示）、没人看的文档、软件缺陷、机械性的重复工作等。

图1-9用户视角的增值活动与浪费

尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断地优化流程与工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。

1.2.2双环模型

自2009年Flickr（一个聚合全球知名热门图片分享网站）声称其网站每天部署10次之时起，“主干开发+持续集成+持续发布”已成为硅谷知名互联网公司应对VUCA环境的一种主流软件研发管理模式。这种变化的原动力并不是来自技术团队本身，而是来自业务与产品方的诉求。为了在VUCA环境中更快地了解海量用户，快速验证大量业务假设和解决方案，他们改变了业务探索的模式，并催生了软件研发管理模式的改变，两种模式相互促进，从而形成了互联网软件产品研发管理的双环模式，即“持续交付2.0”，如图1-10所示。

图1-10持续交付2.0的双环模型

“持续交付2.0”是一种产品研发管理思维框架。它将精益创业与持续交付1.0相结合，强调业务与IT间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。

对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付“8”字环。

它由两个相连的环组成：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动，如图1-10所示。

探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。

（1）提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。

（2）锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。

（3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。

（4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。

验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。

（1）构建：是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。

（2）运行：是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。

（3）监测：是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。

（4）决策：是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。

探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度；如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。

1.2.34个核心原则

“持续交付2.0”是指企业能够以可持续发展的方式，在高质量、低成本及无风险的前提下，不断缩短持续交付“8”字环周期，从而与企业外部频繁互动，获得及时且真实的反馈，最终创造更多客户价值的能力。下面逐一介绍缩短持续交付“8”字环周期的4个核心工作原则。

1．坚持少做

在咨询的过程中，最常听到的一句话就是：“我们最大的问题是人力不足。”无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。

Moran在 Do It Wrong Quickly

一书中写道：“Netflix认为，他们想做的事情中，可能有90%是错误的。”Ronny Kohavi等共同发布的文章“Online Experimentation at Microsoft”中也指出，在微软，“那些旨在改进关键指标而精心设计和开发的功能特性中，只有1/3左右成功地改进了关键指标”。

正如当年Mike Krieger（Instagram的联合创始人兼CTO）被问及“5个工程师如何支持4000万用户”时所说的那样——“少做，先做简单的事情”。

2．持续分解问题

复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。

3．坚持快速反馈

当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。

4．持续改进并衡量

无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。

某数据公司就曾因无度量数据，而无法提出有效改进方向的情况。该系统是一个数据标注志愿者招募考试系统。虽然它被分成多个迭代，每个迭代都发布了很多功能，但是，由于没有实现产品人员所关注的数据收集与统计分析功能，使得团队仅知道人们可以使用这个系统完成工作，却无法知道是否能够高效完成工作，也很难提出下一步的产品优化方向。

1.2.4持续交付七巧板

我们讨论了“持续交付2.0”的指导思想、工作理念和核心原则。大家很容易意识到，它对适应快速变化的市场环境和激烈的市场竞争是非常有效的。那么，企业如何让“持续交付2.0”成为一种组织能力，成为组织的DNA，持续发挥作用，从而领先竞争对手，成为自己的一种竞争优势呢？

持续交付双环模型的实施与改进将涉及企业内的多个部门与不同的角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行“持续交付2.0”的思想、理念与原则。企业需要在组织管理机制、基础设施以及软件系统架构3个方面付诸行动，而每一个方面都包含多项内容，如图1-11所示。

图1-11持续交付七巧板

条条大路通罗马，而且，罗马也不是一天建成的。每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。正如中国传统玩具七巧板一样，每个企业都应根据自己的意愿和诉求，拼出属于自己的持续交付实践地图。

1.3小结

“持续交付2.0”建立在“持续交付1.0”的“可持续地快速发布软件服务”及精益创业的“最小化可行产品”两种理念基础之上，强调要以业务为导向，从一开始就将业务问题进行分解，并通过不断的科学探索与快速验证，减少浪费的同时，快速找到正确的业务前进方向，简称为“双环模型”。因此，其涉及组织中的多个团队，需要各个团队之间紧密合作，才能缩短“8”字环的周期，如图1-12所示。

图1-12持续交付2.0的相关角色

“持续交付2.0”的4个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。只有这样，才能不断缩短持续交付“8”字环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。这要求管理者跳出原有软件交付管理思维模式，摆脱“害怕失败”的恐惧感，拥抱“科学探索—快速验证”思维方法，快速试错，提升持续交付能力，进而发展现有业务，并快速开创新业务。