用户尝试错误的密码登录系统、cpu占用率超过预定阀值、任务执行中断报错、未授权的软件被安装等。既不属于正常也不属于例外的状况，是指那些没有被明确定义为正确的、允许的，或错误、不允许的情况，这类状况往往需要更进一步的监测，例如网络延迟时间高于正常范围却还没有达到不可接受的程度，cpu或内存占用率长时间维持在预定报警阀值之下一点点等。
至于事件属于何种情况，正常还是例外，这点在不同的组织、环境、服务级别的要求下也是不同的，没有明确统一的规定，it组织当自行制定，服务最终分解后的软件、硬件、服务的提供商可以给出一部分参考。以下给出一个event management process的详细例子。过程采用近epc的方式描述。event management的主要输入是源于日常的检查和即时触发的event。
在level 2层面，event management process被划分为3个主要活动：
eve.01 receive event，接收事件；
eve.02 response event，事件响应；
eve.03 event closure，事件结束。
eve.01 receive event包括事件的检测和过滤，以及优先级划分。事件的检测主要是通过对应应用系统本身的功能或是专用的监控系统实现，将收到的事件信息与在其他流程中定义的标准相结合，对其进行过滤、分类和优先级的排序。可以将事件划分为例外、警告和信息类。

对于例外，应按预先的定义，采取相应的处置方式，往往是借助事故管理、问题管理或变更管理实现的。信息性的事件由于也被认为是有意义的，因此虽然不需要采取针对性的响应，但需要妥善记录，以备他用。这类记录可能会以零散的方式被不同的系统分别自动保存于日志之中，也可以安排专应用软件实现集中保存。对于警告类的事件，一般需要进一步分析以决定处置方式，可能最终会变为例外或信息性的，也有可能需要临时处理。

事件的响应完成后应有回顾检查，以保证其执行的质量并对以后形成经验，以此形成一个pdca的闭环。实践中，事件管理可以和事故管理一样主要是由service desk来执行。这是因为通常service desk具有较充足的人力资源、单位人力成本较低、事件管理本身对事件的处理不用很复杂，可以依赖于事故管理、问题管理等其他流程的支持。同时，由于service desk是primary point of contact，与最终用户间存在最广泛和直接的联系，负责事件管理的人员最好是在service desk之内，或紧邻service desk，这样可以带来集同 (co-location)办公所具备的好处，尤其是可以增强沟通，使处于一线的service desk工程师在第一时间了解到问题以及对工作的影响，并有助于加速service desk和incident management的相关管理人员制定应急响应方案。
这里所说的应急响应方案并不等同于针对问题的解决方案，例如，当监控系统显示出某地办公室网络中断时，event management通常能先于最终用户打入的报修电话而首先发现问题，即使这个问题不能立即得到修复，service desk和incident management的相关管理人员依然可以做一些应急的准备，例如采用标准的回答语句，如当用户询问此问题时可回答“目前xx办公室的网络处于中断状态，所有网络相关的应用暂时都受到影响，我们已经了解到这个问题，目前网络组的同事正在修复，根据以往经验，有可能1小时左右能够解决。”，或是通报问题给指定的联系人等。

三、总结

由于事件管理中大量采用自动化的处理方法，因此对事件的定义、检查和响应方法都需要做出明确的规定，这是实现事件管理流程的重要前提。自动化的监控工具、系统往往能提供一些这方面的帮助。itil的核心方法论是pdca，流程和规则都不是死的，需要不断改进。事件的定义和响应方式，乃至流程步骤都需要根据业务发展不断调整。

参考文献：
[1]itil version 3 service operation – published by tso for ogc, 2007.

上一页  [1] [2]