在讲解事件和排查思路之前，先说一个故障场景（以呼叫中心系统为例）：业务人员反映呼叫中心系统运行缓慢，部分呼叫在自助语言链接中超时，呼叫转给人工座席，人工座席断线。运维人员开始忙碌起来，查看资源使用情况，查看服务是否正常，查看日志是否报错，查看交易量是否还在……时间不知不觉的敲着、敲着、敲着，但原因仍未定位。经理来了解情况：“系统恢复了吗？”、“故障有什么影响？”、“交易中断了吗？”……运维人员急忙敲键盘，写SQL，并查看交易量；敲键盘，写命令，看系统资源和情况……最后定位到问题原因是因为其中一个函数没有控制返回的个数，导致内存泄漏。针对该故障，业务希望运维能够更快的解决故障恢复。经理希望制定和优化呼叫中心的故障处理流程。不使用键盘“提前发现故障，加强监控：”技术比业务更早发现问题，监控不仅是报警，还能辅助故障定位“完善的故障应急预案：”应急预案是最新的，准确、简单、清晰”长期目标：故障自愈：“可以固化的运行自动化，让机器做机器能做的事。”下面将从常见的故障处理方法入手，以及然后从故障前的准备工作（完善监控、制定应急预案等）解决管理者提出的问题，并提出以后的故障排除思路1、常用方法1）判断故障现象，初步判断对故障的影响问题。在处理故障之前，运维人员首先要了解故障现象。对整体功能有一定的熟悉程度。只有在确认故障现象后引导运维人员判断故障影响。2）应急恢复运维最基本的指标是系统可用性，而应急恢复的及时性是系统可用性的关键指标。对上述故障现象及影响进行判断后，即可制定故障应急措施。故障突发情况有很多，比如：服务整体性能下降或异常，可以考虑重启服务；资源不足，可以考虑紧急扩容；应用性能问题，可以考虑调整应用参数和日志参数；数据库繁忙，可以考虑通过数据库快照分析优化SQL；应用功能设计有误，可以考虑功能菜单紧急关闭；还有很多……另外，需要补充的是，在出现故障紧急情况之前，如果可能的话，需要保存当前的系统场景。比如在kill进程之前，可以先抓取一个CORE文件或者数据库快照文件。3）快速定位故障原因是否为偶发性、可重现性。故障现象能否重现，对于快速解决问题非常重要。可以复现说明总有一种方法或者工具可以帮助我们定位问题的原因，并且可以复现的故障往往可能是服务异常、变更等工作导致的。但是，如果故障是偶发的，发生的概率很小，则很难排查。能否定位到一般原因取决于系统在故障过程中是否有足够的现场信息。是否进行了相关更改大多数故障都是由更改引起的。确定故障现象后，如果有相应的变化，有助于从变化的角度分析是否是变化引起的，进而快速定位故障并准备切线等应急预案。范围能否缩小一方面，应用系统提倡解耦，一笔交易会流经不同的应用系统和模块；另一方面，失败可能是由于应用程序、系统软件、硬件和网络方面的问题。在排查故障原因时，应避免全面排查。建议先将问题范围缩小到某个流程，再开始与相关团队协调调查。配合相关方分析问题和第（3）点，避免相关团队同时进行无头调查。缩小牵头方范围后，需要以开放的态度要求关联方配合定位，对于关联方，需要主动出击。合作的工作态度。是否有足够的日志来定位故障原因，最常用的方法是分析应用程序日志。运维人员不仅要知道业务功能对应哪个服务进程，还要知道服务进程对应哪些应用日志，并且具备一些简单的应用异常日志错误判断能力。故障时系统站点是否有core或dump等文件很重要。紧急情况发生前，有条件的情况下建议在系统现场留下文件，比如CORE\DUMP，或者TRACE采集信息等，备份可以用到Coveredlogs等。以上是一般故障的常用方法。当出现重大故障或多方处理故障时，小规模排查往往不利于快速解决，需要启动应急处理程序。建议考虑以下沟通方式：呼叫相关人员描述故障状态说明正常的应用逻辑流程，陈述变更和调查进度，展示信息，引导决策2.提高监控1)提高从监控可视化角度看监控策略。需要统一的可视化操作界面。制定完善的监控策略后，故障处理人员需要快速看到相应的运行数据，比如：可以看到一段时间的趋势，故障期间的数据表现，性能分析等数据，而这些数据可以提前制定，分析结果可以直接发布给故障处理人员。大大提高了故障的处理效率。以呼叫中心系统为例，为了故障定位需要提前配置以下实时交易数据：交易性能数据：平均交易耗时、系统内部模块交易耗时（IVR交易耗时、接口总线交易时间），相关系统交易时间（核心交易时间、工单系统交易时间等）重要交易指标数据：交易量、IVR交易量、话务量、座席呼叫率、核心交易笔系统交易量、工单、等异常交易数据：交易成功率、失败率、错误代码大多数交易按服务器分析交易数据：统计服务器每个服务处理的交易数量，以及交易总耗时与上述交易数据，并通过以一定的频率进行监控和计数，当故障发生时，运维人员可以点击鼠标查看故障是从什么时候开始的，系统内部或相关系统是否有问题，哪一个是最突出的交易，各个服务器的交易量是否平衡等。2）最基本的任务从监控侧提升监控，实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件、应用软件等IT资源的全面监控和管理。在应用软件的监控中，不仅需要对服务进程和端口进行监控，还需要对业务层和事务层进行监控。全面的应用监控，可以提前预警故障，保存影响应用运行环境的数据，缩短故障处理时间。3）从监控报警完善监控策略需要有清晰的监控报警提示，值班人员可以根据监控报警做出简单的问题定位和应急处理方案。比如类似如下的监控信息：22:00，【金融应用系统】中【应用服务器LC_APPsvrA10.2.111.111】的【预应用模块】出现【应用端口：9080】不存在，而这个端口的功能是【提供金融应用处理（负载均衡部署）】，原因可能是【SERVER1服务异常停止】，监控系统进行了如下应急处理【自动执行端口进程启动】，紧急本次活动等级为【高】。管理员可以通过短信的内容看到是哪个系统、哪个应用、哪个模块出现了问题，可能的原因，对业务的影响，是否需要立即处理（例如，是否提前警告可以延迟到第二天）和其他信息。4）完善的监控策略不仅需要实时的数据告警，还需要从监控分析的角度进行聚合数据分析告警。不用说，实时数据分析警报的重要性可用于检测聚合和分析数据的潜在风险，也为疑难杂症的分析提供帮助。5）提高监测主动性。监控不只是报警，它可以做的更多。只要我们想办法给它主动解决事件的规则，它就有能力为管理员处理故障。3、应急预案需要提前制定故障应急预案，但我们的应急预案在日常工作过程中遇到了一些问题：应急预案缺乏持续维护，缺乏演练，信息不及时准确；应急预案过于追求大而全的结果，不利于阅读和使用；应急预案形式大于实际使用效果，方案不够具体；只关注应急预案的内容，不关注运维人员对预案的理解；针对以上常见问题，应急预案需要做到以下几点：1）内容简化。很多人可能认为故障的发生形式多种多样，因此应急预案需要涉及方方面面。但是在实际的故障处理过程中，我们可以发现我们的应急措施往往会重复使用几个常见的步骤，所以我认为应急预案应该有所侧重。如果应急计划可以处理80%的常见故障排除场景，那么本应急手册应该是可以接受的。过于追求影响应用系统方方面面的内容，会导致解决方案的可读性差，最终改成一个应该检查的文档。以下是我认为应用系统应急预案应该具备的：（1）系统层面：知道当前应用系统在整个交易中的作用，知道出现问题时如何配合上下游分析问题当前系统或者上下游存在问题，比如：上下游系统如何通信，通信是否有唯一关键字等。另外，系统层面还涉及到一些基本的应急操作，比如扩容，系统和网络参数调整等(2)服务级别：知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级别参数等。(3)交易层面：能够知道如何发现某个分支或交易类型的问题，无论是大规模的、局部的还是零星的问题，都可以用数据来说明对交易的影响交易，并可以定位到交易错误的信息。这里最常用的方法是使用数据库查询或工具。知道如何检查最重要的交易是否正常，重要的预定任务的应急处理方案，如开立、改期、对账的时间要求和应急措施。(4)辅助工具的使用：有时需要借助一些工具或自动化工具来辅助分析和应急响应。这时候就需要有辅助工具的使用方法了。（5）沟通方案：沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。(6)其他：不管以上5点有多完善，我相信这本应急手册可以解决80%的故障恢复工作。2）应急预案是一项持续性工作。有了应急预案，如何让运维人员持续更新是困难的。我觉得要解决这个难点，需要让运维人员经常使用这本手册。如果手册没有场景可以使用，管理者需要创造运维人员使用手册的机会，比如应急演练。3）注意运维人员对应用关键信息的理解。前两点关注手册，最后一点我觉得有必要关注使用这个手册的人。一些运维人员认为应用运维人员不具备深入了解应用系统本身内容的能力，因此应用运维人员在故障处理过程中的地位非常尴尬。运维人员有操作权，但不知道该做什么。对此，我认同应用运维人员不需要掌握应用系统的业务功能，但我认为对于应用系统本身，应用运维人员需要具备以下基本能力：知道什么应用系统做什么，基本业务是什么；了解应用架构部署，了解上下游系统的逻辑关系；知道应用下服务的作用，端口，服务级别的应急处理，如何查找和轻松定位日志等数据信息。了解应用系统的重要时间点和任务，如开盘、关盘、换日、定时任务等时间点，以及如何判断这些任务是否正确；了解最重要的交易流程；了解常用的数据库表结构并能使用。4、智能事件处理方式如下图（详细智能涉及监控、规则引擎、配置工具、CMDB、应用配置库等模块协同工作）
