开发者2018最想发力技术领域之一，外挂指南DevOps实践第一书中文版上架！

Posted 2021-04-16 图灵教育

GitLab《2018 全球开发者报告》中提到，2018 年，开发者最希望投资的前三大技术领域是：

• 持续集成、部署和交付

• 自动化/容器

• DevOps

https://about.gitlab.com/developer-survey/2018/

看到这三大领域，老司机们大概会微微苦笑一下.....开发和运维之间的冲突和矛盾大概是大部分互联企业的切肤之痛。一旦趟过基础技术的河流，你就越来越意识到这三大技术领域的重要性。

不知道作为一位开发者，你是否关注过这三大领域？关于这三大领域，图灵都出版了经典图书（《持续交付》《容器与容器云》《凤凰项目》）。不过，需要注意的是，DevOps 畅销书《凤凰项目》是一本 IT 小说，超级受欢迎，但是一部分读者觉得小说的实践和指导意义相比技术实战类图书略有逊色，那么，同作者 Gene Kim 跟其他几位 DevOps 领域顶级大佬合著的真 · 实践书《DevOps实践指南》来了！

DevOps 领域第一书

不夸张，确实第一书。Amazon 原版 4.6 星评，延续了《凤凰项目》一书的超级好评和持续广受读者欢迎：

全部图书排名第 3341 位，什么概念？看起来一般嘛！但是，已经是技术类图书里面相当受欢迎的了， 信息管理亚类排名第 5 位：

新书一上架，即进入京东新书畅销榜 TOP 20：

好书抢先购入

扫一扫，京东购

DevOps实践指南

扫一扫，当当购

DevOps实践指南

 DevOps 领域顶级大佬

耗时 5 年倾力打造

 国内 DevOps 领域专业人士

精心打磨翻译

刘征  Nutanix 路坦力资深架构师，EXIN 首批国内 DevOps Master 和 DevOps Professional 认证讲师，持有红帽 RHCA 认证和 AWS 高级架构师认证，谙熟企业数据中心的 IT 服务管理。目前致力于推广 DevOps 相关的理念和实践，在 DevOps 社区中积极地参与培训和研讨会等活动，是 DevOpsDays 大会社区在中国的核心组织者和志愿工作者。

翻译与实践感言

这本书对开发和运维具有同样重要的意义，而且覆盖了传统的 QA 测试和信息安全工作；它是传统的敏捷开发、精益管理和 ITSM 管理等实践各自发展多年以后的首次 IT 管理实践大融合。本书和 DevOps 本身应该得到更广泛的应用和推广。

王磊  前 ThoughtWorks 咨询师，EXIN 首批国内 DevOps Master 认证讲师。拥有 10 多年软件行业经验，以及服务化架构、持续交付和 DevOps 转型等方面的丰富实践经验。国内较早倡导和实践微服务的先行者，著有国内首本微服务架构相关图书《微服务架构与实践》，是西安 DevOps Meetup 活动的联合发起人。

翻译与实践感言

本书从业务视角描述了 DevOps 的必要性，分析了为什么 DevOps 是基于精益、约束理论、丰田生产系统、学习型组织、康威定律等知识体系的集大成者。同时，它系统性地定义了 DevOps “三步工作法”：流动原则、反馈原则、持续学习与实验原则，并阐述了 DevOps 实施需遵守的原则与最佳实践。

马博文  前 ThoughtWorks 咨询师，AWS 认证助理架构师、开发者。拥有多年 Web开发和 DevOps 经验，熟悉持续交付、微服务。曾参与翻译《 Scala 编程实战》《DevOps 实践》等书，是西安 DevOps Meetup 活动的发起人。

翻译与实践感言

翻译本书，收获颇多。本书的作者 Patrick、Gene、Jez 和 John 确实贡献了一本集 DevOps 大成的著作。希望读者在阅读后也会有相同的感受，能够在团队中逐渐采用本书提供的工作法或者实践，改进交付速度、质量、软件可用性以及构建高可扩展的组织结构。

曾朝京  Micro Focus 资深解决方案顾问，曾参加 EXIN 首批国内 DevOps Master 讲师认证培训。长期从事 IT 运维管理领域咨询工作，曾为能源、金融、航空运输、政府行业中的多个大型企业提供 IT 运维管理规划。目前致力于探索 DevOps 理念在企业 IT 部门的实践。

