04 某汽车金融公司ITIL事件管理流程说明书

返回本章节索引     阅读下一篇

某汽车金融公司ITIL事件管理流程说明书

1 .1 流程目的

本文档是针对IT桌面支持及IT运维项目范围内基于Agile-ITSM平台的相关事件进行处理的详细说明。

事件管理流程的主要功能是尽快解决出现的事件，保持业务系统的稳定性，其目的包括：

◆在成本允许的范围内尽快恢复IT服务

• 快速响应服务请求（电话/Web/邮件/短信等）
• 用户在线获得帮助
• 沟通事件解决的状态 
• 和客户确认事件的解决
• 启动应急预案

◆进行事件控制

• 按规范记录事件
• 就事件的优先级，影响度进行分类
• 分析，诊断，必要时进行升级
• 监视并结束事件
• 进行定期服务流程回顾

◆提供IT管理信息

• 人力资源利用情况
• 故障处理情况
• 支持效率

1.2 流程主要内容

事件管理流程始于事件的登记和报告，结束于事件的解决。该流程包含下述主要内容：

◆事件检测和记录

这个环节是事件管理流程的起点。所有用户或系统报告的IT事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。

◆分类和初步支持

对于每个事件，需要确立事件所属的领域、子领域和优先级。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

◆调查和诊断 

若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

◆解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回用户或通知用户解决的结果，并得到用户的确认。

◆优先级为一级的事件（紧急事件）和事件升级

用户报告经运维一线判定事件优先级为一级事件，将立刻转交给应急小组并上报管理层；在经应急小组确认事件优先级后，立即启动紧急事件流程。

◆结束事件

当用户确认事件解决后，此时可结束该事件。

◆事件例外

当发生如地震、洪水和战争等不可抗力的因素时，由此导致的故障将不作为事件管理流程记录范围。

1.3 与其他流程的关系

◆和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来进行事件趋势分析和问题定位；在优先级为一级的事件解决并恢复服务后做为问题进行进一步的分析和处理。

◆和配置与资产管理流程的关系

需要从配置与资产管理清单中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

◆和变更管理流程的关系

变更实施人员和监控人员应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。

1.4 流程范围

在此次项目中事件管理流程的范围包括涉及用户端的软硬件、机房内的基础架构和应用系统

不包括：

◆尚处于开发或测试环境的系统和应用引发的事件

1.5 流程执行原则

1.5.1 常规原则

• 所有IT事件管理范围内发生的事件，都应该记录在Agile-ITSM平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
• 所有IT支持人员对优先级为一级和二级的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
• 应该每月产生事件管理报表，包含对考核指标的统计，以及相应的报表。并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
• 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

1.5.2 所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。

表2-1 事件管理RACI模型

1.5.3 再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组，由组内的支持人员处理。

• 一线技术人员可以将事件单分配给其他一线技术人员。
• 一线支持人员可以将事件单重新再分配给其他一线支持人员或升级厂商。
• 一线支持人员将事件升级至厂商后，由于一线支持人员代表厂商完成工单流转。

1.5.4 重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件，或者一人/多人申告的同一来源（系统、应用）现象相同的事件。

当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

• 重复的事件必须被关联，并且不计入事件流程的关键衡量指标。
• 如果一线技术人员可以判断到重复事件，则由一线支持人员关联重复事件，否则由事件经理进行关联。

1.5.5 关闭原则

事件工单关闭环节的基本原则：谁开单，谁负责关闭。

◆ 用户通过系统登记事件工单或IT人员通过电话、邮件等方式受理的事件工单，由一线支持人员与用户确认解决后进行关闭。

◆ 一线支持人员自行创建的事件单，由创建人关闭。

◆ 监控平台产生的告警，由一线支持人员根据监控平台的反馈确认后关闭。

◆ 优先级为一级的事件工单由事件经理进行关闭。

◆ 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码并转用户关闭：

• 用户确认问题已解决，则关闭工单。
• 工单处理人员在转用户确认后，要与用户持续保持沟通，了解用户对工单处理的满意程度；如果用户不满意，则需要进一步处理直至满足用户需求。

◆已关闭的事件单不允许重开。如果事件再次发生，则创建一个新的事件单，并与已关闭的工单进行关联。

1.5.6 升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

• 对所有事件，一线支持人员应立即接受事件单并着手解决。
• 优先级为一级的事件，由应急小组再次确认，如果确认了优先级为一级，则通过线下通知的方式升级到事件经理，启动紧急事件处理流程。
• 优先级为二级的事件，一线人员处理4小时后，如不能解决，则要求立即升级到二线人员进行处理。
• 优先级为三、四、五级的事件，处理时间超过80%时，由事件经理对处理人进行督促，要求将规定时间内不能解决的事件升级。（一线升级到厂商）。
• 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定解决时限，运维管理系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理。
• 各支持人员处理优先级为三、四、五级的事件时，应及时将不能解决的事件升级；事件经理对未及时升级的事件及时介入，负责协调升级处理。事件经理通过对事件的抽查和对超时解决的事件统计情况对各支持人员的主动性进行监督。

