本文整理自书籍《SRE 原理与实践》

第一部分 概览

第1章 介绍

不能将碰运气当成战略。
——SRE俗语

系统管理员模式

• 雇佣系统管理员（sysadmin）运维复杂的计算机系统，是行业内一直以来的普遍做法。
• 传统冲突：研发部门（Dev）关注快速发布新功能；运维部门（Ops）关注避免值班期间发生故障。
• 矛盾根源：绝大部分生产故障由部署变更（新版本、配置修改、流量变化）触发，两个部门的目标本质上互相矛盾。

Google的解决之道：SRE

• 核心理念：通过雇佣软件工程师，创作软件系统来维护系统运行，以替代传统模型中的人工操作。

• 团队构成：

  • 50%~60%：标准软件工程师。
  • 40%~50%：基本满足软件工程师标准，并具备其他技术能力的工程师。

• SRE特点：

  • 对重复性、手工操作有天然的排斥感。
  • 有足够的技术能力开发软件系统以替代手工操作。
  • 用软件工程的思维和方法论完成系统管理员的任务。
  • 终极目标：推动整个系统趋向于无人化运行。
• 经验法则：SRE团队必须将50%的精力花在真实的开发工作上。
• 优势：消除了研发和运维的冲突，促进部门整体水平提高，人员可自由流动，知识共享。

DevOps还是SRE？

• DevOps：是SRE核心理念的普适版，适用于更广范围的组织结构。
• SRE：是DevOps模型在Google的具体实践，带有特殊的扩展。

SRE方法论

SRE团队承担以下职责：可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理。

• 确保长期关注研发工作：

  • 运维工作限制在50%以内，剩余时间用于研发项目。
  • On-call准则：每8~12小时的轮值期间最多处理2个紧急事件，确保有足够时间正确处理故障、恢复服务并撰写事后报告。
  • 事后总结（Postmortem）：包含事故发生、发现、解决的全过程、根本原因、预防或优化的解决方案。
  • 原则：对事不对人，目标是发现和堵住漏洞，而非绕过和掩盖。

• 在保障服务SLO的前提下最大化迭代速度：

  • SLO（服务等级目标）：指定服务所提供功能的期望状态。

  • 错误预算（Error Budget）：

    • 起源：任何产品都不应追求100%可靠（对最终用户而言，99.999%和100%无实质区别）。
    • 作用：解决研发团队和SRE团队之间的组织架构冲突。SRE目标从“零事故”转变为共同管理风险，事故成为创新流程中不可避免的环节。
    • 管理：只要系统表现高于SLO，研发可继续发版；预算耗尽时，需降低发布速度或优先修复可靠性问题。

监控系统

• 原则：不应依赖人分析警报，系统应自动分析，仅当需要用户执行操作时才通知。

• 三类输出：

  1. 紧急警报（Alert）：需立即执行操作。
  2. 工单（Ticket）：需执行操作，但非立即。
  3. 日志（Logging）：平时无人关注，供调试和事后分析使用。

应急事件处理

• 可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数。
• 降低MTTR：通过事先预案并将最佳方法记录在“运维手册（Playbook）”上，可使MTTR降低3倍以上。经过多次演习的on-call工程师比初期几个万能工程师更可靠。

变更管理

• 数据：约70%的生产事故由部署变更触发。

• 最佳实践（自动化）：

  • 渐进式发布机制（如蓝绿部署、滚动更新）。
  • 迅速检测问题。
  • 安全快速地回退改动。

需求预测和容量规划

• 定义：保障业务有足够的容量和冗余度去服务预测中的未来需求。

• 步骤：

  1. 准确的自然增长需求预测模型。
  2. 准确的非自然增长需求来源统计。
  3. 周期性压力测试，将系统原始资源与业务容量对应起来。
• 主导：SRE应主导容量规划和资源部署过程。

资源部署

• 是变更管理与容量规划的结合物，需要小心谨慎地执行。

效率与性能

• 责任：SRE负责容量的部署和配置，也必须承担有关利用率的讨论及改进。
• 驱动因素：用户需求（流量）、可用容量、软件的资源使用效率。
• 延迟与容量：负载上升导致延迟升高，延迟升高等同于容量损失。SRE的目标是根据预设的延迟目标部署和维护足够的容量。

