告警刚响，排查很容易被监控页面上最显眼的那条曲线带着走。看到 CPU 高就抓线程栈，看到 Full GC 就查堆，发布刚结束就准备回滚。可这些现象经常互相传导：慢 SQL 会占住数据库连接，连接池等待又会拖住业务线程，最后可能同时看到延迟、错误率和 CPU 上升。单看其中一项，很难定根因。

故障还在扩大时，先按预案控制影响。实例还有余量，确认取证不会继续压垮服务后，再保存日志、Trace、线程栈和内存信息。重启往往能暂时恢复，但也会清掉现场；为了抓取 Heap Dump 一直让异常实例承载流量，同样可能把问题拖大。现场情况决定先摘流量、回滚，还是先取证。

下面只讨论 Java 应用侧的常见问题。如果证据已经指向容器调度、内核、网络设备或云平台，需要转到相应平台的监控和操作手册继续排查，这里不展开。