关于 DevOps 你必须知道的 11 件事

编辑注：本文来自技术出版商 IT Revolution ，最初以白皮书的形式发布为 The Top 11 Things You Need to Know about DevOps 。经本文作者 Gene Kim 和本文译者戚一品的授权与推荐，现将完整译文分享给 InfoQ 中文章的读者们参阅。

关于作者

Gene Kim在多个角色上屡获殊荣：CTO、研究者和作家。他曾是 Tripwire 的创始人并担任了 13 年的 CTO。他写过两本书，其中包括《The Visible Ops Handbook》，目前他正在编写《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》。Gene 是 IT 运维的超级粉丝，痴迷于改进运维流程——在不影响当前 IT 生产环境的情况下，使得开发人员可以向生产交付更多可运行的功能，而非只是完成代码。他与多个顶级互联网公司合作过，致力于改进他们的发布流程，提高 IT 运维流程的完整性。2007 年，Computer World 将 Gene 列入了“40 岁以下的 40 个创新 IT 人士”的名单中，普度大学还给他颁发了杰出校友奖以表彰他在专业领域的成就和领导力。

目录

1. 什么是 DevOps
2. DevOps 与敏捷有什么不同
3. DevOps 与 ITIL 以及 ITSM 有什么不同
4. DevOps 与可视运维
5. DevOps 的基本原则
6. DevOps 模式的应用领域
7. DevOps 的价值
8. 信息安全和 QA 如何融入 DevOps 的工作流
9. 我最喜欢的 DevOps 模式一
10. 我最喜欢的 DevOps 模式二
11. 我最喜欢的 DevOps 模式三

1. 什么是 ****DevOps

术语“DevOps”通常指的是新兴的专业化运动，这种运动提倡开发和 IT 运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

为什么是开发和 IT 运维？因为典型的价值流就是在业务（定义需求）和客户（交付价值）之间。

DevOps 运动的起源通常被放在 2009 年前后，伴随着许多运动的相辅相成和相互促进——效率研讨会运动，特别是由 John Allspaw 和 Paul Hammond 展示的开创性的“一天 10 次部署”，基础设施即代码”运动 (Mark Burgess 和 Luke Kanies)，“敏捷基础设施运动” (Andrew Shafer)，“敏捷系统管理”运动 (Patrick DeBois)，“精益创业”运动（Eric Ries），Jez Humble 的持续集成和发布运动，以及 Amazon 的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。

DevOps 的合著者 John Willis 写了一个非常好的帖子在这里

http://itrevolution.com/the-convergence-of-devops/

2. DevOps**** 与敏捷有哪些不同？

相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。在敏捷的目标里，最明显的是在每个 Sprint 的迭代周期末尾，都具备可以交付的功能。

部署的高频率经常会导致部署堆积在 IT 运维的面前。StreamStep 公司的创始人，Clyde Logue 总结过一句话：“敏捷对于开发重新获得商业的信任是大有益处的，但是它无意于将 IT 运维拒之门外，DevOps 使得 IT 组织作为一个整体重新获得商业的信任”。

DevOps 和敏捷软件开发是相辅相成的，因为它拓展和完善了持续集成和发布流程，因此可以确保代码是生产上可用，并且确实能给客户带来价值。

DevOps 不仅仅创建了一个面向 IT 运维的工作流，当代码已经开发完成但是却无法被部署到生产上时，这些部署就会堆积在 IT 运维的面前，客户也将因而无法享受到任何价值，更糟糕的是，部署经常导致 IT 环境的中断和服务不可用。

DevOps 具有与生俱来的文化变革的基因组成，因为它革新了开发和 IT 运维之间的工作流和传统的衡量标准。John Willis 和 Damon Edwards（两位都是《DevOps Cookbook》合著者）就这个话题写过很多文章：

http://itrevolution.com/devops-culture-part-1/

3. DevOps与ITIL和ITSM**** 有什么不同？