总结

Google SRE代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。它由“我是一名软件工程师，这是我如何来应付重复劳动的办法”这一简单想法，发展成一套指导思想、方法论、激励方法和独立职业。

第2章 Google生产环境：SRE视角

本章阐述Google如何将SRE方法论落实在生产环境中，其生产环境本身是一个高度工程化的大系统。

硬件

• 数据中心：Google自己设计，从供电、制冷、网络拓扑到计算硬件统一设计。

• 概念区分：

  • 物理服务器（Machine）：具体硬件。
  • 软件服务（Server）：对外提供功能的软件系统。
• 组织层次：机器 → 机柜（Rack） → 机柜排（Row） → 集群（Cluster） → 数据中心（Datacenter） → 园区（Campus）。
• 硬件故障常态：系统软件将硬件故障对业务的影响隔离掉。

管理物理服务器

• Borg：分布式集群操作系统，负责在集群层面编排任务。

  • 职责：接收job、拆分为task、选择物理机、监控、异常重启/迁移。
• 核心思想：任务实例与物理机器无固定对应关系。
• BNS：名称解析机制，将逻辑名字解析成具体的IP:Port。

• 工程特点：资源声明调度、考虑故障域、资源超限即杀进程。

  SRE观点：一个缓慢但不断重启的实例，好过一个一直泄漏资源却不重启的实例。

存储

• 分层结构：分布式文件服务 → Colossus（集群文件系统） → 数据存储服务（Bigtable、Spanner等）。
• 思路：不同一致性、延迟、吞吐、复制需求，对应不同存储系统，而非一套存储包打天下。

网络

• 数据中心内部：自研交换机，Clos拓扑，高带宽（如Jupiter）。
• 数据中心之间：全球骨干网连接，进行带宽承载、路径选择、动态管理、跨区域流量优化。
• GSLB（全局负载均衡）：贯穿DNS、用户服务、RPC等多个层面，形成分层体系。

其他系统软件

• Chubby（分布式锁服务）：提供类似文件系统的API，处理跨机房一致性。用于主实例选举、存储关键元数据、提供分布式协调能力。
• 监控与警报系统：定期抓取指标，用于报警、版本对比、资源分析和容量规划。

软件基础设施

• 目标：最高效地使用硬件基础设施。
• 特征：多线程设计、内置HTTP接口暴露调试信息、大量使用RPC通信（数据格式为Protobuf）。

研发环境

• 特点：统一的共享软件仓库、代码评审、分布式编译和测试。
• 结果：研发环境本身也是大规模分布式基础设施的一部分，从写代码起就与生产体系相连。

莎士比亚搜索：一个示范服务

通过一个全文搜索服务，串起上述基础设施。

• 两部分：

  1. 批处理：用MapReduce建立索引，写入Bigtable。
  2. 在线前端：接收用户请求并返回结果。
• 请求链路：DNS查询 → GSLB决策 → Google Frontend（GFE）代理 → 前端服务 → RPC请求后端 → 从Bigtable读取结果 → 返回用户。
• 容量规划：考虑实例数、发布、机器故障、地区流量、成本，设计N+2冗余、跨区域部署和数据副本。

总结

Google的SRE是建立在一整套统一、工程化的基础设施之上的。

第3章 拥抱风险

SRE与传统“死守稳定”思维的区别在于主动管理可靠性、成本和创新速度之间的风险。

管理风险

• 为什么不是100%可用：

  • 边际成本极高。
  • 用户对极高可用性感知差别不大。
  • 牺牲新功能交付速度。
  • 工程资源有限。
• 成本维度：物理资源冗余成本 + 机会成本（工程师做新功能的时间）。

度量服务的风险

• 指标：计划外停机时间或用户感知到的不可用程度。

• 两类定义：

  1. 基于时间：正常运行时间 / (正常运行时间 + 停机时间)。
  2. 基于请求成功率：成功请求数 / 总请求数（Google更常用，更贴近用户体验）。

