探求规律

如果没头绪，那就试试总结规律吧！

比如

• 有一堆服务器做负载均衡，出问题时可分析监控和日志看请求是否是均匀分布的，可能问题都集中在某个机器节点上
• 应用日志一般会记录线程名称，出问题时可分析日志是否集中在某类线程
• 若发现应用开启大量TCP连接，通过netstat可分析出主要集中连接到哪个服务

探求到了规律，就很容易突破了。

调用拓扑

比如看到Nginx返回502，一般可认为是下游服务的问题导致网关无法完成请求转发。

对于下游服务，不能想当然就认为是我们的Java程序，比如在拓扑上可能Nginx代理的是Kubernetes的Traefik Ingress，链路是Nginx->Traefik->应用，如果一味排查Java程序的健康，则始终找不到根因。

有时虽然使用了Feign进行服务调用，出现连接超时也不一定就是服务端问题，有可能是客户端通过URL调用服务端，并非通过Eureka的服务发现实现的客户端负载均衡。即客户端连接的是Nginx代理而非直接连接应用，客户端连接服务出现的超时，其实是Nginx代理宕机所致。

资源限制

观察各种监控指标，如果发现曲线慢慢上升然后稳定在一个水平线，一般就是资源达到瓶颈。

观察网络带宽曲线时，如果带宽上升到120MB左右不动了，很可能就是打满了1GB的网卡或传输带宽

观察到数据库活跃连接数上升到10个不动了，很可能是连接池打满了

观察监控一旦看到任何这样曲线，都要引起重视。

连锁反应

CPU、内存、IO和网络相辅相成，一个资源出现瓶颈，很可能同时引起其他资源连锁反应。

内存泄露后对象无法回收会造成大量Full GC，CPU会大量消耗在GC从而引起CPU使用增加

经常会把数据缓存在内存队列进行异步IO，网络或磁盘出现问题时，就很可能会引起内存暴涨。

所以出问题时，要综合考虑避免误判

客户端or服务端or传输问题？

比如MySQL访问慢了，可能：

• 客户端原因，连接池不够导致连接获取慢、GC停顿、CPU占满
• 传输过程问题
  包括光纤可能被挖断了呀、防火墙、路由表等设置有问题
• 真的服务端背锅了

这都需要逐一排查区分。

服务端慢一般可以看到MySQL出慢日志，传输慢一般可以通过ping来简单定位，排除了这两个可能，并且仅仅是部分客户端出现访问慢的情况，就需要怀疑是客户端本身的问题。对于第三方系统、服务或存储访问出现慢的情况，不能完全假设是服务端的问题。

第七，快照类工具和趋势类工具需要结合使用。比如，jstat、top、各种监控曲线是趋势类工具，可以让我们观察各个指标的变化情况，定位大概的问题点；而jstack和分析堆快照的MAT是快照类工具，用于详细分析某一时刻应用程序某一个点的细节。

一般情况下，我们会先使用趋势类工具来总结规律，再使用快照类工具来分析问题。如果反过来可能就会误判，因为快照类工具反映的只是一个瞬间程序的情况，不能仅仅通过分析单一快照得出结论，如果缺少趋势类工具的帮助，那至少也要提取多个快照来对比。

第八，不要轻易怀疑监控。我曾看过一个空难事故的分析，飞行员在空中发现仪表显示飞机所有油箱都处于缺油的状态，他第一时间的怀疑是油表出现故障了，始终不愿意相信是真的缺油，结果飞行不久后引擎就断油熄火了。同样地，在应用出现问题时，我们会查看各种监控系统，但有些时候我们宁愿相信自己的经验，也不相信监控图表的显示。这可能会导致我们完全朝着错误的方向来排查问题。

如果你真的怀疑是监控系统有问题，可以看一下这套监控系统对于不出问题的应用显示是否正常，如果正常那就应该相信监控而不是自己的经验。

第九，如果因为监控缺失等原因无法定位到根因的话，相同问题就有再出现的风险，需要做好三项工作：

做好日志、监控和快照补漏工作，下次遇到问题时可以定位根因；

针对问题的症状做好实时报警，确保出现问题后可以第一时间发现；

考虑做一套热备的方案，出现问题后可以第一时间切换到热备系统快速解决问题，同时又可以保留老系统的现场。

总结

分析问题必须讲理

靠猜是猜不出来的，需要提前做好基础监控的建设。监控的话，需要在基础运维层、应用层、业务层等多个层次进行。定位问题的时候，我们同样需要参照多个监控层的指标表现综合分析。

定位问题要先对原因进行大致分类

比如是内部问题还是外部问题、CPU相关问题还是内存相关问题、仅仅是A接口的问题还是整个应用的问题，然后再去进一步细化探索，一定是从大到小来思考问题；在追查问题遇到瓶颈的时候，我们可以先退出细节，再从大的方面捋一下涉及的点，再重新来看问题。

经验很重要

遇到重大问题的时候，往往也需要根据直觉来第一时间找到最有可能的点，这里甚至有运气成分。我还和你分享了我的九条经验，建议你在平时解决问题的时候多思考、多总结，提炼出更多自己分析问题的套路和拿手工具。

定位到问题原因后，要做好复盘回溯。每次故障的解决都是宝贵经验，复盘不止是记录问题，更是为了架构优化。

复盘可重点关注如下：

• 记录完整的时间线、处理措施、上报流程等信息
• 分析问题的根本原因
• 给出短、中、长期改进方案，包括但不限于代码改动、SOP、流程，并记录跟踪每一个方案进行闭环
• 定期组织团队回顾过去的故障