前言

啊哈！

本书的写作由来已久。早在2011年2月，我们几位合著者就开始每周一次的Skype通话，准备写一本通用的DevOps参考指南，算作《凤凰项目：一个IT运维的传奇故事》的姊妹篇。

前后历时5年多，耗费2000多小时，本书终于呈现在你的面前。过程相当漫长，但也是一个非常有益且难得的学习过程，最终涉及的范围比我们早期预想的更广。在整个写作过程中，所有合著者都始终坚信DevOps的重要性。我们在早期的职业生涯中，都曾经历过“啊哈”的顿悟时刻，相信很多读者也都会与我们产生共鸣。

Gene Kim

从1999年以来，我有幸一直在研究高绩效技术组织，最早的一个发现是：IT运维、信息安全和开发等不同职能部门之间的良好合作是成功的关键。我依然清楚地记得第一次看到由于这些部门目标相左导致恶性循环的场景。

那是在2006年，我跟某管理团队待了整整一星期，他们当时正在为一家大的机票预订公司提供外包IT运维的管理服务。他们给我描述了每年要做的软件升级的后果：每次发布都会让外包商和客户的服务中断；由于客户受到了影响，公司也会根据服务等级协议（SLA）受到处罚；公司利润下滑，不得不解雇一些很有才华和经验的员工；由于有大量计划外的工作和紧急任务，剩下的员工无法处理日益增长的客户服务请求；只好投入中层管理团队一道完成合同要求；所有人都认为3年后肯定得重新招标。

这种绝望和无助的感受使我加入了这场道义上的征程。开发似乎总是被视为战略性的，而IT运维则被视为战术性的，因此常常被委托甚至整个外包出去，结果是5年后的情形比当初交接时更加糟糕。

多年来，我们许多人都认为一定有更好的做法。在2009年的Velocity会议上，我看到了这样的演讲——介绍了在架构、技术实践和文化方面并举的革新（我们现在称之为DevOps）所产生的惊人效果。当时，我非常兴奋，因为它就是我们一直在寻找的那个更好的方法。传播DevOps是我合著《凤凰项目》的动机之一。你可以想象，看到更广大的社群对那本书做出的反应，说它是如何帮助他们实现自己的“啊哈”时刻的，我是多么地倍感欣慰！

Jez Humble

我的DevOps“啊哈”时刻发生在2000年，当时我就职于一家创业公司，那是我毕业后的第一份工作。有一段时间，我是公司仅有的两名技术人员之一。我包揽了网络、编程、支持、系统管理等一切工作。我们通过FTP直接从工作站往生产环境部署软件。

我在2004年加入了ThoughtWorks咨询公司，参与的第一个项目涉及大约70人。我所在的部署团队共8名工程师，团队的主要工作就是将软件部署到类生产环境中。刚开始的时候，工作非常紧张。但几个月后，我们就从需要花两个星期的手动部署，进步到了只用一个小时的自动化部署。在正常的工作时间段里，我们也可以使用蓝绿部署模式，以毫秒为单位来发布或者回滚业务的应用。

这个项目对《持续交付：发布可靠软件的系统方法》和本书的诸多想法都很有启发意义。对于我和从事该领域工作的其他人而言，动力有两个：我们知道无论是什么限制，总能做得更好；我们热切希望帮助那些正在奋斗的人们。

Patrick Debois

对我来说，DevOps意味着一系列的回忆。2007年，我与几个敏捷团队一起，做一个数据中心迁移项目。我很嫉妒他们的高生产力——能够在很短的时间里做很多的工作。

在接下来的一个项目中，我便开始在运维工作中试验看板方法（Kanban），并看到了团队的显著变化。后来，在2008年的多伦多敏捷大会上，我基于这个实践发表了一篇IEEE论文，不过当时它并没有在敏捷社区里引起广泛的共鸣。我们创建了敏捷系统管理组（Google Group），但忽视了人这一因素。

在2009年的Velocity会议上，我听了John Allspaw和Paul Hammond所分享的“每日10次部署”的演讲以后，确信其他人与我英雄所见略同。因此我决定组织第一次DevOpsDays活动，误打误撞地创造了“DevOps”这个词。

DevOpsDays活动体现了独特的魅力和感染力。当人们开始因DevOps改善了他们的工作而感谢我时，我才真正意识到它的影响力。从那以后，我就开始持续地推广DevOps。

John Willis

2008年，我第一次见到Luke Kanies（Puppet Labs的创始人）本人，那时我刚刚出售了专注于大型系统的配置管理和监控（Tivoli）实践的咨询业务。Luke在O’Reilly开源大会的配置管理分会场里介绍了Puppet软件。

演讲刚开始时，我在会场最后一排走来走去消磨时间，心想：“关于配置管理，这个20岁的年轻人能讲些什么呢？”毕竟，我在整个职业生涯中，基本都在帮助世界上最大的那些企业构建配置管理和其他运维管理方案。然而，他大约讲了5分钟后，我就坐到了第一排，同时意识到在过去20年里，我真是一无是处。Luke所描述的就是现在我们所说的第二代配置管理。

在他演讲完之后，我找机会和他坐下来一起喝了杯咖啡。我完全被“基础设施即代码”（infrastructure as code）的理念所折服了。Luke一边喝着咖啡，一边更详细地向我阐述了他的想法。他告诉我，他相信运维人员的工作模式可能会变得像开发人员一样，他们必须在源代码控制系统里维护系统的配置，并在工作中使用持续集成/持续交付（CI/CD）的模式。作为一名IT运维的老兵，我当时的回应大概是“运维人员不会喜欢你这个想法的”。（显然是我错了。）

