Gregg 真正交付的，不是工具表，而是一套先收窄再深挖的诊断顺序

很多性能书会教你认识指标、认识工具、认识硬件。《性能之巅》更往前走一步。Gregg 反复要解决的，不是“你会不会用 perf”，而是“问题一来，你先信什么、先排什么、什么时候才值得把证据打深”。

真正的起点，不是工具，而是把问题压成可验证的描述

Gregg 的整套方法，第一步都不是观察资源，而是先把故障说清。谁在变慢，慢的是哪类请求，影响范围多大，从什么时候开始，工作负载有没有变化。

这个起点看着朴素，却决定了后面会不会走偏。问题如果还停留在“系统变卡了”这种松散描述，任何指标都能被硬解释进去。性能分析会迅速滑成搜图和猜谜。

所以这本书的第一个方法前提，不是系统知识多深，而是愿不愿意先收窄问题。没有这个前提，后面所有资源扫描和工具升级都失去顺序。

USE 不是答案，它负责先把战场切开

很多人读《性能之巅》会先记住 USE。利用率、饱和度、错误，的确是 Gregg 最稳定的一把起手刀。

但 USE 的作用不是直接给根因，而是先把战场切开。CPU、内存、磁盘、网络逐项过，把还不像问题的资源先排掉，把最先开始排队、失败或异常的资源域挑出来。

这也是 USE 在全书里最关键的位置。它不深，但它防漏。性能现场最怕一开始就押注最熟的方向。USE 的价值恰好在于，用一轮广度扫描把“我觉得”压回“我先过一遍”。

如果只把 USE 当成一个检查表，就会低估它。Gregg 借这一步交付的，是一种纪律：先做全局分流，再决定局部深挖。

真正拉开层次的，是把时间拆成执行和等待

资源域露头之后，书里的方法才开始显出真正锋利的地方。Gregg 不满足于知道“CPU 忙”或“磁盘慢”，他持续追问的是：请求时间到底花去了哪里。

于是主线往下自然进入时间拆解。on-CPU 是线程真正在运行；off-CPU 是线程没跑，但请求还在付出时间成本。锁竞争、I/O 等待、调度延迟、网络阻塞，都从这里显形。

这一步是整套方法的分水岭。很多团队会在资源利用率附近停住，Gregg 则逼你继续问“忙”和“慢”是不是同一回事。它们经常不是。

也因为有了这层拆解，后面工具的角色才清楚。profile 主要服务 on-CPU，等待分析和追踪工具更多服务 off-CPU。没有前面的时间分解，工具切换就只剩经验和偏好。

工具不是并列摆放，而是按证据成本逐级升级

Gregg 留下来的第二条硬方法，是证据升级顺序。

先看 metrics。因为便宜，覆盖广，适合做第一轮排除。再上 profile。因为它能回答时间分布，但还没进入事件细节。最后才是 trace。因为 trace 最接近因果链，也最容易带来开销、噪声和解释负担。

这条顺序看起来像工具分类，实际是方法论的核心约束。越贵的证据，越要晚拿；越重的工具，越要在问题已经收窄后再上。否则排障不是深入，而是过载。

这也是为什么《性能之巅》虽然覆盖 perf、Ftrace、BPF，却没有把它们写成“会这些就够了”的英雄工具。工具服从问题，不能反过来定义问题。

RED、线程状态分析和各资源域章节，都是主线上的支撑件

把全书摊开看，最容易误读的地方，是把 USE、RED、线程状态分析、各资源域分析法看成几套并列方法。

更准确的理解是，它们都在服务同一条主线。RED 保留用户和服务视角，提醒你别只盯底层资源；线程状态分析帮助你在“资源不够异常、延迟却明显变坏”时继续分解时间；CPU、内存、磁盘、网络等章节，则提供每个资源域往下钻时该看什么证据、哪些表象最会骗人。

所以《性能之巅》的方法并不是一个横向罗列的工具箱，而是一条递进路径：先定义问题，再做分流，再拆时间，再按资源域和证据类型往下钻。

一旦按这个角度读，书里各章的关系就清楚了。它们不是彼此竞争，而是在接力。

第二版真正补上的，是“看不全时也要继续收窄”

第二版比第一版更重要的增量，不只是多了云和 BPF，而是把主方法推进到可见性残缺的环境里。

裸机场景里，你往往默认能摸到底层。到了云、容器、托管服务，很多关键证据天然缺席。宿主机不可见，邻居噪声不可见，部分指标被虚拟化包装后才呈现给你。

Gregg 没有因此放弃原来的方法骨架，而是把“先收窄再深挖”继续保住，只是把证据换成边界证据和对照证据。实例对比、可用区对比、版本前后对比、steal time、cgroup 配额，都属于这个补丁。

这说明《性能之巅》的方法不是依赖完美观测条件才成立。它更像一条证据收窄原则：信息再不完整，也先把范围压小，再决定是否升级观测。

最容易失效的地方，是把顺序拆散后各取一段

这套方法最常见的失效方式，不是完全不用，而是只用自己顺手的一段。

有人只记 USE，于是排障永远停在资源清单层。有人只记火焰图，于是所有问题都被翻译成 CPU 热点。有人只记 BPF，于是问题还没定义清楚就先写脚本。还有人只记“要看全链路”，结果在证据不完整的环境里反而走不动。

Gregg 方法真正难的，不是学会其中任何一项，而是守住顺序依赖。先收窄，再深挖；先低成本证据，再高成本证据；先判断时间花在哪，再决定上哪类工具。

顺序一散，整套方法就会退化成熟练工具人的个人手感。

这套方法最适合处理“症状很明显、根因很分散”的现场

《性能之巅》最擅长解决的，是那些用户已经感到慢，但潜在根因横跨应用、内核、硬件和云环境的复杂性能问题。

它特别适合排障、优化、容量判断和性能复盘，因为这些工作都需要一条稳定的收窄路径。只靠局部经验，很容易在复杂系统里绕圈。

边界也同样清楚。如果你的问题主要是纯业务逻辑正确性、算法设计取舍，或完全缺少基本可观测性数据，这本书不能单独替你完成工作。它提供的是系统性能诊断顺序，不是所有技术问题的总方法。

Gregg 最核心的主张，可以压成一句话：性能问题先别急着解释，先把证据按成本和层次排好顺序。顺序立住了，根因才会自己露头。