在讲解事件和故障处理思路之前，先说一个故障场景（以呼叫中○心系统为例）：

业务人员反映呼叫中心系统运行缓慢，部分电话在自助语言环节超时，电话转人⊙工座席，人工座席出现线路突发情况。

运维人员忙碌，查看资源使用情况，查看服务是否正常，查看日志是否报错，查看交易√量是否还在……时间在敲打键盘，敲打键盘，在键盘上打字，但原因仍然没有找到。

经理过来查看情况：“系统恢复了吗？”、“故障有什么影响？”、“事务中断了吗◤？”……

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

最后定位，问题原因是其中一个函数没有控制返回次数，导致内存泄漏。

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

1、是时候确定故障排除过程的优先级了——“用鼠标可以做什么，而不是键盘”

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

3、完善故障应急≡预案——“应急预案及时、准确、简单明了”

4、长期目标：故障的自愈——“可以??治愈的操作自动化，机器可以做的机器”

下面将从常见的故障排除方法介绍开始，然后从故〇障前的准备工作（完善监控、制定应急预案等）着手解决管理者提出的问题，并提出解决故障的思路未来。

1、常用方法：

1）判断故障现象，初步判断问题影响

在处理故障之前，运维人员首先要了解故障现象，而故障现象直接决定了故障应急预案的制定，这取决于运维人员需要对整体有一定的熟悉程度应用系统的功能。

确认故障现象后，即可指导运维人员初步判断故障影响。

2）紧急恢复

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

通过对上述故障现象和影响的判断，可以制定故障应急操作。故障应急操作有很多，例如：

另外，需要补充的是，在故障出现之前，需要在一定条件下保♀存当前系统场景。例如，在杀死一个进程之前，您可以先捕获一个 CORE 文件或一个数据库快照文ξ　件。

3）快速定位故障原因

故障现象能否重现对于快速解决问题非常重要。可复现是指总会有方法或工具帮助我们定位问题的原因，而可复现的故障往往可能是由于服务异常、变更等工作造成的。

但是，如果故障是零星的，发生概率很小，则故障排除就比较困难，这取决于系统在故障期间是否有足够的现≡场信息来确定是否可以定位始终原因。

大多数故障是由更改引起的。在确定故障现象后，如果有相应的变化，有助于从变化的角度分析是否是由变化引起的it运维技术，以便快速定位故障，制定折返等应急预案。

一方面，应用系统提倡解耦，一笔交易会流经不同的应用系统和模块；另一方面，故障可能是由于应用程序、系统软件、硬件、网络等环节的问题。在排除故障原因时，应避免全面检查。建议在协调相关团队调查之前将问题范围缩小到某个程序。

同时（3）点）为避免所有相关团队同时在没有线索的情况下同时排查，牵头方需要有开放的态度，要求相关方在收窄后配合定位范围，相关方需要积极配合。工作态度。

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

故障期间的系统站点非常重要。紧急情况前，建议保留系统站点文件，如COREDUMP，或TRACE收集信息等，并备份一些可』能被覆盖的日志。

以上是一般故障的常用方法。当发生重大故障或多方故障时，小范围排查往往不利于快速解决，需要启动应急处理流程。建议考虑以下沟通：

2、完美监控

1）从监控可视化提升

完善的监控策略需要统一的可视化操作界面。制定完善的监控策略后，故障处理者需『要能够快速看到相应的运行数据，例如一段时间内的趋势、故障期间的数据性能、性能分析等数据，而这些数据可以在提前将分析结果直接推送给故障处理人员，大大提高了故障处理的效率。以呼叫中心系统为例，需要︽提前配置以下实时交易数据，用于故障定位：

- 事务性能数据：平均事务时间、系统内部模块事务时间（IVR事务时间、接口总线事务时间）、关联系统事务时间（核心事务时间、工单系统事务时间等）

- 重要交易指标数据：交易量、IVR交易量、流量、座席呼叫率、核心交易数、工单等系统交易量

- 交易异常数据：交易成功率、失败率、大部分有错误码◣的交易

- 按服务器分析交易数据：根据每个服务处理的交易数量统计，总交易时间

有了以上交易数据，通过监控以一定的频率统计，当发生故障时，运维人员可以通过鼠标点击查看故障是从什么时候开始的，是系统内部有问题还是关联系统有问题，最突出的事务是哪一个it运维技术，各个服务器的事务量是否均衡等等。

2）从监控的角度来看很完美

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

全面的应用程序监控可以对故障进行早期预警，并保存影响应用程序运行环境的卐数据，以减少故障处理时间。

