应对级联失效：失败会自己繁殖，所以修好起因也救不回来

一句话

级联失效（cascading failure）不是「一次大故障」，而是一连串小故障，每一次都让下一次更容易发生。书里的定义只有一句——由正反馈驱动、随时间不断长大的失效——但推论极其反直觉：回路一旦转起来，把最初的触发原因去掉，系统并不会自己回来。因为此刻的负载已经不由外部流量决定，而由系统自身的重试、排队、冷缓存和健康检查决定。于是本章教的是两件事：设计期怎么把回路的每一段掐断（队列、截止时间、依赖方向、启动路径），以及回路已经转起来时，运维手上那几个动作分别在打断哪一段。

Glossary · 术语表

坐标

本章出自 SRE 书 Part III「实践」，作者 Mike Ulrich。它是第 21 章「处理过载」的下半场：上一章讲单个服务怎么自保（脱载、降级、配额、客户端节流），本章讲自保失败之后，失效怎么在服务之间传播，以及整片系统塌了之后怎么救。往后接第 23 章「管理关键状态」——那一章讲的共识系统，恰恰是本章最忌讳的那种「所有人都依赖它」的枢纽。对应现实里的每一次「某某崩了」上热搜：AWS Kinesis 2020、Roblox 2021，以及各家因为一次例行发布或一次扩容而引发的雪崩。

这章要解决什么

先说一句反直觉的：级联失效几乎从不由「坏事」触发。触发它的通常是一件例行公事——一次发布、一次扩容、一次机房排空、一次跨过了某条看不见的线的自然增长。

算一笔账就懂了。5 个任务各跑在 80% CPU 上，看着还有 20% 余量。现在挂掉 1 个（一次滚动更新、一台机器坏了，什么都行），它的负载被均分到剩下 4 个身上，每个变成 80% × 5 / 4 = 100%——只死了 1 个，剩下的就全部顶在天花板上。接着延迟涨、客户端超时重试、请求量再涨一截；健康检查收不到及时回应，集群管理器判定又有 2 个「坏了」，杀掉重建；剩下 2 个要扛 80% × 5 / 2 = 200%。

关键性质出现了：就算把最初挂掉的那个修好放回来，它一上线就会被 200% 的负载瞬间打死。系统不会自己走回左边那张图——推着它的已经不是用户流量，而是重试洪水、积压队列和一堆空缓存。

这两条性质决定了它必须单独成章：一是非线性——利用率从 50% 走到 80% 是线性变差，越过某条线之后是断崖；二是自持——撤掉触发条件不足以恢复，你必须主动打断回路。本章要解决的就是：怎么让回路根本转不起来，以及转起来之后怎么掐停它。

核心内容，讲透

① 正反馈：这一章唯一真正的主角

本章的定义很短：由正反馈驱动、随时间不断长大的失效。最值钱的是「正反馈」三个字，它给了你一个可以随身带走的判据——审设计时问一句：

会，就有回路。上面那笔账里至少藏了三条：失败 → 负载转移 → 更多失败；变慢 → 重试 → 更多负载 → 更慢；进程被杀 → 重启后缓存空 → 后端请求量暴增 → 后端更慢。普通故障是被外力推着走的，级联失效是自己在长。这也解释了它为什么总在深夜一次例行发布之后爆发，而不是双十一零点——流量高峰你准备好了，例行发布你没有。

② 资源耗尽：四条路，和它们互相点火

服务器被推倒的直接原因通常是某种资源见底。本章列了四条主路，洞见在于它们不是四条平行的路，而是一张互相点火的网：

• CPU 不够：所有请求一起变慢 → 在途请求变多 → 队列变长 → 线程被占住 → RPC 错过截止时间 → 重试 → 回到第一步。
• 内存不够：在途请求多了自然吃内存 → 容器被 OOM 杀掉；就算没被杀，GC 频率上升，而 GC 是要花 CPU 的——内存压力就这样翻译成了 CPU 压力；同时缓存命中率下降，又逼出更多对后端的调用。
• 线程耗尽：线程全被慢请求占住，新请求直接报错；更糟的是健康检查也没线程去响应，于是这个还活着、只是忙不过来的任务被集群管理器当成死的杀掉——你的容量被自动化亲手砍了一刀。
• 文件描述符耗尽：连接建不起来，表现出来同样是健康检查失败。