尽管很多人视 DevOps 为 ITIL 和 ITSM 的颠覆，而我则有着不同的看法，在支撑 IT 运维的业务流程方面，ITIL 和 ITSM 流程无疑还是最好的。实际上，他们描述了需要被 IT 运维支持的功能集合，这些功能集合足以支撑 DevOps 式的工作流。

敏捷和持续集成以及持续发布是开发的输出，这些输出同时作为 IT 运维的输入，为了适用跟 DevOps 相关的快速部署的节奏，ITIL 流程的很多方面，特别是围绕着变更、配置和发布流程方面，需要自动化。

DevOps 的目标不仅只是增加变更的频率，而且也支持在不中断和破坏当前服务的基础上，确保功能部署成功，同时也可以快速检测和修复缺陷。这引入了服务设计，事故和问题管理方面的 ITIL 新准则。

4. DevOps**** 和可视运维如何搭配

2004 年，我与 Kevin Behr 以及 George Spafford 合著了《The Visible Ops Handbook》，可视运维是一个说明性的指南，该指南使得高性能 IT 运维能顺利实现“从优秀到卓越”的转变，关键点之一是如何控制和减少计划外的工作。

在开发和 IT 运维之间，DevOps 不仅聚焦在创建快速和稳定的计划工作流，而且 DevOps 也有一个更全面的方法来系统的消除计划外工作，定义开发弹性准则，并负责管理和减少技术债务。

5. DevOps**** 的基本原则

在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的书里，我们描述了 DevOps 的支撑原则——“DevOps 三个基本点”，所有的 DevOps 模式都可以源自这 3 个基本点。

第一个基本点强调整个系统的性能，而非将性能局限于特定的工作领域里，这个工作领域可以大到一个部门（例如开发和 IT 运维）或者小到一个个人贡献者（例如开发者，系统管理员等）。

重点是由 IT 推动的的业务价值流，换句话说，它始于需求定义（比如被业务或 IT 部门定义），进行开发构建，又交给 IT 运维，最后价值以一种服务的形式交付给客户。

实践第一个基本点的结果——决不传递一个已知缺陷至下游，决不因小失大，总是致力于改进流程，执着于深刻理解系统需求（根据戴明的理论）

第二个基本点是关于创建从右至左的反馈回路，几乎所有的流程改进计划的目标都是缩短和放大反馈回路，以便可以持续进行必要的修正。

应用第二个基本点的结果——包括理解和回应所有内部和外部客户，缩短和放大所有的反馈回路，必要时，非常容易的嵌入客户需要的知识。

第三个基本点是打造一种文化用来促进两件事情——持续不断的探索精神，勇担风险的精神以及从成功和失败中来学习的能力，同时也得谨记：重复和实践是融会贯通的前提。

这两件事情对我们来说同等重要，探索精神和勇担风险的精神可以确保我们持续改进，它甚至意味着我们可能到达了之前曾未到过的危险区域，因此这也迫使我们去学习，掌握并融会贯通那些技能，因而使得我们能够顺利离开危险区。

第三个基本点的结果——分配时间去改进每天的例行工作，培养一种奖励冒险精神的风气，同时主动引入故障到系统中，从而提高弹性。

6**．DevOps模式的应用领域 **

在《DevOps Cookbook》里，我们将 DevOps 模式分成 4 个领域，

领域一，将开发延伸至生产中——包括拓展持续集成和发布功能至生产，集成 QA 和信息安全至整个工作流，确保代码和环境可在生产中直接部署，。

领域二，向开发中加入生产反馈——包括建立开发和 IT 运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。

领域三，开发嵌入到 IT 运维中——包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，而且开发为 IT 运维提供交叉培训，增加 IT 运维处理问题的能力，从而降低升级问题的数量。

领域四，将 IT 运维嵌入至开发——包括嵌入和联络 IT 运维资源至开发，帮助开发创建为 IT 运维 (部署，生产代码的管理等) 使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。

7. DevOps**** 的价值

