ITIL中如何管理突发事件?

1．事件管理概述和目标 ITIL事件管理（Incident Management）是一个被动性任务，就是减少或消除存在或可能存在于IT服务中的干扰因素给IT服务带来的影响，以确保用户可以尽快恢复自己的正常工作。事件管理要求将事件（Incidents）记录下来并分类，再分配给适当的专业人员去处理；事件管理也要监控事件的发展；并在事件得到解决之后将其终止。 事件管理的目标是要在给用户和公司正常的业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。 2. 事件管理的基本流程 ITIL 提供的参考流程如下：
3. 事件管理流程的角色 事件管理经理的职责：(1) 监控事件处理流程的效率和效果。(2) 控制支持小组的工作，协调1线支持人员升级到2线支持，或提交垂直升级（管理升级）。(3) 为改进事件处理工作提供建议。(4) 开发并维护事件管理系统。 支持小组人员及职责 (1) 1线支持小组：1线支持小组成员一般是日常维护人员，负责记录、分类、匹配、转交、解决和终止事件。事件记录人员：接收事件的第一个人，负责记录事件。如果不属于自己维护范围的，转到相应的1线支持人员；否则自己就是1线支持。服务热线：1线支持小组成员，主要提供用户一般电话支持，同时记录事件。必要时，进行现场服务。 (2) 2线支持小组：2线支持小组成员一般是各信息系统的管理人员。负责参与调查、诊断和恢复工作。 4. 事件管理的流程活动 (A) 事件的接收和记录： 事件的接收和记录应该是服务台的工作。事件一旦被接收，就应该被迅速记录下来。所有事件都必须及时记录，不能先处理再记录，以免处理过程得不到有效监控。 对事件的发现和报告分为以下情况：由某一用户发现：用户将此事件报告给1线支持人员或服务热线(事件记录人员)；由系统发现：(1) 系统监控自动在事件流程中登记；(2) 该系统的日常维护人员在事件流程中登记；或将此事件报告给1线支持人员； 由1线支持人员发现：该支持人员确保将此事件记录。 由其他IT人员发现：该人员在在事件流程中登记；或将其报告1线支持人员。 为了避免对同一事件进行重复记录的情况出现，在记录某个事件时需检查并确认是否已有相似的事件记录。 一个新的事件记录时，系统应该会自动分配一个事件号，该事件号可以作为标识来引用该事件。 事件记录中，除了事件号外，还有以下基本信息： 事件发生时间、事件被记录时间、事件的症状、报告事件的用户(或系统，如果事件由系统发现)、事件记录人员、处理问题的1线支持人员、处理事件的地点、受影响的用户/用户组、受影响的服务或硬件。 事件记录中还有附加事件记录：与事件相关的CMDB信息；与事件相关的其他信息，如交流过程等。 如果存在一个具有高影响度的事件，例如关键服务器瘫痪，接收事件后应立即警告其他用户和管理部门。 (B) 分类和初始支持 事件归类由1线支持人员处理，目的是确定事件的种类以便监控和报告。考虑到分类的准确和高效，一般可以考虑2级，大类的数量应该较粗，例如：服务器相关：涉及到服务器的事件，包括接入、系统、应用等的故障。这类故障一般包括服务器硬件、操作系统相关，如宕机、硬件坏、磁盘空间不足等。可能一开始报告的现象不是服务器相关，而是某一服务故障（如OA不能使用），大类记为“功能和使用”，但经过调查和诊断后，发现是服务器硬件故障，此时需更改分类为“服务器”。网络硬件相关：包括路由器、交换机、IP地址类的故障。这类故障一般包括网络硬件故障、或设置错误等。如果是外部网络故障（如Internet外部不能接入），应该划为服务类。其它公用设备相关：网络打印机、公共传真机、公用扫描仪、投影机、机房空调、机房UPS等划为此类。个人终端相关：用户电脑/工作站/手持式设备/外设，包括显示器、网卡、光驱、键盘、个人用打印机、传真机等故障。个人软件相关：用户电脑的操作系统、个人使用的办公软件、客户端软件。功能和使用相关：服务、能力、可用性、备份、手册等相关故障。 服务方面可以根据SLA类别进行分类，对于我公司的情况，也可将ERP、协同等划为大类中。 能力、可用性、备份方面可以根据能力管理、可用性管理、服务连续性管理的要求进行归类。 组织和程序相关：命令、请求、支持、沟通等；服务请求相关：要求支持、交付、信息、建议或文档。 这类其实不属于故障，用户希望能得到IT的某种支持，交付某个服务、提供一些信息、对IT方面的一些建议，或要求提供一些文档。 有些建议可能来源于某个设备故障、或者反映了能力或可用性方面有问题，这类建议应该改为事件处理，并将类别进行相应更改。 每个大类可以再细分小类。 事件的分类还要根据事件的影响度和紧急度来确定优先级。 优先级 = 影响度 * 紧急度 影响度、紧急度和优先级的定义说明参考“2. 基本名词定义”。 （C） 匹配 对事件进行分类后，要检查以前是否发生过类似的事件。如果发生过，则查看是否存在解决方案和应急措施。如果新事件与某一问题或某一已知错误具有相同的症状，那么就可将事件与这些已知的问题或错误进行关联。 （D） 调查和诊断 对于没有快速解决方案的事件，需要进行调查和诊断，初期的调查和诊断通过电话和网络进行，如果必要，还要到用户现场或事件相关的其它地点进行调查。 一般初期调查和诊断由1线支持小组人员进行，如果事件的复杂性超出他们的专业范围或水平，则提交事件经理，由事件经理转其他1线支持小组人员或其他有相应技术能力的2线支持小组人员进行处理。根据谁处理谁负责的原则，此时事件由接收任务的人员负责。 对于优先级低的复杂事件的调查和诊断可以持续到第二天、甚至第三天。对于优先级很高的紧急事件，如果估计或实际在限定的时间内不能完成调查和诊断，则必须立即升级处理，由事件经理转2线支持。如果技术升级估计或实际不能在限定的时间内完成，需要立即进行管理升级。 （E）解决和恢复 如果通过前面的匹配得出解决方案或应急措施，或通过成功的调查和诊断得出解决方案或应急措施后，负责解决问题的支持小组在系统中记录下事件的解决方案。对于某些解决方案来说，需要向变更管理提交变更请求(RFC)。在没有解决问题前，事件状态一直处于“Open”状态。 在解决和恢复活动中也必须记录过程和行动，以便对事件过程进行管理和监控，同时可以为今后的事件处理和问题管理等其它流程提供信息。 （F） 关闭事件（终止） ITIL中关闭事件一般由服务台进行，一般事件处理完成后，转事件经理，由事件经理关闭事件，在关闭事件前，事件经理必须检查事件的记录信息，更新信息或安排人员更新信息，以反映事件的最终分类和优先级、受影晌的服务、用户和客户，以及导致事件发生的配置项(CI)。 事件经理还必须确认解决措施和行动得到客户认可，客户满意。 事件经理还要检查记录事件所花的时间。 关闭时，系统自动记录关闭的人员、关闭时间。 （G） 监控和跟踪 事件经理负责监控突发事件的进展和调配有关资源，对于重大事件没有足够资源时，通过升级处理。1线支持小组和2线支持小组负责处理事件。 事件经理监控事件进展时，也要监控事件的分类和记录情况，有问题进行及时纠正。 事件经理负责对不同类型的事件进行分类、汇总，负责这类的报告。 5. 事件管理的KPI 事件管理的KPI包括一个周期（周或月、年）内的汇总数据，通过这些数据可以判断事件发展趋势。这些KPI例如：事件的总数；平均解决时间；按优先级计算的平均解决时间；在SLA的目标内解决的事件的占比；由1线支持解决的事件的占比；每个支持人员解决的事件数；服务请求的数量和占比；各事件大类的数量和占比； 6. 事件管理的关键成功因素 事件管理的关键成功因素包括（1）建立合适的服务台，（2）建立完善的IT基础架构和应急预案，（3）建立常见事件处理的知识库。