DevOps实践指南（第2版）

第 一部分 DevOps三要义

第 1章 敏捷、持续交付与DevOps三要义5

1.1 制造业价值流5

1.2 技术价值流5

1.2.1 聚焦部署前置时间6

1.2.2 关注返工指标——%C A8

1.3 DevOps三要义：DevOps的基础原则9

案例研究：向着巡航高度爬升：美国航空的DevOps之旅（第 一部分，2020年）11

1.4 小结14

第 2章 第 一要义：流动15

2.1 使工作可视化15

2.2 限制在制品数量16

2.3 缩减批量大小17

2.4 减少工作交接19

2.5 持续识别并改进约束20

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

案例研究：医疗行业中改善流动性和改进约束的实践（2021年）22

2.7 小结24

第3章 第二要义：反馈25

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

3.2 及时发现问题26

3.3 群策群力，攻克难题28

案例研究：Excella的安灯绳实验（2018年）30

3.4 从源头保障质量32

3.5 为下游工作中心优化33

3.6 小结33

第4章 第三要义：持续学习与探索34

4.1 建立学习型组织，打造安全文化35

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

4.3 将局部经验转化为全局改进38

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

4.5 领导层强化与巩固学习文化39

案例研究：贝尔实验室的故事（1925年）40

4.6 小结41

第 一部分总结42

第二部分 从哪里开始

第5章 选择合适的价值流切入45

5.1 绿地项目与棕地项目47

案例研究：Kessel Run：空中加油系统的棕地项目转型（2020年）49

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

5.3 从最具同理心和创新精神的团队开始51

案例研究：在整个企业中推广DevOps转型：美国航空的DevOps之旅（第二部分，2020年）52

5.4 在组织中推广DevOps转型52

案例研究：英国税务及海关总署如何通过超大规模PaaS拯救经济于水火（2020年）55

5.5 小结57

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

6.1 通过绘制价值流图改进工作58

6.2 确定价值流的参与团队59

6.3 通过绘制价值流图展现工作60

6.4 组建专职转型团队61

6.4.1 目标一致62

6.4.2 保持小跨度的改进计划63

6.4.3 为非功能性需求和偿还技术债务预留20%的时间63

案例研究：LinkedIn的“反转行动”（2011年）65

6.4.4 提高工作的可视化程度67

6.5 使用工具强化预期行为67

6.6 小结68

第7章 参照康威定律设计组织结构与系统架构69

7.1 组织原型71

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

7.3 组建市场型团队（“速度优化”）72

7.4 让职能型组织高效运转73

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

7.6 让团队成员都成为通才75

7.7 投资服务与产品，而非项目76

7.8 依照康威定律设定团队边界76

7.9 创建松耦合的架构，保证生产力和安全77

7.10 保持小规模团队（“两张比萨”原则）78

案例研究：Target公司的“API启用”项目（2015年）80

7.11 小结81

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

8.1 构建共享服务，提升开发人员生产力83

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

8.3 为服务团队指派运维联络人85

8.4 邀请运维工程师参加开发团队的例行活动86

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

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

8.4.3 使用共享的看板展示相关运维工作88

案例研究：全英房屋抵押贷款协会：拥抱更好的工作方式（2020年）88

8.5 小结91

第二部分总结91

第三部分 “第 一要义：流动”的具体实践

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

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

9.2 使用统一的代码仓库97

9.3 简化基础设施的重建99

案例研究：酒店公司如何通过容器技术实现年收入300亿美元（2020年）100

9.4 代码运行在类生产环境才算“开发完成”101

9.5 小结102

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

10.1 持续构建、测试和集成代码与环境106

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

10.3 在自动化测试阶段尽早发现问题109

10.3.1 确保测试快速运行110

10.3.2 测试驱动开发111

10.3.3 尽可能将手工测试自动化112

10.3.4 在测试套件中集成性能测试113

10.3.5 在测试套件中集成非功能性需求测试113

10.4 在部署流水线失败时拉下安灯绳114

10.5 小结116

第 11章 实现持续集成117

11.1 小批量开发vs大批量合并119

11.2 基于主干的开发实践120

案例研究：Bazaarvoice的持续集成实践（2012年）121

11.3 小结123

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

12.1 部署流程自动化126

案例研究：CSG的每日部署（2013年）127

12.1.1 实现自动化的自助部署129

12.1.2 将代码部署集成到部署流水线130

案例研究：Etsy持续部署案例：开发者自助部署（2014年）131

12.2 部署与发布解耦133

12.2.1 基于部署环境的发布模式134

案例研究：Dixons Retail：蓝绿部署在POS系统中的应用（2008年）136

12.2.2 基于应用程序的发布模式138

案例研究：Facebook Chat功能的灰度发布案例（2008年）140

12.3 持续交付和持续部署实践调研141

案例研究：CSG：实现开发与运维的双赢（2016年）142

12.4 小结146

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

13.1 提高研发效能、可测试性和安全性的架构148

13.2 架构原型：单体架构vs微服务149

案例研究：亚马逊的演进式架构（2002年）150

13.3 安全地演进企业架构151

案例研究：Blackboard Learn的绞杀者应用模式（2011年）152

13.4 小结155

第三部分总结155

第四部分 “第二要义：反馈”的具体实践

第 14章 使用监控发现和解决问题159

14.1 搭建集中式的监控基础设施161

