本页目录

三个月后再遇到慢请求，你还会不会先乱翻工具

真正看出《性能之巅》有没有进入工作流，不是背出多少术语，而是故障再来一次时，你第一反应有没有变。

请求突然变慢时，你先写问题，还是先点面板

回想最近一次性能告警。你接手后的第一个动作是什么？

如果你先开熟悉的 dashboard，或者直接跑最顺手的命令，说明动作还停在经验反射。Gregg 想改掉的，正是这种先开查、后定义的问题习惯。

如果你会先写下谁在变慢、哪类请求在变慢、从什么时候开始、影响范围有多大，说明起手顺序已经开始变化。那张问题定义，不只是记录，它会替你挡掉大量看似相关的噪声。

性能现场最容易卡在这里：系统确实慢了，但 CPU、内存、磁盘看起来都不够夸张。

如果你到这一步就开始换着工具乱试，说明你还在等某个自动跳出来的答案。Gregg 的方法进入动作后，你会先问另一件事：时间到底花在执行，还是花在等待。

下次再遇到这种局面，看看自己会不会主动说出 on-CPU 和 off-CPU。能自然说出来，说明延迟分解已经开始变成默认动作；说不出来，排障还容易停在表象层。

高峰期一来，很多人的第一反应是扩容，或者盯住利用率最高的资源。

如果你已经被 Gregg 改过，脑子里会先冒出另一个问题：谁先开始排队了。利用率高不高要看，饱和度更要看。run queue、队列深度、延迟分布这些信号，才更接近系统开始失控的那一刻。

判断有没有内化，不用做考试题。只看你上次高峰抖动时，有没有主动补一轮“饱和度”检查。没有这一步，USE 还只是你听过的缩写，不是你真的在用的起手式。

工具用得多，不代表方法已经进入工作流。真正的分水岭，是开工具前能不能先说清问题。

如果你上 perf，只因为“这次想把火焰图拉出来看看”，那还是工具牵着问题跑。Gregg 的顺序应该反过来：先确认自己缺的是 CPU 时间分布、等待原因，还是事件顺序，然后再选 profile、等待分析或 tracing。

下次打开重工具前，试着先写一句理由。写得出“我缺的是哪类证据”，说明工具已经回到方法里；写不出来，说明熟练度还没有转成判断力。

云环境最容易暴露方法有没有真的学进去。很多人一旦拿不到宿主机视角，就开始等更多权限、更多日志、更多别人的协助。

这不一定错，但如果每次都停在这里，说明你还在用裸机思路要求云环境。Gregg 第二版真正补上的，是信息残缺时也继续收窄的能力。

所以下次云上抖动出现时，看看自己会不会主动做实例对比、可用区对比、版本前后对比，或者去看 steal time、配额边界。会这样做，说明你已经接受“看不全”是常态；不会这样做，就还没有把云上那一层方法接上。

很多团队在这里掉链子。问题压下去了，延迟也降了，复盘却只剩一句“优化后快了 40%”。

如果你的文档里只有结果，没有 before/after、关键证据、约束定位和验证方式，那这次成功很难复用。下一次碰到相似问题，团队还是得重新猜。

Gregg 真正想留下来的，不是一份成绩单，而是一条别人能接着走的路径。你最近一次复盘，能不能让没参与过的人看完后知道下次该怎么查？能的话，方法才算沉淀下来。

最后这条最直接。回想最近三次性能问题，你最自然的起手动作是什么。

如果还是“先猜一个最像的方向”，然后去找证据证明它，说明老习惯还在主导。Gregg 的方法真正进到日常以后，第一反应会从猜测变成收窄：先定义问题，再做分流，再拆时间，再升级证据。

动作顺序一旦变了，你会明显感觉排障没那么靠运气。那时就知道，《性能之巅》不是停在书架上，而是已经进了你的手。