编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

今天，大部分企业不再怀疑 DevOps 实施的必要性，并开始行动。问题是，小范围实施效果不错，但一扩大范围就会遇到各种问题，无法达成预期。DevOps 的规模化实施存在诸多陷阱。

要想成功规模化，首先要理解规模化的真实含义，其次是选择有效的规模化路径。接下来我们会从这两个方面为规模化实施提供策略性的指导。

规模化的真实含义

不同人讲规模化时，背后的意思可能千差万别。比如：有人关注人数规模；有人更关注深度；而另一些人则关注规模化方法框架的推广。

为了有效的规模化，首先必须对规模化达成一致的理解。而要达成一致的理解，就必须回到规模化的目标这一本源上来，也就是为什么要规模化。我们从业务出发，认为规模化的目标有两层：

第一是“系统”——延伸至端到端的系统。DevOps 的启动可能会从某个或某几个环节开始，比如从部署环节开始。但，我们必须逐步延展实施范围，打通从业务、研发到运维的整个链路。只有这样，才能带来系统性的改变，实现快速的交付、稳定的运行和即时有效的闭环。

第二是“普惠”——让更多的业务或同一业务各个组成部分都受惠。DevOps 是为了服务企业的数字化，它涉及企业不同的独立业务，或同一业务的不同职能，如：一个业务线中的客户管理、内部运营、生产制造、服务交付等。DevOps 的实施要让更多的业务部门从中受惠，这样才能支持组织的整体数字化转型。

综合以上两点，规模实施的目标就是：让更多业务，更系统性地受惠。DevOps 的规模化实施就是要寻找平滑和可持续的路径来实现这一目标。

设计和选择规模化的路径的原则

DevOps 的规模化实施是一个转型过程。它涉及到技术、流程和组织的变革，甚至是权力和利益的再分配。

转型从来不易，“以复杂对规模”是 DevOps 转型最常见的误区。

规模带来复杂性，直觉上复杂的状况需要复杂的解决方案。于是乎，就出现了各种复杂的规模化框架，比如各种复杂的规模化敏捷框架。然而，照搬规模化框架很少带来好结果，反而带来各种问题。

首先，任何方案的实施都要以对现状的理解为基础，比如说现有的组织结构、对新方法的接受度、具体的业务特征、技术成熟度等。脱离具体的上下文，照搬“普适”的框架，会带来巨大的适配成本。前期花费大量精力在组织和流程上，却不直接改善交付效能，特别是业务可见的效能。这非常容易带来怀疑和抵制，让实施效果大打折扣，甚至半途而废。

其次，为了普适，各种规模化框架都会定义统一组织结构、角色职责、流程机制，引入复杂机制，却无法适配现实的多样性。结果是，老的模式无法被替代，又叠加一套新的机制，复杂度不减反增。复杂的组织结构、流程机制以及更多的角色，这些会加大实施难度，降低实施效果，即使取得暂时的成果，也很难维持。

照搬规模化的框架不行，那该如何做呢？我们必须回到规模化实施的目标——“系统”和“普惠”上，并在具体的上下文中，选择自己的规模化路径。为此我们提出了 DevOps 规模化三原则：

原则一：业务驱动原则。以业务的视角衡量 DevOps 的实施效果，并驱动 DevOps 的实施。

业务驱动是 DevOps 规模化的基本原则。判断方案的好坏，必须要有标准，但它不应该是个人喜好或各个部门的利益。只有业务的成功能成为大家的共同标准。

以业务视角来衡量和选择方案，才能凝聚各个角色的共识；以业务目标驱动 DevOps 实施，更能拉通各职能的协作，保障实施的系统性；以业务为单元来实施 DevOps，也能让实施的边界和节奏更加清晰，尽早取得可感知的业务结果。

原则二：去规模化原则。面对复杂的组织，先“去规模化（Scale Down）”再水平扩展（Scale Out）。

为了更好的规模化，我们绝不应该以复杂来应对复杂、以规模应对规模。恰恰相反，我们首先要做的是“去规模化”。

再大组织，也是由一个个业务和产品交付团队构成的。相对闭环的业务和潜在可独立交付的产品，这是实施的基本单元。我们应该解耦复杂的组织，识别可独立实施单元，把复杂性尽量控制在实施单元以内，而在实施单元之间维持尽可能松的耦合，如：不同业务单元之间通过定期的目标对齐，而不是统一的交付规划来连接；关联的产品之间以业务规划来拉通，而减少执行上的耦合。

