《DevOps 精要:业务视角》- 读书笔记（一）

第1章 什么是DevOps

IT管理方法不是一成不变的。如今，信息系统开发和运维所使用的方法明显区别于几十年前的。这些方法一直在演进，明天可能又会出现下一代基于新的知识、经验和技术的方法。大多数时候，管理方法会基于某些基本的原理和假定，打磨之前已有的模型并使之体系化，逐渐地演进。但是，时不时也会出现一些非连续的情况，个别领先组织在信息技术的有效与高效应用上，已经大步向前迈出了重要的步伐。

IT管理从聚焦于IT系统，转变为聚焦于IT服务的管理，就是一个很好的例子。如图1.1所示，从2000年左右开始，对于管理的认识变化，使得领先者赢得了重要的竞争优势。这些涌现出来的管理实践，被先行者成功采纳之后，成为了所谓的最佳实践.有些最佳实践进一步演进为被业界广泛接受的做法，甚至对行业标准产生了影响。当然，也有些组织并没有在工作中应用这些最佳实践或标准，因为在那个时候，并非所有的经济领域都显著依赖于IT。

我们以IT服务管理为例来看一看。在20世纪80年代，这样的想法开始出现：信息技术以服务的形式提供价值，并以流程的形式组织IT活动。有些欧洲公司成为先行者，他们发展出组织工作的新实践及解决管理问题的新方法。其中有些实践，例如服务台的引入、事件和问题的区分、IT基础设施变更的受控过程等，在2000～2001年的ITIL等重要出版物（那时ITIL代表IT基础设施库）

最终，在2002年，BS15000-1:2002即IT服务管理的首个标准发布，这为那些寻求构建一个连贯的IT服务管理系统的组织而言，建立了一个可以遵循的具体标准。也就是说，实践、出版物和标准，都未曾停止过发展的脚步，如图1.2所示。

从敏捷软件开发中，也可以观察到类似的发展动态。然而，这次酝酿的革命所影响的范围，已经超出了软件开发本身，带来的影响面不亚于当年的ITSM。

如今，新涌现出来的实践，被打上DevOps（开发+运维）的标签。实际上，DevOps的内涵，如同ITIL超出“库”的概念以及COBIT超出受控对象的含义一样，已经大大超出其原始的含义。

这么说来，DevOps的现象值得研究。要想理解DevOps的完整要义，需要结合相关的背景来了解其思想连同与之关联的运动。

1.1 起源

一般认为，DevOps的出现源于两个因素：敏捷软件方法的广泛采用以及IT基础设施即程序代码的管理方式。我们分别来看一看。

1.1.1 敏捷软件开发方法

在20世纪末期，主流的软件开发方法是图1.3所示的所谓“瀑布模型”：顺序式执行预定义的阶段，每个阶段花很长时间，并以达成先前协商好的结果作为结束；很多时候，只有在前一个阶段已经完整且正式完工时，才能转移到下一个阶段。这个模型的另一个显著特征是，每个阶段所涉及的人员职能有专业化的分工：分析师、架构师、开发人员和测试人员等。

当开发的是功能可预先定义、对快速产品交付没有或很少有要求的大型信息系统时，这个模型能够确保我们创建高质量产品并进行有效与精细的成本控制。

然而，在20世纪90年代末期，随着互联网技术与Web编程的快速发展，瀑布模型的消极作用开始显现，影响到信息系统客户（内部或外部业务）与提供者（内部或外部软件开发者）之间的交互和理解。事实上，对业务客户的市场机会不断涌现，这要求团队能够快速发布（最多在几个月之内）新产品到市场上。然而，从项目启动到第一个可运行原型的典型开发闭环，可能要花6到18个月时间；而在大型企业中，甚至需要2到3年。此外，随着很多在之前并不为人知晓但有潜在前景的市场机会涌现，客户的需求在开发过程中很可能会发生变化，这样一来，要有效应对市场机会而不延误截止日期，且同时还不降低产品质量，就变得极为困难，如图1.4所示。

因此，这就造成了客户与提供者之间的紧张关系，这种紧张关系存在于核心业务与软件开发者之间。创新性的开发方法是应对这个挑战的答案。

Ken Schwaber（肯·施瓦伯）出版了几本关于Scrum ，Kent Beck（肯特·贝克）出版了《极限编程》。不过，这些新想法的应用效果差强人意，主要因为它只关注于软件开发周期的其中一个阶段——即实际开发阶段，而所遇到的问题往往涉及更大的范围。端到端的软件开发周期需要简化和加速。

2001年，Schwaber（施瓦伯）、Beck（贝克）与其他15位专家联合发起一场聚会，共同讨论当前的问题并尝试找出解决方案。这次聚会的成果就是著名的《敏捷宣言》，用以弥补业务与软件开发之间的空白。敏捷宣言的其中一位作者罗伯特·马丁（Robert C. Martin）如此解释道：

“当使用正确的准则及正确的最简过程的时候，开发者与业务方之间的信任就能自然浮现并发展起来。业务方会开始信任开发者，而不再认为他/她们是慵懒、讨厌的生物，开发者也会开始关注业务，并意识到他/她们是理性与理智的人，而不是从其他星球来的物种。”

