接到性能告警后，先把问题说窄，再决定上哪类工具

性能告警刚响时，最浪费时间的动作就是立刻开重工具。先把问题说窄，后面每一步都会更快；问题还没说清就上 tracing，只会把噪声一起放大。

先用五分钟，把“到底哪里慢”钉成一句话

第一轮不要急着解释原因，先把问题定义写清。

要写下来的至少有四件事：谁在报慢，慢的是哪个接口或哪类请求，影响范围有多大，从什么时候开始变坏。没有这四项，后面的所有指标都容易变成“看起来有关”。

紧接着补一刀，把现象拆成更具体的形状。是平均值变差，还是 P99 拉长？是所有实例一起坏，还是少数节点抖？是吞吐掉了，还是错误升了？

做到这里，才算进入 Gregg 的起手顺序。你不是在找答案，而是在把问题压成一个可以验证的描述。

最小产物很简单：一条问题定义，加一条时间边界。比如“18:20 之后，支付接口 P99 从 80ms 升到 260ms，只影响一组云实例”。

如果连这句话都写不出来，先别急着往下钻。

先扫资源，不先押注最熟的方向

问题定义立住后，下一步不是挑工具，而是做一轮 USE 扫描。

CPU、内存、磁盘、网络逐项过，每项都看三件事：利用率、饱和度、错误。利用率告诉你资源忙不忙，饱和度告诉你请求有没有排队，错误告诉你有没有直接失败。三项缺一项，方向就容易歪。

这一步的目标不是锁根因，而是快速排除。五分钟内要拿到一份“哪些资源暂时不像问题源头，哪些资源值得继续追”的清单。

如果只看 CPU 和内存，就停了，说明 USE 还没真正跑起来。Gregg 的方法价值，恰好在于它逼你别被熟悉感带偏。

当某个资源域开始露头，再往下钻。没有露头之前，不要提前决定问题一定在应用、内核或数据库。

慢，到底是算得慢，还是等得久

第一轮资源扫描之后，经常还会剩下一种尴尬局面：系统确实慢了，但没有哪条利用率指标高到足以直接定案。

这时要做的，不是继续刷更多平均值，而是拆时间。线程在 CPU 上执行的时间是 on-CPU；线程没跑、但请求还没结束的那部分，是 off-CPU。锁等待、I/O 等待、调度等待、网络等待，都会落到这里。

这个动作决定了后面工具怎么换。如果时间主要烧在 on-CPU，profile 更值钱；如果时间主要烧在 off-CPU，调度延迟、等待事件和相关追踪更值钱。

做到哪算这一段过关？你至少能回答一句：现在更像“谁算得慢”，还是“谁让请求一直在等”。回答不出来，就不要贸然进优化。

只有缺哪类证据，才值得上对应工具

Gregg 在工具章节最实用的一条纪律，是别把工具当身份标签。perf、BPF、Ftrace、tcpdump 都很强，但每样工具都只擅长补一种视角。

缺 CPU 时间分布，上 profile。缺延迟分布和尾部形状，上直方图类工具。缺事件因果，再上 trace。顺序反过来，成本会立刻变高。

所以工具升级前，先问自己一句：我现在缺的到底是哪类证据？如果答案只是“这个工具最强”或“大家平时都这么用”，那还没到该上它的时候。

一个实用做法，是把升级条件写成短句。比如：

• 已确认资源域在 CPU，且需要知道时间花在哪个调用栈上，再上 perf。
• 已确认问题在等待层，且需要知道线程为什么睡着，再补 off-CPU 或调度相关工具。
• 已知统计量不够，必须看事件顺序时，再上 tracing。

这样做的好处，是每次开工具前都能回到问题本身，而不是被工具牵着走。

进了云环境，先接受你看不全

如果现场在云上，动作要再改一层。别等完整视角，先拿边界证据继续推进。

先做实例对比。异常是所有实例一起出现，还是只在少数节点上出现？再看可用区、版本、部署时间和 steal time。你拿不到宿主机，也一样能先把问题范围压小。

这一步做偏的信号也很明显：你开始反复等待别人补数据，却迟迟没有缩小问题空间。那说明你还在按裸机场景思考。

云上排障的最小闭环，不是“看全底层”，而是先把异常收窄到某批实例、某次变更、某类资源边界。

真正做完，不是找到一个猜测，而是留下一条证据链

定位到瓶颈后，不要急着宣布结束。还要留下 before/after、关键证据、约束定位和验证方式。

before/after 至少保留同一组指标快照。关键证据要能解释为什么你认定瓶颈在这里。约束定位要说清解除的是什么等待、排队或竞争。验证方式要说明你怎么确认改动真的碰到了根因，而不是只赶上流量回落。

做到这里，排障才算完整结束。否则你只是把这次故障压下去，没有把方法带回团队。

下次还能不能复用，看你有没有留下这三样东西

收尾不要写成长篇流水账，只留下三样最值钱的东西。

第一，问题定义。让三个月后的同事一眼就知道当时到底坏成什么样。

第二，判断路径。资源扫描怎么做的，哪条证据让你换了方向，为什么从 metrics 升级到 profile 或 trace。

第三，复用信号。下次再看到什么症状，可以直接套这条路，而不是重新猜一轮。

如果这三样都在，Gregg 的方法就不只存在于你这次排障里，而是开始进工作流了。