我相信企业在应用了 DevOps 之后可以得到 3 个业务优势：产品快速推向市场（比如，缩短开发周期时间和更高的部署频率），提高质量（比如，提高可用性，提高变更成功率，减少故障，等等）并提高组织的有效性（比如，将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中）。

产品快速推向市场：

2007 年，在 IT 流程协会，在评测了超过 1500 个 IT 组织结构之后，我们得出结论：相比较于一般的组织，高效的 IT 组织的效率要高出 5 到 7 倍。变更要多出 14 倍，变更故障率只有前者的 1/2，第一次修复率要高出 4 倍，而且一级事故时间要短 10 倍。 重复审计发现要少 4 倍，通过内部控制来检测漏洞方面要高出 5 倍左右，并且 8 倍于前者的项目到期日表现！

在我们的研究中，观察到的最高部署频率大约是每周 1000 次生产变更，变更成功率为 99.5%，我们认为这真得很快……

其中一个高绩效的特点是，最好正在继续变得更好。这绝对是发生在部署频率的领域内。 在应用了 DevOps 实践的组织正表现出更快的快速部署和实施，而且相比于一般组织要快几个数量级。

埃森哲最近做了一个研究：互联网公司都在做什么？ 通过亚马逊的记录显示，他们在保持目前每周部署 1000 次的情况下，同时还能保证 99.999% 的成功率！

http://www.youtube.com/watch?v=dxk8b9rSKOo

http://www.slideshare.net/slideshow/embed_code/9466635?startSlide=33 )

维持高部署率（即，快速的迭代次数）的能力转化为业务价值的两种主要方式：

组织如何快速的把一个想法变成价值交付到客户手中 (比如，Damon Edwards 和 John Willis 说得“概念到落地”), 组织同时可以做多个尝试。

对我来说，如果我在一个每 9 个月才能部署一次的机构里，而我的竞争对手可以每天部署 10 次，那么无疑我将有着明显的竞争劣势。

高频率部署也实现了快速和持续不断的部署。Intuit 公司的创始人，Scott Cook 一直在组织的各个层面，不停的倡导“犀利创新文化”，我最喜欢的例子之一就记录在 http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/。

“每一位员工应该能够做到快速，高速的交付……Dan Maurer 负责我们的消费者部门，包括 TurboTax 网站。当他接手的时候，我们一年只做几次部署，但是通过营造一个犀利的创新文化，在报税季节的 3 个月里，他们现在能做 165 次部署。商业价值？ 网站转化率高达 50%。员工价值？这帮家伙们真得喜爱它，因为可以将他们的想法很快交付到市场中”

对我来说，Scott Cook 的故事最令人震惊的是，他们在繁忙的报税季节做所有这些部署！在旺季，大多数组织都会冻结任何变更（例如，从十月到一月，零售商可能经常有变更冻结）。但如果在旺季，若你能提高转换率，而你的竞争对手不能，那么这就是一个真正的竞争优势。

达到这个效果的前提就是，在不影响客户的基础上，可以快速的完成并部署很多小的变更。

减少IT浪费总量：

Mike Orzen 和我很早就谈到了 IT 价值流中的巨大浪费，这些浪费是缘起于交付期限延长，不良的交接，计划外工作和返工。基于 Michael Krigsman 的一篇文章，在应用了 DevOps 的原则之后，可以挽回很多价值而非浪费。

我们计算过，如果能够减少一半的 IT 浪费量，然后把这些省下来的钱重新投资，若能得到 5 倍的投资回报，那么每年可以产生 30 万亿美元的价值。

这就是溜过我们指尖的巨大的价值和机会。占了全球 GDP 的 4.7%，甚至超越整个德国的经济产出。

我觉得这真的很重要，尤其是当我想到我的三个孩子将继承的这个世界，这些浪费对生产率，生活水平和经济繁荣的潜在影响正在不断增加，让我觉得不得不改变。

