ITIL Event管理流程的咨询设计（二）
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
六、流程活动
事件管理的活动通常是包括事件的发生、通知、监测、事件的过滤、事件的重要性判断、事件的关联、触发器、响应选择、事件回顾和事件关闭等。图是事件管理流程的总体流程概览，可以作为事件管理流程设计参考。
（1）事件发生（Event occurs ）
事件总是不断地发生的，但并不是所有的事件都需要监测和记录。因此很重要的一点就是，在设计、开发、管理和支持IT服务和IT基础架构工作中的每个人员，都应该理解哪些类型的事件需要监测和记录。
（2）事件通知（Event Notification ）
大部分的配置项（CI）都设计了关于传递自身相关的特定信息的功能。当某特定条件出现时，配置项（CI）自动产生一个通知。配置项内置了这种通知功能，例如，插入到一个应用程序中的钩子（Hook）程序等。
事件通知的产生可能是专有的通道，在这种情况下只有厂家的管理工具才能够检测到事件。但是，大多数配置项遵照开放标准（如SNMP）产生事件通知。
很多配置项都基于设计者的经验设置了用于产生一套标准的事件集，比如当需要“运行”某配置项时，通过与“启用”这项活动相关事件的生成机制而产生某种类型的事件。
对于其他类型配置项，为了启动监视功能，则需要安装某些“代理”软件。通常这些监控功能是免费的，但有时需要为工具软件许可付费。
理想情况下，服务设计流程应该定义需要产生哪些事件，然后说明各类配置项如何产生这些事件。在服务转换阶段，将设置相关的策略并测试事件发生情况。
事件管理的一个总体原则就是它包含的数据越有意义、越受关注，就越容易做出关于事件的决定。运营操作人员经常遇到错误消息编码，但完全不知道如何响应和处理它们。有意义的通知数据和清晰定义的角色、责任，需要在服务设计和服务转换阶段编写和记录下来。如果角色和责任定义不清楚，在事件告警时，没有人知道谁该做什么，这样就会导致失误或重复劳动。
（3）事件监测（ Event Detection ）
一旦事件通知产生，它将被运行在同一系统中的“代理”程序监测出来，或者直接传送到管理工具软件，这种管理工具软件能够读取和翻译事件的含义。
（4）事件过滤（ Event Filtering ）
事件过滤的目的是决定将事件传送到管理工具还是丢弃它。如果丢弃，事件通常记录在设备内的日志文件中，而不再做任何处理。
过滤不是必需的。对于有些关键的配置项，每个事件都是重要的并且直接送到管理工具的关联引擎中，甚至是重复的事件。
（5）事件的重要性判断（Significance of Events ）
通常，组织应当事先定义通知性消息、警告、异常三种事件类型的划分标准，并针对每一种情形定义明确的处理机制。在已经明确事件的划分标准的情况下，事件管理人员应对当前发生的事件作出判断。
（6）事件关联（Event Correlation ）
对于警告性事件，需要将其与其他警告或者异常进行关联，以进一步判断该警告的严重程度。有时候，单独来看某一个警告不算太严重，但当与其他关联事件结合起来判断，就会作出完全相反的结论。事件关联可以帮助IT运营管理者“未雨绸缪、防微杜渐”，从而实现真正的主动式预防。
关联工作通常由“关联引擎”完成，通常关联引擎是管理工具的一部分，它按照预定顺序的标准和规则对事件进行比较，这些标准通常被称为“业务规则”。
关联引擎是按照性能标准和其他运行环境相关指南进行设定的，这个性能标准在服务设计阶段就应当已经确立。
关联引擎的例子包括：
类似事件的数量（如同一个用户第三次用错误的密码登录，业务应用就会报告这是一台移动电脑不正常使用的方式，这表明该设备遗失或者被盗）；
产生相似事件配置项的数量；
一个特定行动是否关联到事件中的代码和数据；
事件是否表示异常；
利用率是否超标（比如设备是否超出阈值）；
是否需要更多的数据进一步调查事件，可能甚至通过轮询系统或数据库得到相关数据；
事件分类；
为事件分配优先级。
（7）触发器（ Trigger ）
如果事件关联识别出一个事件，这时就需要进行响应了。用于启动这个响应的机制就是触发器。
有很多不同类型的触发器，每个触发器设计成处理某一特定的仟务。比如：
故障（Incident）触发器：
变更触发器；
执行特定功能的脚本；
数据库触发器（限制用户访问特定记录、创建或删除数据库中的实体）。
（8）响应选择（Response Selection ）
在流程的这一环节，有大量响应措施可供选择，有一点需要重点注意的就是响应选项可能是多种选择的复合。比如需要保存日志以便日后参考，但同时还要将事件升级到运营管理组以采取行动。
不同的组织就会有不同的选项，并且肯定更加详细。比如，对于每个不同技术都有一系列的响应。关于决定哪个最合适和如何执行它的流程，没有在流程图中标明。可用的选项有：事件记录；自动响应；告警后人工干预；判断属于故障、问题还是变更；发起变更申请RFC；打开故障记录；打开并连接到问题记录和特殊类型的故障。
（9）回顾行动（Review Actions ）
由于每天发生数以千计的事件，所以不可能回顾每一个事件。但是有一点很重要，要检查每一个重要事件或异常是否被恰当处理了，或者跟踪事件类型的数量和发展趋势。在很多情况下，这些事情可以自动执行。比如，检查一台采用脚本自动执行启动的服务器，看看它是否正常工作。
在事件导致一个故障、问题和变更情况下，回顾行动不需要在这些流程中重复的回顾。展开回顾的意图是确保事件管理流程和其他流程之间的传递按照设计进行，并且确保采取所期望的行动。这样将确保来源于运营管理的故障、问题或变更不会在团队与团队之间丢失。
（10）关闭事件（Close Event）
一些事件将保持“打开”状态直到某一行动发生，比如关联到故障的事件。但是，很多事件并非处于“打开”或“关闭”状态。信息事件（Informational events）只是做简单日志，并作为备份和存储管理等其他流程的输入项。自动响应事件则一般在生成下一个事件后关闭，比如一台设备产生一个事件，并通过自动响应重新启动，一旦设备成功返回正常运行状态，它就会完成这个闭环，从而清除第一个事件。
有时候由于格式上的差异，将“打开”的事件与“关闭”的通知相关联就变得异常困难。理想的情况是，基础架构中的设备都以同样的格式生成“打开”和“关闭”事件，并明确其状态的变化。这就使得在流程中事件关联步骤更容易将“打开”和“关闭”通知进行匹配。
继续支持，学习中 学习了。 :) {:soso_e179:}
页:
[1]