[p=30,2,left] 学习资料：IT运维管理社区专家讲堂直播300期视频回放[p=30,2,left]
[p=30,2,center]
一、事件Event流程管理的意义
事件event可以被定义为，发生的任何可发现、可辨别的，对IT基础架构管理、IT服务交付以及服务影响评估有意义的事情。负责管理事件的整个生命周期的流程就是事件管理流程EventManagementProcess。
事件管理流程在ITILv2时还不是一个单独的流程，而可以被认为是涵盖于事故管理IncidentManagement流程内，在ITILv3中独立出来。直观一点来说，一个最简单的事件管理的例子就是，ServiceDesk或其他相关的IT运维部门出2个人，负责关注监控工具的输出和报警，甚至这2个人也可以不是全职负责监控或不是专职技术人员，当发现异常事件发生时，他们要马上联系相关人员并生成相应的incidentticket。
事故管理中的事故往往是来自多方的输入，包括来自事件管理的输入，但更主要的是来自最终用户的直接反馈。与事故不同，事件的来源则通常是自动化的监控工具、系统，于是IT部门便有可能在最终用户发现之前首先发现问题。监控有两种，主动的和被动的，主动的是指没有报警提示而主动去检查各关键CI(配置项)的状态和可用性；被动监测是在事件被认为已发生的情况下根据相关报警信息去检查可疑CI。
事故管理相对来说比较倚赖监控工具或系统。其负责的范围包括各类CI，尤其是以下两种：
1．关键且通常需要稳定维持在常态的CI。例如核心网络设备，端口要求是up的，链路要求是连通的。
2．状态需要经常改变的CI。由于这种CI状态经常改变，在CMS中的对应更新会牵扯较多精力，事件管理可以帮忙实现CMS自动更新。
此外，它的范围还可包括：（1）环境条件，如机房状况、温度、湿度、水、火、烟、供电等。（2）安全，机房门禁、入侵检测(网络)等。（3）软件使用状况，是否有非法软件使用、软件使用率和分布等。（4）性能表现，leasedline带宽占用率、存储状况、服务器(内存、CPU、硬盘)状况等。
实际上，监控(monitoring)这个术语所涵盖的范围是大于事件管理的，事件管理是事件驱动的，而监控不仅监控事件，也可以监控那些没有触发事件的状况。
事件管理的价值很明显。首先，由于它可能先于用户发现问题、先于服务中断就做出响应，将一部分外部失效成本转化为了内部失效成本，减少了对客户造成的影响。其次，事件管理中可以通过对自动化工具的应用实现大部分的监测工作和一部分处理工作，提高响应效率，降低人工成本。此外，事件管理还提供了一个检查现实状态的途径，它所提供的输出可以作为其他流程的输入，为AvailabilityManagement、CapacityManagement等提供信息，或是用来和设计、基线如SLA等作比较，成为服务报告、保证和改进的重要依据，可以为乃至IT服务管理整体改进提供支持。
二、方法和模型
不同类型的事件对应不同类型的处理方式。事件可以有多种分类方式，按照事件是否符合预期，可以分为三类，正常、例外以及既不属于正常也不属于例外的状况。正常，指已定义为没有问题的情况，比如用户登录了某系统、计划任务运行完成等。例外，指已定义为有问题或不可以的情况，比如用户尝试错误的密码登录系统、CPU占用率超过预定阀值、任务执行中断报错、未授权的软件被安装等。既不属于正常也不属于例外的状况，是指那些没有被明确定义为正确的、允许的，或错误、不允许的情况，这类状况往往需要更进一步的监测，例如网络延迟时间高于正常范围却还没有达到不可接受的程度，CPU或内存占用率长时间维持在预定报警阀值之下一点点等。
至于事件属于何种情况，正常还是例外，这点在不同的组织、环境、服务级别的要求下也是不同的，没有明确统一的规定，IT组织当自行制定，服务最终分解后的软件、硬件、服务的提供商可以给出一部分参考。以下给出一个EventManagementProcess的详细例子。过程采用近EPC的方式描述。EventManagement的主要输入是源于日常的检查和即时触发的event。
在Level2层面，EventManagementProcess被划分为3个主要活动：
Eve.01Receiveevent，接收事件；
Eve.02Responseevent，事件响应；
Eve.03Eventclosure，事件结束。
Eve.01Receiveevent包括事件的检测和过滤，以及优先级划分。事件的检测主要是通过对应应用系统本身的功能或是专用的监控系统实现，将收到的事件信息与在其他流程中定义的标准相结合，对其进行过滤、分类和优先级的排序。可以将事件划分为例外、警告和信息类。
对于例外，应按预先的定义，采取相应的处置方式，往往是借助事故管理、问题管理或变更管理实现的。信息性的事件由于也被认为是有意义的，因此虽然不需要采取针对性的响应，但需要妥善记录，以备他用。这类记录可能会以零散的方式被不同的系统分别自动保存于日志之中，也可以安排专应用软件实现集中保存。对于警告类的事件，一般需要进一步分析以决定处置方式，可能最终会变为例外或信息性的，也有可能需要临时处理。
事件的响应完成后应有回顾检查，以保证其执行的质量并对以后形成经验，以此形成一个PDCA的闭环。实践中，事件管理可以和事故管理一样主要是由ServiceDesk来执行。这是因为通常ServiceDesk具有较充足的人力资源、单位人力成本较低、事件管理本身对事件的处理不用很复杂，可以依赖于事故管理、问题管理等其他流程的支持。同时，由于ServiceDesk是primarypointofcontact，与最终用户间存在最广泛和直接的联系，负责事件管理的人员最好是在ServiceDesk之内，或紧邻ServiceDesk，这样可以带来集同(Co-Location)办公所具备的好处，尤其是可以增强沟通，使处于一线的ServiceDesk工程师在第一时间了解到问题以及对工作的影响，并有助于加速ServiceDesk和IncidentManagement的相关管理人员制定应急响应方案。
这里所说的应急响应方案并不等同于针对问题的解决方案，例如，当监控系统显示出某地办公室网络中断时，EventManagement通常能先于最终用户打入的报修电话而首先发现问题，即使这个问题不能立即得到修复，ServiceDesk和IncidentManagement的相关管理人员依然可以做一些应急的准备，例如采用标准的回答语句，如当用户询问此问题时可回答“目前xx办公室的网络处于中断状态，所有网络相关的应用暂时都受到影响，我们已经了解到这个问题，目前网络组的同事正在修复，根据以往经验，有可能1小时左右能够解决。”，或是通报问题给指定的联系人等。
三、总结
由于事件管理中大量采用自动化的处理方法，因此对事件的定义、检查和响应方法都需要做出明确的规定，这是实现事件管理流程的重要前提。自动化的监控工具、系统往往能提供一些这方面的帮助。ITIL的核心方法论是PDCA，流程和规则都不是死的，需要不断改进。事件的定义和响应方式，乃至流程步骤都需要根据业务发展不断调整。
|
转播
分享
淘帖
()