然而，还有一个更大的成本，在大部分的 IT 组织结构里，工作是吃力不讨好和令人沮丧的，人们觉得他们自己就像被困在一部不断重复的恐怖电影里，无法改变最终的结局。管理人员本应将 IT 管理的很好，但是他们放弃了这样的职责，直接导致开发，IT 运维与信息安全之间无休止的部门冲突，而审计师的出现只会让事情变得更糟。

长期来说，必然的结果就是进步迟缓。IT 专业人士的生活往往令人泄气和沮丧的，通常导致渗透在生活方方面面的无力感和高压状态。IT 专业人员面临着压力相关的健康问题、社交问题、宅在家里等问题，这样使得他们不但不健康，同时生活也很可能难以为继。

作为人，我们注定就是去贡献，感觉就好像我们正在积极发挥作用，与众不同。但是，往往当 IT 专业人员向他们的组织寻求帮助的时候，他们会得到回答：“你不明白”，更糟的是，他们甚至会得到“你不重要”这样的待遇。

8. 信息安全和QA如何融入DevOps工作流

DevOps 的高部署频率通常会给 QA 和信息安全带来很大的压力，考虑这样一种情形，开发每天部署 10 次，而信息安全通常需要 4 个月的时间来评估应用的安全。很显然，在代码开发和代码安全审计方面的速率一点都不匹配。

2011 年 Dropbox 故障就是一个著名的例子，其体现了未经充分测试的开发代码带来的风险有多大。因为这次事故，认证功能被关闭了 4 个小时，从而导致未授权的用户可以访问所有存储的数据。

当然对 QA 和信息安全来说，也不全是坏消息， 开发会通过持续集成和好的发布惯例 (持续测试的文化) 来维持高频率部署。换句话说，一旦代码被提交，自动测试便开始运行，而且一旦发现问题，必须马上解决，就像开发人员在检查还没编译的代码。

通过集成功能测试，集成测试和信息安全测试到开发的每天例行工作中，问题将会被更快发现，同时也会被更快解决。

同样，也有着越来越多的信息安全工具，比如 Gauntlet 和 Security Monkey， 可以帮助我们在开发和上线的过程中测试安全对象，达到信息安全目标。

但是也有一个很重要的问题需要考虑，静态代码分析工具通常需要花费很长时间才能运行完，以数小时或天记。在这种情况下，信息安全就必须注明特定的有安全隐患的模块，比如加密，认证模块。只要这些模块变化，一轮全面的信息安全测试就运行，否则部署就可以继续，而不需要全覆盖信息安全测试。

需要特别提到的一点是，我们观察到，相较于标准的功能单元测试，DevOps 工作流依赖于检测和恢复更多一点。换句话说，当然开发以软件套件的方式交付的时候，那么部署变更和补丁就比较困难，同时 QA 也严重依赖代码测试来验证功能的正确性。另一方面，当软件以服务的形式交付，缺陷就可以被很快修复。而且 QA 也可以减少测试依赖，取而代之的更多依赖缺陷的生产监控，只要缺陷能被快速的修复。

代码故障恢复可借助于“功能标签”等手段，通过以配置的形式来启用或禁用某些代码功能，从而达到避免推出一个全功能部署，而只部署通过测试的功能至生产。

当功能不可用或性能出现下降等较坏的情况发生的时候，依赖于检测和恢复进行 QA 将会一种更好的选择。但是当面对损失保密性或数据和系统一致性的时候，我们就不可以依赖检测和恢复这种方法。取而代之的是，在部署之前，必须进行充分的测试，否则可能导致重大的安全事故。

9. 我最喜欢的DevOps模式一

通常，在软件开发项目中，开发都会用完所有计划中的时间用于开发功能。这样会导致无法充分解决 IT 运维的问题，于是他们就在定义，创建和测试数据库、操作系统、网络、虚拟化等代码依赖的方面直接抄捷径，以此节省时间。

所以这就是开发和 IT 运维以及次优结果之间的永恒的紧张关系的主要原因。后果很严重，比如不适当的定义和指定环境、无法重部署、代码和环境的不兼容等等。

