第一部分
背 景
这一部分为本书的后续章节提供了必要的背景知识。DevOps是一项运动，它设想在开发组和运维组之间没有冲突。DevOps的出现与云发展成为大小型组织的基本平台是同时发生的。第一部分有3章。
在第1章中，我们将定义DevOps，并且讨论DevOps的各种驱动力。DevOps是一个包罗万象的术语，它可以涵盖多个含义，包括让开发人员和运维人员互相沟通；允许开发团队自动化地部署到生产环境；当在生产环境中发现错误时，让开发团队成为第一个响应者。在这一章中，我们将梳理出各种关注点，并且关于DevOps是什么、它的驱动力和目标是什么以及如何实现这些目标，我们也将给出条理清晰的描述。
为了理解某个DevOps实践是如何工作的，有必要了解云是如何工作的，我们将在第2章中讨论这一内容。特别是，你应该知道虚拟机是如何工作的、IP地址是如何使用的、域名系统（Domain Name System，DNS）服务器的角色和如何操作它，以及负载均衡器和监控器是如何交互以提供按需伸缩的。
DevOps包含了对Dev和Ops实践的修改。在第3章中，我们将讨论Ops整体。其中讨论了Ops提供给组织的服务，也引入了Ops的责任——从支持部署的应用到强制组织范围的安全规则。
第1章 DevOps是什么
有人告诉我，我放在书中的每个方程式都会让书的销量减半。
于是我决定一个方程式也不放。
——史蒂芬·霍金
1.1 概述
本书试图回答的问题是：“我为什么要关注DevOps，它对我有何影响？”阅读本书可以找到详尽的答案，不过也可以简而言之：如果你的工作与构建软件系统有关并且你所在的组织有意缩短新功能推向市场的时间，那你就应该关注DevOps。这是DevOps产生的驱动力，DevOps实践将影响你们如何组织团队、如何构建系统，甚至影响你们所构建系统的架构。如果你是软件工程领域的学生或研究人员，你应该关注采用DevOps实践会如何影响你们正在处理的问题。如果你是教育工作者，你也应该关注，因为在课程中融入DevOps材料可以帮助学生学习最新的开发实践。
我们首先给出DevOps的定义并提供了一个简短的示例，然后介绍DevOps运动产生的驱动力、概貌，以及阻碍DevOps成功实施的障碍。对DevOps的大部分描述都是讨论各种组织和文化方面的问题的。本章先概述这些主题，并围绕这些主题展开本书的剩余章节。
1.1.1 定义DevOps
2013年根据应用开发的Gartner技术成熟度曲线，将DevOps分类为“处于上升期”的类别。这个分类意味着DevOps正在成为一个流行术语，正因如此，其本身还没有良好的定义，并且浮夸之词四溢。我们对DevOps的定义关注目标，而不关注方式。
DevOps是一套实践方法，在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。
在深入探讨这套实践包含的内容之前，首先看看这个定义隐含的一些内容。
在部署对系统的变更时（通常是代码形式），质量很重要。质量意味着适合于包括最终用户、开发人员或系统管理员在内的各种干系人使用。质量还涵盖了可用性、安全性、可靠性及其他属性。保证质量的一种方法是，在把修改后的代码放到生产环境之前必须跑通各种自动化测试用例。另一种方法是，在把变更对外开放之前，先让一小部分用户对生产环境的变更进行测试。还有一种方法是，对新部署的代码密切监控一段时间。我们在定义中没有说明如何保证质量，但我们要求生产环境代码是高质量的。
这个定义要求交付机制也是高质量的。这意味着交付机制应该具备高度的可靠性和可重复性。如果交付机制经常失效，所需的时间就增加了。如果交付变更的方式出现错误，所部署的系统的质量就会受到影响，例如降低可用性或可靠性。
我们认为有两个时间周期很重要。一个是开发人员提交新开发的代码的时间。这标志着基本的开发过程结束，部署工作开始。另一个是把代码部署到生产环境的时间。在第6章将看到，在将代码部署到生产环境后，有一段时间是现场测试代码并密切监控潜在的问题。在代码通过了现场测试及密切监控后，就可以认为是正式生产环境系统的一部分了。这有别于把代码部署到生产环境进行现场测试和密切监控，并且在通过测试后把新部署的代码提升为等同于以前部署的代码。
我们的定义是目标导向的。我们没有说明实践的形式或者是否使用工具来实施。如果一种实践的目的是减少开发人员从提交代码到部署到生产环境之间的时间，那么不论是否包括了敏捷方法、工具和协作形式，这都是一种DevOps实践。这与其他几个定义是不同的。例如，*（Wikipedia）强调不同干系人之间的交流、协作与融合，但没有说明这种交流、协作和融合的目的。时间方面的目标是隐含的。其他定义强调DevOps与敏捷方法之间的联系。同样，也没有说明使用敏捷方法在开发时间或生产系统质量方面的收益。还有些定义强调使用的工具，却没有提及DevOps实践的目标、所需的时间，或者质量。
最后，定义中说明的目标并不限于DevOps用于测试和部署的实践。为了实现这些目标，很重要的一点是在需求阶段就包含运维人员的视角——这比变更提交阶段要早得多。类似地，这个定义也并不意味着把开发的内容部署到生产环境之后，DevOps实践就结束了。DevOps的目标是确保部署的系统在整个生命周期中都是高质量的。这样，有助于实现这个目标的监控活动也包含在了定义中。
1.1.2 DevOps实践
我们接下来标识5种不同类别的DevOps实践。这些都是一些有关DevOps的著述提及的，并且满足我们的定义。
从需求的角度把运维人员视为首要干系人。这些实践符合定义中高质量方面的要求。运维人员有一套与日志及监控相关的需求。例如，日志信息需要能够被运维人员理解和使用。在需求开发阶段引入运维人员可以确保这种类型的需求能够考虑到。
让开发人员更多地负责相关事件处理。这些实践的目的是缩短错误从发现到修复的时间。使用这些实践的组织通常是，新部署的内容在开始一段时间由开发人员负主要责任，之后由运维人员负主要责任。
强制推行所有人使用的部署过程，包括开发人员和运维人员。这些实践的目的是确保更高的部署质量。可以避免由于即兴部署和由此产生的配置不当而造成的错误。这个实践也与诊断和修复错误的时间有关。正式的部署过程应该是易于追踪特定部署工件的历史并且易于理解工件中包含的组件。
使用持续部署。与持续部署相关的实践是为了缩短从开发人员向代码库提交代码到代码被部署的时间。持续部署同时也强调自动化测试，以提高部署到生产环境的代码的质量。
在开发诸如部署脚本这样的基础设施代码时，也应遵守一套与应用程序代码相同的实践。适用于基础设施代码开发的实践，目的是不但确保部署的应用程序是高质量的，而且部署过程能够按照预定计划执行。部署脚本中的错误，例如配置不当，会导致应用程序、环境或部署过程出错。在开发运维脚本和过程时应当采用与正式软件开发中使用的相同的质量控制实践，这将有助于控制这些规格说明的质量。
图1-1是DevOps过程的概述。最基本的是，DevOps提倡把运维人员作为首要干系人。准备一个发布是非常严肃、严谨的过程（我们将在1.2.1节中描述）。同样对于开发过程中系统会发生的运行时错误的类型，可能需要对运维人员进行培训。他们可能会对日志文件的类型和结构提出建议，可能在需求过程中给出其他类型的意见。极端情况下，DevOps实践要求开发人员负责监控进度和在部署和执行过程中出现的错误，这样运维人员的声音就可能成为建议的需求。两者之间的实践包含了团队实践、构建过程、测试过程和部署过程的实践。我们将在第5章、第6章讨论持续部署流水线。我们也会在后面的章节讲述监控、安全与审计。
图1-1 DevOps生命周期过程[标注法：波特价值链]
你可能对术语IT专业人士（IT Professional）、运维人员（Operator）、运维人员（Operation Personnel）的命名方式有些疑问。另一个相关术语是系统管理员（System Administrator）。IT专业人士包含了上面提到的角色以及其他人，例如帮助台的支持人员。运维人员和系统管理员这两个术语的区别是历史原因造成的，但是今天已经不是这样了。历史上，运维人员直接接触硬件（安装、配置硬件、管理备份、维修打印机），而系统管理员负责计算机系统的正常运行时间、性能、资源和安全。今天很少有哪个运维人员不需要承担以前分配给系统管理员的职责。我们将使用术语运维人员来指代执行计算机操作或系统管理的人（也可能两者都做）。
1.1.3 持续部署的例子：IMVU
IMVU是一家社交娱乐公司，它的产品允许用户以一种3D阿凡达式的体验互相连接起来。本节内容改编自一位IMVU工程师所写的博客。
IMVU采用了持续集成。开发人员尽早提交并经常提交。每次提交都触发测试套件的执行。IMVU有上千个测试文件，分布在三四十台机器上，测试套件的执行大约需要9分钟。在提交的内容通过了所有的测试之后，就自动实施部署。这大约需要6分钟。代码移动到集群中的数百台机器上，但是在开始时代码只在一小部分机器上执行（金丝雀）。一个取样程序检查金丝雀的结果，如果回归的数量很多，则改动的版本自动回滚。否则集群中的其他机器就会自动启用。IMVU平均每天部署50次代码。
这个过程的核心是测试套件。每当提交的内容通过执行测试套件并回滚后，都会产生一个捕获出错部署的新测试并将它添加到测试套件中。
注意，对于一个大规模的系统来说，只要9分钟就能执行一次完整测试（有信心在生产环境中部署）的情形并不常见。在很多组织中，获得生产环境信心的完整测试套件需要执行数个小时，且常常是在夜间执行的。一个常见的挑战是审慎地缩减测试套件的大小，去掉“不可靠”（flaky）测试。