敏捷宣言
我们一直在实践中探寻更好的软件开发方法，在身体力行的同时也帮助他人。由此，我们建立了如下价值观：

• 个体和交互 优先于 流程和工具
• 可工作的软件 优先于 面面俱到的文档
• 客户协作 优先于 合同谈判
• 响应变化 优先于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

我们遵循以下原则：

1．我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2．欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
3．经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4．业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5．激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6．不论团队内外，传递信息效果最好效率也最高的方式是面对面的交流。
7．可工作的软件是进度的首要度量。
8．敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9．坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10．以简洁为本，它是极力减少不必要工作量的艺术。
11．最好的架构、需求和设计出自自组织团队。
12．团队定期地反思如何能提高成效，并依次调整自身的举止表现。

随后，编程人员和项目管理者社区发展并采纳了敏捷方法，极大地加速与重构了软件开发。敏捷开发的关键元素有客户与开发者之间更紧密的交互、批量大小的降低、以短间隔（周期）交付的产品以及团队的有限规模。使用敏捷方法，软件开发团队每隔2到4周发布一个新的可行产品。最终用户可以更近距离地参与到开发过程当中，确保快速的反馈，并由此激发更快速的变更。

但是在许多公司，弃用瀑布模型转向敏捷开发的实际效果却小于预期。从这些公司中观察到的敏捷收益缺失，通常与瀑布的优势或者敏捷的劣势无关。事实上，问题的根源在于代码开发仅仅是一个很长的价值链中间的一环。

实际上，在开发之前还有不少的环节，比如致力于识别业务需求并对这些需求进行阐释、分析和排序等。此外，在开发之后应用需要快速部署到生产环境，以便客户能收到向自己承诺的所有收益，并提供反馈给开发人员。然而，对于成立于2010年之前的IT组织，IT基础设施几乎都是基于多年前采购的刚性、昂贵的硬件，它们获取IT预算很难，新采购的预算流程也相当长。

还有，在大量的组织中，基础设施处在相当脆弱的状态中。造成这种脆弱性的一个因素，是IT解决方案极其复杂，在基础设施中可能有成千上万个相互连接的组件。另一个因素可能是缺乏IT系统文档以及这些文档的迅速过时，人员的流失又持续加剧了知识的遗失。

在许多组织中，触碰IT基础设施是相当不安全的。变更对IT运维部门来说，是一个最大的“梦魇”，而不断到来的变更“洪流”，真的可能招致灾难性的后果。

这样一来，就降低了使用敏捷方法可能获得的积极收益，先进的软件开发方法由于IT运维侧的阻碍而停滞不前。为了处理IT基础设施的脆弱性，有些组织使用规范化与自动化的变更管理流程，以规范变更流以及最小化与变更实施相关联的风险。

1.1.2 管理基础设施即代码

在基础设施即代码的管理方式涌现之前，有两种技术已经发展起来：虚拟化和云计算。

虚拟化
软件和硬件环境虚拟化的历史始于很久以前，可以追溯到1964年IBM CP-40操作系统的发展。经过多年的持续发展，虚拟化技术取得了可观的进步。大型机上的首个可商业化应用的系统出现在20世纪70年代，那些基于Intel x86架构的更通用的机器所用的系统，出现在20世纪80年代。图1.5显示了从1964年到2008年与虚拟化有关的关键事件数量，如果我们能看得更远，这个图上的数据在近年来并没有停歇。

虚拟化不仅使更有效地使用昂贵而强大的硬件成为可能，还在提供有用功能的可执行代码与背后的系统软件之间引入了一个额外的抽象层。这在分离“应用工程师”和“系统工程师”的能力与职责的方向上迈出了重要的一步，也为这些概念建立了更广泛的认知。

云计算
云计算技术的发展更快。到了20世纪90年代中期，电信公司给它们的客户提供了广域网（WAN）服务，通过直接布线将每个客户的相关端点连接起来。但是，随着专用虚拟网络技术（VPN，虚拟专用网）的涌现，通过同一个数据传输信道来发送不同客户的数据包，并提供必要层级的安全性、私密性与服务质量，都成为可能。在那个时候，云服务供应商开始使用云的符号来标识客户专用网络和共享网络之间的边界及各自职责的分离。

有了长距离传输数据的新能力，客户开始使用这种技术，不仅是在远程系统之间交换信息，也可以在多个网络结点之间分布计算负载。随后，让这个交互过程变得简单与廉价的技术也出现了。小型的去服务供应商迈出了最初的步伐，但真正重大的变化出现在2006年，在这一年亚马逊推出了ECC（可伸缩的计算云）。很快，在2008年，微软发布了它的服务Azure，谷歌也推出了Google App Engine，之后升级为Google Cloud Platform。当然，这些并不是出租云计算能力仅有的例子，但它们最有影响力。

虚拟化与云技术已经显著改变了计算领域的格局。商业提供者提供的资源已经成为负担得起且可靠的选择，同时也保证了必要级别的安全性。客户对云的态度及应用，也从“有人正在某个地方控制着我的硬件”，转变为“我远程管理着我的基础设施”。

美国国家标准与技术协会识别了云计算的5个本质特征：