服务的风险容忍度

• 消费者服务：考虑用户预期、是否影响收入、免费/付费、替代选择、客户类型（企业/个人）。
• 基础设施服务：需满足不同内部客户（如在线低延迟 vs 离线高吞吐）的诉求，通过分层、分池提供不同服务等级。

使用错误预算的目的

将研发和SRE的争论转为客观数字。

• 构建过程：共同定义SLO → 监控实际水平 → 差值即为剩余错误预算。
• 好处：对齐激励机制。事故不再是“坏事”，而是创新过程中被量化管理的成本。不允许对失败没有度量、边界和约束。

第4章 服务质量目标

系统解释SLI / SLO / SLA。

服务质量术语

• SLI（服务等级指标）：服务质量属性的可量化表示。如：请求延迟、错误率、吞吐量。
• SLO（服务等级目标）：针对某个SLI设定的目标值或范围。如：99%的请求在100ms内完成。
• SLA（服务等级协议）：未达到目标后的后果（如赔偿）。重点：人们常说的SLA，实际讨论的是SLO。

指标（SLI）在实践中的应用

• 用户关心什么：不要先看能采集什么，而要先看用户真正依赖什么。
• 指标收集：服务端监控 + 客户端观测（捕捉DNS、浏览器等问题）。
• 汇总：平均值会骗人，应关注分布、百分位、直方图。
• 标准化：将常见SLI模板化，降低理解和配置错误成本。

目标（SLO）在实践中的应用

• 定义：必须具体，如“99%的Get RPC在100ms内完成”。
• 选择建议：不要仅依当前状态设目标；保持简单；SLO越少越好但每个都重要；可先宽后严。
• 控制手段：SLO需进入控制回路（监控 → 对比 → 判断 → 执行动作，如扩容、限流、回滚）。
• 建立用户预期：明确SLO可管理用户预期，避免其脑补过高。

协议（SLA）在实践中的应用

SRE的主要职责是帮助定义可客观测量的指标、评估目标现实性，避免触发惩罚性条款。

第5章 减少琐事

划定SRE的边界，区分琐事与工程工作。

琐事（Toil）的定义

运维服务中那些手工、重复、可自动化、战术性、没有长期价值，且会随规模线性增长的工作。

• 特征：手工性、重复性、可自动化、战术性、无持久价值、线性增长。

为什么琐事越少越好

• Google设定目标：SRE至少50%时间花在工程项目上。
• 恶性循环：琐事膨胀 → 无时间做自动化 → 琐事继续增加。

什么算作工程工作

• 定义：具有长期战略价值、需要主观判断、能带来持续改进、偏设计和建设的工作。
• 示例：编写自动化工具、构建平台框架、改善可靠性/性能、优化配置管理。

琐事繁多是不是一定不好

• 少量好处：带来掌控感、反馈快、压力低。
• 大量坏处：职业发展停滞、士气下滑、角色被误解、人才流失。
• 结论：琐事不可能清零，但必须持续消减。

第6章 分布式系统的监控

回答什么样的监控体系才适合生产环境。

术语定义

• Monitoring：收集、处理、汇总和展示系统量化数据。
• White-box monitoring：基于系统内部暴露的状态。
• Black-box monitoring：从外部用户视角观察行为。
• Dashboard：展示核心健康指标的页面。
• Alert：发给某个人或系统的通知。
• Root cause：修复后可防止同类问题再次发生的根因。

为什么要监控

观察趋势、版本对比、发现故障、支持调试、容量规划。对SRE最关键的是发现问题并在需要时及时通知。

对监控系统设置合理预期

• 原则：监控规则应尽量简单、直接映射故障场景、信噪比高、系统本身可靠易理解。价值在稳定、清晰、可操作，而非“聪明”。

现象与原因

• 现象（Symptom）：用户感知到的问题（如网站变慢）。
• 原因（Cause）：导致问题的底层根因（如数据库连接被拒）。
• 准则：报警应优先围绕现象，因为现象更接近用户体验，更能保证报警值得叫醒人。

黑盒监控与白盒监控

