十六句提醒，把排障顺序和证据意识钉住
排障起手
先定义问题，再打开工具。
告警响了，第一个动作不是敲命令。先回答三件事：谁慢了、慢到什么程度、影响范围多大。
把慢拆成 on-CPU 和 off-CPU，再谈瓶颈。
延迟 200ms。其中 on-CPU 30ms，off-CPU 170ms——等锁、等 I/O、等调度。不拆这一步，后面所有工具都在盲跑。
USE：利用率、饱和度、错误，逐资源过一遍。
CPU、内存、磁盘、网络——每种资源都走一轮 USE。遗漏比误判更贵。
先用低成本证据缩小范围，再上高成本证据挖深。
计数器、日志、变更记录能排除大部分方向。profile 和 trace 是第二层。BPF 是第三层。方向没缩小就上重武器，只是更昂贵地迷路。
资源域判断
CPU 忙，不等于 CPU 有问题。
利用率高可能是正常做工。要继续看 run queue 深度、调度延迟、steal time。没有饱和信号，CPU 忙就是健康的忙。
内存满，先看回收压力。
缓存吃满是正常行为。判断内存压力的硬信号：page scan rate、swap activity、major fault、OOM kill。
文件慢，不等于磁盘慢。
I/O 路径隔着文件系统、page cache、写回策略和块层调度。先分逻辑 I/O 和物理 I/O，再决定该怪谁。
网络问题，单边证据不够定位。
只看本端的重传和延迟，无法区分问题在本端、对端还是链路中间。网络排障的起手是两端对照。
工具边界
热点不等于根因。
火焰图告诉你时间花在哪个函数。它不回答「为什么这个函数会成为约束」。从热点到根因，中间隔着工作负载分析和等待结构分析。
工具用来替换直觉，不是用来确认直觉。
如果你打开 perf 之前已经「知道」答案了，你在做的不是分析，是找背书。
tracing 要晚上，BPF 更要晚上。
重工具适合补事件级证据。前提是你已经知道缺哪一段证据。问题还没收窄就上 trace，采到的数据量大到没法用。
高利用率只是线索，不是结论。
80% CPU 可能完全正常。判断是否构成瓶颈，要看饱和度——有没有请求因为资源不足而排队或失败。
可观测性与闭环
看不全，不是停止分析的理由。
云上拿不到宿主机数据是常态。用实例对比、可用区对比、版本前后对比——边界证据足以继续收缩范围。
优化前先算收益上限。
一个函数占总延迟 3%。就算优化到零，整体只快 3%。不值得的优化不要做。
指标变好还不够，要解释为什么变好。
「快了 40%」只是结果。解除的是什么约束、靠什么证据验证、有没有副作用——三项补齐，才能复用。
一次排障留下的应该是方法，不是英雄故事。
团队排障能力的标志：下次遇到类似问题，不需要同一个人再来一次。
调用场景
接手告警时——先用 #1 定义问题，用 #2 拆延迟，用 #3 做 USE 扫描。
选工具时——用 #4 控制证据成本，用 #10 防止确认偏误，用 #11 控制重工具上场时机。
看到资源指标异常时——用 #5–#8 逐域判断。CPU 看饱和，内存看回收，I/O 分逻辑和物理，网络做两端对照。
准备优化或写复盘时——用 #14 估收益上限，用 #15 补因果解释，用 #16 沉淀团队方法。