运维问题排查思路

运维问题排查思路

1、常见的方法：

1）确定故障现象并初判问题影响
在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。确认了故障现象后，才能指导运维人员初判断故障影响。

2）应急恢复
运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。
有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：

服务整体性能下降或异常，可以考虑重启服务；
应用做过变更，可以考虑是否需要回切变更；
资源不足，可以考虑应急扩容；
应用性能问题，可以考虑调整应用参数、日志参数；
数据库繁忙，可以考虑通过数据库快照分析，优化SQL；
应用功能设计有误，可以考虑紧急关闭功能菜单；
还有很多……

另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在结算进程前，可以先抓个CORE文件或数据库快照文件。

3）快速定位故障原因
是否为偶发性、是否可重现
故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。

是否进行过相关变更
大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

是否可缩小范围
一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

关联方配合分析问题
与第（3）点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

是否有足够的日志
定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，