02-ITIL 重大事件管理流程详细设计方案

ITIL重大事件管理流程详细设计方案
目录
目录 (2)
1综述 (4)
1.1设计目的 (4)
1.2适用范围 (4)
1.3相关术语 (4)
2重大事件流程设计 (4)
2.1流程目的 (4)
2.2与其他流程的关系 (5)
2.3关键角色、职责定义 (5)
2.3.1监控小组成员职责 (6)
2.3.2应急小组成员职责 (6)
2.3.3流程监督员职责 (6)
2.3.4故障分析报告邮件发送组 (6)
2.3.5实际岗位与方案角色的映射 (7)
2.4流程执行原则 (8)
2.4.1常规原则 (8)
2.4.2流程关联原则 (8)
2.4.3所有权原则 (8)
2.4.4关闭原则 (9)
2.4.5人员岗位与角色落实原则 (9)
2.4.6工单流转原则 (9)
2.5流程图设计 (10)
2.5.1重大事件流程图如下： (10)
2.5.2步骤说明 (10)
2.6流程相关定义 (11)
2.6.1事件信息项 (11)
2.6.2重大事件获知来源（必填项） (15)
2.6.3重大事件受影响系统(必填项) (15)
2.6.4重大事件影响程度 (17)
2.6.5重大事件原因分类(故障分类)标准 (17)
2.6.6是否影响可用率 (19)
2.6.7影响范围 (19)
2.6.8是否变更引起 (19)
2.6.9变更类型 (19)
2.6.10数据模型 (20)
2.7相关模板 (25)
2.7.1重大事件通知恢复模板 (25)
2.7.2重大事件故障分析报告模板 (25)
2.7.3重大事件改进措施跟踪表模板 (25)
2.7.4重大事件故障分析报告邮件通知模板 (25)
2.8报表需求 (25)
2.8.1关键应用系统综合可用率 (25)
2.8.2按照公司名称统计重大事件报表 (27)
2.8.3按服务目录统计重大事件 (27)
1综述
1.1设计目的
重大事件处理流程是运营体系服务保障中的重要组成部分，制定该流程的根本目的是在重大事件发生时，高效调动IT所有资源，高效协同诊断事件，以期在最短时间内恢复应用，减少关键业务系统的故障时间，提高IT资源的使用率，向用户提供更优质的IT服务。

1.2适用范围
重大事件流程的最终用户是总公司及各分支机构的信息人员。

该流程要求提供7×24小时服务。

1.3相关术语。

2重大事件流程设计
2.1流程目的
重大事件处理流程是运营体系服务保障中的重要组成部分，制定该流程的根本目的是在重大事件发生时，高效调动IT所有资源，高效协同诊断事件，以期在最短时间内恢复应用，减少关键业务系统的故障时间，提高IT资源的使用率，向用户提供更优质的IT服务。

事件接收和记录
这个环节是重大事件流程的起点，其来源主要是监控系统或用户上报。

此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。

在此步骤中将会收集创建重大事件记录所需的信息。

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

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

❑解决和恢复
支持人员实施事件的解决方案，并将解决完毕的重大事件工单转回服务台，由服务台通过邮件通知用户解决的结果。

❑结束重大事件
当确认重大事件解决后，此时可完成该重大事件，重大事件完成由重大事件的改进措施创建问题工单，并派发给改进措施的相关负责人，在必要时更新问题库。

2.2与其他流程的关系
❑和问题管理流程的关系
重大事件流程将提供故障的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及为重大事件解决并恢复服务后作为问题进行进一步的分析和处理。

❑和配置管理流程的关系
需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

❑和变更管理流程的关系
服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。

在重大事件的解决过程中，涉及到需要对基础架构、应用系统及操作系统等进行变更的需要发起变更请求来解决事件。

2.3关键角色、职责定义
流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系
列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时
也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足
流程所需角色的基础上，为具体的实现提供足够的灵活性。

重大事件流程主要分为以下几个职责/角色，分别简述如下：
2.3.1监控小组成员职责
✧及时处理监控报警信息，诊断错误，及时反馈进展信息，如遇重大问题及时通知应急小组成员。

✧非工作时间监控处理人由值班人员承担，如遇重大问题根据事故原因，及时电话通知应急小组成员，并根据
重大事件当值决策人的决策实施恢复行动。

✧严格遵守本流程制定的所有规则。

2.3.2应急小组成员职责
✧应急小组成员当确认为重大事件时，必须立刻根据当时故障定位情况电话通知本小组负责人。

✧接受各小组负责人的安排。

✧及时根据重大事件当值决策人的决策实施恢复行动。

✧严格遵守本流程制定的所有规则。

✧应急小组成员由各小组负责人指定，并根据附件4的格式提交小组成员通讯录。

✧详细记录处理过程
2.3.3流程监督员职责
✧负责督促整个流程的实施。

在每个关键时间点到达时提醒并监督各小组负责人处理重大事件，流程监督员负责将以上处理过程在《重大事件改进措施跟踪表》中进行记录并跟进改进措施的执行情况。

重大事件的最终当值决策人负责提供相关信息及资料。

2.3.4故障分析报告邮件发送组
✧知晓重大事件解决过程，各处理记录，原因分析，改善措施。

