DevOps：软件架构师行动指南

　　《DevOps：软件架构师行动指南》从软件架构师视角讲解了引入DevOps实践所需要拥有的技术能力，涵盖运维、部署流水线、监控、安全与审计以及质量关注。通过三个经典案例研究，讲解在不同场景下应用DevOps实践的方法，对于想应用DevOps实践的组织提供切实的指导。

　　全书共五部分。第一部分（第1~3章）讨论DevOps的背景，包括DevOps的目标和期望使用DevOps解决的问题、云、运维等。第二部分（第4~6章）介绍部署流水线，从功能性视角介绍部署实践的内容，涵盖微服务架构风格、构建和测试过程、工具链，以及具体的部署问题。第三部分（第7~10章）介绍横切关注点，讨论了计算监控、实时测试、安全与安全审计，以及部署流水线的性能、可靠性、可修改性等。还介绍了业务关注点，包括为引进DevOps所需要准备的业务计划的组成元素，以及如何进行论证、推出和测量业务计划。第四部分（第11~13章）描述3个案例研究：为了实现业务连续性如何维护两个数据中心，管理一个持续部署流水线，一个组织如何迁移到微服务架构上。第五部分（第14~15章）设想evOps的未来，介绍了目前的研究以及如何基于把运维视作一系列过程来进行，并给出了3~5年内DevOps将如何发展的预测。

　　作者简介:

　　伦恩·拜斯（Len Bass） 澳大利亚NICTA的高级首席研究员。他曾在卡内基梅隆大学软件工程研究所工作25年，有超过50年的软件开发和研究经验。他是两本软件架构方面获奖图书的合作者（《Software Architecture in Practice, Third Edition》和《Documenting Software Architectures：Views and Beyond，Second Edition》），他还与人合作出版或发表了数篇计算机科学与软件工程领域的其他书籍和论文。

　　英戈·韦伯（Ingo Weber） 澳大利亚NICTA软件系统研究组的高级研究员，也是新南威尔士大学计算机科学与工程系的兼职高级讲师。他的研究领域包括云计算、DevOps、业务过程管理以及人工智能。

　　朱黎明（Liming Zhu）　澳大利亚NICTA一个研究小组的负责人和首席研究员。他拥有新南威尔士大学和悉尼大学的联合职位。曾就职于数个在软件领域具有领先地位的技术公司。

　　译者简介:

　　胥峰 资深运维专家，有10年运维经验，在业界颇具威望和影响力。2011年加入盛大游戏，工作至今，曾参与盛大游戏多款大型端游和手游的运维，主导 运维自动化平台的功能设计和实施。通过公众号“运维技术实践”发布 “网络分析技术实践”系列主题技术文章，引发万人阅读转发。拥有工信部认证高级信息系统项目管理师资格。
　　任发科目前担任融数数据研发总监，曾任职唯品会、会唐网、亚*逊、ThoughtWorks，有十余年软件开发、架构和管理经验。曾参与多个电商相关系统的研发工作，近年主要从事DevOps工具链的设计与实现，大数据平台的组建，以及高效研发团队的组建与管理。

　　DevOps为加速新软件功能的发布和改善对生产环境系统的监控带来了希望，但是对软件架构师和软件架构来说，DevOps的关键意义却常常被忽视。本书全面解决了这些问题，不仅剖析了软件架构师为实现DevOps目标必须要做出的决策，并且说明了DevOps的其他参与者有可能以哪种方式来影响架构师的工作，还详细介绍了高效部署DevOps所需要的组织、技术和运营环境，以及DevOps对每个开发阶段的影响。作者解决了把多个功能关联起来的横切关注点问题，提供了对合规性、性能、可靠性、可重复性和安全方面的切合实际的洞察。

　　译　者　序

　　为什么要翻译这本书

　　2016年7月中旬，机械工业出版社华章公司王春华老师问我有没有兴趣翻译一本DevOps实践的书，在看过这本书的英文版之后，我欣然答应了。

　　因为，我知道这是一本有重要价值的书，我愿意花时间把它翻译出来，我想让它被更多人研读学习。

　　自从在Agile 2008大会上讨论DevOps一词以来，DevOps理念得到了IT从业者的认可和追捧。数年之后，再次客观地审视DevOps运动时，我们发现从整个信息技术领域来看，DevOps还没有成为开发和运维的事实标准。

　　原因何在？

　　我想，其中最重要的一个原因是，很多组织缺少在业务中引入DevOps实践的专家知识，也没有很多可以借鉴的成功案例。而这本书正好可以解决这个问题。

