最快速生产问题排查要义

业务反馈功能响应变慢？

收到服务平均响应超时告警？

接口响应错误率激增？

 

 

0.确定实时变化

是否有大流量冲击？

是否最近上线发布，配置变更，依赖升级？

是否有服务节点或组件节点有异常？

 

 

1.哪些检查项

检查流量

检查异常告警

检查服务各指标，jvm各指标，服务网络情况

检查依赖组件情况。(mysql死锁，redis大key， mq消息堆积)

排查日志

 

 

2.确认范围

根据就ARM确定请求链路中，定位哪个服务应用响应慢。

 

是应用所有接口响应慢，还是特定接口响应慢。

是应用执行逻辑慢，还是依赖的mysql、redis、ES等组件响应慢。

服务节点的各项指标如何，cpu，内存，连接数，IO情况。

jvm各项指标如何，堆空间，线程数，锁情况， GC情况。

 

 

 

3.精准定位

如果所有接口都慢，大概率节点cpu，内存或者jvm等指标有异常导致整体服务响应性能下降。

如果单个接口慢，可能依赖服务/组件响应慢，或异常逻辑导致。

 

分析接口具体逻辑，排除依赖服务接口响应慢，排除依赖组件异常，排除逻辑问题(死锁，死循环，慢查询)，

结合日志 + APM + jstat等工具分析，最终定位并解决问题。

 

 

最后，记住一个原则：优先恢复，再找根因。

如果是慢 SQL，先 kill 掉慢查询，临时索引或重启服务；如果是连接池满，临时扩大连接数；如果是 GC 频繁，先 dump 堆内存，必要时加内存或回滚版本。恢复业务优先，根因分析可以后做。”