IT 运维中的事件、故障排查处理思路

在讲解事件、故障处理思路前，先讲一个故障场景（以呼叫中心系统作为一例子）：

业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。

运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。

经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？”……

运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况……

最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。

针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事：

1、优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“

2、提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”

3、完善故障应急方案——“应急方案是最新的、准确的、简单明了的”

4、长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做“

下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。

1、常见的方法：

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

在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。

确认了故障现象后，才能指导运维人员初判断故障影响。

2）应急恢复

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

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

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

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

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

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

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

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

还有很多……

另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CO