2.3.5实际岗位与方案角色的映射
2.4流程执行原则
2.4.1常规原则
❑所有IT和信息技术中心重大事件范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
❑应该每月产生重大事件报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的重大事件会议对这些事件进行评估
❑应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进重大事件流程
2.4.2流程关联原则
❑和问题管理的关联
➢所有严重的重大事件在恢复服务后，都应该由改进措施创建问题单（问题单必须和重大事件可建立关联）
➢支持人员在解决事件的过程中，可以通过问题记录查找相应的解决方案。

❑和变更管理的关联
➢重大事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理。

❑和配置管理的关联
➢重大事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位。

➢重大事件处理过程中，如果可以将故障定位到某个系统和相关的改进措施，改进措施创建问题工单，所创建的问题与重大事件相关联，如问题工单可以定位到某个配置项，则必须将问题工单与该配置
项关联。

2.4.3所有权原则
所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。

❑由监控人员建的事件单，服务台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责处理相关联的问题工单。

2.4.4关闭原则
与重大事件所关联的所有问题工单都关闭后，系统自动关闭重大事件工单。

2.4.5人员岗位与角色落实原则
❑
2.4.6工单流转原则
当重大事件发生时，通知组启动重大事件工单，并填写邮件通知内容和选择好邮件发送人并提交给相关处理记录人，处理记录人填写好处理过程后，因为可能有多个处理人，所以当所有人处理完成后，当提交给原因分析组后，提交时，系统发送重大事恢复通知，原因分析组分析重大事件发生的原因，并填写重大事件故障报告，填写完后，系统给故障分析报告邮件发送通知组发送重大事件故障分析报告邮件通知；提交给改进措施跟踪组，改进措施跟踪组改进所有的处理记录，并查看所以有处理过程的完成情况是不是都为已完成，如果是则完成工单，工单完成后，根据改进措施关联问题工单，并把问题工单派发给改进措施的负责人，由重大事件改进措施所关联的问题工单都关闭以后，系统自动关闭重大事件工单。

2.5流程图设计
2.5.1重大事件流程图如下：
2.5.2步骤说明
2.6流程相关定义
2.6.1事件信息项
事件单必须包含如下事件信息项：
注：以提供的模板为主
2.6.2重大事件获知来源（必填项）
重大事件来源用来标明事件的提出方式，重大事件来源可以包括以下几种：
2.6.3重大事件受影响系统(必填项)
根据目前信息技术中心支撑的应用系统和二级分类的划分定义事件所属系统类型，当事件发生时，应该由服务台初步定位是哪个系统及二级分类出现问题，由一线进行进一步的明确。

说明：第一层为”其它”的话，分公司可以对其子类可以扩充并提交到总公司，由总公司统一协调配置事件发生时的通告定义
2.6.4重大事件影响程度
事件影响度用于衡量事件所影响业务的严重程度。

严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。

2.6.5重大事件原因分类(故障分类)标准
2.6.6是否影响可用率
2.6.7影响范围
2.6.8是否变更引起
2.6.9变更类型
2.6.10数据模型
2.6.10.1 字段菜单配置表
2.6.10.2 改进措施跟踪表
2.6.10.3 通知对象后台表
2.6.10.4 处理过程记录表
2.6.10.5 单位营业时间配置表
2.6.10.6 系统配置表
2.6.10.7 发生系统人员角色配置表
2.6.10.8 故障分析报告邮件发送信息后台表
2.7相关模板
2.7.1重大事件通知恢复模板
重大事件通知恢复
模板.doc
2.7.2重大事件故障分析报告模板
重大事件故障分析
报告模板.doc
2.7.3重大事件改进措施跟踪表模板
重大故障改进措施
跟踪表.xls
2.7.4重大事件故障分析报告邮件通知模板
重大事件故障分析
报告邮件通知模板.do
2.8报表需求
2.8.1关键应用系统综合可用率
1、指标含义
重大事件指公司信息系统运行过程中发现的、导致关键业务应用中断、对公司信息系统乃至公司业务正常运营可能会造成重大或广泛影响的信息系统问题或突发事件，其发生的频率和时长直接说明了分公司综合IT 管理能力。

以故障通知为准，每一笔故障都需要录入服务管理系统（SDMS）；在服务窗口以外的故障不参与可用率计算；在服务管理管理（SDMS）记录为主，有条件的系统逐步使用与监控系统对接的辅助采集手段。

关键应用系统如下表：
服务窗口定义：5×8 5×12、6×12 、7×12、 7×15、 7×24
5×8是指各分公司营业或上班时间。

12小时代表：8：30-20：30
15小时代表：8：00-23：00
2009年统一采用5×8服务窗口。

服务窗口时段故障时间指在在服务窗口时段内每一次故障从发生时间到恢复时间的时长。

故障影响度：部分功能不可用－50%
整个系统不可用－100%
机构影响系数：部分机构不可用－0.5
整个机构不可用－1
服务窗口总时间指服务窗口总的时长合计。

时间：以分钟为单位。

数据来源：服务管理系统（SDMS）
计算公式：
关键应用系统可用率＝100%-∑（服务窗口时段故障时间×故障影响度×机构影响系数）/服务窗口总时间2、评分方法
2.8.2按照公司名称统计重大事件报表
统计条件：公司名称、统计期间（X年X月至X年X月）
报表输出格式:
重大事件统计表号：
2.8.3按服务目录统计重大事件
统计条件：服务目录级别、统计期间（X年X月至X年X月）
年月日
统计时间：年月日至。