翻译与实践感言

本书用大量真实的案例描述了 DevOps 实践产生的过程。他们所遇到的问题和困境，很多 IT 团队都曾经经历、正在经历，甚至在未来不可避免地即将经历。希望本书能在你感到困惑之时，对你有所启发、有所帮助。

切实有效将 DevOps 精髓

融入日常工作

联结产品经理、开发人员、QA人员、IT运维人员和信息安全

国内外 DevOps 实践者大力推荐

快速概览图书目录

掌握 DevOps 知识架构

目　　录

第一部分　DevOps介绍

第1章　敏捷、持续交付和三步法　　4

1.1　制造业价值流　　4

1.2　技术价值流　　4

1.2.1　聚焦于部署前置时间　　5

1.2.2　关注返工指标——%C/A　　7

1.3　三步工作法：DevOps的基础原则　　7

1.4　小结　　8

第2章　第一步：流动原则　　9

2.1　使工作可见　　9

2.2　限制在制品数　　10

2.3　减小批量大小　　11

2.4　减少交接次数　　13

2.5　持续识别和改善约束点　　14

2.6　消除价值流中的困境和浪费　　15

2.7　小结　　16

第3章　第二步：反馈原则　　17

3.1　在复杂系统中安全地工作　　17

3.2　及时发现问题　　18

3.3　群策群力，战胜问题获取新知　　19

3.4　在源头保障质量　　21

3.5　为下游工作中心而优化　　22

3.6　小结　　22

第4章　第三步：持续学习与实验原则　　23

4.1　建立学习型组织和安全文化　　23

4.2　将日常工作的改进制度化　　25

4.3　把局部发现转化为全局优化　　26

4.4　在日常工作中注入弹性模式　　27

4.5　领导层强化学习文化　　27

4.6　小结　　29

4.7　第一部分总结　　29

第二部分　从何处开始

第5章　选择合适的价值流作为切入点　　32

5.1　绿地项目与棕地项目　　34

5.2　兼顾记录型系统和交互型系统　　35

5.3　从最乐于创新的团队开始　　36

5.4　扩大DevOps的范围　　37

5.5　小结　　38

第6章　理解、可视化和运用价值流　　39

6.1　确定创造客户价值所需的团队　　40

6.2　针对团队工作绘制价值流图　　40

6.3　组建专门的转型团队　　42

6.3.1　拥有共同的目标　　43

6.3.2　保持小跨度的改进计划　　44

6.3.3　为非功能性需求预留20%的开发时间，减少技术债务　　44

6.3.4　提高工作的可视化程度　　47

6.4　用工具强化预期行为　　47

6.5　小结　　48

第7章　参考康威定律设计组织结构　　49

7.1　组织原型　　51

7.2　过度职能导向的危害（“成本优化”）　　51

7.3　组建以市场为导向的团队（“速度优化”）　　52

7.4　使职能导向有效　　53

7.5　将测试、运维和信息安全融入日常工作　　54

7.6　使团队成员都成为通才　　54

7.7　投资于服务和产品，而非项目　　56

7.8　根据康威定律设定团队边界　　56

7.9　创建松耦合架构，提高生产力和安全性　　57

7.10　小结　　60

第8章　将运维融入日常开发工作　　61

8.1　创建共享服务，提高开发生产力　　62

8.2　将运维工程师融入服务团队　　63

8.3　为每个服务团队分派运维联络人　　64

8.4　邀请运维工程师参加开发团队的会议　　65

8.4.1　邀请运维工程师参加每日站会　　65

8.4.2　邀请运维工程师参加回顾会议　　66

8.4.3　使用看板图展示运维工作　　66

8.5　小结　　67

8.6　第二部分总结　　67

第三部分　第一步：流动的技术实践

第9章　为部署流水线奠定基础　　70

9.1　按需搭建开发环境、测试环境和生产环境　　71

9.2　应用统一的代码仓库　　72

9.3　使基础设施的重建更容易　　74

9.4　运行在类生产环境里才算“完成”　　75

9.5　小结　　76

第10章　实现快速可靠的自动化测试　　77

10.1　对代码和环境做持续构建、测试和集成　　 79

10.2　构建快速可靠的自动化测试套件　　81