　　本书从软件架构师的视角讲解了引入DevOps实践所需要掌握的技术能力，涵盖了运维、部署流水线、监控、安全与审计以及质量关注。第四部分通过3个经典案例研究，讲解了在不同场景下应用DevOps实践的方法。这对于想应用DevOps实践的组织具有切实的指导意义。

　　初识本书，我有一种相见恨晚的感觉。研读之后，这种感觉尤甚。相信读者也一定会有这样的感觉。

　　衷心希望本书中文版能给读者带来有价值的信息，为推动DevOps进一步发展和应用做出贡献。

　　读者对象

　　本书适合以下几类读者阅读：

　　软件架构师

　　中高级运维工程师

　　计算机相关专业的学生

　　希望提高IT生产力的人员

　　勘误支持

　　虽然译者试图努力保证本书翻译中不出现错误，但鉴于译者的知识和视角，书中难免出现用词错误、技术适用性的问题。在此，译者恳请读者不吝指教，指出错误。请读者发送邮件到[email protected]或者加入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时序图标注。我们给出了通过其他方法进行的标注。

译者序

前言

第一部分　背　　景

第1章　DevOps是什么 …… 2

1.1　概述 …… 2

1.1.1　定义DevOps …… 2

1.1.2　DevOps实践 …… 3

1.1.3　持续部署的例子：IMVU …… 5

1.2　为什么是DevOps …… 5

1.2.1　发布过程 …… 5

1.2.2　配合不佳的原因 …… 7

1.2.3　运维人员能力有限 …… 7

1.3　DevOps视角 …… 8

1.3.1　自动化 …… 8

1.3.2　开发团队的职责 …… 9

1.4　DevOps与敏捷 …… 9

1.5　团队结构 …… 10

1.5.1　团队规模 …… 10

1.5.2　团队角色 …… 10

1.6　协作 …… 13

1.6.1　协作的形式 …… 13

1.6.2　团队协作 …… 14

1.6.3　跨团队协作 …… 14

1.7　障碍 …… 15

1.7.1　文化及组织类型 …… 15

1.7.2　部门类型 …… 16

1.7.3　筒仓思维方式（Silo Mentality） …… 17

1.7.4　工具支持 …… 17

1.7.5　人员问题 …… 17

1.8　小结 …… 18

1.9　更多阅读材料 …… 18

第2章　云即平台 …… 20

2.1　概述 …… 20

2.2　云的特性 …… 21

2.2.1　虚拟化 …… 22

2.2.2　IP和域名系统管理 …… 23

2.2.3　平台即服务 …… 25

2.2.4　分布式环境 …… 25

2.3　独特的云特性对DevOps的影响 …… 30

2.3.1　环境 …… 30

2.3.2　轻松创建虚拟机 …… 31

2.3.3　数据考量 …… 31

2.4　小结 …… 32

2.5　更多阅读材料 …… 33

第3章　运维 …… 34

3.1　概述 …… 34

3.2　运维服务 …… 34

3.2.1　供给硬件 …… 34

3.2.2　供给软件 …… 35

3.2.3　IT功能 …… 36

3.2.4　服务级别协议 …… 36

3.2.5　容量规划 …… 36

3.2.6　业务连续性和安全 …… 37

3.2.7　服务策略 …… 38

3.2.8　服务设计 …… 39

3.2.9　服务移交 …… 39

3.2.10　服务运维 …… 40

3.2.11　服务运维概念 …… 40

3.3　服务运维功能 …… 41

3.4　持续服务改进 …… 42

3.5　运维和DevOps …… 43

3.6　小结 …… 44

3.7　更多阅读材料 …… 44

第二部分　部署流水线

第4章　整体架构 …… 48

4.1　DevOps实践是否需要架构调整 …… 48

4.2　架构结构总览 …… 49

4.2.1　协作模式 …… 50

4.2.2　资源管理 …… 51

4.2.3　架构元素之间的映射 …… 52

4.3　微服务架构的质量 …… 52

4.3.1　可靠性 …… 53

4.3.2　可修改性 …… 54

4.4　团队的亚马逊规则 …… 55

4.5　现有系统的微服务方案 …… 56

4.6　小结 …… 56

4.7　更多阅读材料 …… 57

第5章　构建与测试 …… 58

5.1　概述 …… 58

5.2　在部署流水线中移动系统 …… 59

5.2.1　可追溯性 …… 59

5.2.2　环境 …… 60

5.3　横切关注点 …… 61

5.4　开发及提交前测试 …… 63

5.4.1　版本控制与分支 …… 63

5.4.2　功能开关 …… 65

5.4.3　配置参数 …… 66

5.4.4　在开发和提交前测试中的测试 …… 67

