事件/故障处理应该要有什么思路 导读：在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子)：业务人员反映呼叫中心系统运行缓慢,部份电话在自助语言环节系统处理超时,话务转人工座席，人工座席出现爆线情况。运维人员开始忙活了，查资源使用情况、查服务就是否正常、查日志就是否报错、查交易量还有没有……时间不知不觉得在敲键盘、敲键盘、敲键盘中过去，但就是原因还未定位。经理过来了解情况：“系统恢复了吗?”、“故障影响就是什么？”、“交易中断了吗？”……运维人员赶紧敲键盘，写 sql,瞧交易量；敲键盘，写命令,瞧系统资源、情况……最终,定位到问题原因就是其中一个功能没有控制返回数量，导致内存泄露。针对这个故障，业务希望运维能否更快得解决故障得恢复,经理希望制定优化呼叫中心故障处理流程，做了以下几件事：1. 优先故障处理过程得时间——”能通过鼠标完成得工作,不要用键盘“2. 提前发现故障，加强监控-—“技术早于业务发现问题,监控不仅就是报警,还要协助故障定位”3. 完善故障应急方案——“应急方案就是最新得、准确得、简单明了得"4. 长远目标:故障自愈—-”能固化得操作自动化，能机器做得让机器做“下面将从故障常见得处理方法开始介绍,再从故障前得准备工作（完善监控、制定应急方案等方式)来解决经理提出得问题,并提出未来解决故障得想法。1、常见得方法：1)确定故障现象并初判问题影响在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案得制定，这依赖于运维人员需要对应用系统得整体功能有一定得熟悉程度。确认了故障现象后，才能指导运维人员初推断故障影响。2）应急恢复运维最基本得指标就就是系统可用性，应急恢复得时效性就是系统可用性得关键指标。有了上述故障现象与影响得推断后,就可以制定故障应急操作，故障应急有很多,比如:服务整体性能下降或异常，可以考虑重启服务；应用做过变更，可以考虑就是否需要回切变更；资源不足,可以考虑应急扩容；应用性能问题，可以考虑调整应用参数、日志参数；数据库繁忙，可以考虑通过数据库快照分析,优化 SQL;应用功能设计有误,可以考虑紧急关闭功能菜单；还有很多……另外，需要补充得就是，在故障应急前，在有条件得情况需要保存当前系统场景,比如在杀进程前，可以先抓个 CORE 文件或数据库快照文件。３)快速定位故障原因就是否为偶发性、就是否可重现故障现象就是否可以重现,对于快速解决...
