更多内容关注微信公众号：fullstack888

【故障场景】

以运维监控系统为例，先给大家分享一个案例：

值班电话响了，有业务人员反映业务系统运行缓慢，部分业务系统处理超时。

运维人员开始忙活了，查系统资源使用情况、查应用服务是否正常、查日志是否异常报错、层层递进只为尽快定位问题根本原因。

时间在不知不觉中流逝，业务员不断催促，值班经理也围上来了解情况，甚至惊动了部门老大，可以想象的问题三连：“系统恢复了吗？”、“影响了哪些业务？”、“问题原因是什么？”

而此刻，值班人员面色凝重，手飞快的在敲键盘，输命令、查日志、写sql、看业务波动。

随着值班人员紧皱的眉头舒展开，最终定位到问题原因是其中一个功能没有控制返回数量，导致内存OOM。

定位了问题解决起来就很容易了，问题虽然很快被处理了，但运维的工作才刚刚开始...

针对这个故障，各方诉求是不同的：

1、业务人员希望尽快恢复系统使用并确保以后不再出现此类问题；

2、运维经理希望进一步优化完善运维中心故障处理流程：

• 优先故障处理过程的时间，

• 提前发现故障，加强监控，

• 完善故障应急方案，

• 长远目标：故障自愈。

【运维监控机制】

这个问题解决了，还有解决不完的其他问题。尤其是运维经理还提出了新问题。

如何解决经理提出的问题，并提出未来解决故障的想法？其实这涉及到IT自动运维监控系统的设计理念。

从故障常见的处理方法到故障前的准备工作（完善监控、制定应急方案等方式）来阐述一下运维监控机制。

一、故障处理方法

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

在处理故障前，技术人员首先要明确故障现象，故障现象直接决定故障应急方案的制定，这就要求技术人员需要对应用系统的整体功能有一定的了解。

2、应急恢复

保证系统可用性运维最基本的指标，这就涉及系统应急恢复。

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

• 服务整体性能下降或异常，可以考虑重启服务；

• 应用做过变更，可以考虑是否需要回切变更；

• 资源不足，可以考虑应急扩容；

• 应用性能问题，可以考虑调整应用参数、日志参数；

• 数据库繁忙，可以考虑通过数据库快照分析，优化SQL；

• 应用功能设计有误，可以考虑紧急关闭功能菜单；

• 等等

另外，在故障应急前，运维人员并不能充分利用不受破坏的现场去定位故障，所以日志收集显得尤为重要。

在有条件的情况需要保存当前系统场景，比如重启数据库前，可以先抓个数据库快照。

3、快速定位故障原因

• 偶发还是频发

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

如果故障是偶发的，能否准确定位原因很大程度上依赖于系统是否有足够的故障期间的现场信息。

• 是否进行过系统升级

升级会导致系统出现很多问题，如果恰好系统进行过变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

• 缩小范围

故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

• 足够的日志

分析日志是定位故障原因的常见方式，运维人员需要知道业务功能对应的哪些应用日志。

• 故障现场快照

故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件。

二、运维监控机制

1、监控可视化

故障处理人员能够快速的看到相应的运行数据。

比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等，这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率。

2、监控面

监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。

3、监控告警

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

三、应急方案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题：

1）应急方案缺乏持续维护；

2）应急方案过于追求大而全，导致不利于阅读与使用；

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

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

1、内容精简

很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。

实际的故障处理过程中不是这样的，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以应急方案要有重点。

过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是我觉得系统应急方案应该有的内容：

（1）系统级：

了解当前业务系统，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题。

（2）服务级：

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

（3）辅助工具的使用：

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

2、持续迭代

有了应急方案，要让运维人员持续去更新，需要让运维人员经常使用这个手册。

如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。

- END -

往期回顾

◆再谈如何写好技术文档？

◆如何高效阅读源码？

◆面试题：为什么数据库连接池不采用 IO 多路复用？

◆8点帮你构建自己构建知识体系

◆51 个核心点助你搞懂 Kafka

◆事件、故障排查处理思路，你值得试试

◆原来 Elasticsearch 还可以这么理解

◆如何构建10x程序员的思考模型

◆企业级高可用延时消息中台设计方案

◆一种避免递归查询所有子部门的树数据表设计与实现！

技术交流，请加微信： jiagou6688 ，备注：Java，拉你进架构群