目录
前言 I. .................................................................. Xvii
前言 II................................................................... xix
序言..................................................................... xxiii
1、SRE和DevOps的关系...................................................1
DevOps的背景 2
不再需要孤岛 2
事故是正常的 3
应该逐步进行更改 3
工具和文化是相互联系的 3
测量至关重要 4
SRE的背景 4
运维是软件问题 4
通过服务水平目标（SLO）进行管理 5
努力使工作量最小化 5
自动化今年的工作 6
降低失败成本来快速采取行动 6
与开发人员共享所有权 6
使用相同的工具，无论其功能或职务如何 7
比较和对比 7
组织背景和促进成功采用 9
狭窄，严格的激励措施使您的成功狭窄 9
最好自己动手；不要责怪其他人 10
将可靠性工作视为专门角色 10
何时可以代替是否 11
力求平等职业与财务 12
结论 12
第一部分： 基础
2、实施SLO。.......................................................17
SRE为什么需要SLO 17
入门 18
可靠性目标和错误预算 19
测量内容： 使用SLI 20
工作示例 23
从SLI规范过渡到SLI实施 25
测量SLI 26
使用SLI计算启动器SLO 28
选择适当的时间窗口 29
获得利益相关者协议 30
建立错误预算政策 31
记录SLO和错误预算政策 32
仪表板和报告 33
持续改进SLO目标 34
提高SLO的质量 35
使用SLO和错误预算进行决策 37
高级主题 38
用户旅程建模 39
交互作用的重要性排序 39
依赖关系建模 40
用宽松的SLO做实验 41
结论 42
3、SLO工程案例研究...............................................43
Evernote的SLO故事 43
为什么Evernote采用SRE模型？44
SLO的介绍：进行中的旅程 45
打破客户与云提供商之间的SLO墙 48
当前状态 49
家得宝的SLO故事 49
SLO文化项目 50
我们的第一批SLO 52
向SLO宣传 54
自动化VALET数据收集 55
SLO的扩散 57
将VALET应用于批处理应用程序 57
使用VALET进行测试58未来的愿望 58
摘要 59
结论 60
4、监控...............................................................61
监控策略的理想功能 62
速度 62
计算 62
接口 63
警报 64
监测数据来源 64
例子 65
管理监控系统 67
配置即为代码 67
鼓励一致性 68
首选松耦合 68
有目的的度量标准 69
预期的变化 70
依赖 70
饱和度 71
服务流量的状态 72
实施有目的的度量标准 72
测试警报逻辑 72
结论 73
5、基于SLO发出警报..........................................................75
警报注意事项 75
重大事件警报的方式 76
1：目标错误率≥SLO阈值 76
2：警报窗口增加 78
3：递增警报持续时间 79
4：资金消耗率警报 80
5：多个资金消耗率警报 82
6：多窗口，多资金消耗率警报 84
低流量服务和错误预算警报 86
生成人工流量 87
合并服务 87
进行服务和基础架构更改 87
降低SLO或增加窗口 88
极限可用性目标 89
大规模预警 89
结论 91
6、消除人工运维工作...........................................................93
什么是苦力劳动？94
度量苦力劳动 96
苦力劳动分类法 98
业务流程 98
生产中断 99
发布发布 99
迁移 99
成本工程和容量规划 100
不透明架构的故障排除 100
苦力工作管理策略 101
识别和衡量苦力工作 101
系统之外的苦力工程师 101
拒绝苦力工作 101
使用SLO减少苦力工作 102
从人为支持的界面入手 102
提供自助服务方法 102
获得管理层和同事的支持 103
促进减少苦力工作作为一项功能 103
从小处着手然后改进 103
提高一致性 103
评估自动化范围内的风险 104
自动化苦力工作 104
使用开源和第三方工具 105
使用反馈来改进 105
个案例研究 106
案例研究1： 使用自动化减少数据中心的苦力劳动工作量 107
背景 107
问题陈述 110
我们决定要做的事情 110
设计第一步： 土星线卡维修 110
实施 111
设计第二步： 土星线卡维修与木星线卡维修 113
实施 114
经验教训 118
案例研究2： 退役由Filer支持的家庭目录 121
背景 121
问题陈述 121
我们决定做什么 122
设计和实现 123
关键组件 124
经验教训 127
结论 129
7、简单化...............................................................131
测量复杂度131
SRE们擅长端到端的简化 133
案例研究1： 端到端API简化 134
案例研究2：项目生命周期的复杂性 134
简化 135
案例研究3： 简化展示广告Spiderweb 137
案例研究4：在共享平台上运行数百个微服务 139
案例研究5： pDNS不再依赖于自身 140
结论 141
第二部分：练习
8、值班.................................................................147
回顾第一本SRE书籍的"Being On-Call(随时待命)” 一章 148
Google内部和外部Google的On-Call设置示例 149
Google： 组建新团队 149
Evernote：云中漫步 153
实际实施的详细信息156值班负载的剖析156 On-Call的灵活性 167
On-Call团队动态 171
结论 173
9、事件响应........................................................175
Google的事件管理 176 事件管理系统 176
事件响应中的主要角色 177
案例研究 177
案例研究1： 软件Bug ---灯亮但没人（Google）首页 177
案例研究2： 服务故障-如果可以，请缓存 180
案例研究3： 停电---雷电不会击中两次？直到它做到为止 185
案例研究4： PagerDuty的事件响应188将最佳实践付诸实践 191
事件响应培训 191
事前准备 192
操练 193
结论 194
10、事后文化： 从失败中学习..................................195
案例研究 196
不合适的事后分析 197
为什么此事后分析不好？199
好的事后分析 203
为什么这个事后分析更好？212
组织激励措施 214
建立典型并对事不对人 214
奖励事后分析 215
公开分享事后分析 217
响应事后分析文化的失败 218
工具和模板220事后分析模板 220
事后分析工具 221
结论 223
11、管理负载..........................................................225
Google云负载均衡225
Anycast 226
Maglev 227
全局软件负载均衡器 229
Google前端 229
GCLB：低延迟 230
GCLB：高可用性 231
案例研究1： Pokémon GO运行于GCLB 231
自动缩放 236
处理不正常的机器 236
运行有状态的系统 237
保守配置 237
设置约束 237
终止开关和手动替代都要包括 238
避免后端过载 238
避免流量不平衡 239
组合策略来管理负载 239
案例研究2： 当甩负荷攻击的时候 240
结论 243
12、介绍非抽象大型系统设计...............................245
什么是NALSD？245 为什么是“非抽象”？ 246
AdWords示例 246
设计流程 246
初始要求 247
一台机器 248
分布式系统 251
结论 260
13、数据处理管道.................................................263
管道应用 264
事件处理/数据转换为订单或结构数据 264
数据分析 265
机器学习 265
管道最佳实践 268
定义和衡量服务水平目标 268
依赖关系失败的计划 270
创建和维护管道文档 271
映射开发生命周期 272
降低热点和工作量模式 275
实施自动扩展和资源规划 276
遵守访问控制和安全策略 277
规划升级路径 277
管道要求和设计 277
您需要什么功能？ 278
幂等性和两相突变 279
检查点279代码模式 280
管道生产准备就绪 281
管道故障： 预防和响应 284
潜在故障模式 284
潜在原因 286
案例研究：Spotify 287
事件交付 288
事件交付系统设计和体系结构 289
事件交付系统操作 290
客户集成和支持 293
总结 298
结论 299
14、配置设计和最佳实践.....................................301
什么是配置？301
配置和可靠性 302
哲学与力学分离 303
配置理念 303
配置向用户提问 305
问题应接近于用户目标 305
必选问题和可选问题 306
逃离简单性 308
配置原理 308
单独的配置和结果数据 308
工具的重要性 310
所有权和变更跟踪 312
安全配置更改应用程序 312
结论 313
15、配置细节....................................................315
感应配置的苦力工作 315
减少感应配置的苦力工作 316
配置系统的关键属性和陷阱 317
陷阱1： 无法将配置识别为编程语言的问题317
陷阱2： 设计偶发或临时语言功能 318
陷阱3： 建立太多特定于领域的优化 318
陷阱4： 将“配置评估”与“副作用”交织在一起 319
陷阱5： 使用现有的通用脚本语言，例如 Python，Ruby或Lua 319
集成一个配置语言320以特定格式生成配置 320
推动多个应用程序 321
集成现有应用程序： Kubernetes 322
Kubernetes提供什么 322
示例Kubernetes配置 322
集成配置语言 323
集成自定义应用程序（内部软件）326
有效地运行配置系统 329
版本 329
源代码控制 330
工具 330
测试 330
何时评估配置 331
早期： 检入JSON 331
中途： 评估建立时间 332
末期： 在运行时评估 332
防止滥用配置 333
结论 334
16、金丝雀发布.......................................................335
释放工程原理 336
平衡释放速度和可靠性 337
什么是金丝雀? 338
发布工程和金丝雀 338
金丝雀过程的要求 339
我们的示例设置 339
前滚部署与简单的金丝雀部署 340
金丝雀实施 342
最大限度地降低SLO和错误预算的风险 343
选择金丝雀发布数量和持续时间 343
选择和评估指标 345
指标应指出问题 345
指标应具有代表性并应归因 346
评估前后有风险 347
使用渐进式金丝雀能更好地选择度量 347
依赖关系和隔离 348
非交互式系统中的金丝雀发布 348
监控数据要求 349
相关概念 350
蓝绿部署 350
人工负载生成 350
流量准备 351
结论 351
第三部分：流程
17、识别过载并从中恢复...................................355
从负载到过载 356
案例研究1： 一半团队离开时工作超负荷 358
背景 358
问题陈述 358
我们决定做什么 359
实施 359
经验教训 360
案例研究2： 在组织和工作量之后感知超载更改 360
背景 360
问题陈述 361
我们决定做什么 362
实施 363
效果 365
经验教训 365
缓解过载策略 366
识别过载的症状 366
减少超载并恢复团队健康 367
结论 369
18、SRE参与模型...................................................371
服务生命周期 372
阶段1：架构与设计 372
阶段2：积极发展 373
阶段3：限量供应 373
阶段4：一般可用性 374
第5阶段：弃用 374
第6阶段：被遗弃的 374
阶段7： 不支持的 374
建立关系 375
沟通业务和生产优先级 375
识别风险 375
调整目标 375
制定基本规则 379
规划和执行 379
保持有效的持续关系 380
花时间进行更好的合作 380
保持沟通畅通 380
进行定期服务审核 381
当基本规则开始降低时重新评估 381
根据SLO和错误预算调整优先级 381
正确处理错误 382
将SRE扩展到更大的环境 382
通过一个SRE团队支持多种服务 382
构建一个多个SRE团队环境 383
使SRE团队结构适应不断变化的环境 384
开展有凝聚力的分布式SRE团队 384
结束关系 385
案例研究1： Ares 385
案例研究2：数据分析管道 387
结论 389
19、SRE：超越自己...........................................391
不言而喻的真理 391
可靠性是最重要的功能 391
用户而不是您的监控决定您的可靠性 392
如果您经营一个平台，那么可靠性就是合伙人 392
一切重要的最终会成为平台 393
当您的客户遇到困难，您必须慢下来 393
您将需要与客户一起练习SRE 393
如何练习： 与您的客户进行SRE 394
步骤1： SLO和SLI就是练习的方法 394
步骤2： 监控审计和构建共享仪表板 395
步骤3： 测量并重新协商 396
步骤4： 设计审查和风险分析 396
步骤5： 练习练习再练习 397
有思想有纪律 397
结论 398
20、SRE团队生命周期......................................................399
没有SRE的SRE实践 399
担任SRE角色 400
找到您的第一个SRE 400
放置您的第一个SRE 401
引导您的第一个SRE 402
分布式SRE 403
您的第一个SRE团队 403
组队 404
猛攻 405
规范 408
请开始你的表演 411
增加更多的SRE团队 413
服务复杂性 413
SRE推广 414
地理位置上的割裂 414
管理多个团队的建议做法 418
任务控制 418
SRE交流 419
培训 419
水平项目 419
SRE机动性 419
旅行 420
启动协调工程团队 420
生产精益求精 421
SRE资金和招聘 421
结论 421
21、SRE中的组织变更管理..................................423
SRE 拥抱变更423
变更管理简介 424
Lewin的三阶段模型 424
麦肯锡的7-S模型 424
Kotter引领变革的八步流程 425
Prosci ADKAR模型 425
基于情感的模型 426
Deming周期 426
这些理论如何适用于SRE 427
案例研究1： 缩放Waze-从临时到计划的更改 427
背景 427
消息队列： 在维持可靠性的同时更换系统 427
下一个变更周期：改善部署过程 429
经验教训 431
案例研究2： SRE中的通用工具采用 432
背景432
问题陈述 433
我们决定做什么 434
设计 434
实现： 监控 436
经验教训 436
结论439
结论...................................................................441
A、SLO文档示例...................................................445
B、示例错误预算政策..............................................449
C、事后分析的结果.................................................453
索引.....................................................................455