1.2 监控体系总体规划
构建一套完整的监控体系需要从IT运营体系的阶段性和监控系统建设的阶段性两个方面考量。项目管理中经常提到“渐进明细”一词，任何系统的建设都是一个在摸索中前行的过程，本节将分享监控体系构建的一些实践经验。
1.2.1 IT运营体系的阶段性
监控体系的建设，规模小的可以是一套简单的监控系统，如运用Zabbix监控软件，实现操作系统、数据库等IT基础监控，也可以是整合网络监控、IT基础监控、应用监控、点检系统、巡检机器人等监控系统与数据中心的流程管理、配置管理、大数据平台等共同组建的运维监控平台。
监控体系的构建需要参照IT运营组织的管理成熟度。处于不同管理成熟度的企业在选择自己的监控系统时区别很大，好的监控体系不能一味求大求全，也就是我们常说的“只买对的，不买贵的”。
参照图1-1 IT运营组织的管理成熟度发展的不同阶段，IT运营组织的管理成熟度分不同阶段，包括：面向资源管理、面向应用和流程管理、面向服务管理、面向业务管理四个阶段。
图1-1 IT运营组织的管理成熟度发展的不同阶段
1.面向资源管理阶段
该阶段的企业主要关注的是不同类别的IT基础资源的可用性和性能。处于该阶段的企业一般处于创业初级阶段，对外提供的服务单一，对时效性要求也不高，架构简单，服务器的类型、数量、版本等少，而且IT基础资源的配置和使用上以最低廉的成本实现基础功能，规范性差，可维护性也差。
企业将有限资源用于保障对外服务的“刀刃”上，运营资源被无限压缩，员工在企业中的运维手段和技术也很欠缺，常常使用人工点检的方式。
建议处于该阶段的企业将主要精力用在IT基础架构平台监控上和网络监控的设计和搭建上。如果有其他的特定需求和余力，可按照选择发展IT虚拟资源池监控、存储资源监控、动力环境监控，以及IAAS云监控等。
2.面向应用和流程管理阶段
该阶段的企业开始关注跨越IT基础设施的业务应用端到端的管理，驱动来自应用可用性和服务水平。“古典经济学之父”亚当·斯密认为，分工导致劳动者技能的提高、时间的节约和技术进步，企业在发展过程中通过专业分工、有效协同来提高工作效率成为必然。管理能力和团队规模也将跟随业务增长而快速增长。
建议处于该阶段的企业基于上一阶段搭建的各类型基础监控发展用户体验、主动监控、应用性能监控和诊断，推进面向应用的IT资源管理持续优化，建立应用监控规范，构建ITIL服务支持流程，如有需求可选择发展PAAS云、混合云监控。
3.面向服务管理阶段
该阶段的企业初具规模，为提高整个IT服务水平，需要IT基础设施、业务应用和服务的组合，驱动力来自IT整体服务水平要求。企业关注整体服务目录、每项服务的质量和效果，以及用户满意度。
建议处于该阶段的企业致力于搭建全渠道交互门户，集中管理告警和管理性能；设计企业自动配置库CMDB，持续维护CMDB数据的正确性；完善ITIL服务交付流程，形成配置变更控制平台；集中汇聚运维组织过程资产、搭建运维知识库，并可初步建设运维大数据分析系统，为后续运维故障分析及预警打下基础。
4.面向业务管理阶段
该阶段的企业关注每项服务成本，关注资源跟随业务要求的动态部署。处于该阶段的企业将视角完全转向业务，应逐步形成一套业务交易监控、业务服务监控规范、业务影响分析、业务监控指标体系、业务服务水平管理，以及运维绩效考核体系。
1.2.2 监控体系建设的阶段性
监控的工作就是发现故障、定位故障、解决故障、预防故障、及时准确告警、分析定位故障、高效快速排障、资源架构优化的过程，监控体系建设的阶段性如图1-2所示。
图1-2 监控体系建设的阶段性
1.阶段一 基础监控
目标：专业监控覆盖率→100%。
IT设施有各种类别，任何单一的监控软件都有自己的局限性，无法满足所有IT设施监控的需求。当企业处于面向资源管理阶段时，不建议过多地使用各类专有监控软件，因为专有监控软件大多是由被纳管IT基础组件厂商设计开发的，在针对自己的组件监控上尚可发挥作用，但是针对同类型其他厂商的产品就显得不那么得心应手了，而且这类专有监控软件大多是闭源的，无法深度定制纳管其他厂商的产品。
在市面上各类监控软件中，搭建企业级基础监控系统建议采用Zabbix，它几乎能满足你的“温饱”需求。Zabbix是一款开源的IT基础监控解决方案，提供了多种数据收集方式，灵活的模板定义，高级告警配置，可实时绘图并扩展图形化显示网络拓扑等特性。即使Zabbix标准组件无法满足监控需求，用户也可以自行编写脚本实现定制需求，实现网络设备、服务器、Cloud、应用、服务等监控，Zabbix监控解决方案如图1-3所示。
当然，Zabbix监控无法作为动能环境监控使用，同样也不能用于业务交易路径监控，要覆盖所有的IT设施，需要以较完备的监控软件为基础。
2.阶段二 集中监控
目标：事件及时响应→100%。
图1-3 Zabbix监控解决方案
基础监控软件存在专业性，在阶段一中部署的多款基础监控软件之间无法做数据交互，存在数据“竖井壁垒”。但是任何生产事件是不会独立存在的，事件之间存在因果关系。在实际工作中，工程师只负责自己模块的事情，也同样存在“竖井壁垒”。这就造成了即使IT设施异常的事件通知到具体的工程师，他们在应对具体事件时也只能各行其是，事件是什么原因造成的，会影响其他什么业务，均无法定位。
集中监控的本质就是将各类基础监控软件事件、性能等数据集中汇聚和管理，为人工统筹、处置和管理事件提供一个接口。IBM Tivoli产品架构是集中监控平台中相对比较成熟的架构，读者在搭建时可以参考，其架构如图1-4所示。
该平台用到了如下Tivoli产品线功能组件。
（1）ITM/ITCAM用于操作系统、中间件、数据库等监控。
（2）Netcool/OMNIbus用于用户数据集中、转发、丰富、降噪等，为IBM多数架构的核心组件。OMNIbus据称有300余项接口组件，其扩展性、性能、友好度、稳定性等均堪称翘楚之作。
（3）EIF Probe ITM/ITCAM连接OMNIbus的接口。
（4）Syslog Probe Syslog服务器连接OMNIbus的接口。
（5）Trap Probe硬件连接OMNIbus的接口。
（6）ISM Probe端口、ping、监控工具连接OMNIbus的接口。
（7）Precision网络拓扑工具连接OMNIbus的接口。
（8）Netcool/Impact用于OMNIbus连接CMDB并做事件丰富。
（9）TADDM配置项自动发现工具。
（10）TIP事件管理展示平台。
图1-4 IBM Tivoli的产品架构
（11）Cognos报表工具。
（12）TEC本地监控日志工具，在早期IBM项目中的作用类似于OMNIbus。
如上组件共同构建了集中监控平台，OMNIbus作为“万能胶”将各组件黏合在一起，构建了一个有扩展性的运维监控平台。
3.阶段三 监控运营
目标：监控有效率→100%。
监控运营的范畴很大，简单概括起来就是“用最高效的方式满足监控需求，保证需求持续改进并有效”。让该被监控的被监控起来，该报的警报出来，不该报的警不报出来。另外，还要做好监控自动化，缩减监控运维成本，提高工作效率。做好监控与其他运维工具的集成，使大家能方便地使用监控，进而依赖监控，最终乐于使用监控。
4.阶段四 根因定位
目标：故障定位时间→0。
根因定位解决的问题可概述为“发生了什么”“为什么发生”“影响到哪些业务”。
监控运维阶段是根因分析的“神经元”形成的过程。根因定位的关键词主要是“大数据”“算法”“AI”。IT运维的根因分析不是玄学，而是一套依赖于切实可行的配置管理信息，以及行之有效的算法绘制故障“影响树”形成的降维故障影响元素，缩减故障定位成本，助力快速发现问题的一套方法论和解决方案。
5.阶段五 协同止损
目标：MTTR（平均故障恢复时间）→0。
投资术语中的止损也叫“割肉”，是指当某项投资出现的亏损达到预定额度时，及时“斩仓出局”，以免形成更大亏损。监控中提到的止损通常也叫“自愈”，是指在监控系统探测到某些异常后，通过自动化软件或脚本等，按照预先定义好的操作流程，对已发生事件进行处置，以恢复生产运营的过程，以求及时解除生产事故，最小限度地影响生产。
协同止损发起于监控系统，由监控系统探测具体组件功能异常；其核心是基于CMDB、知识库的告警决策模块，当然，决策在很大程度上也依赖根因定位；自动化模块完成事故异常的处理操作，也就是“监控”中的“控”。
6.阶段六 故障规避
目标：MTBF（平均故障间隔时间）→∞。
业界常将运维人员称为“背锅侠”，故障是运维人员心中永远的痛，如果仅依赖监控发现问题，不对问题做改进，那无非是不断揭“伤疤”的痛。
在日常运维中，通过监控系统发现问题是最基础的要求，针对发现的问题不断深挖原因才是运维人应该具有的品质。我们有必要遵循PDCA（Plan、Do、Check、Action）模型（见图1-5）持续改进，依赖基础监控软件发现新问题、梳理故障脉络、快速定位问题根因，运用自动化平台高效解决问题、分析问题数据并规避问题，持续改善运维品质。
图1-5 PDCA模型