• 1．按需自服务。消费者可以视需要单方面配置计算能力，如服务器时间和网络存储，这通过自动化的方式实现，无需与各个服务供应商进行人工的交互。
• 2．宽泛的网络接入。通过网络提供能力，并通过可促进异构廋/胖客户平台使用的标准机制来接入。
• 3．资源的池化。供应商的计算资源被池化，使用多租户模式服务于多个客户，基于客户需求来动态分配或重分配不同的物理或虚拟资源。
• 4．快速的伸缩性。能力可以被可伸缩地配置和释放，有些情况下可自动进行，以快速匹配需求而向外或向内扩展。对消费者而言，可配置的能力通常看起来是无限的，并且可以在任何时间以任何数量进行分配。
• 5．可度量的服务。云系统利用适合相应服务类型的某种抽象度的度量功能，自动控制及优化资源使用。

**远程管理基础设施意味着什么？**让我们回忆UNIX系统的关键范式之一：系统所有必要的动作，都应该能够通过命令行（所以使用脚本）来访问。图形化的用户界面很美，但它不是必需的。

现在，我们结合虚拟的云技术和命令行界面来处理所有任务。结果是，IT专业人士能够使用文本命令创建其所需要的IT基础设施组件，包括服务器、存储系统、网络组件以及它们之间的所有接口、设置和配置。自动化程度得以大幅提升，因而变更实施的速度也大幅提升。之前，基于内部硬件来部署一个IT基础设施，需要以下流程：

• 申请与审批预算（几周或几个月）。
• 等待下一个采购周期（几个月）。
• 给供应商下订单及支付（几天）。
• 等待交付（几周或几个月）。
• 接收、安装、配置及准备使用（几天或几周）。

今天，创建类似的IT基础设施，可能只需要走两个流程：

• 运行一个脚本，等它执行完毕（几分钟，很少会是几小时）；
• 在月末与云提供商结账。

也就是说，只需要程序代码，就可以创建出所需的基础设施。不光只是创建，还可以把基础设施视同代码进行管理：进行版本控制、变更追踪、调试、重用之前版本等。

结束这部分之前，我们也承认，有些相对老旧的技术已经获得了第二次生命。例如，操作系统层面的虚拟化，在20世纪80年代的许多UNIX系统上就已经做到了。然而严格来说，这项技术的商业化成功，即通常被称为容器化的技术，到21世纪前10年的后半段才出现，这与前面描述的事件相吻合。当初的chroot机制在功能和能力上颇受制约，而如今在容器之间隔离文件系统、分配磁盘空间、限制可用RAM/处理器时间或I/O带宽等，都已然成为可能。

1.1.3 这是必然的

“有人说这是必然的，当你听到有人这样说时，很可能有大批企业正在为实现它而努力。”——理查德·斯托曼（Richard Stallman）

通过对DevOps起源的回溯，我们可以得出以下的结论。

• 首先，由于与业务客户交互的新方式的涌现以及敏捷开发技术的充分应用，对新的IT管理方法的需求变得愈加迫切。
• 其次，随着新的基础设施管理技术的涌现，用不一样的方式来组织IT工作，也成为了可能。
• 用现实的视角来看待前面理查德·斯托曼（R. Stallman）的话（虽然看起来他对云计算似乎有些误解），我们可以断定，迟早会出现某种类似DevOps的东西。

1.2 定义

只有那些非常自信或极不称职的人以及公认的大师，才会在不下定义或不依赖于一个被广泛接受定义的情况下严肃讨论一种现象。不幸的是，对DevOps来说，这件事情远没有这么简单。

有些专家试图按照他们的理解创造一些自己的东西。其他一些人则主张，因为DevOps更像是一个现象、一场运动、一个想法，而不是一门学科或一种方法论，因而当下不可能给它下一个定义。还有人说，每个人都可以有自己的DevOps，还提供一个著名的盲人摸象的比喻，说什么有人说它最像一棵树，有人说它像一块毯子，第3个人说它像一条蛇，等等。

为了研究这个话题，我（作者）阅读了大量的书籍和在线出版物，与俄罗斯以及欧洲其他国家参与DevOps运动的不同人员进行交流，参加各种专业培训，并通过了几个国际认证考试。在我看来，不可能定义DevOps这件事在某种程度上被夸大了。当然，有这么多的人，这么多的观点，而且当遇到咨询顾问时，这件事变得更难琢磨，因为2个顾问会至少提出3个观点。然而，凭借系统性的思维、IT的专业学位以及在IT管理领域的咨询经验，我发现还是有机会以一种清晰和结构化的方式来探讨这个话题。目前，我总结出如下的定义，虽然仍不敢说这是业界通行的或者是终极真理：

“DevOps是对敏捷软件开发与精益生产思想的演进，应用于IT端到端的价值链中，使得业务基于现代信息技术，并通过文化、组织与技术变革来获得更大的成功。”

在这个定义中，有4个重点需要强调。