大约又过了一年，在2009年O’Reilly的Velocity会议上，我听了Andrew Clay Shafer关于敏捷基础设施的演讲。在演讲中，Andrew展示了一幅形象的插图，图中的开发部门和运维部门之间存在一堵高墙，以此隐喻工作被两个部门踢来踢去。他将此称为“混乱之墙”（the wall of confusion）。这个想法其实和一年前Luke的想法如出一辙，这让我眼前一亮。那年年底，我作为唯一受邀的美国人，参加了比利时根特市的首次DevOpsDays活动。在活动结束时，这个所谓DevOps的东西已然融入了我的血液。

显然，本书的合著者都有类似的顿悟，尽管他们来自完全不同的方向。有充分的证据表明，上述这些问题几乎在所有地方都发生过，而那些DevOps相关的解决方案也几乎是普遍适用的。

编写本书的目的是描述如何复制我们参与过的或观察到的DevOps转型的成功经验，驳斥那些说DevOps在某些场景里行不通的谬论。以下是我们听说过的关于DevOps的一些最常见的误区。

误区1：DevOps只适用于创业公司。 虽然谷歌、亚马逊、Netflix和Etsy等互联网“独角兽”公司是DevOps的先行者，但这些公司在过去都面临过巨大的风险，而且他们所遇到的问题和传统企业相比并无二致：软件的高风险代码容易导致灾难性故障，无法快速发布新功能来击败竞争对手，存在安全合规性问题，服务无法扩容，开发和运维彼此高度不信任等。

然而，这些公司都能够适时地改变它们的架构、技术实践和文化，如今他们都创造出了惊人的DevOps成果。正如信息安全高管Branden Williams博士所说：“不要管DevOps是适合独角兽还是马，只要跑得快就能抵达目的地。”

误区2：DevOps将取代敏捷。 DevOps的原则和实践与敏捷方法一致，许多人认为DevOps是自2001年开始的敏捷之旅的合理延续。敏捷通常是DevOps效率的保障，因为它专注于让小团队向客户持续交付高品质的代码。

如果我们每次迭代的目标不限于“潜在可交付的代码”，而是扩展到让代码始终处于可发布状态，让开发人员每天都把代码提交到主干，并在类生产环境中做功能演示，那么许多DevOps相关的实践就会浮现。

误区3：DevOps与ITIL不兼容。 许多人认为，DevOps与1989年发布的ITIL（Information Technology Infrastructure Library，IT基础架构库）或ITSM（IT Service Management，IT服务管理）是背道而驰的。ITIL广泛影响了好几代运维实践者，包括本书的一位合著者，并且它依然在演进，是一个不断发展的实践体系，旨在稳定地支撑世界级的IT运维，而且横跨服务战略、设计和支持等流程和实践。

DevOps实践可以与ITIL流程兼容。然而，为了支持DevOps所追求的更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题，例如保持配置管理数据库和最终软件库是最新的。由于DevOps需要在服务事件发生时进行快速的定位和恢复，因此这些其实还是和ITIL的服务设计、事件和问题管理方面的原则相一致。

误区4：DevOps与信息安全及合规活动不兼容。 传统控制手段（例如职责分离、变更审批流程、项目结束时的手动安全审查）的缺位，可能会令信息安全和合规审计人员感到失望。

然而，这并不意味着采用DevOps的公司里没有有效的控制，只是它并不一定体现在项目结束时的安全和合规性活动中，而是集成到了软件开发生命周期的每一项日常工作中，因此会得到更好的质量、安全性和合规性。

误区5：DevOps意味着消除IT运维，即“NoOps”。 许多人错误地将DevOps解释为完全消除IT运维的职能，然而，这种情况是很少见的。虽然IT运维工作的性质可能会发生改变，但它仍然像以前一样重要。IT运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境中后，开发团队也要继续与运维团队合作。

IT运维不只是工单驱动的手动操作，而是能够通过自助服务平台和API来提升开发人员的生产效率，让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式，IT运维人员变得更像是开发人员（或者QA和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行IT服务的平台。

误区6：DevOps只是“基础设施即代码”或自动化。 尽管本书所展示的许多DevOps模式都需要自动化，但是DevOps还需要文化规范和架构，以便在IT价值流中实现共同的目标。而这远远超越了自动化的范畴。DevOps最早的拥护者之一Christopher Little也是一名技术主管，他写道：“DevOps不仅是自动化，就像天文学不只是望远镜一样。”

误区7：DevOps仅适用于开源软件。 尽管许多DevOps成功案例发生在使用LAMP栈（Linux、Apache、MySQL、PHP）等构建软件的公司，但实现DevOps与所使用的技术无关。在使用Microsoft .NET、COBOL和大型机汇编语言以及SAP甚至嵌入式系统（如惠普LaserJet打印机固件程序）等编写应用程序的公司，DevOps也能取得成功。

传播“啊哈”时刻

本书的每一位作者都被DevOps社区里发生的惊人创新及成果深深地打动和启发：他们正在创建安全的工作系统，让小型团队能够快速独立地开发和验证能够为客户安全地部署的代码。我们相信，DevOps是创建动态、学习型且强化高度信任的文化规范的公司的一种表现形式，这些公司一定会持续地在市场上创新并在竞争中脱颖而出。

我们真诚地希望本书能以多种方式为许多人提供价值，它可以是一个DevOps转型计划和实践指南，也可以是一组可供研究和学习的参考案例，可以是一部DevOps编年史，也可以是一种联结产品经理、架构师、开发人员、QA、IT运维和信息安全团队以实现共同目标的方法，可以是一条为DevOps活动获取高层领导支持的途径，也可以是一种改变技术组织管理方式的道德使命，以帮助企业提高效率，创造更快乐和更人性化的工作环境，并帮助每个人成为终身学习者。这不但能帮助每个人实现他们个人的最高目标，而且还能帮助他们的公司取得更大的成功。