第一部分 基础
第1章 挑战与原则 3
1.1 为什么采用基础设施即代码 3
1.2 什么是基础设施即代码 4
1.3 动态基础设施的挑战 5
1.3.1 服务器蔓延 5
1.3.2 配置漂移 6
1.3.3 雪花服务器 6
1.3.4 脆弱的基础设施 7
1.3.5 自动化恐惧症 7
1.3.6 侵蚀 8
1.4 基础设施即代码的原则 8
1.4.1 系统能够轻松复制 8
1.4.2 系统是用完可扔的 9
1.4.3 系统是一致的 10
1.4.4 过程是可重复的 10
1.4.5 设计经常变更 10
1.5 实践 11
1.5.1 使用定义文件 11
1.5.2 自文档化的系统和流程 11
1.5.3 一切版本化 12
1.5.4 持续测试系统和流程 13
1.5.5 小的变更，而不是批量变更 13
1.5.6 让服务持续可用 13
1.6 反脆弱性：超越“稳健性” 14
1.7 结语 15
1.8 下一步 15
第2章 动态基础设施平台 16
2.1 什么是动态基础设施平台 16
2.2 对动态基础设施平台的要求 17
2.2.1 可编程 17
2.2.2 按需获取 19
2.2.3 自服务 19
2.3 平台提供的基础设施资源 19
2.3.1 计算资源 20
2.3.2 存储资源 20
2.3.3 网络资源 22
2.4 动态基础设施平台的类型 23
2.4.1 公有IaaS云 23
2.4.2 社区IaaS云 23
2.4.3 私有IaaS云 23
2.4.4 反模式：手摇云 24
2.4.5 混合云服务 24
2.4.6 裸机云 24
2.5 如何选择动态基础设施平台 25
2.5.1 公有还是私有 25
2.5.2 云的可移植性 27
2.6 与云和虚拟化的“机械通感” 29
2.7 结语 30
第3章 基础设施定义工具 31
3.1 选择基础设施即代码的工具 31
3.1.1 需求：脚本接口 32
3.1.2 需求：无人值守的命令行工具 32
3.1.3 需求：支持无人值守的执行 33
3.1.4 需求：外部化配置 34
3.2 配置定义文件 36
3.3 使用基础设施定义工具 37
3.3.1 用过程化脚本置备基础设施 38
3.3.2 声明式定义基础设施 40
3.3.3 使用基础设施定义工具 41
3.3.4 配置服务器 41
3.4 配置注册表 42
3.4.1 轻量级配置注册表 42
3.4.2 配置注册表是CMDB吗 43
3.4.3 CMDB的审计与修复反模式 44
3.4.4 CMDB的基础设施即代码方式 44
3.5 结语 44
第4章 服务器配置工具 45
4.1 自动化服务器管理的目标 45
4.2 具有不同的服务器管理功能的工具 46
4.2.1 创建服务器的工具 46
4.2.2 配置服务器的工具 47
4.2.3 打包服务器模板的工具 48
4.2.4 在服务器上运行命令的工具 49
4.2.5 从中央注册中心获取配置 50
4.3 服务器变更管理模型 51
4.3.1 临时变更管理 51
4.3.2 配置同步 51
4.3.3 不可变的基础设施 51
4.3.4 容器化服务 52
4.4 容器 52
4.4.1 以容器方式和非容器方式管理Ruby应用程序 53
4.4.2 容器是虚拟机吗 54
4.4.3 使用容器而不是虚拟机 55
4.4.4 运行容器 56
4.4.5 安全和容器 56
4.5 结语 58
第5 基础服务概述 59
5.1 基础设施服务和工具的考虑 59
5.1.1 支持外部配置的工具优先 60
5.1.2 假定基础设施是动态的工具优先 61
5.1.3 具有云兼容许可的产品优先 61
5.1.4 支持松耦合的产品优先 62
5.2 团队之间共享服务 62
5.3 监控：告警、指标和日志 63
5.3.1 告警：出现问题时告诉我 64
5.3.2 指标：收集和分析数据 65
5.3.3 日志聚合和分析 65
5.4 发现服务 66
5.4.1 服务器端的服务发现模式 67
5.4.2 客户端的服务发现模式 67
5.5 分布式进程管理 67
5.5.1 使用服务器角色编排进程 67
5.5.2 使用容器编排进程 67
5.5.3 调度短期任务 68
5.5.4 容器编排工具 68
5.6 软件部署 68
5.6.1 部署流水线软件 68
5.6.2 打包软件 69
5.7 结语 70
第二部分 模式
第6章 置备服务器的模式 73
6.1 服务器置备 74
6.1.1 服务器的生命周期 74
6.1.2 服务器都承载了什么 77
6.1.3 服务器上东西的类型 77
6.1.4 服务器角色 79
6.2 创建服务器的模式 80
6.2.1 反模式：手动制作服务器 80
6.2.2 实践：将服务器创建参数放在脚本中 81
6.2.3 反模式：热克隆服务器 82
6.2.4 模式：服务器模板 82
6.2.5 反模式：雪花工厂 82
6.3 引导新服务器的模式 83
6.3.1 推送引导 83
6.3.2 拉取引导 84
6.3.3 实践：对每个新服务器实例进行冒烟测试 84
6.4 结语 85
第7章 管理服务器模板的模式 86
7.1 供应模板：不能让别人来做吗 86
7.2 使用模板置备服务器 87
7.2.1 创建时置备服务器 87
7.2.2 在模板中置备 88
7.2.3 平衡模板和创建之间的置备工作 88
7.3 构建服务器模板的流程 89
7.4 原始镜像 90
7.4.1 反模式：热复制服务器模板 90
7.4.2 基于操作系统安装镜像烘焙模板 91
7.4.3 基于供应镜像烘焙模板 91
7.4.4 基于Unikernel构建模板 92
7.4.5 在不启动服务器的情况下自定义服务器模板 92
7.5 更新服务器模板 92
7.5.1 重新烘烤模板 93
7.5.2 烘焙新模板 93
7.5.3 版本控制服务器模板 93
7.6 构建基于角色的模板 95
7.6.1 模式：分层模板 95
7.6.2 共享模板的基础脚本 96
7.7 自动化服务器模板管理 96
7.7.1 在烘焙前自定义服务器 96
7.7.2 实践：自动测试服务器模板 97
7.8 结语 97
第8章 服务器更新与变更模式 98
8.1 服务器变更管理模型 99
8.1.1 临时性变更管理 99
8.1.2 持续配置同步 99
8.1.3 不可变服务器 99
8.1.4 容器化服务器 100
8.2 通用模式和实践 100
8.2.1 实践：最小化服务器模板 101
8.2.2 实践：当服务器模板变更时更换服务器 101
8.2.3 模式：凤凰服务器 101
8.3 持续部署的模式与实践 102
8.3.1 模式：无主服务器的配置管理 102
8.3.2 实践：应用Cron 103
8.3.3 持续同步流 104
8.3.4 未配置领域 104
8.4 不可变服务器的模式与实践 106
8.4.1 服务器镜像作为制品 106
8.4.2 使用不可变服务器简化确认管理工具 106
8.4.3 不可变服务器流程 107
8.4.4 使用不可变服务器引导配置 108
8.4.5 事务性服务器更新 109
8.5 管理配置定义的实践 109
8.5.1 实践：保持配置定义最小化 109
8.5.2 组织定义 110
8.5.3 实践：使用测试驱动开发来驱动良好的设计 110
8.6 结语 110
第9章 定义基础设施的模式 111
9.1 环境 112
9.1.1 反模式：手动制作的基础设施 112
9.1.2 定义基础设施栈即代码 112
9.1.3 反模式：每个环境单独的定义文件 114
9.1.4 模式：可重用的定义文件 114
9.1.5 实践：测试并推进栈定义 115
9.1.6 自服务的环境 116
9.2 组织基础设施 116
9.2.1 反模式：单体栈 116
9.2.2 迁移基础设施时避免“直接迁移” 118
9.2.3 将应用程序环境分到不同的栈中 118
9.2.4 管理栈之间的配置参数 119
9.2.5 共享基础设施元素 120
9.2.6 实践：应用程序代码和基础设施代码一起管理 122
9.2.7 共享定义的方法 123
9.2.8 实践：基础设施设计要与变更范围匹配 124
9.2.9 示例：微服务的基础设施设计 125
9.3 运行定义工具 128
9.4 结语 128
第三部分 实践
第10章 基础设施的软件工程实践 131
10.1 系统质量 132
10.1.1 低质量的系统很难变更 132
10.1.2 高质量的系统能更容易、更安全地变更 132
10.1.3 基于代码的基础设施质量 133
10.1.4 快速反馈 133
10.2 基础设施管理的版本控制系统 133
10.3 持续集成 134
10.3.1 持续测试分支不是持续集成 134
10.3.2 谁破坏了构建 136
10.3.3 忽略失败的测试 137
10.3.4 针对基础设施的持续集成 137
10.4 持续交付 137
10.4.1 集成阶段的问题 137
10.4.2 部署流水线和变更流水线 138
10.4.3 持续交付不是持续部署 139
10.5 代码质量 140
10.5.1 整洁代码 140
10.5.2 实践：管理技术债务 140
10.6 管理重大的基础设施变更 141
10.7 结语 142
第11章 测试基础设施变更 143
11.1 敏捷测试方法 144
11.1.1 自动化测试提供快速反馈 144
11.1.2 有机地构建一个测试套件 145
11.2 构建测试套件：测试金字塔 145
11.2.1 避免失衡的测试套件 146
11.2.2 实践：尽可能在最低层级进行测试 147
11.2.3 实践：仅实现需要的层级 148
11.2.4 实践：经常删减测试套件 148
11.2.5 实践：持续评审测试的有效性 148
11.3 实现均衡的测试套件 149
11.3.1 低层级测试 150
11.3.2 中间层级测试 151
11.3.3 高层级测试 154
11.3.4 测试运维质量 155
11.4 管理测试代码 156
11.4.1 实践：将测试代码与所测代码放在一起 156
11.4.2 反模式：反射测试 156
11.4.3 隔离组件进行测试的技巧 157
11.4.4 重构组件以便隔离 158
11.4.5 管理外部依赖 158
11.4.6 测试设置 159
11.5 测试的角色和工作流 161
11.5.1 原则：人们应该为所构建的东西编写测试 161
11.5.2 编写测试的习惯 162
11.5.3 原则：每个人都应该能够使用测试工具 162
11.5.4 质量分析师的价值 162
11.5.5 测试驱动开发 163
11.6 结语 164
第12章 基础设施的变更管理流水线 165
12.1 变更管理流水线的好处 166
12.2 设计流水线的准则 166
12.2.1 确保每个阶段的一致性 167
12.2.2 对于每个变更都立即得到反馈 167
12.2.3 在手动阶段之前运行自动阶段 168
12.2.4 尽早获得类生产环境 168
12.3 基本流水线设计 169
12.3.1 本地开发阶段 169
12.3.2 构建阶段 169
12.3.3 发布配置制品 170
12.3.4 自动化测试阶段 171
12.3.5 手动验证阶段 172
12.3.6 上线 173
12.3.7 流水线的节奏 173
12.4 使用流水线的实践 174
12.4.1 实践：证明每个变更都对生产准备就绪 174
12.4.2 实践：每个变更都始于流水线起点 175
12.4.3 实践：出现错误时停止流水线 175
12.5 扩展流水线到更复杂的系统 175
12.5.1 模式：扇入型流水线 176
12.5.2 实践：保持较短的流水线 179
12.5.3 实践：解耦流水线 179
12.5.4 集成模型 180
12.6 处理组件之间依赖的技巧 181
12.6.1 模式：库依赖 181
12.6.2 模式：自置备的服务实例 183
12.6.3 提供预发布的库构建 183
12.6.4 为消费者提供服务的测试实例 184
12.6.5 将服务的测试实例用作消费者185
12.7 管理组件间接口的实践 186
12.7.1 实践：保证接口的向后兼容性 186
12.7.2 实践：从发布解耦部署 186
12.7.3 实践：使用版本相容 187
12.7.4 实践：提供测试替身 187
12.7.5 实践：用契约测试来测试提供者 188
12.7.6 实践：用参考消费者来测试 188
12.7.7 实践：提供者接口的冒烟测试 188
12.7.8 实践：运行消费者驱动契约测试 188
12.8 结语 189
第13章 基础设施团队的工作流 190
13.1 任何可以自动化的都要自动化 190
13.1.1 手动变更 191
13.1.2 临时的自动化 191
13.1.3 自主的自动化 192
13.1.4 自主的自动化工作流 193
13.2 使用本地沙箱 194
13.2.1 使用本地虚拟化做沙箱 194
13.2.2 具有本地测试的工作流示例 196
13.2.3 使用虚拟化平台做沙箱 197
13.3 代码库组织模式 197
13.3.1 反模式：基于分支的代码库 198
13.3.2 模式：每个组件一个主干 199
13.3.3 模式：单一主干 199
13.4 工作流的效率 199
13.4.1 加快变更 199
13.4.2 代码评审 200
13.4.3 将治理融入工作流 200
13.5 结语 202
第14章 动态基础设施的连续性 203
14.1 服务连续性 204
14.1.1 真实可用性 204
14.1.2 用动态服务器池做恢复 205
14.1.3 为动态基础设施设计软件 206
14.1.4 为连续性划分系统 208
14.2 零停机变更 208
14.2.1 模式：蓝绿替换 209
14.2.2 模式：凤凰替换 209
14.2.3 实践：缩小替换的范围 210
14.2.4 模式：金丝雀替换 211
14.2.5 为零停机替换路由流量 212
14.2.6 有数据的零停机变更 213
14.3 数据连续性 214
14.3.1 冗余地复制数据 214
14.3.2 重新生成数据 215
14.3.3 委托数据持久化 215
14.3.4 备份到持久存储 215
14.4 灾难恢复 216
14.4.1 持续的灾难恢复 217
14.4.2 灾备计划：为灾难做计划 218
14.4.3 实践：优先重建而不是冷备份 218
14.4.4 通过流水线持续监控 219
14.5 安全 220
14.5.1 自动掩盖危害 220
14.5.2 以可靠的更新作为防护 221
14.5.3 包的来源 221
14.5.4 自动加固 222
14.5.5 流水线中安全验证的自动化 223
14.5.6 变更流水线的漏洞 223
14.5.7 管理云账号的安全风险 224
14.6 结语 225
第15章 基础设施即代码的组织要求 226
15.1 演进式架构 226
15.1.1 在实战中学习 228
15.1.2 从先驱者流水线开始 228
15.2 度量有效性 229
15.2.1 首先对期望的结果达成一致 229
15.2.2 选择有助于团队的度量指标 230
15.2.3 跟踪和改善周期时间 230
15.2.4 使用看板可视化工作 232
15.2.5 回顾会议及事后分析 233
15.3 组织授权用户 233
15.3.1 划分功能模型的陷阱 233
15.3.2 采取自服务模型 235
15.3.3 承担全部责任：谁构建，谁运行 235
15.3.4 组织跨职能团队 236
15.4 持续变更管理的治理 237
15.4.1 提供稳固的构建单元 237
15.4.2 在流水线中证明运维就绪 238
15.4.3 共享运维质量的所有权 238
15.4.4 审查和审计自动化流程 238
15.4.5 优化发现和修复问题的时间 239
15.5 结语：永无止境 239
关于作者 240
关于封面 240
· · · · · · (
收起)
涅瓦纳
O'Reilly Media, Inc.2015版
1 有用 LipingTaBaBa 2018-11-18 06:46:17
跟thoughtwork其他员工的书一样，提出很多新概念不错，但是作者总想拔高高度，三句话就宣言，五句话就定义，随时都要革命，好像自己写的不是工程总结而是《人权宣言》，而实际上能力撑不起这么高的高度，这种不匹配让读者忍不住厌恶。
0 有用 石头大云 2021-01-29 17:25:27
这本书描述的运维困境，在工作中亲身遇到很多。所以读书时会不住地笑，於我心有戚戚焉呀！ 但是，解决方案则有点... 理想化吧。而且技术细节提到得不多。同时，因为我的工作规模上，难以达到云的水平，因此帮助不是很大。我用一天就浏览完毕了，大概建立了"目录"级的认识，作为解决问题的思路。
0 有用 ansonhrj 2022-07-23 09:18:51
本书系统勾勒了iac的模型和工具。针对读者应该是有服务器构建经验，并使用过ansibile等基础设施管理工具的工程师。本书介绍了做iac应该怎么写基础设施的代码，写好后，怎么用软件开发的里面，对这些代码进行单元测试，自动化测试，流水线发布等。
0 有用 ansonhrj 2022-07-23 09:18:51
本书系统勾勒了iac的模型和工具。针对读者应该是有服务器构建经验，并使用过ansibile等基础设施管理工具的工程师。本书介绍了做iac应该怎么写基础设施的代码，写好后，怎么用软件开发的里面，对这些代码进行单元测试，自动化测试，流水线发布等。
0 有用 石头大云 2021-01-29 17:25:27
这本书描述的运维困境，在工作中亲身遇到很多。所以读书时会不住地笑，於我心有戚戚焉呀！ 但是，解决方案则有点... 理想化吧。而且技术细节提到得不多。同时，因为我的工作规模上，难以达到云的水平，因此帮助不是很大。我用一天就浏览完毕了，大概建立了"目录"级的认识，作为解决问题的思路。
1 有用 LipingTaBaBa 2018-11-18 06:46:17
跟thoughtwork其他员工的书一样，提出很多新概念不错，但是作者总想拔高高度，三句话就宣言，五句话就定义，随时都要革命，好像自己写的不是工程总结而是《人权宣言》，而实际上能力撑不起这么高的高度，这种不匹配让读者忍不住厌恶。