1.6 流程相关定义

1.6.1 事件信息项

事件单包含如下事件信息项：

1.6.2 事件优先级判定标准

用户/BA在登记事件单时根据系统所属的领域、子领域的选择和影响范围两者加权来定义事件优先级。

表5-2事件优先级

1.6.3 服务类别、服务子类 

表5-3服务类别、服务子类域、业务关键程度和对应一线映射表

1.6.4 事件响应时限和解决时限

在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于优先级别高的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间；

解决时限指的是事件状态从“已登记”到“已解决”经过的时间；

事件优先级对应的事件响应时限和解决时限参考下表（以下时间是9×5工作时间）：

 表5-4事件响应·解决·升级时限

超出和即将超出解决时限的通告定义：

通知人员列表的用途：当Agile-ITSM平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件通知。

​​​​​​​1.6.5 通知与提醒

在事件流程开始和处理过程中，发送满足以下条件的通知或提醒，推进事件工单的及时执行：

• 当事件工单分（转）派时，发送通知给接收人。
• 当一级事件确认后，通知应急小组。
• 对二、三、四、五和九级优先级的事件，在处理时间过去50%时，发送提醒给事件处理人和事件经理。
• 对二、三、四、五、九级优先级的事件，超过解决时间时，发送提醒给事件处理人和事件经理。

 表5-4通知时间和对应人员列表

​​​​​​​1.6.6 故障厂商列表

用来在事件单中记录是哪个厂商的设备/系统或者哪个集成商的应用软件发生故障。

表5-5故障厂商列表

​​​​​​​1.7 流程设计

为了更清晰地描述事件管理流程，我们将通过事件管理流程和紧急事件管理流程来详述：

1.7.1 事件管理流程

事件管理流程文字说明：

 一线互相转派子流程文字说明：

​​​​​​​1.7 一级（紧急）事件管理流程

图5-2 一级（紧急）事件管理流程

制定一级（紧急）事件管理流程的目标：

◆当（一级）紧急事件发生时，尽可能采取措施减少对于业务带来的影响。

◆确保对紧急情况的有效管理：

• 加快一级（紧急）事件的响应和处理速度。
• 对紧急情况中的人员及采取的行动加强管理。
• 加强处理人员与用户之间的沟通和反馈。
• 对紧急情况妥善处理。

一级（紧急）事件处理的特殊性包括各系统应急处理预案的制定和使用，及时上报等。

应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。

由于一级（紧急）事件通常对企业造成非常严重的影响，从实际工作出发此时在进行电子化工单的流转不合适宜，因此当事件经理对一级（紧急）事件进行确认后，应急小组直接介入处理，待一级（紧急事件）解除后，由事件主要相关一线进行补单。

一级（紧急）事件管理流程文字说明：

​​​​​​​1.8 关键角色、职责定义

事件管理流程主要分为以下角色：

​​​​​​​1.8.1 事件管理流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职责：

1. 确定管理流程的衡量指标
2. 确保事件流程能够取得管理层的参与和支持
3. 确保事件流程符合公司实际状况和公司 IT发展战略
4. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
5. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
6. 保持与其他流程负责人的定期沟通

​​​​​​​1.8.2 事件经理

事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。

职责

1. 负责对事件的解决协调资源，保证故障的最终排除
2. 确保和问题管理流程经理的有效合作
3. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
4. 监督优先级为紧急、高的事件的处理情况
5. 监督一线是否及时将事件工单升级。

1.8.3 一线支持人员

一线支持人员根据预定义进行不同类型的事件开单和接受事件，对事件进行快速有效的分析，提出解决方案以尽快恢复服务。在解决事件过程中，一线支持人员可以再分类和转派事件至其他一线支持小组；另外，一线支持人员可以将事件升级至厂商寻求技术支持。

职责：

1. 按照系统进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务；
2. 验证事件的描述和信息，进一步收集相关信息；
3. 进行深入调查研究或协调二线支持，提供/获取有效的解决方案；
4. 实施事件解决方案；
5. 更新事件解决信息，已解决的事件转用户确认。

1.8.4 二线支持人员

包括现场支持和远程支持设备厂商。

职责:

1. 必要时提供现场支持和深入调查研究，提供有效的解决方案
2. 参与解决方案的实施
3. 将解决方案和实施结果反馈给一线人员，由一线人员进行解决方案的记录。

1.8.5 流程角色和人员对应表

 表5-6流程角色和人员对应表

​​​​​​​1.8.6 关键流程衡量指标

为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

表5-7流程角色和人员对应表 

返回本章节索引     阅读下一篇