有效排障：先止血，再破案

一句话

SRE 第 12 章要拆掉一个流行误解：排障（troubleshooting）不是某些人天生的直觉，而是一门可分解、可传授的手艺。它等于两样东西相乘——一套通用的假设-演绎流程（问题报告 → 分诊 → 观察 → 诊断 → 测试 → 治愈），乘以对这个系统的具体了解；缺了流程，你会瞎猜，缺了系统知识，你连能被检验的假设都提不出来。最反直觉的一课是顺序：第一步不是找原因，是止血——「你正在找根因的时候系统死了，对用户没有任何帮助。」

Glossary · 术语表

坐标

作者 Chris Jones。本章是 SRE 书 Part III「实践」里的核心技能章：上承第 6 章「监控分布式系统」（症状告警负责把问题送到你面前）与第 11 章「值班」（谁去接），下启第 13 章「紧急响应」、第 14 章「事故管理」与第 15 章「复盘文化」。它也是第 9 章「简单性」的直接受益方——你能排的障，不会超出你还理解得了的系统。放到现实里，它对应的是值班手册、事故指挥、可观测性平台选型，以及那道最常见的面试题：「线上 500 错误率突然涨到 3%，你怎么查？」

这章要解决什么

本章开篇挑明的问题是：排障常被当成一种天赋——有人有，有人没有。之所以有这种错觉，是因为对天天干这事的人来说，这套流程已经内化到说不清了。把它当天赋的代价很实在：不教、不练、不写下来，团队的排障能力就绑在几个老人身上，人一走就归零。

第二个问题是分布式系统让老经验失效。单机时代的调试是「找到坏掉的那台机器 / 那个进程」；而在一次请求扇出到几十上百个 RPC 的系统里，往往没有任何一台机器是坏的——只是某一跳慢了 300 毫秒，然后超时、重试、排队，最终在最外层表现为「网站慢」。你要找的不是坏零件，是一条路径上的一段异常。

不解决会怎样？把账算给 SLO 看最直接：一条 99.9% 的月度可用性目标，整月只允许约 43 分钟不可用（第 3、4 章的口径）。也就是说排障时长不是软指标，它就是可用性的分母——同一次故障，30 分钟定位和 5 分钟定位，差的那 25 分钟就吃掉当月大半个错误预算。

本章还先教「不要做什么」，列了四种无效排障的典型病：① 盯着不相干的症状，或误读了某个指标的含义，一路缘木求鱼；② 不清楚怎么安全地改动系统 / 它的输入 / 它的环境，因而没法验证自己的假设；③ 提出极不可能的理论，或死抓住上一次故障的原因不放；④ 追逐虚假相关——纯属巧合，或两者其实同源于第三个原因。第四条随规模自动恶化：一个服务导出几千个指标，两两配对就是几百万对，总会有几对曲线长得一模一样。而这里还有一条本书引论给过的经验值：约 70% 的线上故障源自对运行中系统的变更——这既是坏消息，也是最好的第一线索。

核心内容，讲透

一、理论：排障 = 通用流程 × 系统知识

本章给排障下的定义是假设-演绎法的一次应用：手上有一组关于系统的观察，加上一套「系统本该怎么运转」的理论，于是反复地提出可能的原因，然后想办法检验它。注意这里的两个输入缺一不可。只靠通用流程也能干活，但通常远不如懂这个系统的人有效率；反过来，只有系统知识、没有流程，人就会跟着直觉乱撞，而直觉恰恰是四种无效排障的温床。

这也解释了为什么排障「看起来」像天赋——老手的系统知识是隐性的、流程是内化的，两样都说不出口，外人只看见「他一眼就看出来了」。本章的全部工作就是把这两样摊到桌面上：流程写成图 1，系统知识落成值班手册与「可观测性要设计进去」。

二、分诊：止血优先，但不许毁现场

这一节是全章最该背下来的。本章的原话是：「止血应当是你的第一优先级；你正在找根因的时候系统死了，对用户没有任何帮助。」分诊的目标被定义成一句朴素的话——让系统在当前条件下尽可能地正常工作。手段是应急性的，不需要知道原因：把流量从坏掉的集群切走、主动丢弃一部分负载保住其余、把功能降级成返回缓存或简化结果。

