转自：http://www.infoq.com/cn/articles/11devops数据库
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人士”的名单中，普度大学还给他颁发了杰出校友奖以表彰他在专业领域的成就和领导力。数组
术语“DevOps”一般指的是新兴的专业化运动，这种运动提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提升生产环境的可靠性、稳定性、弹性和安全性。安全
为何是开发和IT运维？由于典型的价值流就是在业务（定义需求）和客户（交付价值）之间。运维
DevOps运动的起源一般被放在2009年先后，伴随着许多运动的相辅相成和相互促进——效率研讨会运动，特别是由John Allspaw和Paul Hammond展现的开创性的“一天10次部署”，基础设施即代码”运动(Mark Burgess 和Luke Kanies)，“敏捷基础设施运动” (Andrew Shafer)，“敏捷系统管理”运动(Patrick DeBois)，“精益创业”运动（Eric Ries），Jez Humble的持续集成和发布运动，以及Amazon的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。ide
DevOps的合著者John Willis写了一个很是好的帖子在这里工具
http://itrevolution.com/the-convergence-of-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/
尽管不少人视DevOps为ITIL和ITSM的颠覆，而我则有着不一样的见解，在支撑IT运维的业务流程方面，ITIL和ITSM流程无疑仍是最好的。实际上，他们描述了须要被IT运维支持的功能集合，这些功能集合足以支撑DevOps式的工做流。
敏捷和持续集成以及持续发布是开发的输出，这些输出同时做为IT运维的输入，为了适用跟DevOps相关的快速部署的节奏，ITIL流程的不少方面，特别是围绕着变动、配置和发布流程方面，须要自动化。
DevOps的目标不只只是增长变动的频率，并且也支持在不中断和破坏当前服务的基础上，确保功能部署成功，同时也能够快速检测和修复缺陷。这引入了服务设计，事故和问题管理方面的ITIL新准则。
2004年，我与Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》，可视运维是一个说明性的指南，该指南使得高性能IT运维能顺利实现“从优秀到卓越”的转变，关键点之一是如何控制和减小计划外的工做。
在开发和IT运维之间，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 Cookbook》里，咱们将DevOps模式分红4个领域，
领域一，将开发延伸至生产中——包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工做流，确保代码和环境可在生产中直接部署，。
领域二，向开发中加入生产反馈——包括创建开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽量使得开发能够自助服务，同时建立信息指示器用来代表本地的决策如何影响全局的目标。
领域三，开发嵌入到IT运维中——包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，并且开发为IT运维提供交叉培训，增长IT运维处理问题的能力，从而下降升级问题的数量。
领域四，将IT运维嵌入至开发——包括嵌入和联络IT运维资源至开发，帮助开发建立为IT运维(部署，生产代码的管理等)使用的可重用的用户故事，定义一些能够被全部项目共用的非功能性需求。
我相信企业在应用了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专业人员向他们的组织寻求帮助的时候，他们会获得回答：“你不明白”，更糟的是，他们甚至会获得“你不重要”这样的待遇。
DevOps的高部署频率一般会给QA和信息安全带来很大的压力，考虑这样一种情形，开发天天部署10次，而信息安全一般须要4个月的时间来评估应用的安全。很显然，在代码开发和代码安全审计方面的速率一点都不匹配。
2011年Dropbox故障就是一个著名的例子，其体现了未经充分测试的开发代码带来的风险有多大。由于此次事故，认证功能被关闭了4个小时，从而致使未受权的用户能够访问全部存储的数据。
固然对QA和信息安全来讲，也不全是坏消息， 开发会经过持续集成和好的发布惯例(持续测试的文化)来维持高频率部署。换句话说，一旦代码被提交，自动测试便开始运行，并且一旦发现问题，必须立刻解决，就像开发人员在检查还没编译的代码。
经过集成功能测试，集成测试和信息安全测试到开发的天天例行工做中，问题将会被更快发现，同时也会被更快解决。
一样，也有着愈来愈多的信息安全工具，好比Gauntlet和Security Monkey， 能够帮助咱们在开发和上线的过程当中测试安全对象，达到信息安全目标。
可是也有一个很重要的问题须要考虑，静态代码分析工具一般须要花费很长时间才能运行完，以数小时或天记。在这种状况下，信息安全就必须注明特定的有安全隐患的模块，好比加密，认证模块。只要这些模块变化，一轮全面的信息安全测试就运行，不然部署就能够继续，而不须要全覆盖信息安全测试。
须要特别提到的一点是，咱们观察到，相较于标准的功能单元测试，DevOps工做流依赖于检测和恢复更多一点。换句话说，固然开发以软件套件的方式交付的时候，那么部署变动和补丁就比较困难，同时QA也严重依赖代码测试来验证功能的正确性。另外一方面，当软件以服务的形式交付，缺陷就能够被很快修复。并且QA也能够减小测试依赖，取而代之的更多依赖缺陷的生产监控，只要缺陷能被快速的修复。
代码故障恢复可借助于“功能标签”等手段，经过以配置的形式来启用或禁用某些代码功能，从而达到避免推出一个全功能部署，而只部署经过测试的功能至生产。
当功能不可用或性能出现降低等较坏的状况发生的时候，依赖于检测和恢复进行QA将会一种更好的选择。可是当面对损失保密性或数据和系统一致性的时候，咱们就不能够依赖检测和恢复这种方法。取而代之的是，在部署以前，必须进行充分的测试，不然可能致使重大的安全事故。
一般，在软件开发项目中，开发都会用完全部计划中的时间用于开发功能。这样会致使没法充分解决IT运维的问题，因而他们就在定义，建立和测试数据库、操做系统、网络、虚拟化等代码依赖的方面直接抄捷径，以此节省时间。
因此这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要缘由。后果很严重，好比不适当的定义和指定环境、没法重部署、代码和环境的不兼容等等。
在这种模式下，咱们会再开发过程的早期提出环境要求，并强制代码和环境必须被一块儿测试的策略，一旦使用敏捷开发方法，咱们能够作到很是简洁和优雅。
按敏捷的要求，在每一个迭代结束后，咱们就会发布能运行且可被部署的代码，一般时间为两周。咱们将修改敏捷迭代周期策略，不只仅只交付能运行且可被部署的代码，同时在每一个迭代周期的早期，还必须准备好环境用于部署这些代码。
由此，咱们再也不让IT运维负责建立生产环境的规格要求，取而代之的，创建一个自动化的环境建立流程，这种机制不只仅只建立生产环境，同时也包括开发和QA环境。
经过使得环境早期便可用，甚至可能早于软件项目开始以前，开发和QA能够在统一和稳定的环境中运行和测试他们的代码，从而控制不一样环境之间的差别。
此外，经过保持不一样阶段（例如，开发、QA、集成测试、生产）尽量小的差别，在生产部署以前，咱们就能发现并修复代码和环境之间的互操做性问题。
理想状况下，咱们创建的部署机制是彻底自动化的。可使用像Shell脚本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等不少工具来完成。
BrowserMob前CEO，Patrick Lightbody曾经说过，“当咱们在凌晨2点叫醒开发工程师来解决问题时，缺陷被修复的比之前更快了，这真是一个惊人的反馈回路”，
这是我最喜欢的引用之一。
它强调了问题的关键点，开发通常会在周五的5点提交代码，而后高高兴兴的回家，而IT运维则要花费一整个周末来收拾残局。更糟的是，缺陷和已知错误在生产上不断递归，迫使IT运维不停的救火，而根本缘由从不被修复，形成这种现象的缘由就是开发老是关注开发新功能。
第二种模式的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验(包括IT运维和最终用户)
注意这里的对称性，模式一讨论的尽早让环境统一并可用便是将IT运维嵌入到开中发，而模式二则为将开发嵌入到IT运维中。
咱们将开发嵌入进IT运维的问题升级链中，能够将他们放在三级支持中，甚至使开发对整个代码的部署成功负责。要么回滚，要么修复缺陷，直到服务恢复。
咱们的目标不是让开发取代IT运维，相反，就是想确开发看到他们工做和变动的下游变化，激励他们以IT运维的视角来更快的解决问题，从而达到一个全局的目标。
在开发和IT运维之间DevOps价值流中，另外一个常常发生的问题就是不够规范。这方面的例子是，每一个部署都带有其特殊性，所以也使得每次部署后的环境带有特殊性，一旦这样的事情发生，那么这个组织里就没有针对流程配置的控制。
在这种模式下，咱们定义可重用且可跨多个项目的部署流程，敏捷方法里有个很简单的解决方案。就是将部署的活动变成一个用户故事。例如，咱们为IT运维构建一个可重用的用户故事，叫作“部署到高可用环境”，这个用户故事定义了明确的构建环境的步骤、须要多长时间、须要哪些资源等等。
那么这些信息能够被项目经理用来集成部署内容到项目计划中去。例如，若是咱们知道在过去的3年时间里，“部署到高可用环境”用户故事被部署了15次，每次的平均部署时间为3天，加或减一天，那么咱们对本身的部署计划将会很是有信心。
此外，咱们还能够因部署活动被合适的集成到软件项目中而得到信心。
咱们也得认识到有些特定的软件项目要求特别的环境，且其不被IT运维官方支持，咱们能够容许这些被生产容许的环境中的例外，可是被IT运维部门外面的人提供支持的。
经过这种方法，咱们即得到了环境标准化的好处（好比，减小生产差别，环境更一致，IT运维的支持和维护能力增长），又能再容许的特殊状况下，提供业务须要的灵活性。