14.2 为应用程序添加日志监控163

14.3 用监控指引问题的分析和解决165

14.4 把添加监控融入日常工作165

14.5 以自助方式访问监控数据166

案例研究：搭建自助的监控体系：LinkedIn的实践（2011年）167

14.6 对监控配置查漏补缺169

14.6.1 应用程序和业务的监控169

14.6.2 基础设施的监控171

14.6.3 显示其他相关信息172

14.7 小结172

第 15章 使用监控预防问题并实现业务目标173

15.1 用均值和标准差发现潜在问题174

15.2 监测到非预期结果时告警175

15.3 监控数据非高斯分布带来的问题176

案例研究：Netflix的自动扩容能力（2012年）177

15.4 使用异常检测技术179

案例研究：异常检测中的高级技术（2014年）180

15.5 小结182

第 16章 引入反馈机制实现安全部署183

16.1 利用监控确保部署上线更安全184

16.2 让开发和运维轮流值班186

16.3 让开发人员到价值流下游看一看186

16.4 先由开发人员自行运维188

案例研究：谷歌的移交就绪评审和发布就绪评审（2010年）190

16.5 小结192

第 17章 将假设驱动开发和A B测试纳入日常工作193

17.1 A B测试简史194

17.2 在新功能测试中整合A B测试195

17.3 在软件发布中整合A B测试196

17.4 在功能规划中整合A B测试196

案例研究：雅虎问答在快速迭代中实验，实现收入翻倍197

17.5 小结198

第 18章 通过评审和协调提升工作质量199

18.1 变更审批流程带来的问题200

18.2 过度变更控制带来的问题201

案例研究：从三位高管审批到自动审批——阿迪达斯的大规模发布实践（2020年）202

18.3 对变更进行协调和规划204

18.4 对变更进行同行评议204

案例研究：谷歌的代码评审（2010年）206

18.5 冻结变更并进行大量手工测试的隐患207

18.6 用结对编程提升各种类型变更的质量207

案例研究：Pivotal用结对编程代替阻滞的代码评审过程（2011年）208

18.7 分析拉取请求过程的有效性209

18.8 对官僚化流程进行大胆简化210

18.9 小结211

第四部分 总结212

第五部分 “第三要义：持续学习与探索”的具体实践

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

19.1 建立公正的学习文化216

19.2 故障发生后及时召开回顾会议217

19.3 尽可能广泛公开回顾会议纪要219

19.4 降低事故容差以发现更弱的故障信号220

19.5 重新定义失败并鼓励评估风险221

19.6 向生产环境注入故障，培养系统弹性和学习氛围222

19.7 设立故障演练日223

案例研究：CSG如何将故障转化为有效的学习机会（2021）224

19.8 小结226

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

20.1 将可复用的标准流程自动化228

20.2 创建组织级的单一共享源代码仓库229

20.3 用自动化测试记录、交流实践以传播知识231

20.4 通过规范非功能性需求来设计运维231

20.5 将可复用的运维用户故事融入开发过程232

20.6 确保技术选型有助于组织达成目标233

案例研究：Etsy的新技术栈标准化（2010年）234

案例研究：Target的众包技术治理（2018年）235

20.7 小结236

第 21章 预留时间开展组织学习和改进237

21.1 将偿还技术债务变为例行活动238

21.2 让所有人教学相长239

21.3 在DevOps会议中分享经验241

案例研究：美国全国保险、Capital One和Target的内部技术会议（2014年）242

21.4 创建社区结构来推广实践243

21.5 小结245

第五部分 总结245

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

第 22章 信息安全是每个人的日常工作249

22.1 将安全集成到开发迭代演示249

22.2 将安全问题纳入缺陷跟踪和事后分析250

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

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

22.5 保障应用程序安全253

案例研究：Twitter的静态安全测试（2009年）254

22.6 保障软件供应链安全256

22.7 保障环境安全261

案例研究：18F使用Compliance Masonry实现联邦政府合规性审查自动化（2016年）261

22.8 将信息安全集成到生产监控系统262

22.8.1 为应用程序创建安全监控263

22.8.2 为环境创建安全监控263

案例研究：Etsy的环境监测（2010年）264

22.9 保护部署流水线265

案例研究：在Fannie Mae开展安全左移（2020年）266

22.10 小结267

第 23章 保护部署流水线268

23.1 将安全和合规集成到变更审批流程268

23.2 将低风险的变更归类为标准变更269

23.3 当变更被归类为常规变更时如何处理270

案例研究：Salesforce将自动化基础设施变更归类为标准变更（2012年）270

23.4 通过代码评审实现职责分离271

案例研究：Etsy的PCI合规性以及一则职责分离的警示故事（2014年）272

案例研究：通过业务与技术合作，Capital One实现每天10次有信心的发布（2020年）274

23.5 确保为合规官和审计师提供文档和证据275

案例研究：证明监管环境下的合规性（2015年）275

案例研究：ATM系统离不开生产监控（2013年）277

23.6 小结278

第六部分 总结278

附录1：DevOps大融合286

附录2：约束理论和长期存在的根本矛盾288

附录3：恶性循环列表289

附录4：交接和队列的危害289

附录5：工业安全的误区291

附录6：丰田安灯绳291

附录7：COTS软件292

附录8：事后分析会议（回顾会议）292

附录9：猿猴军团293

附录10：上线时间透明化294