译 者 序
为什么要翻译这本书
2016年7月中旬，机械工业出版社华章公司王春华老师问我有没有兴趣翻译一本DevOps实践的书，在看过这本书的英文版之后，我欣然答应了。
因为，我知道这是一本有重要价值的书，我愿意花时间把它翻译出来，我想让它被更多人研读学习。
自从在Agile 2008大会上讨论DevOps一词以来，DevOps理念得到了IT从业者的认可和追捧。数年之后，再次客观地审视DevOps运动时，我们发现从整个信息技术领域来看，DevOps还没有成为开发和运维的事实标准。
原因何在？
我想，其中最重要的一个原因是，很多组织缺少在业务中引入DevOps实践的专家知识，也没有很多可以借鉴的成功案例。而这本书正好可以解决这个问题。
本书从软件架构师的视角讲解了引入DevOps实践所需要掌握的技术能力，涵盖了运维、部署流水线、监控、安全与审计以及质量关注。第四部分通过3个经典案例研究，讲解了在不同场景下应用DevOps实践的方法。这对于想应用DevOps实践的组织具有切实的指导意义。
初识本书，我有一种相见恨晚的感觉。研读之后，这种感觉尤甚。相信读者也一定会有这样的感觉。
衷心希望本书中文版能给读者带来有价值的信息，为推动DevOps进一步发展和应用做出贡献。
读者对象
本书适合以下几类读者阅读：
软件架构师
中高级运维工程师
计算机相关专业的学生
希望提高IT生产力的人员
勘误支持
虽然译者试图努力保证本书翻译中不出现错误，但鉴于译者的知识和视角，书中难免出现用词错误、技术适用性的问题。在此，译者恳请读者不吝指教，指出错误。请读者发送邮件到xufengnju@163.com或者加入QQ群434242482，帮助译者修正错误。本书的勘误将在网站http://xufeng.info/刊载。
译者说明
本书由来自盛大游戏、唯品会等互联网企业的资深DevOps专家联合翻译完成。
除胥峰、任发科外，参与翻译的人员还有米全喜、吴昊、黄灵等。全书由胥峰完成统稿和技术审校。
致谢
感谢华章公司引进了本书的中译本版权，这是本中译本得以面市的最核心要素。
感谢华章公司盛思源、关敏和王春华老师，你们专业的编辑能力为本书提供了重要的质量保证。
感谢盛大游戏各位领导对我翻译本书的关心和支持。
感谢我的妻子吕宁和可爱的女儿胥欣，谢谢你们的支持和理解。
前言
多年以来，我们一直在探索研究运维中的问题。自然而然地，我们也一直在追踪DevOps运动。它正在沿着Gartner成熟度曲线向上发展。这种现象有着坚实的业务原因。我们能够找到从信息技术经理视角对DevOps的探讨（例如小说《凤凰项目：一个IT运维的传奇故事》），也能找到从项目经理视角对DevOps的探讨（例如《持续交付：发布可靠软件的系统方法》）。而且，关于文化变革和文化变革对于打破组织单元之间障碍的意义，也有大量的资料。
然而，令我们感到失望的是，鲜有从软件架构师角度对DevOps探讨的资料。把运维人员视为首要干系人并且聆听他们的需求当然是非常重要的。使用工具来支持运维和项目管理也是非常重要的。然而，我们强烈感觉到，DevOps并不仅仅是关于干系人管理和工具使用的。
事实上，正是因为目前缺少这方面的资料，所以我们才决定撰写本书，把这些缺失的内容填充起来。DevOps与设计、过程、工具化和组织结构之间的相互作用令人着迷。我们试图回答两个主要问题：作为软件架构师，我需要做出什么样的技术决策才能够实现DevOps目标？DevOps领域的其他参与者会对我产生什么样的影响？
以上这些问题的答案是，实现DevOps目标可能包含着对你的系统架构和角色以及责任做出重大变更，在把系统部署到生产环境以及在生产环境中支持这些系统时，需要以上角色及责任。
正如软件架构师必须理解他们所设计与构建的系统的业务情境和目标一样，理解DevOps也要理解组织和业务情境，同时也要理解技术和运维情境。我们探索了所有这些内容。
本书的主要读者是那些曾经被问过或者将被问到“这个项目或者组织是否应该采用DevOps实践”这个问题的执业软件架构师。甚至他们不是被追问这个问题，而是他们有可能被告知是否应该采用DevOps实践。与所有书一样，我们期望还有其他类型的读者。那些有兴趣学习更多关于软件架构实践的学生应该可以在本书中找到一些感兴趣的资料。那些想探索研究DevOps课题的研究人员可以在本书中找到重要的背景资料。然而，我们的主要读者还是那些执业软件架构师。
概述
在本书的开始，我们讨论了DevOps的背景。在第一部分中，我们研究了DevOps的目标以及期望使用DevOps来解决的问题。我们会涉及组织和文化问题，也会涉及DevOps实践和敏捷方法学的关系。
在第2章中，我们研究了云。随着云即平台（Cloud as a Platform）的增长，DevOps实践也得到了发展。理论上，DevOps和云即平台是可分开的，但是事实上，虚拟化和云是推动DevOps实践的重要力量。
在介绍背景知识的最后一章（第3章）中，我们按照信息技术基础设施库（Information Technology Infrastructure Library，ITIL）的理论研究了运维。ITIL是对运维组的最重要功能进行组织的体系。不是所有的运维工作都包含在DevOps实践中，但是理解运维组的职责却会提供重要的上下文信息，特别是当需要理解角色和职责时。
第二部分描述了部署流水线（Deployment Pipeline）。在这一部分中，我们首先探索了微服务架构风格，这出现在第4章中。为了应用DevOps实践而以微服务风格进行系统架构并不是必需的，但是，却能用微服务架构风格来解决DevOps所需要解决的一些问题。
在第5章中，我们简略介绍了构建和测试过程以及工具链。理解这些内容很重要，但它们不是我们的焦点。我们介绍了把系统部署到生产环境所关联的各种不同环境以及在这些环境上执行的不同类型的测试。因为在DevOps中用到的很多工具也在构建和测试过程中被用到了，所以我们提供了理解这些工具和如何控制它们的上下文信息。
我们以讨论部署结束第二部分。DevOps的目标之一是加速部署。实现这个目标的一种技术是，使得每个开发团队可以在完成准备后独立地部署他们的代码。独立部署带来了很多一致性的问题。我们将讨论不同的部署模型；管理同时运行在生产环境中不同版本的系统；在发生错误时回滚；以及与实际把系统部署到生产环境中有关的其他主题。
第二部分提供了从功能视角观察部署实践的内容。然而，与其他任何系统一样，质量视角常常是控制系统设计和系统接受度的主要因素。在第三部分中，我们聚焦在横切关注点上。我们首先在第7章中讨论了监控和现场测试（live testing）。现代软件测试实践在将系统部署到生产环境中以后并没有结束。首先，系统被广泛地监控以检测问题；其次，在将系统部署到生产环境以后，测试正以各种形式继续进行。
另一个横切关注点是安全。我们在第8章中讨论了该内容。我们展示了环境中各种不同类型的安全控制，包括组织范围和特定系统范围的安全控制。我们讨论了与实现安全相关联的不同角色以及在安全审计案例中如何评估这些角色。
安全不是质量关注的全部。在第9章中，我们讨论了与DevOps实践有关的其他方面的质量。我们讨论的主题包括部署流水线的性能、可靠性和可修改性。
第三部分的最后，我们在第10章中讨论了业务关注。像DevOps这种涉及面广泛的实践，如果得不到来自管理层的支持，是无法被采用的。业务计划是寻求这种支持的一种典型方法。因此，我们描述了为引进DevOps所需要准备的业务计划的组成元素，然后讨论了如何进行论证、推出和测量业务计划。
在第四部分中，我们描述了3个案例研究。这些实施了DevOps实践的组织给我们讲解了他们所采用的一些技巧。第11章讨论了为了实现业务连续性如何维护两个数据中心；第12章展示了一个持续部署流水线的细节；第13章描述了一个组织是如何迁移到微服务架构上的。
作为本书的结尾，我们在第五部分展望了DevOps的未来。第14章描述了我们的研究以及它是如何基于把运维视作一系列过程来进行的。第15章预测了未来3～5年DevOps将如何发展。
致谢
本书离不开众多人的帮助。在此，感谢Chris Williams、John Painter、Daniel Hand和Sidney Shek，他们为案例研究做出了贡献。同时，感谢Adnene Guabtni、Kanchana Wickremasinghe、Min Fu和Xiwei Xu在有些章节中提供的帮助。
感谢Manuel Pais帮助我们编排了案例研究。感谢Philippe Kruchten、Eoin Woods、Gregory Hartman、Sidney Shek、Michael Lorant、Wouter Geurts和Eltjo Poort对本书做出了评论或者为本书的某些方面做出了贡献。
下列人士对第13章做出了评论，在此表示感谢：Jean-Michel、Lemieux、Greg Warden、Robin Fernandes、Jerome Touffe-Blin、Felipe Cuozzo、Pramod Korathota、Nick Wright、Vitaly Osipov、Brad Baker和Jim Watts。
在出版阶段，Addison-Wesley出版社的编辑用他们一贯的专业和高效的工作为本书顺利出版做出了贡献。他们的专业知识和工作经验提升了本书的质量。
最后，感谢NICTA和NICTA的管理层。NICTA是由澳大利亚政府通过通信部（Department of Communications）和由澳大利亚研究委员会（Australian Research Council）通过ICT卓越中心（Centre of Excellence）项目组建的。如果没有他们的慷慨支持，本书将难以完成。
图例说明
对于图，我们使用了4种不同的图例。我们使用架构标注法来识别我们使用的关键架构概念；使用业务流程建模标注（Business Process Model and Notation，BPMN）来描述一些过程；使用波特价值链标注（Porter’s Value Notation）来描述一些其他的过程；使用UML时序图来组织活动的顺序。这里没有给出UML时序图标注。我们给出了通过其他方法进行的标注。
