监控系统的阶段建设

监控的工作就是发现故障、定位故障、解决故障、预防故障、及时准确告警、分析定位故障、高效快速排障、资源架构优化的过程，监控体系建设的阶段性如下图所示。

1、阶段一基础监控

目标：专业监控覆盖率→100%。

IT 设施有各种类别，任何单一的监控软件都有自己的局限性，无法满足所有 IT 设施监控的需求。当企业处于面向资源管理阶段时，不建议过多地使用各类专有监控软件，因为专有监控软件大多是由被纳管 IT 基础组件厂商设计开发的，在针对自己的组件监控上尚可发挥作用，但是针对同类型其他厂商的产品就显得不那么得心应手了，而且这类专有监控软件大多是闭源的，无法深度定制纳管其他厂商的产品。

在市面上各类监控软件中，搭建企业级基础监控系统建议采用 Zabbix，它几乎能满足你的“温饱”需求。Zabbix 是一款开源的 IT 基础监控解决方案，提供了多种数据收集方式，灵活的模板定义，高级告警配置，可实时绘图并扩展图形化显示网络拓扑等特性。即使 Zabbix 标准组件无法满足监控需求，用户也可以自行编写脚本实现定制需求，实现网络设备、服务器、Cloud、应用、服务等监控。 当然，Zabbix 监控无法作为动能环境监控使用，同样也不能用于业务交易路径监控，要覆盖所有的 IT 设施，需要以较完备的监控软件为基础。

2、阶段二集中监控

目标：事件及时响应→100%。

基础监控软件存在专业性，在阶段一中部署的多款基础监控软件之间无法做数据交互，存在数据“竖井壁垒”。但是任何生产事件是不会独立存在的，事件之间存在因果关系。在实际工作中，工程师只负责自己模块的事情，也同样存在“竖井壁垒”。这就造成了即使 IT 设施异常的事件通知到具体的工程师，他们在应对具体事件时也只能各行其是，事件是什么原因造成的，会影响其他什么业务，均无法定位。

集中监控的本质就是将各类基础监控软件事件、性能等数据集中汇聚和管理，为人工统筹、处置和管理事件提供一个接口。IBM Tivoli 产品架构是集中监控平台中相对比较成熟的架构。

3、阶段三监控运营

目标：监控有效率→100%。

监控运营的范畴很大，简单概括起来就是“用最高效的方式满足监控需求，保证需求持续改进并有效”。让该被监控的被监控起来，该报的警报出来，不该报的警不报出来。另外，还要做好监控自动化，缩减监控运维成本，提高工作效率。做好监控与其他运维工具的集成，使大家能方便地使用监控，进而依赖监控，最终乐于使用监控。

4、阶段四根因定位

目标：故障定位时间→0。

根因定位解决的问题可概述为“发生了什么”“为什么发生”“影响到哪些业务”。 监控运维阶段是根因分析的“神经元”形成的过程。根因定位的关键词主要是“大数据”“算法”“AI”。IT 运维的根因分析不是玄学，而是一套依赖于切实可行的配置管理信息，以及行之有效的算法绘制故障“影响树”形成的降维故障影响元素，缩减故障定位成本，助力快速发现问题的一套方法论和解决方案。

5、阶段五协同止损

目标：MTTR（平均故障恢复时间）→0。

投资术语中的止损也叫“割肉”，是指当某项投资出现的亏损达到预定额度时，及时“斩仓出局”，以免形成更大亏损。监控中提到的止损通常也叫“自愈”，是指在监控系统探测到某些异常后，通过自动化软件或脚本等，按照预先定义好的操作流程，对已发生事件进行处置，以恢复生产运营的过程，以求及时解除生产事故，最小限度地影响生产。

协同止损发起于监控系统，由监控系统探测具体组件功能异常；其核心是基于 CMDB、知识库的告警决策模块，当然，决策在很大程度上也依赖根因定位；自动化模块完成事故异常的处理操作，也就是“监控”中的“控”。

6、阶段六故障规避

目标：MTBF（平均故障间隔时间）→∞。

业界常将运维人员称为“背锅侠”，故障是运维人员心中永远的痛，如果仅依赖监控发现问题，不对问题做改进，那无非是不断揭“伤疤”的痛。 在日常运维中，通过监控系统发现问题是最基础的要求，针对发现的问题不断深挖原因才是运维人应该具有的品质。我们有必要遵循 PDCA（Plan、Do、Check、Action）模型持续改进，依赖基础监控软件发现新问题、梳理故障脉络、快速定位问题根因，运用自动化平台高效解决问题、分析问题数据并规避问题，持续改善运维品质。