1.1 起源
一般认为，DevOps的出现源于两个因素：敏捷软件方法的广泛采用以及IT基础设施即程序代码的管理方式。我们分别来看一看。
1.1.1 敏捷软件开发方法
在20世纪末期，主流的软件开发方法是图1.3所示的所谓“瀑布模型”：顺序式执行预定义的阶段，每个阶段花很长时间，并以达成先前协商好的结果作为结束；很多时候，只有在前一个阶段已经完整且正式完工时，才能转移到下一个阶段。这个模型的另一个显著特征是，每个阶段所涉及的人员职能有专业化的分工：分析师、架构师、开发人员和测试人员等。
当开发的是功能可预先定义、对快速产品交付没有或很少有要求的大型信息系统时，这个模型能够确保我们创建高质量产品并进行有效与精细的成本控制。
然而，在20世纪90年代末期，随着互联网技术与Web编程的快速发展，瀑布模型的消极作用开始显现，影响到信息系统客户（内部或外部业务）与提供者（内部或外部软件开发者）之间的交互和理解。事实上，对业务客户的市场机会不断涌现，这要求团队能够快速发布（最多在几个月之内）新产品到市场上。然而，从项目启动到第一个可运行原型的典型开发闭环，可能要花6到18个月时间；而在大型企业中，甚至需要2到3年。此外，随着很多在之前并不为人知晓但有潜在前景的市场机会涌现，客户的需求在开发过程中很可能会发生变化，这样一来，要有效应对市场机会而不延误截止日期，且同时还不降低产品质量，就变得极为困难，如图1.4所示。
图1.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年与虚拟化有关的关键事件数量，如果我们能看得更远，这个图上的数据在近年来并没有停歇。
图1.5 关键虚拟化事件的时间分布
虚拟化不仅使更有效地使用昂贵而强大的硬件成为可能，还在提供有用功能的可执行代码与背后的系统软件之间引入了一个额外的抽象层。这在分离“应用工程师”和“系统工程师”的能力与职责的方向上迈出了重要的一步，也为这些概念建立了更广泛的认知。
云计算技术的发展更快。到了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基础设施，可能只需要走两个流程：
● 运行一个脚本，等它执行完毕（几分钟，很少会是几小时）；
● 在月末与云提供商结账。
也就是说，只需要程序代码，就可以创建出所需的基础设施。不光只是创建，还可以把基础设施视同代码进行管理：进行版本控制、变更追踪、调试、重用之前版本等。在第3章中，我们会再次展开讨论。
结束这部分之前，我们也承认，有些相对老旧的技术已经获得了第二次生命。例如，操作系统层面的虚拟化，在20世纪80年代的许多UNIX系统上就已经做到了。然而严格来说，这项技术的商业化成功，即通常被称为容器化的技术，到21世纪前10年的后半段才出现，这与前面描述的事件相吻合。当初的chroot机制在功能和能力上颇受制约，而如今在容器之间隔离文件系统、分配磁盘空间、限制可用RAM/处理器时间或I/O带宽等，都已然成为可能。
1.1.3 这是必然的
“有人说这是必然的，当你听到有人这样说时，很可能有大批企业正在为实现它而努力。”
——理查德·斯托曼（Richard Stallman），2008年云计算大会
通过对DevOps起源的回溯，我们可以得出以下的结论。
首先，由于与业务客户交互的新方式的涌现以及敏捷开发技术的充分应用，对新的IT管理方法的需求变得愈加迫切。
其次，随着新的基础设施管理技术的涌现，用不一样的方式来组织IT工作，也成为了可能。
用现实的视角来看待前面理查德·斯托曼（R. Stallman）的话（虽然看起来他对云计算似乎有些误解），我们可以断定，迟早会出现某种类似DevOps的东西。