什么是DevOps，如何实现DevOps？

，还能周周比对手早一步──Gartner预言：2016年全球大企业中25％要抢用DevOps。

　　正是如此，企业正为DevOps所苦恼。他们都想得到DevOps，即使很多企业并不知道它到底是什么。比如，在很多情况下，一些工程师将自己宣传为DevOps，但是这仅是你自己的看法，实际上你并不是。DevOps并不是一个人，一个角色或者一个头衔。

　　

　　那么DevOps到底是什么呢？

　　DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。Cloud Technology Partners公司的副总裁兼首席架构师Mike Kavis如此定义。

　　Kevin Behr是HedgeServ的创始人和首席信息官，他说，DevOps综合了社会体系和技术体系。

　　ThoughtWorks Studios的首席顾问 Jez Humble谈到了DevOps不仅仅是个工具，更是一种理念。DevOps是一种使持续交付成为可能的理念，关注于所有人共同协作以改进开发效率方面的衡量（比如生产力），同时增加稳定性并降低平均故障修复时间。

　　2U Inc的技术总监James Kenigsberg描述了DevOps几个主要部分的本质：

　　自动化：自动化确保过程的可重复性和稳定性。一直以来，它都是将任务执行予以标准化的最佳方式，避免任何可能产生偏差的风险，从同行评审代码到整个团队的流程改进。

　　透明度：透明度让团队中的每个成员都可以清楚地看到其他人正在做什么，正在改进的沟通机制和业务流程，等等等等。

　　才华：天才雇员把业务需要、效率和自动化放到硬件如何运作之前，在IT和开发人员之间不做严格的区分。在解决问题之前，他们到处找有此类经验的同事们交流，问问他们之前是如何解决这种问题的。

　　DevOps是种与众不同的方案，它同时兼顾技术和人的问题。VersionOne 的敏捷老师Steve Ropa如此认为。Steve说，DevOps参考了许多技术方案。充分理解大多数这类实践是DevOps的基础。像持续集成此类的已经深入人心非常长的时间了，为了确保持续集成值得花时间做下去，它不但需要一台持续集成服务器还需要一致的自动化装置和验收测试。它还需要和版本控制系统紧密地集成在一起，以使所有事都在版本控制之下。除了这种技术实践之外，为了成功地实施DevOps，我们还要关注人、协作和理念。要从事这些实践，我们就需要人。把运维融入团队中需要一种理念，那就是心甘情愿地去做出艰难地调整和改变。这是思维模式的巨大转变。

　　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与敏捷有哪些不同？

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

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

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

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

　　DevOps具有与生俱来的文化变革的基因组成，因为它革新了开发和IT运维之间的工作流和传统的衡量标准。

　　DevOps与ITIL和ITSM有什么不同？

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

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

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

　　DevOps和可视运维如何搭配

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

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

　　DevOps的基本原则

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

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

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

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

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

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

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

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

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

　　DevOps模式的应用领域

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

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

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

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

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

　　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专业人员向他们的组织寻求帮助的时候，他们会得到回答：“你不明白”，更糟的是，他们甚至会得到“你不重要”这样的待遇。

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

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

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

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

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

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

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

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

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

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

　　DevOps模式之一

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

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

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

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

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

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

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

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

　　DevOps模式之二：

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

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

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

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

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

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

　　DevOps模式之三：

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

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

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

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

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

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

　　的确，DevOps的提出旨在消除开发人员和系统运维工程师之间的障碍，但能否成功却取决于公司的文化和灵活性。