这两件事根本不该串行：成熟系统里一次跨集群切流量是分钟级操作，而定位一个偶发的内存泄漏可能要几小时。让用户为后者等着是纯粹的浪费。

但本章紧接着补了一句最常被忘掉的约束：「强调快速分诊，并不排除采取措施保存出问题的证据（比如日志），以便后续做根因分析。」它的现实含义很刺眼——最常用的止血手段（重启 / 换机器）同时也是最有效的毁证手段：内存状态、当时的堆栈、只在故障期间出现的日志，重启之后全没了，于是同一个故障每月准时回访、每次都靠重启「解决」。可操作的做法很便宜：留一个摘出流量但不杀掉的实例、先抓一份转储再重启、把这段时间的日志单独归档。

三、观察：你只能看见你当初埋下的东西

「观察」这一步要做的是逐个组件地看它自己的行为，判断整体是否健康。本章给的工具是三层：

• 指标：程序自己导出的白盒计数器与耗时分布，回答「哪个组件不对劲」，但只到组件粒度。
• 日志：反应式调试的主力。本章强调一个工程细节——详细程度要能在运行时动态调高，否则你要么平时被日志淹没、要么出事时什么都没有。
• 分布式追踪：Google 的 Dapper，解决指标解决不了的那个问题：一次请求扇出到几十上百个 RPC 时，聚合指标只能说「整体 p99 变差了」，说不出「差在第几跳」。它靠低比例采样把开销压到可以常年在生产开着。

四、诊断之一：简化与折半

诊断的第一把刀是把搜索空间砍小。在一条由多个组件串起来的链路上，不要从第一个开始挨个查，而是在中间下刀：如果中间那一点的输入输出都正常，故障在下游；如果中间已经不对，故障在上游。每一刀砍掉一半，n 个环节大约 log₂n 刀收敛——7 跳约 3 刀，100 个候选版本约 7 刀。同一把刀也能横着用在时间轴上：在 100 个提交里二分定位是哪次改动引入的回归。

五、诊断之二：问「什么、在哪、为什么」

第二把刀基于一个观察：坏掉的系统通常还在努力做事，只是没在做你想要的事。所以别问那个太大的问题「它为什么坏了」，改问三个小的：它在做什么？它的资源花在哪儿 / 输出去了哪儿？为什么花在那儿？每回答一层，就往下钻一层。本章给的例子把这套下钻演示得极干净：

六、诊断之三：最近谁动过它

第三把刀最省事，也最常被跳过。本章的说法带点物理味道：系统是有惯性的——一个正在正常运转的计算机系统会保持运转，直到受到某种外力作用，比如一次配置变更，或者流量性质的变化。所以「最近的变更」永远是第一顺位的嫌疑人，回滚则是最快的一次假设检验：退回去好了，基本就是它。

要让这把刀好用，有个前置条件：系统各层都得有变更记录——从处理用户流量的服务二进制版本、配置、实验与旗标，一直到集群里每台机器上装的软件包。没有这份记录，「最近动过什么」就变成了群聊里的口头考古。

七、测试与处置：一次只动一个变量

有了假设就要检验。本章列的注意事项，条条都是血泪：

• 理想的测试要让备选假设互斥——一刀能同时排除一组、留下一组，而不是「测完还是两边都有可能」。
• 先测明显的，但要按「可能性 ÷ 风险」排序。「重启主库看看」可能信息量最大，但它同时是风险最高、最不可逆的一步，该排在后面。
• 混杂因素会让结果骗人：你改了 A 之后好了，也可能只是同一时刻高峰过去了。
• 主动测试有副作用，会改变后续结果。本章给的例子很典型：把日志调成 verbose 本身就会让延迟问题更糟；给进程更多 CPU 会让它更快，但也更容易撞上数据竞争。
• 有些测试只是提示性的，不是决定性的——竞态和死锁很难稳定复现，测一次没出现，不等于排除。
• 把你想过的念头、做过的测试、看到的结果写下来。故障拖得越久、卷进来的人越多，这份记录的价值越大：它是换班交接的唯一载体，也防止第二个人把第一个人测过的东西再测一遍。

