第一部分 DevOps三要义
第1章 敏捷、持续交付与DevOps三要义 5
1.1 制造业价值流 5
1.2 技术价值流 5
1.2.1 聚焦部署前置时间 6
1.2.2 关注返工指标——%C/A 8
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
· · · · · · (
收起)
wdpm
人民邮电出版社2018版
0 有用 alswl 2025-01-24 17:21:14 上海
我一开始有点轻视这本书，想着自己搞了这么久、工程和方法论应该都是耳熟能详。但细看之后感觉挺高屋建瓴的，写的很简练精要，有一些观念梳理比自己想要结构化很多。 有几个印象深刻和反直觉的点： 1. 价值流是帮助 DevOps 落地重要，要帮助上下游团队解决他们的问题 2. 多大的权利解决多大的问题，设定目标很关键 3. 20% 时间用来创建用户不可见的正面价值 4. 形成流，从 Source 到 P... 我一开始有点轻视这本书，想着自己搞了这么久、工程和方法论应该都是耳熟能详。但细看之后感觉挺高屋建瓴的，写的很简练精要，有一些观念梳理比自己想要结构化很多。 有几个印象深刻和反直觉的点： 1. 价值流是帮助 DevOps 落地重要，要帮助上下游团队解决他们的问题 2. 多大的权利解决多大的问题，设定目标很关键 3. 20% 时间用来创建用户不可见的正面价值 4. 形成流，从 Source 到 Product 的流 5. 指派运维联络人，不要多点联系 6. 建设反馈机制，前期研发 Owner 要自己运维，如果服务质量下降要做退还托管机制 (展开)
0 有用 图灵社区 2024-05-14 16:11:07 北京
技术圈的《孙子兵法》，DevOps领域经典重磅升级，第2版根据最新研究和最佳实践更新了内容，增加了大量新案例，方便大家在各行各业落地DevOps实践