• 首先需要指出，DevOps并没有取代敏捷及精益实践，而更像是吸收了两者。我跟同事、客户和培训学员进行了很多交流，发现不熟悉敏捷开发的人在DevOps中找到了很多新奇与有趣的东西。有相关培训和经验的人，则为DevOps与精益、Scrum和看板等其他实践之间的很多重叠而感到诧异。在我看来，把这个现象称作“重叠”也不尽准确，DevOps更多地是从敏捷开发和精益生产中借用及扩展了思路，这方面的话题会在第2章中展开讨论。
• 其次，DevOps的本质在于这样一个事实，即IT部门与业务部门所考虑的不仅是软件开发，而是整个价值链。价值链始于业务干系人产生的新想法，经过开发、测试和部署，最后到运维。这个方法有助于在端到端价值链中分析、识别及消除瓶颈。它建立的反馈回路，不仅是从价值链的末端回到始端，也包括每个步骤之间乃至每个步骤之中产生的反馈。DevOps对系统性方法、基于约束工作、实现反馈等要素给予极大的关注，这些会在后文中详细描述。
• 接下来，强调应用DevOps所获得的预期价值也很重要，这体现了信息技术带来的更大回报。通常的看法是，信息技术使得组织可以获得更多的收益（通过创造新机会或者消除现有约束）、降低风险并优化资源。如果应用得当，DevOps可以处理好这3个方面。这并不是说组织没有DevOps就不能以传统方式从信息技术中获益。然而，DevOps提供了更大的价值，体现为加速新产品及产品补丁上市、更快响应客户需求、改善IT系统可用性与可持续性、更高效使用有限资源等。这些话题会在1.3节中展开讨论。
• 最后，在定义的末尾明确地指出了如图1.6所示的3个基本要素：文化、组织和技术手段。事实上，这就是关于流程、人和技术的经典准则。DevOps领先者及其追随者的经验都表明，这几个要素依然至关重要。
  
  这里把DevOps的定义分解成几个组成部分，以方便强调其中的关键点。DevOps包含以下四个部分。
• 1．敏捷软件开发与精益生产思想的一种演进。
• 2．应用到IT端到端的价值链中。
• 3．使得业务基于现代信息技术。
• 4．通过文化、组织与技术变革而获得更大的成功。

1.3 为什么要实施DevOps？

“听着，如果星星都亮了，那就意味着有人需要它。”——马雅科夫斯基（V. Mayakovsky），1914

一些管理框架，就像通过作者（也许是一个专家甚至一个“大师”）的想象涌现出来的产品，是某种理论研究。它们的适用性（或者不适用性），由试图在工作与管理中应用这个新方法的拥护者和追随者来证明。

其他一些方法，则诞生于对紧迫需求的反应。它们的创建，不是出于英国皇家的命令，也不是出于一群专门聘请的顾问。这些方法由实践者开发出来，他们尝试寻找消除具体困难或约束的方法，或者让有限可用资源的使用更加高效，或者创造出新的业务、新的商机和新的工具以解决具体且真实的问题。

DevOps更接近于后者而不是前者。关于它的起源，细节会在1.4节中进行讨论。现在，让我们聚焦于不同组织应用DevOps所试图解决的主要问题。

1.3.1 缩短市场响应时间

应用DevOps的公司通常都会提出显著缩短市场响应时间（time to market）的诉求。对市场响应时间这个术语，不同的人可能有不同的理解。一种常见的理解是从业务想法被提出来到客户能够购买这个产品或得到这个想法被实现之后的新服务所历经的时间。这样一来，计算（或者评估）市场响应时间就涉及相当大的时间跨度。对相关的IT部门，这个时间跨度包含以下环节。

• 针对一种或若干种业务想法构建、起草方案并进行论证。
• 评估和选择一个业务想法来实施。
• 规划实施所需要的行动，并获取资金。
• 准备人员和业务流程。
• 同时还有规范化需求、开发原型、初始化测试、开发完整特性的IT系统、全面的测试、发布和部署。
• 与此同时：进行市场活动、准备市场营销、准备销售渠道和工具。
• 发布新的产品或服务。

以上流程带来了很多现实的挑战。首先，它可能需要花好几年的时间，然而业务方可能希望缩短到数月。产生这种紧迫性的业务理由是显而易见的：在新产品开发期间，市场可能会发生很大的变化而导致产品本身不再有用，或者竞争对手会更早发布一个类似的产品、拿走“蛋糕”并成为市场领导者。以有吸引力和竞争力的价格及早进入市场，有助于在新的商机面前赢得压倒性的优势，这又会给领导者带来进一步改变市场格局、根据己方所需来主动调整的机会。这是一个只有少数企业才能拥有的优势，但所有人都对此虎视眈眈。此外，我们不应该忘记持续上升的变化率。这个理论的一个最好例证，是Ray Kurzweil（雷·柯兹威尔）1999年发表的加速收益准则。根据这个准则，一个演进的系统的总变化率（包括但不限于新技术）趋向于以指数级别增长。在实践中，这意味着技术（包括信息）的创新突破会更加频繁地发生。那些加快变化步伐的公司成为了领导者，那些保持快速步伐的公司得到了场内竞争的机会。而那些不能快速变化的公司，还能说些什么呢……

上述流程带来的第二个困难，是如何在这些独立步骤之间清晰地进行协调和同步，尤其在那些并行实施的步骤之间。在这一点上，许多公司落入了一个典型的陷阱：如果没有就绪的最终产品，就没有东西可以做广告和销售，但当产品生产出来后再去进行市场活动，只会导致销售延迟，进而财务回款延迟。这个陷阱进一步拉长了实际的市场响应时间，并且需要更细化地去协调每一个人的工作。