• 黑盒：擅长证明“用户现在真的受影响了”。
• 白盒：擅长帮助定位“为什么会这样”。
• 关系：现象和原因是相对的，取决于观察层级。

4个黄金指标

1. 延迟（Latency）：请求耗时。
2. 流量（Traffic）：系统承受的负载。
3. 错误（Errors）：失败速率。
4. 饱和度（Saturation）：资源利用率（应在接近极限前预警）。

关于长尾问题

平均值无法描述真实用户体验。监控需能看到分位数、直方图和分布。

度量指标时采用合适的精度

监控本身要有成本意识，非所有指标都需高频率、高精度采集。

简化，直到不能再简化

持续删除不常用的规则、不展示的数据、未被使用的指标。监控系统本身不能成为运维负担。

将上述理念整合起来

报警哲学：每条Page都应代表一个真实紧急的问题；收到后必须有可执行动作；报警应少而准；纯机械动作应自动化。

监控系统的长期维护

监控规则需随软件、负载、架构变化而持续维护。

总结

健康的On-call体系必须把报警系统控制在一个可承受范围内。监控和报警不是越多越好，而是要为长期稳定服务。

第7章 Google的自动化系统的演进

Google对自动化的理解：自动化是手段，自治系统才是更高形态。

自动化的价值

1. 一致性：程序执行比人更稳定可靠。
2. 平台性：一次构建，多方受益，暴露平台指标。
3. 修复速度更快：显著降低MTTR。
4. 行动速度更快：处理人类反应不过来的场景。
5. 节省时间：将操作与操作者解耦。

自动化对Google SRE的价值

Google控制了大部分技术栈，能获取源码，适合将自动化向平台化推进。

自动化的应用案例

用于新资源创建、服务上下线、部署退役、版本发布、配置修改等。SRE更关心自动化系统的生命周期管理。

自动化分类的层次结构

1. 纯手工操作。
2. 外部维护的系统特定脚本。
3. 外部维护的通用自动化系统。
4. 内部维护的自动化能力。
5. 自治系统（理想形态）：系统自身具备自愈、自调度、自修正能力。

让自己脱离工作：自动化所有的东西

SRE排斥重复劳动，但需追问：自动化放在哪里，谁来维护，是否与核心系统一致演进。

舒缓疼痛：将自动化应用到集群上线中

自动化不能与服务脱节，否则流程会重新变慢、变脆弱。

使用Prodtest检测不一致情况

自动化不仅要做事，还要验证做完后系统是否处于正确状态。

幂等地解决不一致情况

自动化操作必须考虑幂等性，防止重试导致情况恶化。

专业化倾向

自动化质量的维度：能力（对不对）、延迟（快不快）、相关性（覆盖主要流程）。

以服务为导向的集群上线流程

将上线动作本身做成一种服务化能力，从“胶水逻辑”向“平台能力”推进。

Borg：仓库规模计算机的诞生

Borg改变了抽象层级，管理对象从“某台机器”变成“一整池计算资源”，实现了任务重新调度、自动处理机器故障，是基础设施平台化的一次抽象跃迁。

可靠性是最基本的功能

自动化也可能出大规模事故。真正好的自动化必须具备：权限控制、审计记录、合理性检查、限速、幂等性、可回退性。自动化是为了更可靠，而非炫技。

第8章 发布工程

回答如何将变更（最容易制造故障的事）做成可重复、可审计、可加速的工程流程。

发布工程师的角色

跨领域角色，懂源代码管理、构建系统、自动化工具、测试集成、配置管理，与SRE和研发一起定义发布流程。

发布工程哲学

• 自服务模型：每个团队具备自己发布服务的能力，基于统一工具和流程，下放操作权。
• 追求速度：高频发布，每次变更小，测试、调试、回滚更简单，问题定位更清晰。
• 密闭性：构建必须可重现，固定构建工具、依赖库、环境版本。
• 强调策略和流程：关键动作（批准、发版、部署）可控制、可审计。

持续构建与部署

