故障场景

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

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

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

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

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

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

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

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

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

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

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

解决方法

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

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

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

2、应急恢复

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

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

是否为偶发性、是否可重现

故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。

但是，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总的原因。

是否进行过相关变更

大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

是否可缩小范围

一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

关联方配合分析问题

与第3点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

是否有足够的日志

定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。

完善监控

完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率。

监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。

完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。

完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙。

监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。

在数字化转型“深水区”，业务、技术体系和平台架构的日益复杂化和多元化，催生了智能化的运维服务需求。这一点从网强适应市场的不断变迁中可以得到印证。

智能化运维管理系统

网强专注于为客户提供卓越的全面IT网络运维整合服务。集网络设备、服务器、数据库、中间件、服务、安全设备、ORACLE数据库集群、虚拟机集群、存储运维管理、无线运维管理、视频设备运维管理 、机房动力环境管理、业务管理、可视化大屏展示、云平台等各种软硬件实现一体化IT网络运维监控方案，打造IT网管软件产品的智能化运维管理、自动化管理的网管需求，遵循用户实际使用习惯，以管理概念为导向，为您提供全方面多纬度的IT网络运维管理平台整合服务。