目录

Why：为什么

What：是什么

How：怎么做

Google SRE

要回答的问题： SRE的原则有哪些？

1. 以SLA为基础开发；
2. 监控：警报、工单、日志；
3. 应急响应：MTTF(平均故障时间间隔), MTTR（平均恢复时间）；（避免人工介入、提前写好文档）
4. 变更管理：灰度、迅速准确的问题检测、安全回滚。
5. 需求预测容量规划：预测合理、定期测试；

从 SRE 的视角看 Google 的生产环境

要回答的问题： Google生产环境是什么样的？

1. 硬件：Service→Rack→Row→Cluster→AZ→Region；
2. GSLB：DNS→L4LB→L7LB;
3. 架构：DNS→LB→Proxy→（rpc）Service→DB；

供参考。

影响SRE操作一般领域的模式、行为和关注领域

要回答的问题： SRE原则有哪些？

1. 风险与目标：风险评估 → SLO → 错误预算
2. 运行与反馈：监控 → 发现偏差 → 干预和改进
3. 持续演进：消除 toil、自动化、发布工程
4. 贯穿原则：保持简单

摘录：

安全地提高产品迭代速度是任何组织的核心原则

拥抱风险

要回答的问题： 为什么需要管理风险？（Why）理想状态什么样？（What）怎么管理，怎么评价？（How）

1. Why： 为什么需要风险管理？故障伤害用户，但过度追求可靠性也会增加成本、拖慢迭代；开发与 SRE 的目标还可能冲突。

2. What： 希望达到什么状态？根据用户和业务需求，评估成本等，确定“足够可靠”的程度，用 SLO 明确表达。

3. How： 怎么做？为了达到SLO，应该怎么做（合理安排：测试、可用性、发布频率等非功能性开发）。

摘录：

管理服务可靠性，在很大程度上就是管理风险，而管理风险可能代价高昂

服务水平目标

要回答的问题： SLI/SLO/SLA都是什么（指标、目标、协议）？

1. Why： 为什么需要明确服务水平？SLA的目的是正确管理服务，了解哪些服务重要；

2. What： 怎么制定SLA？SLA源于SLO，SLO源于SLI，SLI是一些指标（实际的：请求延迟、错误率、系统吞吐量、可用性），SLO是基于SLI的相应目标（目标达到的：每个指标应该达到多少），SLA（承诺的：如果达不到对应的惩罚条款）

