运维故障处理思路

事件/故障处理应该要有什么思路导读：在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子）：业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有……时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？”……运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况……最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事：优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”完善故障应急方案——“应急方案是最新的、准确的、简单明了的”长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做“下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。1、常见的方法：1）确定故障现象并初判问题影响在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。确认了故障现象后，才能指导运维人员初判断故障影响。2）应急恢复运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：服务整体性能下降或异常，可以考虑重启服务；应用做过变更，可以考虑是否需要回切变更；资源不足，可以考虑应急扩容；应用性能问题，可以考虑调整应用参数、日志参数；数据库繁忙，可以考虑通过数据库快照分析，优化SQL；应用功能设计有误，可以考虑紧急关闭功能菜单；还有很多……另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CORE文件或数据库快照文件。3）快速定位故障原因是否为偶发性、是否可重现故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。是否进行过相关变更大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。是否可缩小范围一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。关联方配合分析问题1）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；2）应急方案过于追求大而全，导致不利于阅读与使用；3）应急方案形式大于实际使用效果，方案针对性不强；4）只关注应急方案的内容，但没有关注运维人员对方案的理解；针对上述常见问题，我认为应急方案需要做到以下几点：1）内容精&简很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以我认为应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是我觉得应用系统应急方案应该有的内容：（1）系统级：能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。（2）服务级：能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。（3）交易级：能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。（4）辅助工具的使用：有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。（5）沟通方案：沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。（6）其它：上述5点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。2）应急方案是一项持续的工作有了应急方案，如何让运维人员持续去更新是难点。我认为要解决这个难点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。3）关注运维人员对应用关键信息的认识前两点关注了手册，最后一点我觉得有必要关注使用这个手册的人。有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻，所以应用运维人员在故障处理过程中的地位很尴尬，运维人员掌握操作权，但却不知道应该操作什么。对此，我认同应用运维人员不需要掌握应用系统的业务功能，但我觉得就对应用系统本身来讲应用运维人员需要具备以下最基本的能力：（1）知道应用系统这个是干什么的，基本的业务是什么；（2）知道应用架构部署、上下游系统逻辑关系；（3）知道应用下的服务的作用、端口、服务级的应急处理，日志等数据信息如何找到并简单定位。（4）知道应用系统重要的时间点及任务，比