2000年至2004年，ITIL的第二个版本ITILv2出版，在第一个版本的基础上进行了修订，并在一个总的框架下合并至7本核心书籍，包括Service Support, Service Delivery, ICT Infrastructure Management, Planning to Implement Service Management, Application Management, The Business Perspective 以及Security Management，其中前两本即蓝皮的Service Support 和红皮的Service Delivery主要探讨了服务管理，最受IT专业人士的关注。ITIL V2 在全球范围内被广泛采用，成为有效提供IT服务的基础。
在ITIL v2 中，IT管理活动被归纳为一项管理功能和十个核心流程，分别是服务台，事故管理，问题管理，变更管理，发布管理，配置管理，服务级别管理，财务管理，持续性管理，能力管理，可用性管理。这些总共被分为两类，其中Service Desk和前面5个流程属于Service Support，后面5个流程属于Service Delivery。
2007年5月，ITIL v3发表，它在v2的基础上，将ITIL的最佳实践和业务的需求都作了更进一步的明确和增强，将原先以服务交付为视角转变为以生命周期(life cycle)为视角。由5本核心书籍构成，即Service Strategy、Service Design、Service Transition、Service Operation、Continual Service Improvement。分别面对是，如何为IT服务管理开发业务驱动的战略；如何设计一个系统去支持已选定的战略；如何将新设计的系统转入生产环境；如何在日常运行中提供支持；如何持续改进流程和运作。它涵盖了从初始的业务需求定义和分析，经过转入现实环境，到现实中的运行维护和改善的IT服务生命周期的各个阶段。
一、事件管理的意义
事件event可以被定义为，发生的任何可发现、可辨别的，对IT基础架构管理、IT服务交付以及服务影响评估有意义的事情。负责管理事件的整个生命周期的流程就是事件管理流程Event Management Process。
事件管理流程在ITIL v2时还不是一个单独的流程，而可以被认为是涵盖于事故管理Incident Management流程内，在ITIL v3中独立出来。直观一点来说，一个最简单的事件管理的例子就是，Service Desk或其他相关的IT运维部门出2个人，负责关注监控工具的输出和报警，甚至这2个人也可以不是全职负责监控或不是专职技术人员，当发现异常事件发生时，他们要马上联系相关人员并生成相应的incident ticket。
事故管理中的事故往往是来自多方的输入，包括来自事件管理的输入，但更主要的是来自最终用户的直接反馈。与事故不同，事件的来源则通常是自动化的监控工具、系统，于是IT部门便有可能在最终用户发现之前首先发现问题。监控有两种，主动的和被动的，主动的是指没有报警提示而主动去检查各关键CI (配置项)的状态和可用性；被动监测是在事件被认为已发生的情况下根据相关报警信息去检查可疑CI。
事故管理相对来说比较倚赖监控工具或系统。其负责的范围包括各类CI，尤其是以下两种：
1．关键且通常需要稳定维持在常态的CI。例如核心网络设备，端口要求是up的，链路要求是连通的。
2．状态需要经常改变的CI。由于这种CI状态经常改变，在CMS中的对应更新会牵扯较多精力，事件管理可以帮忙实现CMS自动更新。
此外，它的范围还可包括：（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的相关管理人员制定应急响应方案。
这里所说的应急响应方案并不等同于针对问题的解决方案，例如，当监控系统显示出某地办公室网络中断时，Event Management通常能先于最终用户打入的报修电话而首先发现问题，即使这个问题不能立即得到修复，Service Desk和Incident Management的相关管理人员依然可以做一些应急的准备，例如采用标准的回答语句，如当用户询问此问题时可回答“目前xx办公室的网络处于中断状态，所有网络相关的应用暂时都受到影响，我们已经了解到这个问题，目前网络组的同事正在修复，根据以往经验，有可能1小时左右能够解决。”，或是通报问题给指定的联系人等。
三、总结
由于事件管理中大量采用自动化的处理方法，因此对事件的定义、检查和响应方法都需要做出明确的规定，这是实现事件管理流程的重要前提。自动化的监控工具、系统往往能提供一些这方面的帮助。ITIL的核心方法论是PDCA，流程和规则都不是死的，需要不断改进。事件的定义和响应方式，乃至流程步骤都需要根据业务发展不断调整。
|
转播
分享
淘帖
()