• Rapid系统：承担构建、测试、打包、发版流程编排。
• 构建（Blaze）：定义构建目标和依赖，二进制自描述（时间、版本、标识）。
• 分支：主分支开发，发布分支切出，修复通过cherry-pick同步。
• 测试：源码改动触发测试，发版前对发布分支重新构建和测试。
• 打包：产物放入统一包管理系统，附带哈希、标签、签名。
• 部署：简单服务由Rapid驱动，复杂服务用专门的rollout框架（分阶段、灰度、地域错峰）。发布速度由服务风险决定。

配置管理

配置是常见事故来源。处理方式包括：配置文件与主分支同步、与二进制同包、单独打包、从外部服务动态读取。每种方式都是在灵活性、可追溯性之间权衡。

小结

发布工程的核心是让每一次变更都成为可控制、可验证、可回退的工程活动。

第9章 简单化

没有简单性，就没有真正的可靠性。

系统的稳定性与灵活性

系统天然是动态的。SRE通过流程和工具在灵活性与稳定性间维持平衡。好的可靠性流程反而能提升灵活性，让错误更快暴露和纠正。

乏味是一种美德

在生产系统中，“乏味”意味着按预期运行，没有惊喜。

• 必要复杂度：问题本身固有的。
• 意外复杂度：实现方式额外引入的。SRE需持续警惕并消除意外复杂度。

我绝对不放弃我的代码

无用的代码应被删除，而不是注释掉或加功能开关。注释代码制造噪声，关闭的功能开关是定时炸弹。删除代码本身就是可靠性优化。

“负代码行”作为一个指标

删除无用代码能降低理解成本、测试成本、缺陷面和资源浪费。

最小API

小而清晰的API意味着对问题理解更透彻，更易理解、使用、演进和测试。

模块化

降低变更成本和故障传播范围。模块职责清晰、耦合低，可局部修复、独立演进。扩展到API版本化和数据格式设计（如Protobuf）。

发布的简单化

小批次发布让每次变更的因果关系更清晰，发布更频繁、更安全。

总结

稳定不是加更多控制，而是减少不必要复杂度。

第10章 基于时间序列数据进行有效报警

介绍Google内部监控系统Borgmon的设计思路。

Borgmon的起源

为适应大规模分布式系统，Borgmon将收集时间序列数据作为第一任务，通过统一规则语言转成图表和报警。

应用软件的监控埋点

应用需暴露内部状态（如通过/varz接口）。增加监控埋点门槛低：新增变量并暴露即可。

监控指标的收集

Borgmon根据动态目标列表周期性抓取指标，抓取时间均匀分散。同时生成“合成指标”描述抓取本身是否成功，使监控系统可观察。

时间序列数据的存储

数据以时间序列（含标签）形式存储在内存数据库，并定期刷到持久化存储。近期数据要快，历史数据要长，可用不同存储层。

标签与向量

通过标签区分变量名、任务、实例、服务、区域等。支持从单实例到全局的多维度汇总。现代监控系统普遍采用“时间序列+标签”模型。

Borg规则计算

高层指标（如错误率）通过规则从原始指标推导。底层指标保持通用，业务判断通过规则层表达。

报警

报警规则为真假判断，需设置最小持续时间以避免抖动。Borgmon将报警交给统一告警管理组件处理去重、合并、路由。

监控系统的分片机制

采用层级式分片：底层实例抓取指标，上层全局实例抓取汇总值。单点压力可控，汇总逻辑清晰，下钻定位容易。

黑盒监控

结合白盒（内部指标）和黑盒（外部探针）监控，同时兼顾“是否坏了”和“坏在哪里”。

配置文件的维护

收集目标和规则分离、支持模板化、规则复用、测试和回归测试。监控系统本身要像软件项目一样被测试和治理。

十年之后

Borgmon代表了一种成熟监控范式：大规模采集时间序列 → 统一规则汇总分析 → 标签和层级支撑规模 → 模板化和测试保证可维护。

第11章 On-call轮值

回答如何值班，团队才不会被值班这件事本身拖死。

On-call的定位

有明确定义的责任人、响应时间、升级路径和恢复目标。值班工程师对恢复结果负责，而非“看过报警”。

SRE式On-call和传统Ops的差别

