Table of Contents**
Foreword 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
Part I. 基础
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
第二部分.练习
- On-Call.................................................................147
回顾第一本SRE书籍的"Being On-Call(随时待命)” 一章 148
Google内部和外部Google的On-Call设置示例 149
Google: 组建新团队149
Evernote：云中漫步153
实际实施的详细信息156值班负载的剖析156 On-Call的灵活性167
On-Call团队动态171
结论173
- 事件响应........................................................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基于情感的模型426Deming周期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