基础要点

定义：对服务或配置项（CI）有重要意义的状态变更。

目标：建立适当的响应机制，通过主动或被动的自动化监控，记录状态变更，确定事件的优先级，启动控制操作，最小化或消除其对业务的负面影响。

信息性事件：不需要采取行动，但要分析、收集数据，发现对服务有益的操作。

警告：在业务实际发生负面影响之前采取行动。

异常：确定违反已建立的规范，即使未影响业务也要采取措施。

应使用工具轮询关键CI，但要控制整体的数据量。

应通过合同，规定第三方应予以配合，并提供监控的数据。

解读

就各种服务的日常监控而言，我们默认需要对系统、网络与应用三大方面开展各类事件的监控活动。通常，业界会采取如下三种模式：

对于实力雄厚的企业而言，他们会自行研发各种针对某些具体目标的监控软件。这些软件虽然会在界面或功能上较为粗糙，但是能够针对痛点且实用有效。

对于开放务实的企业而言，他们会通过采用开源社区的工具，来不断完善与丰富监控的项目与工具。此类工具虽能持续迭代，但难免会存在潜在的缺陷。

对于严谨合规的企业而言，他们会购置成熟的商业版监控服务，并利用第三方厂商所提供的丰富的API 接口，通过双方技术人员的协作，实现与现有企业系统的二次开发与集成。此类监控产品通常拥有友好的界面、完整的流程以及周到的技术支持。

在实现了监控服务的搭建之后，IT 技术人员需要针对当前系统与服务的实际情况，设置好监控项、参照基准以及门限阀值。

为了有效地实现事件的分类、分级以及剔除误报，我们应当事先对于在监控过程中捕捉到的事件信息，根据其重要程度来进行如下区分：

1.信息性事件

例如，某个用户登录了人事管理系统，邮件系统向内部群发了一封邮件，物流系统的全量数据备份已完成等事件。

2.警告

例如，Web 服务器的CPU使用率接近设定阈值，网站大促时用户的访问量接近系统设定的稳定性能拐点等。

图1 事件管理流程

3.异常

例如，上述Web 服务器的CPU 使用率已经超过了设定阈值，需要立即给虚拟机增加CPU。

由于各类事件都是从自动化监控中捕获而来，因此我们在系统的响应能力方面，需要能够达到如下“两个快”。

快速生成：由于是系统自动化监控所产生，因此事件应迅速实现分配编号；初步判断类型；过滤重复与无效；根据标准分级自动关联处理措施以及分派给相应的角色，这样既节省了时间，又提高了准确性。

快速处置：系统除了能够根据现有的“问题和已知错误知识库”以及CMDB，进行事件的自动匹配与流转之外，还应当设定一些预定义的处理路径、并能准确地读取组织内不同的IT 角色信息，以实现多部门按需联动，此外，系统也应该为重要事件自动设置倒计时，以及截止时间，以方便后期对处置的KPI 进行评估。

实务

在自动监控方面，我们通过开源软件——Zabbix 的自动化注册与发现特性实现了：

1.机房环境、物理设备、网络流量、虚拟化、数据库、业务应用、存储状态、备份作业以及日志等方面的实时自动化巡检。

2.通过自动发现和现场核对，分层、分级整理出了2D版的机房拓扑图、3D 版的机架视图、地域链路实时图、网络架构图、系统逻辑框架图、应用间数据流转图、流量历史曲线图以及各类应用的仪表盘。

自动跟踪监测项目包括：标准的CPU、内存、磁盘、I/O，以及定制化服务（如Nginx、PHP 页面等）的KPI 性能。

对于监控到的事件，系统能够自动区分事件的来源，分配事件编号，区分类别，通知人员，以及跟踪处理状态。

同时，在运维人员的二次审验方面，他们只需通过进一步点击，便可细致地观察与获悉到每个服务的详细状态，进而迅速开展各种人工分析以及异常跟踪与诊断。

另外，对于那些自动化监控管理流程无法解决或是简单人工干预无法纠正的事件，我们会根据前面提到的IT 资产的分类标准，依次转入事故管理、变更管理，以及马上要讨论到的问题管理流程。

总的说来，我们在实际操作中，参考了如图1 所示的事件管理流程。