本页目录
先把“系统慢了”拆开
性能问题不能用“系统慢了”起手。这句话太大，里面混着不同对象、不同指标和不同层次的问题。你不先拆开，后面所有人都会按自己的理解去查，越查越散。
先做的不是找工具，也不是找那个“唯一根因”，而是把主观抱怨压成能继续分析的问题。
真实系统里经常不是一个点坏了，而是几个因素一起叠加。排障起手的目标不是立刻抓凶手，而是先定边界，判断当前最值得继续追的限制因素。
先把主观抱怨压成客观延时
“慢”首先是主观感受。不同人嘴里的“系统慢了”，可能指的是不同接口、不同时间段、不同程度的退化。
所以第一步不是争论感受，而是把它翻译成延时、吞吐、错误率这些可测指标。这里最该优先钉住的是延时，因为延时最接近用户体验，也最适合后面估算修复收益。
如果你连“平时 10ms，现在 100ms”这种量化都没有，后面所有判断都容易失真。你甚至没法判断问题到底有多严重，也没法在修完以后确认收益。
别把“系统慢了”直接翻成资源不够
最常见的错法有五种：
- 还没把问题定义清楚，就直接说“先查 CPU”或“先看数据库”
- 把“系统慢了”当成一个完整问题，而不是待拆解的问题集合
- 觉得必须先把系统看全，才能开始分析
- 把导论当成背景页，直接跳去读 CPU、内存、磁盘、网络
- 看到使用率高就立刻宣布资源不够
这些错法的共同点，是都太早下场，太早选方向。
尤其要防“使用率高 = 性能瓶颈”这个直觉。资源一直很忙，不等于业务已经被它拖慢。真正会伤害延时的，是饱和和排队。忙碌只是线索，排队才更接近结论。
以后遇到“系统慢了”，先做这 4 步
先做下面这 4 步，不要抢答。
1. 先说清症状边界
至少先说清这几个边界：
- 慢的是谁：接口、任务、页面、请求、批处理，还是某一类操作
- 慢成什么样：平均值升高、尾延时恶化、吞吐下降，还是错误率上升
- 影响多大：单实例、局部流量，还是整体退化
- 从什么时候开始：突然出现、周期抖动，还是逐步变坏
还要补一条纪律：别只说“大家都觉得慢”。先把主观抱怨客观化，优先写出延时变化。只要这一步还说不清，就不要急着选方向。
2. 再拿一轮最小快照
这里不用追求“数据越多越好”。够支撑下一步判断就行。
至少包括：
- 当前症状的时间范围
- 受影响对象和范围
- 最显眼的资源域异常
- 前后差异：变更、版本、流量、环境
- 运行环境边界：裸机、虚拟机、容器、托管平台
这里的快照，不是重武器，不是 tracing，也不是先把全系统抓一遍。
起手应该是轻量级、低干扰、系统自带的那类检查动作。原书给出的意思很明确：先用一轮便宜、快速、足够广的观察拿到大盘线索，再决定要不要继续上更重的工具。
拿完这轮快照，你至少要知道问题大概落在哪、影响到哪、边界有多大。
3. 再决定先往哪层走
拿到问题定义和最小快照以后，才开始做第一轮方向判断。
这时候先问下面这几件事：
- 这更像工作负载变了，还是资源约束变了
- 这更像运行变长，还是等待变长，还是排队变长
- 这更像整体问题，还是局部路径问题
- 这更像应用问题，还是系统问题，还是环境边界问题
这里可以把两个视角分清。
工作负载视角是自上而下看请求、延时和流量形状，回答“业务到底在施加什么压力”。资源视角是自底向上看 CPU、内存、磁盘和网络，回答“底层到底有没有在排队、报错或顶满”。复杂问题往往要两边一起看，不能只让开发和运维各说各话。
第一轮方向站住了，后面再下钻才不会乱。
4. 最后才决定上什么工具
重型工具不是起手动作。工具是补证手段。
问题还没定义清楚时，工具越重，噪声往往越大。轻量快照可以尽早上，但剖析、跟踪这类更重的工具，应该留给问题已经收缩到足够具体的时候。
忙碌不等于已经形成约束
第 1 章虽然是导论，但已经在拦一个后面会反复出现的误判：高使用率不等于性能已经恶化。
如果一个资源只是一直在忙，但还能持续处理工作，它未必就是当前瓶颈。真正更值得找的，是饱和和排队，也就是新的工作已经进不去了，只能在那儿等。
以后你再看到 CPU、磁盘、网络某个指标很高，先别宣布根因。先追问：有没有排队证据，延时是不是因此变长，等待是不是已经变成了主要损耗。
视角受限时，继续靠边界证据推进
- 接受你看不全，这不是例外，是现代环境的常态
- 不再依赖“我必须拿到底层全量指标”这个前提
- 优先保留边界证据：实例间差异、可用区差异、版本前后差异、流量分布差异
- 把环境约束本身当成分析对象：配额、邻居干扰、宿主共享、托管限制
- 用对照和变化继续推进，而不是等全视角到齐
记住这句就够了：视角受限时，分析方法也要跟着变。
先把对象、范围和快照固定住
先把“慢”的对象、表现、范围、起点说清
先按这个顺序走：
- 把“慢”的对象、表现、范围、起点说清。
- 把主观抱怨压成延时、吞吐、错误率这类客观指标。
- 拿一轮最小快照，先看时间范围、影响范围、显眼异常和前后变化。
- 判断先往哪层走，不要抢着进自己最熟的资源域。
- 方向缩小后，再决定工具。
快照里至少放这 6 项
快照里至少要有这些：
- 时间范围
- 受影响对象
- 影响范围
- 最显眼异常
- 版本、流量、配置或环境变化
- 当前运行环境边界
先把这三条纪律钉住
- 问题没说清前，不选资源域。
- 快照没拿到前，不下重结论。
- 方向没缩小前，不上重工具。
什么时候该停
性能分析可以一直往下钻，但不是每次都值得。
至少有三种情况该停下来：
- 你已经解释了大部分延时损耗，继续下钻只会换来更细的细节，不会显著改变动作。
- 继续分析的工程成本已经高过可能带来的收益。
- 现场还有别的限制因素，投资回报率比当前这个问题更高。
能停下来，不是偷懒，而是在用工程收益而不是技术好奇心做排序。
问题说清以后，再决定往哪一层收缩
第 1 章把问题语言和起手纪律立住。第 2 章接着回答的，才是：问题定义以后，应该按什么顺序继续收缩问题空间，什么时候做分流，什么时候换证据，什么时候继续下钻。