此外，它的范围还可包括：（1）环境条件，如机房状况、温度、湿度、水、火、烟、供电等。（2）安全，机房门禁、入侵检测(网络)等。（3）软件使用状况，是否有非法软件使用、软件使用率和分布等。（4）性能表现，leased line带宽占用率、存储状况、服务器(内存、CPU、硬盘)状况等。
实际上，监控(monitoring)这个术语所涵盖的范围是大于事件管理的，事件管理是事件驱动的，而监控不仅监控事件，也可以监控那些没有触发事件的状况。
事件管理的价值很明显。首先，由于它可能先于用户发现问题、先于服务中断就做出响应，将一部分外部失效成本转化为了内部失效成本，减少了对客户造成的影响。其次，事件管理中可以通过对自动化工具的应用实现大部分的监测工作和一部分处理工作，提高响应效率，降低人工成本。此外，事件管理还提供了一个检查现实状态的途径，它所提供的输出可以作为其他流程的输入，为Availability Management、Capacity Management等提供信息，或是用来和设计、基线如SLA等作比较，成为服务报告、保证和改进的重要依据，可以为乃至IT服务管理整体改进提供支持。
二、方法和模型
不同类型的事件对应不同类型的处理方式。事件可以有多种分类方式，按照事件是否符合预期，可以分为三类，正常、例外以及既不属于正常也不属于例外的状况。正常，指已定义为没有问题的情况，比如用户登录了某系统、计划任务运行完成等。例外，指已定义为有问题或不可以的情况，比如用户尝试错误的密码登录系统、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的相关管理人员制定应急响应方案。
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说计算机ＩＴ服务管理中事件管理过程的实现模型(2)在线全文阅读。