3. How： SLI(制定、采集、聚合、标准化）SLO（明确目标、选择SLI、采取行动达到SLO（不要过高、保持余量））SLA（高于SLO，需要法务一起制定）

摘录：

如果不了解哪些行为对服务真正重要，以及如何衡量和评估这些行为，就无法正确管理服务，更遑论有效管理。

避免手动运维

要回答的问题： 避免苦差事？

1. Why： 服务规模增长时，重复运维工作容易同步增长，最终挤占工程改进时间。

2. What： Toil 通常具有这些特征：需要人工操作、反复发生、可以自动化、被事件打断后被动处理、不产生持久改进、随服务规模线性增长。

3. How： 多做一些系统工程、软件工程的任务；重复性的操作是否可以通过工程改进。

摘录：

如果在正常运行期间需要人工干预系统，那么你的系统就存在漏洞。随着系统规模的扩大，“正常”的定义也会随之改变。

分布式系统的监控

要回答的问题： 分布式系统都有哪些监控？怎么监控？

1. Why： 为什么需要监控？分析趋势、告警、对比新功能、临时回顾性分析、构建仪表盘。

2. What： 监控都有哪些，四个黄金信号是什么？监控、白盒监控、黑盒监控、仪表盘、报警、根本原因、配置修改；四个黄金信号：延迟（请求耗时、p99）、负载（qps、bps、cps）、错误率（err）、使用率（cpu/memory usage）；

3. How： 怎么设置监控？关注尾延迟、合适的测量分辨率（1分钟，5分钟平均）、尽可能简单；

摘录：

从长远来看，要成功实现值班轮换和产品，需要选择对症状或即将出现的实际问题发出警报

自动化的价值

要回答的问题： 为什么需要自动化？

1. Why： 为什么需要自动化？一致性、平台化、更快的维修、快速行动、节省时间；

2. What： 自动化是什么？作用于其他软件的软件。

3. How： 怎么自动化？一步一步发展，以最小化人力为目标。

摘录：

除了黑魔法，就只有自动化和机械化了。

发布工程

要回答的问题： 为什么需要发布工程？

1. Why： 为什么需要发布工程？发布工程的目的是为了让软件从研发到上线过程有完整的一致性规范控制；

2. What： 发布工程是什么？发布工程师与产品开发团队的软件工程师（SWE）、SRE 一起，定义发布软件所需的全部步骤：从软件如何存放在源代码仓库中，到编译所使用的构建规则，再到如何进行测试、打包和部署。

3. How： 发布工程怎么做？自助服务、高发布速度、密闭构建、强制执行策略和流程。持续构建和部署：构建、分支管理、测试、打包、部署、配置管理。

摘录：

构建并交付软件

简洁性

要回答的问题： 为什么需要简洁性？

1. Why： 为什么需要简洁性？软件简洁性是可靠性的先决条件，使系统更可预测；

2. What： 什么是简洁性？满足业务需求前提下，代码简洁、模块简洁等。

3. How： 怎么保护简洁性？负代码行数指标、极简API、模块化、发布简洁性；

摘录：

可靠性的代价是追求极致的简洁。

基于时间序列数据的实用预警

要回答的问题： 监控：数据怎么被采集的？怎么存放？怎么触发告警？

1. Why： 为什么需要监控告警系统？把大量实例的运行情况转化为可查询、可比较、可采取行动的信息，帮助我们发现服务问题、定位原因，并控制监控本身的维护成本。

2. What： 它处理的是什么数据？数值的含义（gauge、counter）、数值的归属（指标名+标签集合）、数值的历史（时间戳+数值）

3. How： 数据怎样发掘所需信息？埋点产生指标→暴露指标并采集→TSDB存储→查询与计算→告警规则→人员行动

监控核心就是如何产生行动依据：运行状态（抽象）→数值→行动

摘录：

监控是生产需求层次结构的最底层，对于稳定运行服务至关重要

On-Call

要回答的问题： 为什么需要on-call，怎么on-call？

1. Why： 为什么需要值班？当生产问题需要人工判断和处理时，确保有人及时响应，同时避免持续救火耗尽团队的工程能力。

2. What： 值班是什么？在约定的轮值期间，承担生产问题的第一响应职责：接收告警、判断影响、推动恢复，并在需要时寻求支援或升级处理。

3. How： 怎么让值班有效且可持续？均衡轮班值守，质量平衡、数量平衡、持续改进、补偿；避免不当的运行负荷（过载和不足）

摘录：

为了确保服务的可靠性和可用性，值班是许多运维和工程团队必须承担的一项关键职责。

应急响应

要回答的问题： 在发生紧急事件时要做什么？

1. Why： 为什么需要应急响应？故障无法完全避免，紧急情况下还可能出现工具失效、信息不足和人员紧张。需要提前准备，降低故障造成的影响，尽快恢复服务。

2. What： 应急响应是什么？一套应对突发故障的能力，包括事前准备、故障中的止损与恢复，以及事后的改进。

3. How： 怎样做好应急响应？事前准备、事中处置。事后改进

摘录：

东西会坏，这就是生活。

事件管理

要回答的问题： 良好的事件管理是什么样的？

1. Why： 为什么需要事件管理？多人、多团队参与故障处理时，容易出现重复排查、操作冲突、信息断层，以及技术负责人被沟通事务拖住的问题。

2. What： 事件管理是什么？一套故障处理期间的组织协作机制，明确：谁指挥、谁操作、谁沟通、谁保障后续工作，以及如何共享信息。

3. How： 怎样管理事件？及时启动响应：及早宣布事件，建立统一的沟通渠道。明确职责、协调操作、共享状态、持续调整与明确交接。

摘录：

通过提前制定事件管理策略，并确保该策略能够平滑扩展，以及定期执行该策略，我们能够缩短平均恢复时间，并为员工提供一种压力更小的应对突发问题的方式。

事后文化：从失败中学习

要回答的问题： 发生事故之后都需要做什么来减少事故的发生？

1. Why： 为什么需要复盘？服务恢复后，如果没有系统地学习和改进，同类故障就可能反复发生。

2. What： 复盘是什么？一份可以审阅和共享的书面记录，说明：发生了什么、造成什么影响、如何处理、有哪些促成原因，以及后续怎样改进。开会是协作手段之一。

3. How： 怎样做好复盘？提前确定复盘条件 → 还原事实 → 无责分析原因 → 制定改进措施 → 审阅与分享 → 落实改进。

摘录：

撰写事后分析报告的主要目标是确保事件得到记录，所有根本原因都得到充分理解，尤其重要的是，要采取有效的预防措施，以降低事件再次发生的可能性和/或影响。

故障跟踪

要回答的问题： 日常出现的任何预期之外的问题，怎么记录、跟踪？

Google的故障跟踪系统：

• 归并：一次网络故障可能触发几十条服务告警，要把它们关联到同一个事件，分别统计“告警数”和“事件数”。
• 记录与分类：保存时间、影响、处理过程，补充 cause:network、action:rollback、误报等标签与注释。
• 横向和长期分析：哪个服务最消耗值班精力？哪些问题反复发生？多个团队是否受到同一个基础设施问题影响？改进后是否真的减少了故障？

摘录：

只有从一个已知的基线出发，并且能够跟踪进展，才有可能持续提高可靠性。

可靠性测试

要回答的问题： 都有哪些测试，都测试什么？

1. Why： 为什么需要测试？通过测试减少变更带来的不确定性，尽早发现问题。

2. What： 测试哪些方面？都有什么测试？

   • 单元测试（单个函数有没有问题）
   • 集成测试（发现整个系统问题）
   • 系统测试
     • 冒烟测试（基本功能，通常自己开发的时候自测）
     • 性能测试（能承受多大压力）
     • 回归测试（是否影响旧的功能）
   • 模糊测试（用不同的输入打入流量）
   • 随机故障测试（依赖组件问题、网络问题）
   • 灾难恢复工具测试（出现故障之后能不能重新启动并恢复）
   • 稳定性测试（持续运行一段时间后，还能保持正常吗）
   • 兼容性测试（不同版本能不能同时工作）
   • 生产环境
     • 黑盒测试，模拟外部调用方进行探测
     • 金丝雀发布，逐步灰度，减小影响域

3. How： 怎样把测试落实到工程流程中？设计优先级、判定用例、自动化执行、验证真实部署；（先标准化流程再做相关的详细设计）

摘录：

SRE 通过将传统的软件测试技术应用于大规模系统来完成这项任务。可靠性可以通过过去的可靠性和未来的可靠性来衡量。

SRE中的软件工程

要回答的问题： SRE相较于研发有什么优势？为什么需要软件工程？

1. Why： 为什么 SRE 需要开展软件工程？通过软件和自动化减少重复劳动、提高可靠性，使服务规模增长时，所需人力不必同比增长。SRE 熟悉生产问题，能够开发贴合实际需求的工具；

2. What： 什么是 SRE 内部的软件工程？将生产运行中的问题，开发成具有明确用户需求、设计、测试、发布和持续维护机制的内部软件产品。

3. How： 怎样开展？选对问题，明确需求→先做可用版本，再持续迭代→把推广和用户支持当作开发的一部分→按正式软件产品的标准保证质量→提供组织保障，并保持生产联系

摘录：

SRE 对生产环境的复杂性有直接经验，因此特别适合开发恰当的工具，
这些工具大多与保持服务可用、降低延迟这一总体目标有关，但形式多种多样。例如，程序发布机制、监控系统，或者基于服务器动态组合构建的开发环境。

前端负载均衡

要回答的问题： 如何在不同数据中心之间分配用户流量？

1. Why： 为什么需要前端负载均衡？单机存在容量限制和单点风险，单个数据中心也无法兼顾全球用户的访问体验。需要分散流量，在可用性、延迟、吞吐和资源利用率之间取得平衡。

2. What： 什么是前端负载均衡？在服务入口，根据用户位置、业务需求、容量和健康状态，将外部流量分配到合适的数据中心及服务实例。

3. How： 怎么进行前端负载均衡？

   • 选择哪个入口／数据中心？ DNS 返回合适的 A/AAAA 地址；（用户位置、网络延迟、容量、健康状态，以及递归解析器和缓存的限制）
   • 选择 VIP 背后的哪台实例？ 根据负载或哈希选择后端，配合连接跟踪（同一连接保持在同一后端；后端变化时尽量减少连接迁移）；
   • 怎样把包送到实例？ NAT、修改二层目标 MAC、GRE 等隧道封装（回包路径、连接状态、二层可达性、封装开销和 MTU）

摘录：

即使在理想世界里，依赖存在单点故障的基础设施，也不是一个好主意。现实中，Google 拥有成千上万台机器，以及数量更多的用户，其中许多用户会同时发出多个请求。流量负载均衡，就是决定由数据中心里的哪一台机器处理某个特定请求。

数据中心负载均衡

要回答的问题： 怎么选择连接哪个server？

1. Why： 为什么需要负载均衡？避免后端负载不均，使部分实例先过载、其他容量却闲置；同时控制连接成本，支持安全上下线。

2. What： 什么是数据中心的负载均衡？数据中心内部，调用方如何选择并使用一组后端处理请求。

3. How： 怎么进行负载均衡？通过健康与生命周期管理确定接流量资格；通过子集化控制连接规模（对于七层比较有用，还有TLS相关）；通过请求调度策略按实际能力分摊负载。

摘录：

客户端任务的进程，与后端任务保持连接。对于每个收到的查询，客户端任务必须决定由哪个后端任务处理。

处理过载

要回答的问题： 过载保护都有哪些（限流、降级、重试控制）？

1. Why： 为什么需要过载保护？系统资源有限，流量突增、请求成本变化、负载分配不均，都可能导致过载。如果任由请求堆积和重试放大，可能导致延迟上升、资源耗尽、进程崩溃，进一步引发级联故障。

2. What： 什么是过载保护？根据可用资源、客户配额和请求重要性，控制系统接受的工作量；必要时降低服务质量、拒绝部分请求，并约束客户端继续发送和重试的行为。（让系统在超出容量的流量下，仍能稳定处理自身承受得住的请求。）

3. How： 怎样实现过载保护？

   • 怎样判断是否过载？（QPS、CPU/内存的usage）
   • 怎样避免一个客户挤占其他客户的资源？（按客户资源）
   • 资源不足时，优先保留哪些请求？（按重要性）
   • 怎样减少服务端的工作量？（降级）
   • 连“拒绝请求”都消耗太多资源怎么办？（客户端本地限流（类似熔断））
   • 怎么样避免重试放大过载？（少量实例过载时允许受控重试；大面积过载时停止重试）
   • 请求不多，为什么仍可能过载？（连接维护、健康检查也消耗资源，可以使用连接池、批处理）

摘录：

避免过载是负载均衡策略的目标之一。但是，无论负载均衡策略多么高效，系统中的某个部分最终还是可能出现过载。妥善处理过载，是运行可靠服务系统的基础。

应对级联故障

要回答的问题： 怎么防范雪崩？

1. Why： 为什么需要防范级联故障？系统中的组件共享资源、相互依赖。局部故障可能增加其他组件的负载，或者降低整个系统的有效处理能力。所以需要隔离故障域。

2. What： 什么是级联故障？部分实例失效→ 可用容量减少→ 剩余实例承担更多负载→ 更多实例失效→ 可用容量进一步减小；

3. How： 怎样防止和应对级联故障？

   • 限制额外负载（过载时限流）
   • 限制资源占用时间和数量（限制队列和并发请求数）
   • 防止恢复机制加重故障（恢复是否会造成冷缓存、可用性的问题）
   • 测试失效和恢复过程（测试超过极限后的表现）
   • 故障时先让系统稳定（修复或缓解触发条件，必要时扩容、限流、降级、熔断）

摘录：

对于希望避免级联故障的服务负责人来说，理解系统的临界点在哪里，以及超过临界点后会如何表现，至关重要。

管理关键状态——通过分布式共识实现可靠性

要回答的问题： 为什么需要分布式共识，什么是分布式共识？

1. Why： 为什么需要分布式共识？为了提高可用性，我们把服务和状态复制到多个节点，但是节点会崩溃，网络会延迟、丢包和分区，多个节点可能因此对“谁是主节点”，“配置是什么”等产生不同认知；

2. What： 什么是分布式共识？让一组通过不可靠网络通信的进程，按照明确的协议，对某个决定达成一致；

3. How： 怎样用共识提高可靠性？

   • 哪些地方需要共识？（识别必须保持一致的关键状态）
   • 怎样实现？（使用成熟的etcd/zk）
   • 怎样保证容错？（配置足够的副本，分散故障域）
   • 怎样平衡性能？（稳定领导制、批处理、流水线、分片等优化）
   • 怎样部署？（副本位置、客户端距离、跨地域延迟和故障范围）
   • 怎样运维？（监控是否有领导者、是否持续提交）

摘录：

如果只能记住本章的一件事，那就是：记住哪些问题应该由分布式共识解决，以及用心跳等临时机制替代共识时，可能产生什么问题。

使用 Cron 进行分布式周期调度

要回答的问题： 周期性调度计算作业，这种调度系统，怎么从单机演变成分布式？

1. Why： 为什么分布式调度很难做？单机 Cron 故障会导致漏启动，重新调度又可能造成延迟和状态丢失。增加备用调度器后，还必须防止接管时重复启动。因此，需要同时保障调度的可用性和启动操作的正确性。

2. What： 分布式周期调度是什么？一个多副本的周期调度服务：保存作业配置、计划启动时间和启动状态，由 Leader 在规定时间请求数据中心调度系统启动作业，其他副本负责同步状态并在故障后接管。

3. How： 怎样实现分布式周期调度？

   • 调度器故障后谁接管？（多副本热备，通过共识选出 Leader）
   • 怎样区分不同轮次的启动？（用“作业标识＋计划启动时间”唯一标识每次启动）
   • 怎样记录启动进度？启动到一半崩溃怎么办？（新 Leader 检查未完成记录；依靠外部操作幂等性或状态查询，补齐尚未完成的部分（要么直接重试，要么能够知道当前状态））
   • 怎样防止新旧 Leader 同时操作？
   • 怎样恢复持久状态？
   • 大量作业同时启动怎么办？

摘录：

通过使用 Paxos，并正确分析大规模分布式环境下作业启动的新故障模式，我们构建了一个健壮、且在 Google 内部被广泛使用的 cron 服务。

数据处理流水线

要回答的问题： 怎么管理具有较大深度和复杂度的数据处理流水线？

1. Why： 为什么需要Workflow这个系统？随着数据量增长和结果时效要求提高，以“定时启动、整轮完成”为单位的数据处理方式，可能出现调度积压、长尾阻塞、失败后大量重算，以及共享资源冲击。因此，需要重新设计任务推进、状态保存和故障恢复方式，让数据处理能够持续、稳定地产出正确结果。

2. What： Workflow这套系统是什么？一个管理“任务如何沿流水线推进”的协调系统。

   • Task Master：任务主控：保存任务状态、租约、配置版本和数据引用；检查并提交状态变更。
   • Worker：工作进程：领取任务，读取数据，执行计算，写出结果，再向主控提交。
   • Controller：控制器，可选：管理扩缩容、快照、暂停、回滚和故障转移等操作。

3. How： 它怎样保证可靠性和正确性？把任务状态与执行进程分离。（分离data plane和control plane）允许计算重做，但严格控制结果提交。让跨集群恢复也有明确依据。

摘录：

如果某个数据处理问题本身就是连续的，或者随着业务增长，最终会演变为连续处理问题，那么就不应该继续采用周期性流水线，而应该使用具有类似 Workflow 特征的技术。

数据完整性

要回答的问题： 怎么保证数据完整性？

1. Why： 为什么需要数据完整性？数据会因程序错误、误操作和基础设施故障而丢失或损坏，多副本也可能传播错误。

2. What： 希望达到什么状态？保证数据正确、完整，并在业务允许的时间和数据损失范围内恢复。

3. How： 怎么做？通过软删除、分层备份和故障隔离保留恢复机会，通过完整性检查尽早发现问题，通过持续恢复演练证明恢复能力。

摘录：

认识到不仅“任何东西都可能出错”，而且“各种东西迟早都会出错”，是做好真实应急准备的重要一步。

列出各种灾难组合，并为每种情况准备方案，可以让你至少安心睡上一晚。

让恢复计划持续更新、持续演练，才能让你在一年其余 364 个晚上也睡得安心。

大规模产品的可靠上线

要回答的问题： 怎么保证产品安全上线？

1. Why： 为什么需要可靠上线？因为开发完成、测试通过，并不代表上线时就能稳定运行。此外，上线往往涉及开发、SRE、依赖服务和市场营销等多个团队，容易出现容量没准备好、配置顺序错误、负责人不明确等遗漏。

2. What： 什么是可靠上线？上线前，服务和依赖已经做好准备。上线中，影响范围逐步扩大，效果能够被观察。出现问题时，能够及时停止、关闭功能或回滚。各参与团队知道自己负责什么，以及发生意外时怎样配合。

3. How： 具体怎么做？上线前（Check list、制定实施计划）、上线中（逐步开放并验证：灰度、监控感知）、持续改进（事后学习）。

摘录：

这个团队还整理了一份“上线检查清单”，收录上线时经常需要考虑的问题，以及解决常见问题的方法。实践证明，这份清单是确保每次上线都能可靠完成的有效工具。

回顾与自测

1. SLI、SLO、SLA 分别解决什么问题？

   1. 观测指标，目标，承诺

2. 黄金信号？

   1. 延迟（请求耗时、p99）、负载（qps、bps、cps）、错误率（err）、使用率（cpu/memory usage）

3. 自动化？

   1. 尽量自动化，目的是一致性；（简化复杂性）

4. SRE？

   1. 工作是保持系统的敏捷性和稳定性之间的平衡。

5. 怎么保护过载和避免级联故障：

   1. 熔断
   2. 降级
   3. 限流
   4. 限制处理时间
   5. 重试控制

6. 重试问题

   1. 优雅降级；
   2. 带随机抖动的指数退避；
   3. 限制每个请求的重试次数；
   4. 考虑设置服务器进程级的重试预算；
   5. 只在某一层重试；
   6. 考虑状态码；

7. 数据完整性：数据有三个副本，备份任务每天也都显示成功，为什么仍然可能无法恢复一次误删？怎样证明数据能够在业务要求的时间和允许的数据损失范围内恢复？

   1. 备份还可能已经包含错误、缺少必要数据，或者虽然保存成功，但恢复过程无法正确完成、耗时过长。
   2. 实际执行端到端恢复演练，检查恢复后的数据及应用是否正确可用，并测量恢复耗时和数据损失范围

8. 分布式周期调度，leader执行到一半崩溃怎么办？

   1. 其他应该能够知道执行的状态，或者能够安全的重试（幂等）；

9. 一个新功能已经通过功能测试和负载测试，上线前还需要确认什么？怎样逐步扩大影响范围、判断是否继续上线，并在出现异常时及时止损？

   1. checklist：对已有服务影响，上下游影响，影响范围；灰度步骤，实施计划，回滚方案。