以去规模化（Scale Down）为基础，在相对独立的单元以尽可能简单的方式实现系统性的转型。我们就可以基于成功的经验复制和水平扩展（Scale Out）出去。水平扩展是源自系统设计的原则，如：互联网网络和云计算基础设施都遵循水平扩展原则，让它们能走到了今天的规模。它同样适用于 DevOps 的实施。

原则三：渐进原则。从现状出发，寻求持续且渐进的改进。在系统改进目标的牵引下，以小步前进，每个小步都带来改进，最终实现系统和全面的转型。

渐进不是妥协。恰恰相反，它是在明确且坚定的最终目标下选择更坚实和可持续的路径。对于转型，现状是我们要改变的东西。但改变必须从理解和尊重现状开始。识别 DevOps 实施的基本单元的基础之上，或者从局部环节开始到拉通整体价值流，或者是先拉通整体价值流，再在各个环节深入，最终实现整体的目标。

规模化转型的实例和策略

介绍完 DevOps 规模化三原则，我们看两个具体的演进路径实例。

路径一：自下而上，从产品交付到业务

从产品交付团队到端到端业务

上图所示的是一个最典型的路径，它采取的模式是从局部延伸至整体。

首先，从产品交付团队开始，建立产品交付团队的持续交付能力，比如：引入精益和敏捷需求实践，梳理需求交付的端到端的价值流，建设持续集成和持续交付的工程能力，形成持续或迭代的交付模式。

接下来，以产品交付团队的持续交付能力为基础，通过业务拉通和对齐各个产品，将价值流从产品交付延伸至端到端的业务，实现持续顺畅地业务价值交付，建立快速的反馈闭环，保证价值的有效性。

这一模式的优点是启动相对容易，但是取得显著的业务效果会相对滞后。对于技术部门主导的 DevOps 转型可以尝试这一模式。重要的是，技术部门的改进，最终一定要拉通并体现到业务效能上。

路径二：自上而下，从业务到产品交付

从端到端业务到产品交付团队

上图是另一个实用的路径，它采取的模式是从整体拉通开始，再寻求局部深化。

首先，从业务价值出发，梳理业务需求交付的端到端流程并形成反馈闭环。此时我们追求的是整体拉通，从一开始就关注整个系统。通过价值流的可视化和优化，就已经能够带来初步业务交付的改进。当然，更深度的改进，还需要深入各个局部。

接下来，在整体拉通的基础上，识别各个环节中的瓶颈和效率问题，驱动各个产品交付团队的变革，引入敏捷和精益的协作方式，和持续交付的工程实践。

这一模式的优点，以系统的优化驱动整个变革过程，更容易保证实施的业务结果和系统性的改进。但是，它要求组织，特别是业务层面对 DevOps 的高度认可和决心，并且要求实施者对系统改进有深入的认知。对于业务或高层主导的 DevOps 实施，可以尝试这一模式。

以上两种路径，不管是自上而下还是自下而上，它们有两个共同点。

首先，解耦各个业务线，把业务线当成衡量 DevOps 实施效果的基本单元，也就是我们前面所说的“去规模化”。通过去规模化实现更加平滑和可持续的规模化，这是一对矛盾的统一。

其次，最终都要走向以业务驱动的端到端的优化，实现 DevOps 规模化的目标，让更多业务，更系统性地受惠，这也是殊途同归。

现实中的转型路径往往是以上两者的混合体，是自上而下和自下而上同步进行，只不过不同时间的侧重不同。

DevOps 规模化三原则和实施三步工作法配合，相得益彰

以上我们介绍了 DevOps 规模化的三原则，并基于它给出了建议的规模化路径。

在概述部分，我们还介绍了 Kim 等人提出的 DevOps 实施三步工作法，它是 DevOps 的实施的实用且有效的指导，具体包含：

• 流动原则：聚焦 IT 系统的整体价值流，全局优化，保证价值从左（上游）到右（下游）的快速流动。
• 反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。
• 持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。

DevOps 实施三步工作法，可以应用在于各个层面的实施，如：业务层面、交付团队层面、持续交付工程实践的落地等。

DevOps 规模化三原则为 DevOps 规模化路径选择提供建议；DevOps 实施三步工作法则为具体的实施提供指导。它们相辅相成、相得益彰。

总结

为了支持组织的全面数字化转型，DevOps 的规模化应用是必然选择。但，规模化实施绝不等于实施复杂的规模化框架。恰恰相反，在规模化的路径选择上，我们应该以业务为驱动，寻求简单、可持续的方案，而“系统”和“普惠”是 DevOps 规模化的最终目标。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。