5.5　构建与集成测试 …… 67

5.5.1　构建脚本 …… 67

5.5.2　打包 …… 68

5.5.3　持续集成与构建状态 …… 69

5.5.4　集成测试 …… 70

5.6　用户验收测试/预发布/性能测试 …… 70

5.7　生产环境 …… 71

5.7.1　早期发布测试 …… 71

5.7.2　错误检测 …… 72

5.7.3　现场测试 …… 72

5.8　事件 …… 73

5.9　小结 …… 73

5.10　更多阅读材料 …… 74

第6章　部署 …… 75

6.1　概述 …… 75

6.2　部署管理的策略 …… 76

6.2.1　蓝/绿部署 …… 76

6.2.2　滚动升级 …… 77

6.3　逻辑一致性 …… 78

6.3.1　相同服务的多个版本同时存在 …… 78

6.3.2　兼容数据库中保存的数据 …… 81

6.4　打包 …… 82

6.5　多环境部署 …… 84

6.6　部分部署 …… 86

6.6.1　金丝雀测试 …… 86

6.6.2　A/B测试 …… 87

6.7　回滚 …… 87

6.8　工具 …… 89

6.9　小结 …… 90

6.10　更多阅读材料 …… 90

第三部分　横切关注点

第7章　监控 …… 94

7.1　概述 …… 94

7.2　监控什么 …… 95

7.2.1　故障检测 …… 96

7.2.2　性能下降检测 …… 96

7.2.3　容量规划 …… 97

7.2.4　用户交互 …… 98

7.2.5　入侵检测 …… 99

7.3　如何监控 …… 99

7.3.1　基于代理的监控和无代理的监控 …… 101

7.3.2　监控运维活动 …… 102

7.3.3　收集和存储 …… 102

7.4　什么时候变更监控配置 …… 103

7.5　解释监控数据 …… 103

7.5.1　日志 …… 104

7.5.2　绘图和展示 …… 105

7.5.3　警报和警告 …… 105

7.5.4　诊断和反应 …… 106

7.5.5　监控DevOps过程 …… 106

7.6　挑战 …… 107

7.6.1　挑战1：持续变更下的监控 …… 107

7.6.2　挑战2：自下向上与自上向下和在云中的监控 …… 108

7.6.3　挑战3：监控微服务架构 …… 109

7.6.4　挑战4：处理大容量的分布式（日志）数据 …… 109

7.7　工具 …… 109

7.8　从监控数据中诊断出异常——Platformer.com的案例 …… 110

7.8.1　背景 …… 111

7.8.2　数据收集 …… 112

7.8.3　检测异常 …… 112

7.8.4　思考 …… 113

7.9　小结 …… 113

7.10　更多阅读材料 …… 114

第8章　安全与安全审计 …… 115

8.1　安全是什么 …… 115

8.2　威胁 …… 117

8.3　需要保护的资源 …… 118

8.4　安全角色和活动 …… 120

8.5　身份管理 …… 122

8.5.1　认证 …… 123

8.5.2　授权 …… 125

8.6　访问控制 …… 126

8.6.1　阻止访问 …… 127

8.6.2　谁负责预防控制 …… 129

8.7　检测、审计和拒绝服务 …… 129

8.8　开发 …… 130

8.9　审计者 …… 130

8.10　应用设计考虑 …… 131

8.11　部署流水线设计考虑 …… 132

8.12　小结 …… 133

8.13　更多阅读材料 …… 134

第9章　其他非功能需求 …… 135

9.1　概述 …… 135

9.2　可重复性 …… 136

9.2.1　在恰当的层级上定义和执行过程 …… 136

9.2.2　版本控制所有事物 …… 138

9.3　性能 …… 139

9.3.1　测量重要的事物 …… 139

9.3.2　提高资源使用率 …… 140

9.4　可靠性 …… 141

9.4.1　理解不同服务的可靠性特性 …… 141

9.4.2　早期检测和修复错误 …… 142

9.5　可恢复性 …… 142

9.6　互操作性 …… 143

9.6.1　注意接口的互操作性 …… 143

9.6.2　理解现有的数据模型 …… 143

9.7　可测试性 …… 144

9.8　可修改性 …… 145

9.8.1　一个工具内的修改 …… 145

9.8.2　工具之间交互行为的修改 …… 146

9.9　小结 …… 146

9.10　更多阅读材料 …… 147

第10章　业务关注点 …… 148

10.1　概述 …… 148

10.2　业务案例 …… 148

10.2.1　问题和解决问题所带来的好处 …… 149

10.2.2　成本 …… 149

10.2.3　干系人影响 …… 150

10.2.4　风险及其减缓 …… 151