传统IT部门的这种做法增加了市场响应时间，而这很少被充分认识到。事实上，对于很多组织，在1.5到2年的整体的市场响应周期中，IT部分占的时间超过50%，甚至可以到70%。

要成为一个电影编剧很难。你很难赶得上以闪电般速度变化的情况……首先得写剧本，然后进行排练，随后提交到发行办公室，这样才会出现在屏幕上。在这个时候，一些新的和与彼时更相关的变化，不期而至……”
编剧……不同的热门影视作品的编剧也面临着一模一样的境地。他/她们需要在还喝着早晨咖啡和读着新闻报纸时，马上着手写。到了中午，这部戏剧准备就绪进行彩排，到了晚上它就将对公众开演。只有在这种不可避免的情形下工作，他们才能抓住时机。”
——来源：The Theatre，Moscow daily theatre newspaper

对“市场响应时间”的另一个理解，虽然不是那么常见，但也值得留意。创造数字化产品的充满活力的公司，习惯于快速行动。相对于严谨、详细的计划，他们更推崇可安全失败的实验。“想法”这个词，被“假设”所取代。这时，流程可能是下面这样的。

• 创建假设，设计验证方案。
• 在实践中实施假设。
• 评估结果，A/B测试，与目标对比。
• 基于分析进行调整，回到第一步或第二步。

在这里，很容易看到一个循环，这个循环的预期时长是几周。这样快速的步伐是必需的，因为DevOps这场运动的本质，就是持续的探寻。在一开始，最终状态是完全不可知的，因而通往最终状态的路径也不可知。制定长期的计划变得没有意义，公司只能看到下一个近似的步骤；或者更准确地说，试图猜测合适的下一步。有一个大家熟悉的隐喻可以阐释这个理论：将业务的生存与发展类比为探索一条流淌着金币的河流，如图1.7所示。一旦进入这条河流发现了商机和新机会，公司就还需要继续探索变化中的河床。传统的流程、监管和现有的产品可能会增加公司的惰性，如果置之不理，则可能会一无所获。

不难猜测，IT部门对于上述循环的延缓起到了很大的作用。实际上，在数字化产品的创造上，IT承担了关键的角色，因而在假设实施阶段发生的延迟，最有可能来自于花好几人月而不是预期几周的“迟缓的”IT部门。

为了缩短市场响应时间，DevOps提供了多种技术，例如降低批量大小、减少移交次数、持续识别与消除损耗等。在第4章中，会更详细地讲解这些方法。现在有一点值得注意，期望应用DevOps技术来加速IT部门的工作，同时又降低IT的成本，这样的想法是幼稚的。在很多时候，由于IT人员数量的增加，信息技术的成本会自然攀升。实际上，图1.8中IT部门的传统组织方式将职能单元分开，每个职能单元处理特定领域下的所有任务，比如业务分析、开发与测试、支持及其他。与此同时，在每个职能单元内确保了必要的相互可替代性，数量很大的具有同样资质和能力的专业人员使得工作负载的均匀分配成为可能。
不同于图1.8，DevOps将专业人员划分为多个专职的产品团队，每个自给自足的团队中包含产品负责人、架构师、开发人员、测试人员及负责运维和安全的专业人员。如图1.9所示，很多个这样的团队各自专注于他们负责的产品，这时保证工作负载均衡就要困难一些，也可能会造成人员利用率不足以及由此带来的更高的人力资源成本，这个话题会在4.2节中继续探讨。
可以这样说，传统IT部门遵循“为成本而优化（optimize for cost）”的模式，而DevOps组织遵循“为速度而优化（optimize for speed）”的模式，这两种模式的目标一般是截然不同的。还要注意，DevOps也提供了限制成本增长的工具和技术，例如自动化所有例行的运维工作或团队内部专业人员可替换。此外，有些DevOps专家直接指出，优化速度在很多时候是致力于业务价值（能够赚更多的钱），这弥补了IT上升的成本。这时，IT部门就可以被视为一个真正的业务伙伴而非成本中心。

1.3.2 减少技术债务

技术债务的概念由Ward Cunningham（沃德·柯宁汉）在1992年提出。当程序员选择一个非最优的方式来解决问题以缩短开发时间时，技术债务就应运而生。Cunningham（柯宁汉）注意到这是一个自然的过程，而问题在于非最优解决方案的累积导致了开发产出的逐步恶化，结果必然是产品质量下滑。随着时间的推移，开发团队将不得不投入更多的资源来修复前期决定所带来的后果，也就是说，需要重构现有的代码而无法开发新的功能。这个与财务债务概念的类比是很贴切的：加速产出，公司就可能“陷入债务”，甚至可能将所有的收入都花在债务偿还上，公司不应该允许这种情况的发生。

Martin Fowler（马丁·福勒）进一步发展了技术债务的思想，提出了图1.10所示债务出现原因的分类
他的观点总体上延续了沃德·柯宁汉（Ward Cunningham）的想法：在一个被恰当组织的开发团队中，增加技术债务也许是获取短期收益的一个有意识的行动，但重要的是，要关注债务的偿还。