10.2.1　在自动化测试中尽早发现错误　　83

10.2.2　尽可能并行地快速执行测试　　84

10.2.3　先编写自动化测试　　84

10.2.4　尽量将手动测试自动化　　85

10.2.5　在测试套件中集成性能测试　　86

10.2.6　在测试套件中集成非功能性需求测试　　86

10.3　在部署流水线失败时拉下安灯绳　　87

10.4　小结　　89

第11章　应用和实践持续集成　　90

11.1　小批量开发与大批量合并　　92

11.2　应用基于主干的开发实践　　93

11.3　小结　　95

第12章　自动化和低风险发布　　96

12.1　自动化部署流程　　97

12.1.1　应用自动化的自助式部署　　100

12.1.2　在部署流水线中集成代码部署　　101

12.2　将部署与发布解耦　　104

12.2.1　基于环境的发布模式　　105

12.2.2　基于应用的发布模式更安全　　109

12.3　持续交付和持续部署实践的调查　　112

12.4　小结　　113

第13章　降低发布风险的架构　　114

13.1　能提高生产力、可测试性和安全性的架构　　115

13.2　架构原型：单体架构与微服务　　116

13.3　安全地演进企业架构　　118

13.4　小结　　121

13.5　第三部分总结　　121

第四部分　第二步：反馈的技术实践

第14章　建立能发现并解决问题的遥测系统　　125

14.1　建设集中式监控架构　　127

14.2　建立生产环境的应用程序日志遥测　　129

14.3　使用遥测指导问题的解决　　131

14.4　将建立生产遥测融入日常工作　　132

14.5　建立自助访问的遥测和信息辐射器　　133

14.6　发现和填补遥测的盲区　　135

14.6.1　应用程序和业务度量指标　　136

14.6.2　基础架构度量指标　　137

14.6.3　显示叠加的指标组合　　138

14.7　小结　　139

第15章　分析遥测数据以更好地预测故障和实现目标　　140

15.1　用均值和标准差识别潜在问题　　141

15.2　异常状态的处理和告警　　142

15.3　非高斯分布遥测数据的问题　　143

15.4　应用异常检测技术　　146

15.5　小结　　149

第16章　应用反馈实现安全部署　　150

16.1　通过遥测使部署更安全　　151

16.2　开发和运维共同承担值班工作　　153

16.3　让开发人员跟踪工作对下游的影响　　153

16.4　让开发人员自行管理生产服务　　155

16.5　小结　　159

第17章　将假设驱动的开发和A/B测试融入日常工作　　160

17.1　A/B测试简史　　161

17.2　在功能测试中集成A/B测试　　162

17.3　在发布中集成A/B测试　　162

17.4　在功能规划中集成A/B测试　　163

17.5　小结　　165

第18章　建立评审和协作流程以提升当前工作的质量　　166

18.1　变更审批流程的危险　　168

18.2　“过度控制变更”的潜在危险　　168

18.3　变更的协调和排程　　170

18.4　变更的同行评审　　170

18.5　人工测试和变更冻结的潜在危害　　173

18.6　利用结对编程改进代码变更　　173

18.7　消除官僚流程　　176

18.8　小结　　177

18.9　第四部分总结　　178

第五部分　第三步：持续学习与实验的技术实践

第19章　将学习融入日常工作　　180

19.1　建立公正和学习的文化　　181

19.2　举行不指责的事后分析会议　　182

19.3　尽可能广泛地公开事后分析会议结果　　184

19.4　降低事故容忍度，寻找更弱的故障信号　　185

19.5　重新定义失败，鼓励评估风险　　186

19.6　在生产环境注入故障来恢复和学习　　186

19.7　创建故障演练日　　187

19.8　小结　　189

第20章　将局部经验转化为全局改进　　190

20.1　使用聊天室和聊天机器人自动积累组织知识　　190

20.2　软件中便于重用的自动化、标准化流程　　192

20.3　创建全组织共享的单一源代码库　　192

20.4　运用自动化测试记录和交流实践来传播知识　　194

20.5　通过确定非功能性需求来设计运维　　194

20.6　把可重用的运维用户故事纳入开发　　195

20.7　确保技术选型有助于实现组织目标　　195

20.8　小结　　197

第21章　预留组织学习和改进的时间　　198

21.1　偿还技术债务的制度化惯例　　199

