工具能给出几百个数字，却不会自动告诉你哪个数字重要。本章解决的是“下一步查什么”：先统一术语与测量边界，再用方法覆盖资源、服务和工作负载，最后以假设和证据收敛。方法的价值在于减少遗漏和随机试错，同时允许你明确记录“已经排除什么、仍有哪些未知”。

一次好调查不一定立刻找到根因，但每项测试都应让可能性空间变小。例如，跟踪发现文件系统等待只占慢查询总时间的 5%，这没有解决问题，却足以排除一个大型分支，比继续调磁盘参数更有价值。

1. 先定义再测量。 延时、响应时间、吞吐量、使用率和饱和度必须带对象、边界、单位与时间区间。
2. USE 看资源，RED 看服务。 USE 检查使用率、饱和度、错误；RED 检查请求率、错误、持续时间，二者互补。
3. 假设必须能预测结果。 科学法不是“我觉得是磁盘”，而是说明若磁盘负责，哪项同步等待会增加，并设计测试证伪。
4. 分布比单一平均数更接近真实。 百分位数、直方图、热图能暴露尾部、多模态和异常值，但 p99 也不能代替完整分布。
5. 基线让数字有上下文。 同机历史、同版本对照、同星期同时间段，通常比脱离环境的“标准阈值”更可靠。

到达的工作 λ → [等待队列] → 服务资源 μ → 完成
                    ↑ 饱和度      ↑ 使用率/错误

服务视角：Rate（请求率） / Errors（错误） / Duration（持续时间）
资源视角：Utilization（使用率） / Saturation（饱和度） / Errors（错误）

• IOPS 是每秒 I/O 操作数；吞吐量可指每秒操作数，也可指字节/比特速率，必须说明对象。
• 响应时间通常包含排队、服务及返回结果的时间；延时有时只指等待，有时指完整操作时间，所以必须加限定词。
• 使用率可能指繁忙时间比例 U = B / T，容量资源又常按已用容量表示。100% 忙碌并不必然等于已经用尽最大吞吐能力。
• 饱和度意味着额外工作开始等待或被拒绝。任何非零等待都值得与业务延时一起评估。
• 稳态排队系统可用 Little 定律 L = λW 理解：系统中平均任务数等于到达率乘平均停留时间。它是关系式，不是对突发流量的万能预测。

1. 问题陈述：是什么变慢、此前是否正常、何时开始、最近改了什么、影响谁、环境与版本是什么。
2. 先做 RED：请求率是否变了？错误是否增加？持续时间的中位数和尾部是否同时变差？这一步先判断负载变化还是服务内部退化。
3. 遍历 USE：画出 CPU、内存、网卡、存储设备、控制器与互联；逐项先查错误，再查饱和度，最后查使用率，并记录暂时测不到的“已知未知”。
4. 归纳工作负载：确认是谁产生、为何产生、类型/方向/尺寸、速率和随时间变化。消除不必要的工作通常是收益最大的优化。
5. 延时向下钻取：将端到端时间拆成 on-CPU 与 off-CPU，再把主要等待拆成锁、文件系统、磁盘、网络等，持续追踪最大部分。
6. 科学法循环：提出假设，写出可观察的预测，只改变一个因素或做只读观测，分析结果；实验未验证时恢复改动。
7. 与基线比较：选择相同负载阶段和聚合周期，做修复前后或正常/异常窗口对比；修复后用原指标复验。

这些命令只读取状态，适合作为方法的证据入口：

uptime
vmstat 1 5
iostat -xz 1 5
sar -q 1 5
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

vmstat 和 iostat 的第一行在很多版本中是自启动以来的汇总，当前行为看后续行。PSI 需要内核配置支持；不存在 /proc/pressure 不代表系统没有压力，只代表该接口不可用。sar、iostat 来自 sysstat，选项会随版本有差异。采集基线时还应保存主机、内核、应用版本和采样周期，否则以后很难做有效对比。

• RED 中请求率稳定、持续时间升高，更像服务或依赖退化；二者同时升高，则先调查负载来源与类型变化。
• USE 中高使用率只是筛选信号；队列长度、调度延时、PSI 或拒绝事件才更直接地表示资源无法及时服务。
• CPU 的低整体均值可能掩盖单核、容器配额或亚秒级饱和；必须匹配业务故障的时间粒度。
• 平均延时 3 ms 可能由“缓存命中约 0.5 ms”和“缓存未命中约 8 ms”混合而成，平均值可能落在几乎从未发生的位置。
• p99 表示 99% 样本不超过该值，并不说明最慢 1% 的形状；稀少异常值还可能落在 p99 之外。
• 两条时间序列一起变化只能产生假设。要证明因果，需要同步路径证据、代码/栈上下文或受控实验。

1. 街灯式调查：只看现成仪表盘能照到的区域，把没有指标误当成没有问题。
2. 工具驱动：按熟悉程度轮番运行命令，没有问题模型，最后得到一堆互相重复的数字。
3. 万能阈值：把“60% 就危险”当硬规则。资源并行能力、突发性和业务目标不同，阈值只能触发调查。
4. 只看 p99：尾部仍可能多模态，且低频严重异常不会稳定进入 p99。
5. 一次改多个变量：即使性能改善，也无法知道哪个改动有效，回退风险随之增加。
6. 把异步工作计入请求关键路径：后台回写可能增加系统负载，却不一定直接构成当前请求等待时间。

1. 分别为 CPU、内存和网卡写出一个 USE 饱和度指标。
2. 某接口请求率不变、p95 上升、错误率不变，你会提出哪两个可证伪假设？
3. 为什么“CPU 平均使用率 70%”不能排除短时 CPU 饱和？
4. 用一句话解释 p99 与完整延时直方图的差别。
5. 说出科学法的五步，并说明实验失败后为什么要恢复改动。

方法把性能分析从“会用命令”提升为“会选择证据”。RED 快速定位用户可见的服务退化，USE 系统覆盖资源瓶颈，工作负载归纳区分负载与架构问题，延时分析沿关键路径向下拆分；科学法负责证伪，基线和分布负责提供上下文。调查的产物不仅是结论，还应包括可复现的测量条件和被排除的方向。