当前，技术债务的概念通常被用作更广泛的含义。随着运维问题的膨胀，传统IT部门各个层面的问题层出不穷：

• 通过重启设备来修复错误；
• 安装没有经过合理测试的软件补丁；
• 没有仔细规划就实施IT基础设施变更；
• 人工打补丁或修改服务器配置而没有文档记录，

这些只是累积的技术债务一些例子，而且，在一个按部就班的IT部门中，没有人会去“偿还”它们。有些IT组织甚至都没有在工作计划中体现降低这些负债的工作或项目，而有些组织则抱有“只要有时间处理，什么事情都会井井有条”的幻觉。当然了，我们都知道，一个现代IT部门不会出现这样闲的美好时光。

此外，可以说，ITIL提供的某些众所周知的实践，当应用不当或者被孤立应用时，也会导致技术债务的增长。例如，ITIL事件管理流程本身，并没有发现与消除失败原因的意图。它的目标是尽快恢复IT系统（或IT服务，其区别在这里并不重要），而通常会使用变通方案和临时补丁。在这种方式下，几乎可以肯定这个失败会再次发生，因而还需要投入新的IT成本来再次进行消除。ITIL的作者假定问题管理流程会与事件管理流程一同工作，致力于识别与消除事件的根因，以在最大程度上实际减少技术债务。然而，我们注意到，在大多数现代IT部门中，都或多或少有一些事件管理的实践，但对散落的问题管理流程的有效追踪则极为困难。

DevOps密切关注如何减少技术债务（或者说是管理技术债务）。这里有两个常用的实践。

• 首先，持续重构程序代码，将运维中获得的经验吸纳进来，同时规划相应的工作来消除之前出现的瓶颈，把这些工作与创造新功能同等对待。
• 其次，DevOps强烈推荐应用“尽可能频繁地直面问题”的实践，以防出现这样一种情况：每个人都知道问题的“就在那儿”，却没有人着手去处理。

1.3.3 消除脆弱性

如同1.1.1节所提到的，大多数组织的IT基础设施都处在非常脆弱的状态，是因为有以下多个因素。

• 技术解决方案是多年以来逐步地、基于不同组件基础之上构建的。
• 使用大型的第三方系统，针对公司目标进行大量的定制。
• 使用内部开发的遗留系统，而关键的程序员和团队已经离职。
• 大量的系统以非常繁杂的方式相互耦合在一起，并且与外部数据源及消费者集成。
• 由于快速实施的需要以及预算的限制，解决方案的质量经常做不到最优。
• 维护与支持工作增加了许多临时变通方案（“拐杖”），只是考虑到让系统能继续运行（撑）下去。
• 程序代码、架构、基础设施、技术解决方案乃至合同责任的文档，非常不尽如人意。

Gene Kim（吉恩·金）、Jez Humble（韩捷）、Patrick Debois（帕特里克·迪波斯）和John Willis（约翰·约尔斯）注意到，具有讽刺意味的是，组织中最重要并且带来最多业务收益的系统，往往是最脆弱的系统。由于与这些系统直接相关的业务中断的高风险、对宕机的零容忍以及新的变更和改进的持续涌入，想要降低这些系统的脆弱性是极其困难的。

但是，继续在这样一个不稳定的基础设施上工作，对IT管理者的职业生涯也是个威胁。此外，除了长期迫在眉睫的麻烦，运维也存在诸多困难。进行任何一次变更都有风险，因此需要有适当的工具来缓解这些风险，需要对每个变更进行长时间和彻底的评估、计划、协商与审批、开发、测试以及最终的实施。这些事情显著拖慢了变更实施的速度，并且对IT组织的创新能力造成了很大的负面影响。

DevOps提出以最激进的方式改变IT系统的脆弱性，即完全消除它。在传统范式里，新代码在被测试证明可工作之前，是不可运维的。相比之下，DevOps中代码与系统作为一个整体，在任何时间都是完全可运行的，如果下一个变更破坏了它们的性能，就会立即回滚，以使系统持续有效地工作。

在《反脆弱：从不确定性中获益》一书中，纳西姆·塔勒布（Nassim Taleb）讨论了复杂系统的特征，并引入了如下分类：脆弱系统、弹性系统和反脆弱系统。这个分类有助于选择适当的工作方法。

• 对脆弱系统，首要的是保证稳定性，它们需要尽可能少地发生变更，变更应该在实施的事前和事后进行仔细检查。
• 弹性系统的设计，是基于它们固有的复杂性和脆弱性，设计容忍失败和灾难恢复的机制，这样就不用太担心失败可能造成的负面影响。
• 反脆弱系统可以从功能障碍和混乱中持续演进，这更接近于完美的状态。其实，混乱其实就是这个时代下公司信息技术领域日常的真实写照。

DevOps与反脆弱相关的一个最棒的实践，是在生产环境中有意引入混乱与不稳定性。这类技术实践拥有不同的称呼：游戏日（Game Day）、乱世猴子（Chaos Monkey）和猿猴军团（Simian Army），但本质上是一样的。使用专门开发的软件，随机地在事前未知的时间点，破坏IT系统、服务器、数据传输与存储系统等的正常运行。目标IT系统必须独立而快捷地做出响应，以侦测到错误根源并恢复正常运行。理想情况下，最终用户对发生的事情毫无感知，当然，数据也没有丢失。这类技术可以在传统IT部门进行尝试，但对许多公司而言，这可能会导致彻底的业务中断。