10.2.5　推出计划 …… 153

10.2.6　成功标准 …… 154

10.3　度量和对DevOps实践的合规性 …… 155

10.3.1　测量DevOps实践的成功度 …… 155

10.3.2　测量对DevOps实践的合规性 …… 156

10.3.3　测量干系人的满意度 …… 157

10.4　Dev和Ops之间的交互点 …… 157

10.4.1　许可 …… 157

10.4.2　事故处理 …… 158

10.5　小结 …… 159

10.6　更多阅读材料 …… 159

第四部分　案 例 研 究

第11章　支持多数据中心 …… 162

11.1　概述 …… 162

11.2　当前的情况 …… 163

11.3　业务逻辑和Web层 …… 163

11.3.1　应用逻辑 …… 163

11.3.2　基础设施 …… 164

11.3.3　增加一个应用 …… 164

11.3.4　发现基础设施 …… 165

11.4　数据库层 …… 167

11.4.1　事务数据 …… 167

11.4.2　基础设施支持 …… 168

11.4.3　会话数据 …… 168

11.5　其他基础设施工具 …… 168

11.5.1　gem存储库服务器 …… 169

11.5.2　Elasticsearch …… 169

11.5.3　域名系统 …… 169

11.6　数据中心切换 …… 170

11.6.1　受控切换步骤 …… 170

11.6.2　非受控切换 …… 174

11.6.3　定义和自动化切换步骤 …… 175

11.7　测试 …… 177

11.7.1　数据中心切换应用程序 …… 177

11.7.2　基础设施测试 …… 177

11.7.3　持续交付流水线 …… 177

11.8　小结 …… 178

11.9　更多阅读材料 …… 179

第12章　实施企业的持续部署流水线 …… 180

12.1　概述 …… 180

12.2　组织背景 …… 180

12.3　持续部署流水线 …… 182

12.3.1　持续部署流水线工具 …… 183

12.3.2　使用AWS CloudFormation的环境定义 …… 184

12.3.3　标准化的应用程序生命周期概览及其使用 …… 186

12.3.4　标准化的应用程序生命周期阶段 …… 188

12.3.5　管理复杂的应用程序和流水线状态 …… 194

12.3.6　管理持久化 …… 196

12.4　让安全成为持续部署流水线的基础 …… 196

12.4.1　使用Amazon CloudFormation分离职责 …… 196

12.4.2　身份和访问管理 …… 197

12.5　高级概念 …… 198

12.5.1　最小化生产环境和非生产环境之间的偏移 …… 198

12.5.2　解决供应商的限制 …… 198

12.5.3　厂商锁定 …… 199

12.5.4　新的AWS内置服务的展望 …… 199

12.6　小结 …… 199

12.7　更多阅读材料 …… 200

第13章　迁移到微服务 …… 202

13.1　Atlassian概述 …… 202

13.2　构建部署微服务的平台 …… 203

13.3　BlobStore：一个微服务例子 …… 206

13.3.1　架构 …… 206

13.3.2　通过纯函数式架构和编程实现安全性和性能 …… 207

13.3.3　解决“非功能需求” …… 210

13.4　开发过程 …… 210

13.4.1　开发人员和支持 …… 211

13.4.2　构建和部署流水线 …… 212

13.4.3　客户应用的生产环境的零停机时间路径 …… 214

13.5　BlobStore演进 …… 215

13.6　小结 …… 219

13.7　更多阅读材料 …… 219

第五部分　走 向 未 来

第14章　作为过程的运维 …… 222

14.1　概述 …… 222

14.2　动机和概览 …… 223

14.3　离线活动 …… 224

14.4　在线活动 …… 227

14.4.1　错误检测 …… 227

14.4.2　错误恢复 …… 229

14.5　错误诊断 …… 229

14.6　监控 …… 231

14.7　小结 …… 231

14.8　更多阅读材料 …… 231

第15章　DevOps的未来 …… 232

15.1　概述 …… 232

15.2　组织问题 …… 233

15.2.1　DevOps活动中可能涉及的其他组 …… 233

15.2.2　所有关系和重组 …… 234

15.2.3　授权与控制 …… 234

15.3　过程问题 …… 235

15.3.1　厂商锁定和标准 …… 235

15.3.2　计费模型 …… 235

15.3.3　变更的速度 …… 236

15.4　技术问题 …… 237

15.4.1　持续部署流水线概念 …… 237

15.4.2　在持续部署流水线中获得质量 …… 239

15.4.3　实现 …… 239

15.5　错误报告和修复 …… 240

15.6　结束语 …… 240

15.7　更多阅读材料 …… 240

参考文献 …… 241