本页目录
最有效的场景
系统级性能诊断。 延迟升高、吞吐下降、资源饱和、排队堆积——问题表现在 CPU、内存、磁盘、网络这些资源域上时，USE + drill-down + 延迟分析的组合覆盖能力最强。
单机和小集群排障。 Gregg 的方法在单机、虚拟机、容器实例这个粒度上设计得最精细。工具链（perf、BPF、Ftrace）也主要面向这个层级。
有系统背景的工程师。 方法默认你知道什么是上下文切换、页表、I/O 调度、TCP 状态机。没有这些背景，方法能理解但用不起来。
需要因果解释的问题。 如果目标只是"先顶住"，直接加缓存、扩容、限流可能更快。USE 和 drill-down 的价值在于提供根因解释，适合需要沉淀方法的团队。
效果打折扣的场景
纯业务逻辑问题。 转化率低、推荐结果不准、支付成功率下降——瓶颈不在系统资源域，USE 扫完会发现所有资源都正常。需要业务指标分析和链路追踪。
大规模分布式的跨服务因果。 Gregg 的方法在单节点内部很强。跨服务调用链的因果推断需要分布式 tracing（Jaeger、Zipkin、OpenTelemetry）。USE 在这个尺度上只能告诉你每个节点的资源状况，串不成跨服务因果。
前端和客户端性能。 页面加载慢、渲染卡顿、首屏时间长——工具链和分析框架完全不同（Chrome DevTools、Lighthouse、Core Web Vitals）。Gregg 的方法面向服务端和操作系统层。
纯配置或架构问题。 数据库索引缺失、连接池配错、超时设置不合理——USE 可以看到症状（饱和度高、延迟升），但根因在配置层。drill-down 能帮你看到"连接池满了"，但"应该配多大"是架构决策。
和相邻方法体系的边界
| 问题类型 | 优先方法 | Gregg 方法的角色 |
|---|---|---|
| 单机 CPU / 内存 / 磁盘 / 网络瓶颈 | USE + drill-down + 延迟分析 | 主力 |
| 服务健康快速判断 | RED | 配合 USE 定位根因 |
| 跨服务调用链延迟 | 分布式 tracing | 在单节点内提供补充 |
| 前端性能 | 浏览器工具链 | 不适用 |
| 容量规划 | 工作负载特征化 + USE baseline | 辅助 |
| SLO / SLI 监控 | SLO 框架 + RED | 不直接覆盖 |
读成工具目录，方法反而进不来
看到 perf、ftrace、BPF、火焰图，就开始忙着记命令、记选项。表面上很努力，脑子里留下的只有工具名，缺一条分析链把它们串起来。
判断标准：读完一章，复述自然落在"这一章列了哪些工具"还是"这一章怎样从症状走到判断"。如果是前者，纠偏动作是每章先写一句——这一章主要补的是哪一种可见性缺口。
盯住最热的点就开修
看到热点、忙点、异常点，立刻当成根因。这种错误在会用 profile 和火焰图的人身上尤其常见，因为工具给出的视觉冲击太强，容易产生"已经看到真相"的错觉。
热点只说明"这里最活跃"，并不自动说明"这里最限制系统"。分析需要继续追问：它为什么热？是等待扩散的结果吗？和外部依赖是什么关系？把热点放回队列、等待、负载和上下文里解释，才能接近根因。
云环境看不全就放弃分析
看不到宿主机、看不到平台内部实现、看不到托管服务深层状态，于是所有问题都被"云上就是这样"打发掉。
只要你还能看到边界指标、对比不同实例、分析尾延迟分布、观察重传和配额变化，搜索空间就还在缩小。自检问题：你是真的没数据，还是因为数据不完整就停了？
一次优化见效就结案
调了参数、换了配置、加了缓存，指标确实好了，事件就结束了。没有解释链的成功很难复用——下次换一个系统、一个版本、一个负载形态，团队还是会从头猜。
每次优化至少留下最小因果说明：解除的瓶颈是什么，为什么这个改动应该有效，它是否只是掩盖了别的约束。
把 USE 当日常监控框架
USE 设计用来排障，不适合做日常 dashboard。日常监控更适合 RED + SLO/SLI 体系。USE 的价值在排障起手阶段。
火焰图只看 on-CPU
火焰图只覆盖 on-CPU 时间分布。off-CPU 问题、I/O 延迟、网络等待都需要别的工具。只用火焰图做诊断，会系统性地遗漏等待类问题。