在这种模式下，我们会再开发过程的早期提出环境要求，并强制代码和环境必须被一起测试的策略，一旦使用敏捷开发方法，我们可以做到非常简洁和优雅。

按敏捷的要求，在每个迭代结束后，我们就会发布能运行且可被部署的代码，通常时间为两周。我们将修改敏捷迭代周期策略，不仅仅只交付能运行且可被部署的代码，同时在每个迭代周期的早期，还必须准备好环境用于部署这些代码。

由此，我们不再让 IT 运维负责创建生产环境的规格要求，取而代之的，建立一个自动化的环境创建流程，这种机制不仅仅只创建生产环境，同时也包括开发和 QA 环境。

通过使得环境早期即可用，甚至可能早于软件项目开始之前，开发和 QA 可以在统一和稳定的环境中运行和测试他们的代码，从而控制不同环境之间的差异。

此外，通过保持不同阶段（例如，开发、QA、集成测试、生产）尽可能小的差异，在生产部署之前，我们就能发现并修复代码和环境之间的互操作性问题。

理想情况下，我们建立的部署机制是完全自动化的。可以使用像 Shell 脚本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed 等等很多工具来完成。

10. 我最喜欢的DevOps模式二：

BrowserMob 前 CEO，Patrick Lightbody 曾经说过，“当我们在凌晨 2 点叫醒开发工程师来解决问题时，缺陷被修复的比以前更快了，这真是一个惊人的反馈回路”，

这是我最喜欢的引用之一。

它强调了问题的关键点，开发一般会在周五的 5 点提交代码，然后高高兴兴的回家，而 IT 运维则要花费一整个周末来收拾残局。更糟的是，缺陷和已知错误在生产上不断递归，迫使 IT 运维不停的救火，而根本原因从不被修复，造成这种现象的原因就是开发总是关注开发新功能。

第二种模式的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验 (包括 IT 运维和最终用户)

注意这里的对称性，模式一讨论的尽早让环境统一并可用即是将 IT 运维嵌入到开中发，而模式二则为将开发嵌入到 IT 运维中。

我们将开发嵌入进 IT 运维的问题升级链中，可以将他们放在三级支持中，甚至使开发对整个代码的部署成功负责。要么回滚，要么修复缺陷，直到服务恢复。

我们的目标不是让开发取代 IT 运维，相反，就是想确开发看到他们工作和变更的下游变化，激励他们以 IT 运维的视角来更快的解决问题，从而达到一个全局的目标。

11. 我最喜欢的DevOps模式三：

在开发和 IT 运维之间 DevOps 价值流中，另一个经常发生的问题就是不够规范。这方面的例子是，每个部署都带有其特殊性，因此也使得每次部署后的环境带有特殊性，一旦这样的事情发生，那么这个组织里就没有针对流程配置的控制。

在这种模式下，我们定义可重用且可跨多个项目的部署流程，敏捷方法里有个很简单的解决方案。就是将部署的活动变成一个用户故事。例如，我们为 IT 运维构建一个可重用的用户故事，叫做“部署到高可用环境”，这个用户故事定义了明确的构建环境的步骤、需要多长时间、需要哪些资源等等。

那么这些信息可以被项目经理用来集成部署内容到项目计划中去。例如，如果我们知道在过去的 3 年时间里，“部署到高可用环境”用户故事被部署了 15 次，每次的平均部署时间为 3 天，加或减一天，那么我们对自己的部署计划将会非常有信心。

此外，我们还可以因部署活动被合适的集成到软件项目中而获得信心。

我们也得认识到有些特定的软件项目要求特别的环境，且其不被 IT 运维官方支持，我们可以允许这些被生产允许的环境中的例外，但是被 IT 运维部门外面的人提供支持的。

通过这种方法，我们即获得了环境标准化的好处（比如，减少生产差异，环境更一致，IT 运维的支持和维护能力增加），又能再允许的特殊情况下，提供业务需要的灵活性。

感谢丁雪丰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。