重磅推荐
【产品特色】

【商品详情】

【编辑推荐】

高德纳公司(Gartner)高级高管合伙人 李长华

中国中钢集团有限公司信息管理中心总经理 李红

中国卫通集团信息中心主任 李炜

EXIN国际信息科学考试学会亚太区总经理、DevOpsDays中国发起人 孙振鹏

中国农业银行数据中心总经理 涂晓军

雪松控股集团CIO、前壳牌中国CIO 徐斌

中信银行信息技术管理部总经理 王燕

联合推荐

技术的有效管理对于商业竞争力而言空前重要。数十年来,技术领导者一直在努力平衡敏捷性、可靠性和安全性。在此背景下,本书旨在提供从启动DevOps转型到实现目标所需的理论、原则和实践,帮助企业提高生产力、盈利能力并且赢得市场。本书不仅适用于从事或影响技术价值流中工作的所有人,通常包括产品管理、开发、QA、IT运维和信息安全,而且适用于业务和市场领导者。


【内容简介】
本书共分为6个部分:*部分概述DevOps的历史和三个基本原则,即“三步工作法”;第二部分介绍开启DevOps转型的过程;第三到五部分深入探讨“三步工作法”的各个要素;第六部分关注如何将安全性和合规性正确集成到日常工作中。全书涵盖40余个DevOps案例,以谷歌、亚马逊、Facebook等全球知名企业和组织的实际调查结果为依据,展示如何通过现代化的运维管理提升管理效率,进而为企业赢得更大市场、创造更多利润。
【作者简介】

Gene Kim 

Tripwire创始人、前CTO,IT Revolution创始人,DevOps企业峰会主办人,畅销书《凤凰项目》合著者。

Jez Humble 

DevOps Research and Assessment公司CTO,加州大学伯克利分校信息学院讲师;曾任ThoughtWorks首席顾问。《精益企业》和Jolt大奖图书《持续交付》的合著者。

Patrick Debois 

DevOps之父,致力于通过在开发、项目管理和系统管理之中应用敏捷技术来填补项目和运维之间的鸿沟。

John Willis 

Chain Bridge System创始人,曾任Docker公司布道师,现就职于SJ Technologies公司。

译者简介:

刘征

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

王磊

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

马博文

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

曾朝京

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


【媒体评论】

“以平台化、生态化、智能化和敏捷为主要特征的数字化时代已经到来,需要我们采用与之匹配的工作方法。DevOps作为与数字化相适应的方法之一,其作用不可或缺。IT人员要实现数字化转型,必须学会此方法,否则将难以胜任当前和未来的工作。”

——李长华,高德纳公司(Gartner)高级高管合伙人

“经历了多年信息化实践,我深感打造坚强IT运维体系和能力对支撑企业经营管理的重要性。接触和深度了解DevOps之后,我*的感受是,它有利于在改善传统‘稳态IT’运维体系的过程中寻获到提升价值的诀窍,也是构建云计算时代‘敏态IT’运维体系中不可或缺的柱石。”

——李红,中国中钢集团有限公司信息管理中心总经理

“对很多人而言,DevOps已经不是一个陌生的概念了,但是其思想精髓该如何融入传统企业的IT管理来助力企业提升商业竞争力呢?这仍然是CIO及其团队面临的挑战。本书结合48个著名公司的案例,介绍了高绩效公司是如何利用DevOps‘三步工作法’原则取得成功的,相信一定会使读者受益匪浅。”

——李炜,中国卫通集团信息中心主任

“在访谈了‘DevOps之父’Patrick Debois之后,我深刻地理解了‘DevOps is the Human Factor’这句话的真谛。DevOps是不断演进的,不是能够被固化定义下来的标准化流程体系。DevOps是一场关于工作方式的革命和企业文化的运动,同时也是企业数字化转型中高效团队所的能力。本书是继《凤凰项目》之后,Gene Kim携手全球三位DevOps界大咖的扛鼎之作,无愧‘全球DevOps畅销书’的美誉。”

——孙振鹏,EXIN国际信息科学考试学会亚太区总经理,DevOpsDays中国发起人

“过去的20年里,中国大型商业银行逐步构建了以研发、测试、运维团队为主体的IT组织架构,基于ITIL建立了信息系统建设和服务的流程。然而,金融科技浪潮的到来要求对产品进行迭代开发、敏捷测试、快速部署,必须同时满足业务连续性、服务稳定性与业务快速创新的要求。因此,IT体系向DevOps转型成为了一个备受关注的课题。本书既是国际DevOps Professional认证的核心教材,也为DevOps转型提供了从启动到实现所必需的理论、原则和实践案例。”

——涂晓军,中国农业银行数据中心总经理

“科技属性正在成为企业能否长期健康成长的核心要素,以个性化和*体验为核心的服务运营模式对业务快速创新迭代能力提出了极高的要求。DevOps为技术组织提供了卓越的能力,来实现科技创新和业务发展的高效融合、协同和共赢。”

——徐斌,雪松控股集团CIO,前壳牌中国CIO

“为保证交付质量,传统理论和做法是开发、测试、运维各自设定自己的目标和准入、准出规则,严控变更。IT人员很累,业务部门却不买账。DevOps开创了开发、运维一体化的理念、方法和流程。面对银行正在实施的数字化转型,本书的出版可谓恰逢其时。”

——王燕,中信银行信息技术管理部总经理

“这是一本切合实际、实用性强、具有指导意义的指南,能帮你完成《凤凰项目》中所有令人拍手叫绝的事情。”

——Tom Limoncelli,Stack Exchange问答平台SRE经理,曾任谷歌公司SRE/系统管理员

“对于想理解、解释和实现DevOps文化、流程和工具,来达成高性能运维的任何人而言,本书都是不二之选。”

——Quentin Fennessy,埃森哲公司DevOps架构经理

“我一直在找探讨如何在大型组织中实现DevOps的书,不得不说,本书‘一站式’地让我了解到了许多:不仅包括技术方面,而且包括业务方面。”

——Jumy Mathew,Sogeti公司首席顾问,欧盟委员会应用架构师

“本书对DevOps新手和老手来说都是很好的材料。作为《凤凰项目》小说的续作,它毫不逊色……强烈推荐。”

——Hamlet Khodaverdian,LMNTRIX公司美洲区副总裁


【目录】
第 一部分 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


【前言】

【免费在线读】

【书摘与插画】

返回顶部