1、事态管理流程简介
事态管理，在ITIL中原来称作事件管理。英文名称是Event Management。
作为一个ITIL最佳实践流程，它无疑也具备目标、范围、角色和职责、输入、输出、活动、工具、KPI、质量控制、触发程序、与其它流程接口、挑战/CSF/Risks，以及其它对这个流程管理有帮助的东西。这些在本文中将都不作为重点去讨论，如果对以上知识或信息缺少了解，可以自行找一些关于ITIL 事态管理流程的介绍资料。
本文会提及一些必要的事态管理流程知识，以帮助了解该流程，但全文的重点是介绍可以怎么利用Devops方法来在公司内落地ITIL事态管理流程，达到兼顾流程管理的严谨性与提高人员工作效率的目的。
1.1 事态管理的定义
- Event被定义为任何可被发现或辨别的事情；
- 此类事情对于IT基础设施的管理或IT服务的交付有重要意义；
- 有助于评估可能导致服务出现的偏差影响；
- 通常是由IT服务、CI或监控工具产生的通知。
1.2 事态管理的目标
为组织提供监测事件、了解其影响和确定适当控制措施的能力。
1.3 对业务的价值
- 提供了及早发现故障机制；
- 为自动化操作奠定基础；
- 配合其它管理流程显示出状态变化或异常情况。
1.4 事态管理流程包含的重要活动
- 事件发生
- 事件通知
- 事件检测
- 事件过滤
- 事件重要性分级
- 事件关联
- 触发程序
- 响应选择
- 建立变更需求
- 检查措施
- 关闭事件
1.5 事态管理流程图
2、设计一个事态管理系统
本章节内容是从一个信息化技术系统的角度去分析怎么设计和实现一个事态管理系统，它需要考虑哪些方面，需要包含哪些功能组件。
事态管理是监视服务性能和可用性的基础，在可用性与容量管理流程中应明确监视的具体目标和机制。而在日常运营中需要定义附件的事件、优先级、告警和其它改进，并通过服务持续改进流程反馈到服务战略和服务设计中。
通常一个事态管理系统的设计需要包含以下四个方面内容：
- 设计规范
- 错误信息
- 事件检测和告警机制
- 阈值的设定与优化
2.1 设计规范
在设计规范中需要完成对CI的监视内容以及影响它们行为的方式的设计。
这包含一组需要制定的决策，以及执行这些决策的设计机制。
事态监控决策的设计：
- 需要监视什么
- 需要进行哪类监视，主动/被动，性能/输出
- 何时生成事件
- 需要在事件中传递哪类信息
- 谁需要该信息
事态监控执行机制的设计：
- 事件如何生成？
- CI的现有标准特性中是否已具备事件生成机制？是否要补充更多？
- 哪些数据将用于构成事件记录？
- 事件是自动生成还是要对CI轮询？
- 事件的记录和存储位置？
- 如何收集补充数据？
2.2 错误信息的设计
- 对于所有组件提供有意义的错误信息和/或编码；
- 对新应用的测试应包括对事件的生成是否准确进行测试；
2.3 事件检测和告警机制的设计
- 设计和安装必要的工具，用于发现、过滤、关联和升级事件；
- 根据各类事件重要性和后续措施的规则与标准，将需要部署特定的信息关联引擎；
要完成一项事件检测与告警机制的全面设计工作，需要掌握很多方面的专业知识，包括但不限于以下这些方面：
- 熟悉通过事件管理所管理的所有业务流程及相关业务知识；
- 各个CI所支持服务的SLA要求；
- CI支持责任人；
- CI正常和异常运行情况；
- 了解多项类似事件的重要性；
- 有效支持CI的所有信息；
- 熟悉故障优先级和分类代码，以便于创建故障记录；
- 了解所有与受影响CI互相依赖的CI项；
- 来自厂商或历史经验的已知错误；
2.4 阈值的设定
大部分阈值并非恒定不变。它们一般包括多种相关变量，此信息通常只能通过经验获得，这意味着关联引擎必须通过持续服务改进程序不断进行调整和更新。
3、事态管理系统的搭建与DEVOPS效率提升
3.1 自研、开源或商业事态监控工具的选型与安装部署
自研监控工具
自研监控工具的门槛并不高，在很多企业里都有自研监控系统的成功实践，为了解决某一类型的问题，往往是借助于自研的工具软件。自研的监控工具并不一定要是那种大规模的、分布式的复杂技术系统，而一定会是针对自有业务应用来说监控效果最好的，或者说是最为适用的。可以使用各类工具和编程语言，甚至是脚本语言来开发这样的或繁或简的定制化监控工具，在这里不做展开说明。
开源监控工具
针对系统、网络或应用监控方面的开源工具最佳实践，至少有以下类型的工具在不同的场景下分别得到了较广泛的应用：
- Zabbix，目前已经发展成为系统监控界的瑞士军刀，2000台设备规模内的监控最佳实践工具，前提是你没有把它运行在一个低配系统上，支持proxy模式，功能丰富，支持的协议覆盖了snmp/agent主被动模式/jmx、IPMI，提供了一套事态监控系统所需要的事件、问题、监控项、触发器、自动发现、用户、群组以及丰富的报警媒价管理功能。支持通过API接口进行增删改查操作。
- Cacti，历史悠久的网络流量采集与监控工具，对大部分的网络设备支持得都很好，甚至有一些商业或免费使用的计费专用模板，专业化程序高但用途较单一，且报警能力弱。
- Grafana，专攻监控数据的图形化展示，支持的数据源非常多且页面效果炫丽，已经发展成为大部分监控系统的大前端了。
- Prometheus，一套开源的监控&报警&时间序列数据库的组合，目前常见于与Kubernetes搭配使用。
- Open-falcon，是小米运维团队从互联网公司的需求出发，根据多年的运维经验，结合SRE、SA、DEVS的使用经验和反馈，开发的一套面向互联网的企业级开源监控产品。特点无疑就是适用于超大规模的技术系统监控服务。
目前已经开源的各类监控工具，使用范围较广的也有几十种，而总数高达上千种也不足为怪。
商业监控服务
不得不提的是一些商业化的第三方厂商提供的监控服务如监控宝、基调等也都有很广泛的使用，而且这些服务厂商往往也提供了可供集成调用的API接口，便于集成到自己公司专用的事态管理平台中去。
很少有哪个公司能单独依赖于某一种监控工具，解决自己全部的服务监控需求的，往往是一个互补的监控系统组合。在这个组合中，很可能是自研、开源和商业服务全都有涉及。
通过这套监控工具的组合，至少能为公司业务应用系统提供覆盖系统、网络与应用全方位的事件监测，视工具的完善程度，可以提供生成监测事件、事件分级与分类管理、事件关联、事件响应管理、触发器、事件的记录、事件确认、关闭事件等功能。
很少有监控工具会提供面向监测事件的工单管理，以及事件背后的故障管理、问题管理或变更管理的服务。如果你恰好需要这样的一些服务能力，恐怕最直接的办法就是自己做一个了。即便是选取一个面向解决这些问题的开源项目作为解决方案，也往往会因为水土不服或开源项目流产而不得不做废。
3.2 使用好监控工具的挑战
- 对于本文第一节中描述的事态监控流程知识，你是否有足够深刻地认识和正确的实践能力？
- 对于本文第二节中描述的设计一个事态监控系统，你是否具备了需要掌握的技术系统、业务应用以及监控架构知识？
- 既然需要借助于这么多的监控工具才能保证不留死角的监控到技术与业务系统中每一个有监控价值的细节，那么你怎么才能管理、管控好这样大一盘散乱监控工具和监测到的事件信息？
- 一套好的监控系统是使用出来的，而不是搭建出来的，在面对一天几百个监测事件的报警信息时，你是否能有足够的决心和信心去坚持优化监控逻辑设计、消除监控杂音，以利于让高价值的故障事件和问题事件从一堆事件中浮现出来？
- 怎么才能保证源自多个监控系统的事态监测事件，都能得到，甚至是及时得到响应和处理呢，有什么措施可以帮助你的团队成员，甚至于是催促、监督和审计他们的工作？通过人力辛苦劳作显然不会是一个用户体验良好且无法持续坚持的解决办法。你可能会需要一个面向事件管理的工单系统，以及可以为团队监控值班提供支持的值班管理系统，当然了，这些IT支持服务最好是可以同时为各种监控系统提供兼容支持。
很多棘手的挑战是取决于你的专业知识、素养，以及信心和决心。这些挑战并不是那么容易被解决，事实上很多人也正是在搭建出一个或一套监控系统后，迅速被铺天盖地的事态监测事件淹没身亡了。
不过，至少最后的一项挑战，我们可以借助于Devops方法给出一个相对容易的解决办法。
3.3 使用Devops提升事态管理工作的效率
下文是使用zabbix监控系统作为生产事态监测事件的工具进行举例，使用禅道项目管理系统作为项目与工单任务的生命周期管理的案例。而承担功能集成作用的无疑是一个自动化运维技术平台，既然是讲Devops，那这个系统要么是依赖自研，要么是选取一个类似功能的开源项目做定制开发即可。
我们面临的困境或是拉低工作效率的最大挑战就是，事态监测信息都在zabbix系统中（实际上在下面的功能设计上，实现为了可以按需支持多种类型的监控系统），而zabbix并不为事件提供一个工单管理的服务。我们虽然安排运维值班团队轮流去监控系统上处理报警事件，但无疑人性的懒散、粗心、无纪律时刻都在挑战着这项工作任务的完整、有效执行。非担会有很多事件未得到及时响应，甚至有不少就是被有意无意的漏掉处理了。
因此，我们需要实现一个自动将事态监测事件生成为工单任务，指派给特定值班人员的技术系统。利用禅道项目管理软件提供的丰富、强大的任务管理功能，保证我们的事态监测事件处理上不会出现遗漏，为工单任务提供了一个生命周期管理，在工单关闭和后还可以对其处理结果进行评价。
（1）事态管理Devops功能设计头脑风暴
从上面中可以看出，我们这项针对事态事件的工单管理系统主要设计了三个功能组件：
- 监控系统组件
- 值班队列管理组件
- 监控响应计划组件
我们可以按需为多种类型的监控系统做做适配，以支持同时接入这个平台中，作为事态监测源使用。我们可以按需定义出不同的值班队列班表，分别用于系统、IT、网络或应用团队。而监控事件响应计划，当然也要支持按需创建，支持同时处理多个响应计划以为不同的运维团队服务。
（2）主要功能组件的实现样例
我们使用Python Django Web框架来实现这个自动化运维服务平台。
jmonitor模块作为该平台上的监控管理模块，功能如下面两个图片所示。
该模块由监控管理下的事件监控、值班队列、响应计划，以及设置模块下的禅道设置（提供必要的禅道配置信息管理）所构成。
jmonitor功能模块各组件的功能说明：
- 事件监控组件，提供增删改”事件监控系统”的功能，例如zabbix、cacti、监控宝，可以按需定义一个或多个。任何一种监控系统只要提供了api接口和方法，就可以在这里定义为一个提供“事件监控信息”的基础服务。这些事件监控信息可以为其它组件事件信息数据支持。
- 值班队列组件，我们经常需要安排多个人轮流响应和处理监控事件，这些人需要按一个值班表去进行管理。该组件提供了按需定义值班队列、值班时长、上岗以及按指定时间间隔轮岗的服务。可以按需定义多个不同用途的值班队列，在每个队列中再按需定义参加值班的成员是哪些。
- 响应计划组件，该组件提供了一个将多个基础服务组件关联起来的功能，即定义一个响应计划时，需要为其选定一个“事件监控组件”中定义的事件监控信息系统；需要指定一个在“值班队列组件”中定义了的队列；需要指定一个在“设置->禅道设置”模块中定义了的禅道系统使用信息。正确定义出一个响应计划后，jmonitor的自动将监控事件生成为禅道任务的功能配置就完成了，监控事件信息会作为禅道任务指派给值班人员处理。
设置->禅道设置的功能说明：
- 该组件提供了定义禅道项目、模块、关联产品，禅道系统账号/密码，禅道服务接口URL地址等信息的功能。
可以按自己的使用需求，为不同的系统、网络、IT等人员分别定义出他们自己适用的禅道项目、模块、账号等管理信息。
这些禅道项目配置信息，可以使用于jmonitor模块中，为生成禅道项目任务，提供信息支持。
（3）事件监控系统的具体实现
监控系统的配置信息：
（4）值班队列管理
值班表：可以自动轮换或手动点击上岗
（5）禅道系统配置信息
（6）事态监控事件响应计划
注：如上图所示，这个功能组件起到了在事件监控系统、值班队列和定制的禅道配置之间建立关联关系的重要作用。至此，我们就可以安排定进执行一下该表中定义出来的有效响应计划即可。最终的效果便是，由系统自动化地去查询zabbix api获取需要的事件信息列表，然后根据禅道配置信息，向指定禅道项目下写入新的监控事件工单任务，同时指派给从值班队列中得到的值班成员去执行任务。因为禅道项目管理系统自身有完善的任务生命周期管理功能，所以得到该任务的值班员很难能漏处理哪个报警事件。
（7）登录到我们的禅道项目任务管理系统中查看下成果
查看一下任务的详情页：
在任务描述中提供了待处理的zabbix监控事件信息，点击后会直接打开zabbix系统中的事件详情页。