• 传统：故障多就加人，操作多就排班，人扛不住就继续加人。
• SRE：故障多说明需工程改造，重复操作多说明自动化不够，报警多说明监控设计有问题。On-call是暴露工程缺陷的传感器。

50%工程时间原则

• 硬约束：On-call时间 ≤ 25%，其他运维性工作 ≤ 25%，至少50%时间用于工程项目。
• 原因：没有工程时间就修不掉重复问题，值班负担会恶性循环。

值班负载的数量平衡

• 轮值频率：不能高到侵蚀正常生活，团队人数要足够覆盖24x7并预留休假和项目时间。
• Follow-the-sun：全球化服务采用多站点轮值、多时区交接，利用白天覆盖夜间。

值班负载的质量平衡

• 关键指标：每次值班期间被打断多少次。
• 经验线：8~12小时窗口内，最好不超过2个真正要介入的紧急事件。
• 影响：一堆“几分钟的小问题”会切碎上下文，降低值班质量。

主、副值班模型

• 主On-call：第一时间接警。
• 副On-call：兜底和升级支援。
• Escalation系统：检查响应情况，必要时升级。避免人力单点故障，减少心理负担。

响应时限

应与服务的SLO挂钩，值班人的打断成本必须与报警的业务价值匹配。不是所有异常都值得叫醒人。

值班人的心理状态

高压下人会变笨，易依赖直觉、抓住第一解释、误判因果。值班体系需提供清晰的升级路径、可执行的手册和随时求助的通道。

Compensation和可持续性

On-call会侵占睡眠、带来压力，健康团队会给予某种形式的补偿，承认这是一项真实负担。

报警质量决定值班质量

值班过载的根因通常是报警设计太差。理想的报警：收到后知道是否要动作、谁做、不做的后果，并能带出关键上下文。

如何缓解值班过载

1. 去掉不可操作报警。
2. 聚合和去重重复报警。
3. 增加最小持续时间抑制尖峰。
4. 低优先级事项沉淀为工单。
5. 临时让其他团队分担。
6. 极端情况下，将支持责任退回开发团队（SRE不无限兜底）。

过少的运维压力也会出问题

工程师需周期性参与On-call，保持生产环境直觉，否则工程优化易脱离现实。

总结

On-call必须存在但不能吞掉团队。值班体系可持续的前提，是用工程手段持续消灭值班负担。

第12章 有效的故障排查手段

将排障从神秘经验拉回到可训练的结构化方法。

排障需要的两类能力

1. 通用方法论。
2. 对具体系统的理解。

故障排查的基本闭环

观察现象 → 建立假设 → 设计验证 → 排除或确认 → 继续下一轮

问题描述越差，排障越慢

好的问题报告需包含：期望行为、实际行为、触发时间、复现路径、影响范围。

利用历史记录

重视历史故障记录，包括上次的排障路径和负结果。保留历史上下文是排障能力的一部分。

分诊优先于根因洁癖

大故障来临时，优先级是：先恢复服务 → 再保留证据 → 最后做根因分析。

常见误区

• 把次级现象当成主要问题。
• 想了一个漂亮但无法验证的理论。
• 过早钻进最复杂的解释。
• 把相关关系误认为因果关系。

从信号里找线索

• 指标：看趋势和爆点。
• 日志：看细节和事件序列。
• 分布式追踪：看链路中最慢的一段。
• Debug页面：看运行期内部状态。
• 真实请求：看用户实际感知。

缩小问题空间

排障要持续缩小范围：判断是新变更还是旧问题；是客户端、服务端还是依赖层；是单地区还是全局；尝试关闭部分功能看症状是否变化。

保留证据

事故中的证据（日志、内存状态、配置）会消失，需在可控风险下尽量保留快照。

负结果也必须写下来

记录查过什么、为什么排除、还剩哪些方向未查，避免重复劳动。

App Engine案例

案例表明：很像答案的不一定是真相，追踪工具暴露瓶颈但不会自动告诉你根因，复杂解释不天然比简单解释更对。

让系统更容易被排障

排障能力是系统设计质量的结果。系统应：暴露关键指标、状态可见、请求有唯一追踪ID、变更可追踪、组件边界清晰。