至此，我们检视了DevOps着力处理的三个主要任务：缩短市场响应时间、减少技术债务与消除脆弱性。如果它们之中的任何一个能够得以实现，都能为业务带来明显的优势，而三个合在一起，就代表了驱动变革的强大力量。我们检视了每个任务，最后都简要描述了相关的DevOps实践。现在我们应该注意到，这些实践的孤立应用，是不足以解决被揭示的问题的。我们需要显著改变IT组织的文化，不仅是使用的工具、方法和技术演进，更重要的是每一个IT员工对公司工作中关键要素的态度发生转变，如客户的角色、信息技术创造的价值、对已知缺点的容忍以及对持续改进的需要。盲目应用DevOps的想法，例如“让我们构建流水线，因为没有它就没有DevOps”，可能会导致一种被称为“货物崇拜”（Cargo Cult）的现象。这个理论我们会在5.5节中展开讨论。

说到这里，我们先暂时从这些重要的事情中退后一步，回忆一下DevOps是如何起源的。

1.4 历史起源

对一个主题的务实考虑，似乎并不需要沉浸到它的历史当中去，比如谁在什么时候遇见了谁，说了些什么话，提出了什么想法，这些真的重要吗？

如果只是把DevOps当作一系列的技术手段，那么就只需要在组织中“实施”就行了，确实可以跳过这一章。但是，看起来任何一家公司成功转型DevOps，都直接依赖于人。需要改变工作实践的，也是人。人们在没有采纳新的价值观和理解“为什么？”“为什么是现在？”等问题的答案前，往往不会采取任何行动。因此，让我们花一点时间来回顾这个历程。以下描述的所有事件背后，都有一些具体的关键人物及其过去与现在的影响。

正如1.1.1节所讨论的，到21世纪前10年的后半段，在软件开发领域，敏捷、Scrum和极限编程等多种方法被广泛采用。把这些方法延伸到运维领域，多半只是个时间问题。有记载的最早尝试之一，是2006年Marcel Wegermann（玛赛尔·魏格曼）发表了一篇文章，论述了如何将敏捷开发原则应用到系统管理工作上。他提出三点建议：

• 把孤立的系统目录一起放到版本控制系统中；
• 让系统管理员采用结对工作；
• 召开运维回顾活动。

2008年，在多伦多定期举办的敏捷论坛上，有两件重要的事件同时发生了。Andrew Shafer（安德鲁·沙弗）建议在日程里新增一个“敏捷基础设施”专题。随后，Patrick Debois（帕特里克·迪波斯）发表题为“敏捷基础设施与运维：你的基础设施有多敏捷？”的演讲。他们在许多方面有着共同的兴趣，当时Shafer刚刚从开发转到运维，而Debois正同时做开发与支持工作，观察到在两边团队完全不同的工作方式（从2007年开始，他参与了一个大型的数据中心迁移项目）。根据Patrick的回忆，当时这个演讲并没有在听众中造成多大的反响。据论坛的其他参与者说，这个演讲的听众人数不是很多。然而，接下来的事情证明，那些来参加的人，是真正对这些新想法感兴趣的，而且这些想法本身正在以很快的速度继续发酵。

同样在2008年，Puppet Labs的创始人Luke Kanies（卢克·凯尼斯）在开源软件大会上发表配置管理主题的演讲，他认为，配置管理这件事情需要加以重新考虑。他的报告引起了John Willis（约翰·威利斯）的注意，后者在日后也有力地促进了DevOps思想的发展。值得注意的是，DevOps这个术语，当时并不存在。

术语DevOps，是在2009年Velocity大会John Allspaw（约翰·沃斯帕）和Paul Hammond（保罗·哈蒙德）的演讲之后出现的。这个题为“每天10+次部署：Flickr开发和运维的协作”的演讲，在对此话题有兴趣的听众中，以这样或那样的方式造成了深远的影响。同年，Debois决定在比利时根特市举办首届DevOpsDays专题大会。2013年，参加这个活动的Gene Kim（基恩·金）出版了《凤凰项目》一书，并开始每年举办两届DevOps企业峰会。

至此，DevOps的概念以及由热心分子组成的社区，开始风起云涌……

每天10+次部署的演讲，现在被认为是DevOps运动的起点。

DevOps企业峰会是最大的及最有代表性的DevOps大会，不管是参会者的规模还是演讲者的阵容。
《凤凰项目》一书应该是世界上最畅销的DevOps相关的书籍。
Puppet实验室和IT Revolution公司是DevOps市场上占据统治地位和最有影响力的组织之一。
前面提到的很多标志性人物，在全世界DevOps奉行者心目中，是绝对的“大师”。

回顾这一段历史，我们可以观察到以下几点。

• 第一，DevOps的关键思想，来自于探寻真实管理问题解决方案的有智慧的工作。
• 第二，DevOps并没有唯一的一个或一群发起人，虽然这些关键人物的思路很接近，但他们在之前彼此互不相识。
• 第三，DevOps并没有、也不可能有一个版权所有者，来独断或决定DevOps的发展、或对其使用作出限制（尽管有些贪心的商业机构已经预留了衍生商标，例如DevOps Foundation）。
• 第四，DevOps还是一个新生事物，因而想要得到一个被完全证明的“秘诀”或通行的可用方法集合的话，还为时过早。