把这条反过来说更醒目：排障中最贵的开销往往不是测试本身，而是忘了自己已经测过什么。

八、治愈，以及「负面结果是魔法」

严格证明因果需要对照实验，线上通常做不到，于是现实中常常止步于相关性加上一个说得通的机制——本章对此是坦诚的。提高把握的做法有两条：在测试环境里复现，以及把整个链条写下来，即一份说清「出了什么问题、怎么定位、怎么修、以后怎么防」的复盘（本章顺口开了个玩笑：但愿写的时候系统还活着）。

本章还专门用一节讲了一件容易被扔掉的东西：负面结果是魔法（negative results are magic）——「我们试了 X，它不是原因 / 它没有变快」。主张有四层：① 负面结果是结论，不是失败，一个干净的否定能一次解决掉最难的设计争论；② 为这次实验造的工具和方法，寿命通常比实验本身长；③ 不发表，下一个人（很可能是三个月后的你自己）会把同样的坑再踩一遍；④ 所以——请发表负面结果。这针对的是行业里一个真实的偏见：没人愿意写「我们试了这个，没用」。

关键权衡与选型

表 1 · 止血（分诊）vs 破案（诊断）：两件事，两个时钟

表 2 · 四把诊断刀：什么时候用哪把

表 3 · 观察手段：各自回答什么问题、盲区在哪

表 4 · 验证假设时，测试怎么排序（低风险在前）

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

这一章的四条判据，几乎每一条都能在公开的事故复盘里找到正反两面的印证。落到日常：值班时先问「切得走吗、降得了吗」再问「为什么」；事故复盘里检查有没有为了止血把证据一起清掉；可观测性选型时先确认「一次请求的耗时能不能拆到每一跳」；面试里遇到「错误率突然涨到 3%，你怎么查」，标准答卷就是这套顺序——先止血、看最近变更、折半缩范围、逐层问力气花在哪。

易错点与争议

• 把止血和破案混成一件事。最常见的失败姿势是：先花 40 分钟找根因，用户疼 40 分钟。本章的顺序是硬的——能切走就先切走，原因回头再说。
• 反过来的错：只止血不诊断。「重启一下就好了」既是最快的止血，也是最彻底的毁证。同一个故障每月准时回访、每次都靠重启「解决」，就是这么来的。止血的同时留一个不动的实例，成本很低，价值极高。
• 把「最近谁动过它」当成唯一答案。约 70% 来自变更，意味着还有 30% 不是：流量性质变了、证书过期、容量爬到线、依赖方悄悄改了行为、时间与闰秒。这 30% 里没有变更记录可查，只能靠前两把刀。
• 相关不是因果，而且规模会主动制造巧合。本章明确点了这条：随着系统变大、监控的指标变多，纯属偶然而高度相关的事件必然出现。看到两条曲线一起翘，先问「有没有共同的第三个原因」。
• 「根因」这个词本身有争议。本章成书于 2016 年，用的还是较朴素的单一根因框架。此后韧性工程一派（STELLA 报告一线）主张：复杂系统的事故是多个条件的合流，追一个「根」往往会过早收束调查、并把注意力引向人。这不否定本章的流程，但提醒你「找到了」不等于「查完了」。
• 把负面结果理解成「没查出来」。本章说的负面结果是结论性的——明确排除了什么、证伪了哪个假设。「查了一天没头绪」不是负面结果，那只是还没开始。
• 时代局限，但判据没过期。2016 年的可观测性主要是白盒指标 + 文本日志 + Dapper 式追踪；此后高基数事件、eBPF、连续剖析（continuous profiling）乃至自动根因建议都改变了成本结构。工具换了一整代，本章的四把刀一把没被替掉——它们约束的是人的搜索策略，不是工具。而「排障可教」这条本身也打折：本章承认它需要系统专属知识，那部分最容易随人流失，所以值班手册与演练是这章隐含的前提，只发流程不发知识，教出来的仍然是猜。

要点