第13章 紧急事件响应

讲述“真的出事时第一时间怎么做”。

第一原则：不要慌

稳住节奏，先确认事实，明确当前目标是止血还是定位。

紧急响应是平时训练出来的

组织真正的质量在事故时暴露：是否有明确流程、值班人是否知道流程、关键人能否快速拉齐、是否习惯记录和演练。

事故中先做什么

顺序：停止正在放大的伤害 → 恢复用户可见服务 → 再做详细分析。若怀疑某变更，优先暂停、回滚或切回稳定路径。

案例一：测试引发的故障

不要默认“测试是内部动作所以安全”。测试系统本身需有隔离、限流、快速撤回能力。

案例二：配置和发布引发的故障

快速确认最近改动，若时间高度重合，先回滚恢复，再确认根因。没有快速回退能力的发布体系是在拿生产做实验。

案例三：自动化或流程引发的严重事故

自动化系统影响面大、传播快，人可能误以为“正在自愈”。需有紧急停机、手工接管、带外恢复通道。越自动化，越需要人为刹车。

共同的成功模式

快速识别可疑触发点 → 停止继续变坏 → 找到相关人 → 用降级/切流/回滚恢复 → 将临时经验沉淀为永久修复。

事故中要一直记录

记录发现时间、谁做了什么、哪步改变了状态、哪些假设已排除。避免回忆不一致、重复尝试、交接混乱。

事后别只问“谁干的”

每次事故都应成为可传播的经验。训练是为了缩短混乱期，事故处理是组织能力。

第14章 紧急事故管理

讲多人卷入后，如何将现场从混乱拉回到可管理状态。

没有流程时会发生什么

大家都在改东西但没人统筹，私聊、开会、另起频道，好心帮忙者增多但变量也增多，沟通成本暴涨，真正信息反而变少。

什么时候要“宣布事故”

• 有明显用户影响。
• 需第二个团队一起处理。
• 集中分析很久未收敛。
• 需专门沟通、记录和协调。若1小时左右未解决且影响清楚，应切换至正式事故处理模式。

事故指挥官（Incident Commander）

不一定是写命令最多的人，但负责：明确当前目标、分配任务、决定人员进出、控制节奏、对优先级拍板。

操作负责人（Operations Lead）

偏执行面，组织排障和缓解动作，汇报进展，告知方案可行性和风险。是战术层。

沟通负责人（Communications Lead）

容易被忽略但极其重要。对内统一口径，对外更新状态，挡住无序追问，避免技术骨干被沟通淹没。

记录员 / 后勤角色

记录时间线、谁在做什么、维护事故文档、准备交接材料。未记录的信息等于不存在。

单一控制面

使用War Room、IRC、统一会议室，所有关键讨论收敛一处，避免信息分散。维护实时事故文档，写明当前影响、假设、已做/待做动作及责任人。

信任被分配的人

角色一旦分配，就要让其真正发挥作用。IC不要跳进技术细节，操作负责人不要被多人遥控，沟通负责人不要被绕开。

交接必须显式进行

交接需明确：当前事实、已排除方向、最优先任务、绝对不要重复的操作、当前风险点。口头说“翻一下聊天记录”等于没有交接。

事故管理流程平时也要练

可拿中等故障做演练，轮流让不同人担任IC，训练记录和沟通。事故管理是肌肉记忆。

总结

事故现场不是“更多人同时操作”，而是“更多人按结构化方式协作”。

第15章 事后总结：从失败中学习

故障处理完，不等于事情结束。

为什么必须写Postmortem

Google体量下事故必然发生。如果不总结，经验无法传播和积累。

哪些情况必须写

• 用户可见中断或明显降级。
• 数据丢失或损坏。
• 需On-call人工介入恢复。
• 恢复时间显著过长。
• 监控未发现，靠人发现。

一份Postmortem至少要写清什么

• 影响（影响了谁、持续多久、数据风险、临时措施）。
• 发现方式。
• 时间线。
• 缓解动作。
• 根因。
• 后续行动项。

根因不是“最近那个失手的人”

