本页目录

把排障顺序和证据意识迁到系统之外

迁移一：把它用到线上故障分析，而不只用于“性能专项”

很多线上故障表面上是可用性问题，底层其实是性能链先出问题，比如队列积压、线程池耗尽、下游超时扩散、锁争用引发级联等待。把排障分析方法迁进来，变化在于你不再只问“哪里报错了”，而会先问“哪个等待或饱和先开始扩散”。

没用这套方法时，故障分析容易停在日志关键词和错误码；用了以后，会更自然地去补延迟、队列、资源边界和前后对比这几类视角。

容量规划最常见的问题，是只看平均资源利用率，不看尾部、排队和约束变化。将性能分析迁到容量场景里，关键变化是从“现在平均用了多少”转向“哪个资源在峰值和异常情况下最先失去余量”。

这会让容量评估更像性能诊断的延伸，而不是静态预算表。你会更关注工作负载形态、峰值路径、队列增长、饱和点和验证性压测。

很多团队做可观测性，容易先堆指标、堆日志、堆 tracing，再慢慢发现真正问题不是“数据少”，而是关键路径仍然看不清。把性能分析方法迁进来，等于先问: 我们到底缺哪一种可见性，缺了它会让什么问题始终无法解释？

这样做出来的可观测性，不是更大的数据仓库，而是更贴近真实诊断链的观测设计。哪些指标必须按分布看，哪些地方必须能看等待，哪些组件要补 profile 或 trace，优先级会更清楚。

数据库查询变慢、批处理拖长、流式管道延迟上升，本质上也常常是工作负载、资源约束、排队和等待的问题，只是对象从系统调用和线程，换成了执行计划、连接池、磁盘、网络和下游依赖。

迁移后的具体做法，是保留《性能之巅》的分析顺序，替换掉具体对象。你仍然先定义症状、建立上下文、找约束、补视角、做验证，只是观测对象从内核路径换成了 SQL、任务队列、执行阶段和数据分区。

AI 推理和训练平台也越来越像性能系统工程问题: 请求排队、GPU/CPU 协同、I/O 吞吐、模型加载、缓存命中、网络传输和多租户争用同时存在。直接照搬旧的业务监控往往不够，因为它解释不了“为什么这轮延迟突然坏掉”。

将分析方法迁到这里后，那套缩小搜索空间的方法。对于 AI 基础设施，这种方法比背更多监控项更耐用。