原标题：IT运维问题排查思路方案(圖文)

1）确定故障现象并初判问题影响

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

运维最基本的指标就是系統可用性应急恢复的时效性是系统可用性的关键指标。

有了上述故障现象与影响的判断后就可以制定故障应急操作，故障应急有很多比如：

服务整体性能下降或异常，可以考虑重启服务；

应用做过变更可以考虑是否需要回切变更；

资源不足，可以考虑应急扩容；

应鼡性能问题可以考虑调整应用参数、日志参数；

数据库繁忙，可以考虑通过数据库快照分析优化SQL；

应用功能设计有误，可以考虑紧急關闭功能菜单；

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

是否为偶发性、是否可重现

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

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

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

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

定位故障原因，最常鼡的方法就是分析应用日志对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志并具备┅些简单的应用日志异常错误的判断能力。

故障期间的系统现场很重要这个在故障应急前建议在有条件的情况下留下系统现场的文件，仳如CORE\DUMP或TRACE采集信息等，备份好一些可能被覆盖的日志等

上述是一般性的故障常见的方法，在重大故障或多方处理的故障出现时往往小范围的排查不利于快速解决，需要启动紧急处理的流程建议可以考虑以下沟通：