3）改进监控和报警

完善的监控策略需要有清晰的监控报警提示，值班人员可以根据监控报警做出简单的问题定位和应急处理方案。例如，类似如下的监◆控消息：

22:00，在【理财应用系统↙】的【应用服务器10.2.111.111】中，【应用端口：9080】不存在，且端口功能【提供财务管理应用处理（负载均衡部署）】，原因可能是【服务异常⌒停止】，监控系统进行了以下应急处理【自动执行端口进程启动】，本次事件的紧急程度高]。

管理员可以通过短信内容看到是哪个系统、哪个应用、哪个模块有问题，可能的原因是什么，对业务有什么影响，是否需要立即处理（例如，预警是否可以延迟㊣　到次日处理）等信息。

4)从监控分析改进

完善的监控策略不仅需要实时数据报警，还需要对汇总数据进行分析报警。不用说，实时数据分析警报的重要性在于从聚合和分析的数据中发现潜在的风险。疾病帮助。

5)通过↓监控主动改进

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

3、应急计划

需要提前制定故障应急预案，但是在日常工作过程中我们的应急预案遇到了一些问题：

1）应急预案缺乏持续维护，缺乏演练，信息不及时准①确；

2）应急预案太大太全面，不利于阅读和使用；

3）应急预案的形式大于实际使用效果，方案针对性不强；

4）只关注应急预案的内容，不关注运维人员对预案的理解；

针对以上常见问☉题，应急预案需要做到以下几点：

1）精简内容

很多人可能认为故障可以有多种形式，因此应急计划需要涵盖方方面面。但是在实际Ψ的排查过程中，我们可以发现我们的应急措施往往会复用几个常用的步骤，所以我认为应急预∴案应该重点突出。如果一个应急计划可以处理 80% 的常见故障，那么这个应急手册应该是合格的。过分追求影响应用系统各个方面的内容，会导致解决方案的可读性差，最终改变一个〖应该检查的文档。以下是我认为应用系统应急计划应具备的内容：

(1）系统级：

可以知道当前应用系统在整个事务中的作用。当当前系统或上下游出现问题时，可以知道如何配合上下游分析问题，例如：上∩下游系统如何通信，是否有唯一的通信关键字等.

此外，在系统层面还涉及到一些基本的应急操作，如扩容、系统∑　和网络参数调整等。

(2）服务等级：

可以知道这个服务影响了哪些业务，服务中涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级☆参数。

(3）事务级别：

能知道如何找出某个分支或某类事务有问题，无论是大规模的、局部的还是偶发的问题，都能用数据解释事务的影响，并能定位事务错误信息。这里最常用的方法是使ζ用数据库查询或工具。

知道如何检查最重要的交易是否正常，以及重要定时任务的应急解决方案，如开户、日期变更、对账时间要求、应急措施等。

(4）辅助工具的使用：

有时，需要使用一些工具或自动化工具来辅助分析和应急响应。这时候，就需要有一个如何使用辅助工具的方法。

(5）交流计划：

沟通计划ω　涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。

(6）其他：

以上五点都完成了，相信这本应急手册可以解决80%的故障※恢复工作。

2）应急计划是一项持续的工作

有了应急预案，很难让运维人员不断更新。我认为要解决这个困难，我们需要让运维人员经常使用这本手册。如果手册没有使用场景，管理人员需要为运维人员创造使用手册的机会，例【如应急演练。

3）关注运维人员对关键应用信息的理解

前两点关注手册，最后一点我觉得有必要关注使用它的人。一些运维人员认为应用运维人员没有能力对应用系统本身的内容了解透彻，因此应用运维人员在排」查过程中的状态非常尴尬。该怎么办。

对此，我同意应用运维人员不需要掌握应用系统的业务功能，但我认为应用运维人员对于应用系统本身需要具备以下基本能力：

（1）知道应用系统是做什么的，基础业务是什么；

(2）了解应用架构部署，上下游系统逻▆辑关系；

（3）知道应用下服务的作用、端口、服务级别的紧急处理，以及如何查找和简单定位日志等数据信息。

(4）了解应用系统的重要时间点和任务，如开、关、换天、定时任务，以及如何判断这些任务是否正确

(5）了解最重要交易的流程；

(6）了解常见的数据库表结构并且可以使用它们。

4、智能事件处理

处理方法如下（详细智能涉及监控、规则引擎、配置工具、CMDB、应用配置库等模块协同工作）

文章转载：twt企业IT社区