所以「哪个资源先见底」往往不重要，重要的是任何一个见底都会把其余几个一起拖下水。这也是级联失效的现场总是一团乱麻的原因：OOM、超时、健康检查失败同时发生，很难说谁是因谁是果。

③ 队列：它不是缓冲区，是延迟放大器

大多数「一请求一线程」的服务器，都在线程池前面挂一个队列。先破除一个直觉：如果到达率和处理时间都稳定，队列根本不该有东西。队列只在到达率超过处理能力时才增长——而那恰恰是你最不希望它增长的时刻。

队列的三笔代价都很实：占内存（每个排队请求都带着自己的上下文）、直接推高延迟（排队时间是白等的），以及最阴的一笔——制造僵尸请求：队首那些等了 8 秒的请求，用户早走了，你却还要老老实实把它算完。

本章给的方向是把队列做小、尽早拒：队列短，服务器过载时会更早开始拒绝，快速失败反而更健康；队列长虽能吸收突发，代价是延迟被推高、僵尸请求成堆。极端一点的服务甚至几乎不排队，宁可直接失败让上游换一个实例。

具体怎么做，业界最经典的答案来自 Facebook：用 CoDel（controlled delay）的变体给排队时间设上限——如果队列在最近 N 毫秒里一直没被清空过（说明存在一条常驻的队伍），就把允许排队的时间压到很小的 M 毫秒；只要最近清空过，就允许排久一点。人话：允许短暂的突发排队，但绝不允许队伍长期站着不走。再叠上 adaptive LIFO——平时 FIFO 公平服务，队列一开始堆积就切成 LIFO。（出处见下面「大厂实证」。）

④ 截止时间：别做没人等的活

队列的病根，其实是「没人知道这个请求什么时候就没意义了」。本章的解药是把截止时间当一等公民，三条动作：

1. 在多个阶段检查截止时间，尤其是从队列里取出请求的那一刻。已经过期的立刻扔掉、返回错误，一个 CPU 周期都别花。这是最便宜、见效最快的一条。
2. 传播绝对截止时间，而不是每跳各设一个超时。每层都写「超时 1 秒」看着很克制，四层叠起来就是 4 秒预算——而用户在第 1 秒就走了。正确做法是最上层定一个绝对时刻，沿调用链一路传下去，每层只减掉一点网络传输余量。下游一看「只剩 0.35 秒」，做不完就直接不做。
3. 取消也要往下传。上游放弃后若不通知下游，下游会继续为一个没人要的结果消耗资源——过载现场这类僵尸工作可能占掉相当可观的算力。

这里还藏着一个必须点名的陷阱：双峰延迟（bimodal latency）——平均值会骗你。算笔账：一个前端有 10 台 × 100 线程 = 1000 个并发槽，正常每请求 100 ms，轻松扛住 1000 QPS。现在后端挂了四分之一，打到坏实例上的请求要死等 10 s 超时。落在这条慢路上的只有 10%、也就是 100 QPS——但每个都占着线程 10 秒，100 × 10 = 1000，正好把全部线程占满。10% 的流量吃掉了 100% 的并发能力。而此刻平均延迟是 0.9 × 0.1 + 0.1 × 10 ≈ 1.1 s，仪表盘上只显示「有点慢」。所以看百分位，别看均值——这是第 1 章那把尺子在这里的回声。

⑤ 慢启动与冷缓存：稳态很健康，一重启就起不来

服务器刚起来的那几分钟和稳态是两种生物：连接还没建立、JIT 还没热、类还没加载完，最要命的是缓存是空的。稳态下缓存命中率 90%，10,000 QPS 进来只有 1,000 QPS 落到后端，后端正是按这个量规划的容量。缓存一空，命中率变 0，后端要面对完整的 10,000 QPS——整整 10 倍。

这条推论把两个最本能的救火动作变成了危险动作：重启会丢掉缓存；扩容拉起的新实例也是冷的，还得先去后端把自己填满——偏偏后端此刻已经在喘。对策是过量配置、主动预热、以及慢慢放量：一次放一小批，热了再放下一批。AWS 恢复 Kinesis 时每小时只加几百台服务器，正是这个道理。