• Blameless原则：默认当事人基于当时信息做判断，真正要修的是系统、流程、工具的漏洞。
• 追问：为什么一个普通失误能穿透到生产？为什么系统没在更早位置拦住？

事后总结要写到什么深度

反对“人为失误”、“配置错误”等表层答案。需追问：为什么会出现这个配置错误？为什么没被测试挡住？为什么监控没覆盖？

协作写作，而不是一个人补作业

使用共享文档，相关人补证据、补细节，做正式评审。Postmortem是团队共同构建的事故知识产品。

评审时该看什么

证据是否充分、时间线是否完整、影响是否写实、根因是否足够深、行动项是否具体、是否值得更广泛传播。

行动项必须可执行

指向明确问题、有负责人、有截止时间、能验证完成。避免“优化流程”、“加强监控”等空话。

奖励好总结，而不是只奖励“没出事”

组织要公开支持Blameless、分享优秀Postmortem、鼓励阅读和讨论、奖励写得好的总结和事故处理。

Postmortem流程本身也该被优化

复盘模板、评审流程、行动项跟进、元数据趋势分析。故障是难免的，但失败若无转化，就白失败了一次。

第16章 跟踪故障

关注如何把日常故障持续沉淀成可检索、可统计、可改进的生产数据。

为什么光有Postmortem还不够

• Postmortem只覆盖影响特别大的事故。
• 小故障、高频故障、噪音型故障常被忽略。
• 单次事故视角难以发现“全局看很值”的改进项。

Escalator：先把“报警有没有人接”管起来

职责：跟踪报警响应，在规定时间内无人确认则按路径升级。底座作用显著。

Outalator：从“报警”升级到“故障”

• 处理更高层抽象的“故障”。
• 可将多条报警收拢成一个上下文。
• 保存原始报警和处理过程中的邮件往来。
• 支持高亮关键回复。

多队列视图很重要

SRE常同时处理多个服务报警。多队列时间序列视图能帮值班人重建故障现场，避免信息割裂。

“重要回复”机制很实用

折叠信息量低的噪音，默认只展开关键信息（如根因猜测、止血动作、变更）。

聚合：把“多条报警”还原成“一个故障”

• 目的：将相关报警合并成一个故障对象，降低认知成本。
• 好处：减少重复劳动、避免信息分裂、便于做故障级分析。

标签：最值钱的小功能

• 形式：前缀式命名空间，如cause:network、action:rollback。
• 好处：快速记录故障元数据、团队可按自己粒度细化、便于检索和统计趋势。
• 现实：虽有拼写错误等问题，但收益远大于成本。

分析：从“记录故障”变成“理解系统”

• 第一层：计数和汇总（每周/每月故障数、哪些服务最吵）。
• 第二层：趋势与对比（报警在变多还是变少、故障密度是否异常）。
• 第三层：语义级分析（哪类基础设施引起最多故障、哪些机制过敏）。

不要只看“故障次数”

故障多不一定修起来最值，故障少也不一定影响小。统计是分析的入口，不是结论。

报告、交接与评审

Outalator可生成事件摘要，支持交接。交接最怕只传结论不传上下文，或只传现象不传已做动作。

意外收益

还可用于记录高权限账号使用、关键周期任务执行等，成为运行期异常事件知识库。

总结

Postmortem解决“单次事故要学什么”；故障跟踪解决“整体运维到底在被什么反复消耗”。

第17章 测试可靠性

核心思想：没有亲自验证过的东西，先假设它是坏的。

测试为什么直接关系到可靠性

• 对未来可靠性的信心来自：过去的监控数据 + 对未来变更的控制。
• 测试是在证明“变化前后某些关键性质未被破坏”。每多一个有效测试，就少一块未知风险区域。

监控给你事实，测试给你前置把关

测试的价值在于把Bug拦在生产前。某些Bug的MTTR可因测试变为0。

测试、MTTR和MTBF的关系

更多有价值的测试 → 更多Bug在发布前被挡住 → 生产低级错误变少 → MTBF拉长 → 团队发布更快。

测试越好，改动空间越大

测试覆盖度越高，每次改动不确定性越低，团队越敢持续修改系统。