1.5 常见误解

结束这一章最好的方式是审视常见的误解。这有助于对DevOps这个现象建立清晰的边界，并使得我们可以继续推进更多的具体工作。我们的目的，不是最完备地去覆盖所有遭遇到的误解。在本章中，我们将从管理的视角，选择更有助于理解“DevOps是什么”的内容，并可以与“DevOps不是什么”相对照。

1.5.1 DevOps是敏捷的一部分

现代软件开发的拥趸有时候声称，DevOps无非就是敏捷那些想法的延续。这是一种受限的世界观，其核心基于一个事实，即敏捷开发能够与客户建立更好的关系以理解其软件产品需求，并足够快速地发布软件产品。“做些什么才能够让发布的产品对客户有用以及具体如何实施”是一个长期存在的问题，现在有了进一步的解决方案：DevOps！针对这个令人尴尬的问题，有人从DevOps中找到了答案。

举例来说，我们看看流行的SAFe（规模化敏捷框架）模型，这个模型的设计目标是帮助敏捷开发在中型到大规模的组织中落地。

我们研究的DevOps出现在SAFe模型的右部、接近中间的位置，位列在Program层级中。从字体判断，DevOps的重要性大致相当于Backlog、Kanban与Business Owner。SAFe中具体描述如图1.11所示。

SAFe企业实施DevOps以打破职能筒仓，赋能各列版本发布火车（ART）及解决方案火车，以持续地向最终用户交付新的特性。随着时间的推移，开发与运维之间的割裂程度会显著降低……目标很简单：更频繁地交付价值。
这是一个非常受限的对DevOps的看法，至少有三个理由。

• 首先，尽管在很大程度上基于敏捷，DevOps把“敏捷开发”的想法延展到了整体的敏捷IT交付、整个组织、整个流程以及整个价值链（参见第3章）。
• 其次，相对于敏捷而言，从DevOps中获得回报，通常需要更大的公司文化变革（参见5.5节）。
• 第三，DevOps的目标集，并不仅限于加速交付——还包括减少技术债务和消除脆弱性（参见前面的1.3节）。

1.5.2 DevOps是工具和自动化

另一个观点与自动化这个词有关。对现代IT部门有帮助的软件工具的数量，近年来翻了几番，常用的工具都有几百种。很多供应商都试图让你确信它们“就是”DevOps，或者它们将提供给你最好的DevOps工具。

“DevOps大会：针对开发者、全球专家和技术死忠粉（18+）。
– 谷歌搜索上的广告，2017年10月

供应商的市场压力非常之大。像CA、HP和微软这样的大公司，已经开始带着它们高大上的营收目标和相应的营销预算投身其中。很多人注意到一个似曾相识的场景，即20年前管理IT服务的软件的历史：那时的软件供应商也说，ITSM就是一套软件，而您所需要做的所有事情，就是安装它，然后让流程自行发生。仅有少数供应商意识到并且认真讨论软件以外的一些东西。

DevOps确实依赖于某种自动化工具的可用性与有效性。但严格来说，这些工具的最小集，可以缩小到一个用来存储所有源代码和IT基础设施配置数据的版本控制系统及一个软件交付流水线自动化系统。提及的所有其他工具，当然也可以作为补充，尝试。虽然有些软件解决方案被广泛采纳，但是没有也不可能有一个放之四海而皆准的DevOps必选软件列表。在本书中，我们会仔细研究DevOps现象，而不会考虑具体的软件产品，甚至压根儿不会提及它们的名称，这也是DevOps的具体实施可以独立于工具软件的一个间接证明。

1.5.3 DevOps是一个新的职业

我们要说的下一个误解，常见诸于一些招聘机构与求职网站。它们把DevOps描绘为一个全能战士，会编码，会测试，会部署环境，还会管理基础设施。也就是说，他/她能够有效地执行软件开发人员和支持工程师的所有工作，但只领一份薪水。另一个常见的场景是，将大家熟悉的系统管理员这个古老职业，替换为更时髦的“DevOps工程师”。看看下面的职位空缺，从其描述中就可以断定，它们与DevOps一点关系也没有。

“一家初创软件公司正在寻找一位远程工作的DevOps/系统管理员（Bitrix）。” ----- 职位搜索网页上的广告，2017年10月

第三个例子是DevOps大师，需要他/她来公司“实施”所有的DevOps“动作”。这有些类似于敏捷教练或Scrum Master。

当然了，所有这些都是严重的误解。DevOps是IT部门从根本上发生深远的变革，这不可能通过招聘一些DevOps工程师或者邀请几个DevOps大师就得以实现。具备实施软件交付流水线的能力，也不能保证取得成功。实施DevOps的实践，也不太会节省成本，这已经在1.3.1节中阐明。

1.6 小结

结束这一章之前，我们简要总结一下本章谈到的主要信息。为了更好地理解这个主题以及您与同事的交流，我们在图1.13和图1.14中以图示的形式来进行展现。

DevOps的发展示意图

为什么要实施DevOps