21.2　让所有人教学相长　　200

21.3　在DevOps会议中分享经验　　201

21.4　传播实践的内部顾问和教练　　203

21.5　小结　　204

21.6　第五部分总结　　204

第六部分　集成信息安全、变更管理和合规性的技术实践

第22章　将信息安全融入每个人的日常工作　　207

22.1　将安全集成到开发迭代的演示中　　207

22.2　将安全集成到缺陷跟踪和事后分析会议中　　208

22.3　将预防性安全控制集成到共享源代码库及共享服务中　　208

22.4　将安全集成到部署流水线中　　209

22.5　保证应用程序的安全性　　210

22.6　确保软件供应链的安全　　214

22.7　确保环境的安全　　215

22.8　将信息安全集成到生产环境遥测中　　216

22.9　在应用程序中建立安全遥测系统　　217

22.10　在环境中建立安全遥测系统　　217

22.11　保护部署流水线　　219

22.12　小结　　219

第23章　保护部署流水线　　220

23.1　将安全和合规性集成到变更批准流程中　　220

23.2　将大量低风险变更重新归类为标准变更　　221

23.3　如何处理常规变更　　222

23.4　减少对职责分离的依赖　　224

23.5　确保为审计人员和合规人员留存文档和证据　　226

23.6　小结　　228

23.7　第六部分总结　　228

行动起来——本书总结　　229

附加材料

附录　　232

附录1　DevOps的大融合　　232

附录2　约束理论和核心的长期冲突　　234

附录3　恶性循环列表　　235

附录4　交接和队列的危害　　235

附录5　工业安全神话　　236

附录6　丰田安灯绳　　237

附录7　软件包产品　　238

附录8　事后分析会议　　238

附录9　猿猴军团　　239

附录10　上线时间透明化　　 240

参考资源　　 241

致谢　　 243

EXIN DevOps Professional认证备考指南&模拟题　　245

上下滑动可查看完整的图书目录

最全 DevOps 思维导图

快速 Get 全书精华

史上最全 DevOps 思维导图下载

作者张乐（DevOps 资深实践者、前百度资深敏捷教练与架构师）

高清大图可通过关注文末二维码，回复 思维导图 获得

2018 DevOpsDays大会

图书首发，引发强烈反响

本书译者和编辑参与图书首发仪式

（从左到右依次为：本书策划编辑朱巍、译者刘征、王磊、马博文）

译者刘征与作者 Jez Humble

作者 Jez Humble 现场签售

DevOpsDays 

DevOpsDays 是一个遍布全球范围的系列会议品牌，内容上涵盖了软件开发到运维，主题通常包括自动化、测试、安全、持续交付、持续集成、组织文化等等。

“DevOps”这个名词的提出，最早可追溯到 2008 年的敏捷大会，会上 Andrew Clay Shafer 和 Patrick Debois 讨论了关于“敏捷基础设施”的问题，Patrick 也首次提出“DevOps”这个说法。

而“DevOps”作为术语流行起来，始于 2009 年比利时根特市的首届 DevOpsDays 活动。自此以后，DevOpsDays 以城市为单位，在全球范围内不断兴起，也带动了全球小伙伴对于 DevOps 实践和 DevOps 学习的热情。

截至 2018 年 1 月，全球范围内已经举办过 168 场 DevOpsDays 活动，遍布城市达到 78 个，部分成熟的国家和地区，一个城市的申办次数已经超过 5 次。迄今为止北京已经举办了两届，上海站将于  2018 年 8 月举行。

一键关注

了解 DevOpsDays 最新资讯

赠书活动

你是开发人员、运维人员、安全人员，还是产品经理、设计师？你是否经常觉得服务和产品不尽如人意？你们的交付周期是不是一拖再拖，夜间交付是家常便饭？是否惯常有一种无力感？快来吐槽你职业生涯中遇到的各种问题...

也可以说说你对 DevOps 的理解，以及你为什么需要这本书。精选评论挑选 5 位小伙伴，送出这本最有可能助力实现 IT 大一统世界，人人开心高效工作的《DevOps 实践指南》。不论你是技术管理者，还是一线技术人士，这本书对你来说都将举足轻重！

活动截止：5 月 17 日。

☟【阅读原文】京东购买《DevOps实践指南》