在讲解事件和故障处理思路之前，先说一个故障场景（以呼叫中心系统为例）：业务人员反映呼叫中心系统运行缓慢，部分呼叫在自检中超时服务语言接通，呼叫转人工座席，人工座席线路断线。运维人员开始忙碌起来，查看资源使用情况，查看服务是否正常，查看日志是否报错，查看交易量是否还在……时间不知不觉的敲着、敲着、敲着，但原因仍未定位。经理来了解情况：“系统恢复了吗？”、“故障有什么影响？”、“交易中断了吗？”……运维人员急忙敲键盘，写SQL，并查看交易量；敲键盘，写命令，看系统资源和情况……最后定位到问题原因是因为其中一个函数没有控制返回的个数，导致内存泄漏。针对该故障，业务希望运维能够更快的解决故障并进行恢复。经理希望制定和优化呼叫中心的故障处理流程。不使用键盘“提前发现故障，加强监控：”技术比业务更早发现问题，监控不仅是报警，也是辅助故障定位“完善故障应急预案：”应急预案是最新的“数据、准确、简单、明了”长远目标：故障自愈：“可以固化的运行自动化，让机器做机器能做的事。”下面将从常见的故障处理入手方法，然后从故障前的准备（完善监控、制定应急预案等）入手针对管理人员提出的问题，提出以后的故障排除思路一、常用方法1、判断故障现象，初步判断原因问题的影响，运维人员在处理故障前，首先要了解故障现象，对整体功能有一定的熟悉度，确认故障现象后，才能指导运维人员判断影响的错。2、应急恢复运维最基本的指标是系统可用性，而应急恢复的及时性是系统可用性的关键指标。对以上故障征兆及影响进行判断后，即可制定故障应急处理措施。故障应急操作较多。例如服务整体性能下降或异常，可以考虑重启服务；如果应用已经改变，可以考虑是否需要切换回来；资源不足，可以考虑紧急扩容；应用性能问题，可以考虑调整应用参数和日志参数；数据库繁忙，可以考虑通过数据库快照分析优化SQL；应用功能设计有误，可以考虑紧急关机功能菜单；还有很多……另外，需要补充的是，在出现故障紧急情况之前，如果可能的话，需要保存当前的系统场景。比如在kill进程之前，可以先抓取一个CORE文件或者数据库快照文件。3、快速定位故障原因1）是否偶发、可重现故障现象能否重现，对于快速解决问题非常重要。可以复现说明总有办法或者工具可以帮助我们定位问题的原因，并且可以复现的故障往往可能是服务异常、变更等工作导致的。但是，如果故障是偶发的，发生的概率很小，则很难排查。这取决于系统在故障期间是否有足够的现场信息来确定是否可以定位到一般原因。是否进行了相关变更。大多数故障都是由变化引起的。确定故障现象后，如果有相应的变化，有助于从变化的角度分析是否是变化引起的，进而快速定位故障并准备切线等应急预案。2）是否进行了相关改动大多数故障都是由改动引起的。确定故障现象后，如果有相应的变化，有助于从变化的角度分析是否是变化引起的，进而快速定位故障并准备切回等应急预案。3）可以缩小范围吗？一方面，应用系统提倡解耦，一笔交易会流经不同的应用系统和模块；另一方面，失败可能是由于应用程序、系统软件、硬件和网络方面的问题。在排查故障原因时，应避免全面排查。建议先将问题范围缩小到某个流程，再开始与相关团队协调调查。配合相关方分析问题和第（3）点，避免相关团队同时进行无头调查。缩小牵头方范围后，需要以开放的态度要求关联方配合定位，对于关联方，需要主动出击。合作的工作态度。4）是否有足够的日志来定位故障原因。最常见的方法是分析应用程序日志。运维人员不仅需要知道业务功能对应于哪个服务进程，还需要知道服务进程对应于哪些应用日志，并具备一些简单的判断异常应用日志的能力。5）是否有core或dump等文件。故障期间的系统站点非常重要。紧急情况发生前，建议有条件的情况下将文件留在系统现场，如CORE\DUMP，或TRACE收集信息等，并做好备份可能被覆盖的日志等。以上是一般故障的常用方法。当出现重大故障或多方处理故障时，小规模排查往往不利于快速解决，需要启动应急处理程序。建议考虑以下沟通方式：呼叫相关人员描述故障状态说明正常的应用逻辑流程，说明变更和调查进展情况，展示信息领导决策二．改进监控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、应用配置库等模块协同工作）。作者丨程序员访谈来源丨网址：https://blog.csdn.net/Dou_Hua...