⑥ 永远向下调用：别让依赖成环

本章有一条近乎纪律的建议：调用永远向下走——避免同层互调，更要避免依赖成环。跨机房的前端互相代理请求、A 调 B 而 B 又回头调 A，这类结构平时看不出问题，一旦某一侧变慢就是一个完美的正反馈环。

最容易被忽略的一种环是监控依赖被监控的对象：出事时你用来定位问题的遥测、配置、服务发现，若本身跑在正着火的那套基础设施上，你就会在最需要看清的时刻失明。Roblox 2021 年那次 73 小时故障就是活标本——排障用的可观测系统依赖 Consul，而 Consul 正是出事的那一个。

⑦ 触发条件与测试：清单在这里

本章列出的常见触发条件读起来有点不适：它们几乎全是好事。进程更新与新版本发布、有计划的变更（排空、下线、维护）、自然增长跨过某条线、请求结构变化（同样 QPS 但更贵）、资源限额调整、机器故障。所以别指望「不做坏事」能躲开级联失效——要在设计上让它塌不下去。

测试方法最重要的只有一句：压到失败为止，然后继续往上压。只测到目标容量等于没测——你要看的是过载之后的行为，尤其是负载降回正常时它能不能自己恢复（很多服务不能，那正是级联失效的定义）。此外要测大客户（它们的重试行为常常和别人不一样），也要测非关键后端——把它干掉，确认关键路径真的不受影响，而不是「我以为不受影响」。

关键权衡与选型

表 1 · 队列策略：短队列不是保守，是防线

表 2 · 四类资源耗尽：症状、点火路径、防线

表 3 · 现场七招：这一招在打断回路的哪一段

表 4 · 两种健康检查混用，等于让自动化替你砍容量

为什么重要 / 落到真实系统

这一章十年后仍是每一份严肃复盘的骨架，因为它把「雪崩」从形容词变成了四段可执行的工程：切断回路（截止时间、取消传播、队列上限）、别让重试相乘（退避、抖动、重试预算）、把启动路径当一等公民（冷缓存、预热、慢放量）、依赖只向下（不成环、监控不依赖被监控者）。面试被问「服务雪崩怎么防」，这四段就是好答案的骨架，而不是「加机器 + 加重试」。

易错点与争议

• 「修好起因就会自己恢复」——本章最贵的误解。回路一旦自持，负载来源已换成重试、积压和冷缓存。Roblox 那次从快照重建后的二次劣化就是公开注脚。
• 加机器是本能，也常常是错的：新实例是冷的，起来第一件事就是去后端把自己填满——而后端正是喘不过气的那个。
• 重启是双刃剑：对 GC 死亡螺旋、线程死锁、大量无截止时间的在途请求很有效；对缓存敏感的服务是火上浇油。动手前先确认病根。
• 健康检查杀得太狠：「忙但活着」被判死，等于让自动化在最缺容量的时刻替你砍容量。书里允许临时关掉健康检查，但明说这是最后手段——你同时也失去了自动清除真坏实例的能力。
• 大红按钮的成本不在技术，在组织：「全掐 → 缓一缓 → 慢慢放」技术上往往最快，但没人愿意在还剩 30% 可用率时主动把它降到 0。这个授权要平时就写清楚，别指望现场请示。
• 只盯平均延迟：双峰分布下 10% 的慢请求能吃掉 100% 的线程，而均值只从 0.1 秒涨到 1.1 秒。看 p99、看并发槽占用。
• 只测到目标容量等于没测：要压到失败之后继续压，并专门验证「负载降回正常后能不能自己爬回来」。
• 时代局限：本章写于 2016 年的 Google 同构 RPC 世界。此后 service mesh 把截止时间传播、重试预算、熔断下沉到了 sidecar，落地成本大降；但也出现了新问题——自动扩缩容本身成了新的正反馈源：延迟一涨就扩容，新实例冷启动打爆后端，后端更慢，于是继续扩容。框架完全成立，只是那份触发条件清单今天要再加一条：你自己的自动化。

要点