ITIL流程体系之事件管理流程设计.docx
《ITIL流程体系之事件管理流程设计.docx》由会员分享，可在线阅读，更多相关《ITIL流程体系之事件管理流程设计.docx（23页珍藏版）》请在冰豆网上搜索。
ITIL流程体系之事件管理流程设计
密级分类：
IT服务事件管理
文件编号：
版本：
1.0
2018-X-X颁布2018-X-X实施
来源于ITIL之家微信公众平台
文档修订记录
版本号
版本日期
修改人
审批人
修改章节
修改记录
1.概述
1.1.目标
尽快解决日常工作环境中出现的事件，保持IT服务的稳定性，监控事件的发展，并在事件得到解决之后将其关闭。
1.2.范围
管理流程
适用范围
管理范围
对于所提供的服务在日常运维过程中出现事件的识别、记录、调查、解决和关闭的管理
2.术语、定义
序号
术语
定义
1
事件
服务的意外中断或服务质量的下降。
尚未影响服务的配置项失效也是事件，例如镜像组中一块磁盘的失效。
2
服务请求
用户对信息、建议、标准变更或服务访问的请求。
例如重置密码、为新用户提供标准的服务。
服务请求通常由服务台处理。
3
重大事件
对业务有重大影响的事件，重大事件将导致重要业务的中断。
一般事件影响度或优先级为1级的事件默认定义为重大事件。
4
升级
在需要时获得额外资源，以达到服务级别目标或客户期望的活动。
任何服务管理流程内部都可以升级，但是升级常常与事件管理、问题管理和有关客户投诉的管理有关联。
主要有两种类型的升级：
技术升级和管理升级。
5
管理升级
通知更多的高级管理人员或使他们参与解决疑难问题升级。
6
技术升级
将事件、问题或变更转给具有更高技术的小组，以便进行疑难问题升级。
7
响应时间
一种衡量完成运营或交易所需时间的指标，在性能管理中一般用于测量IT基础架构的性能，但在事件管理中主要用于测量接起电话或开始诊断的时间。
8
目标解决时间
为了更好的控制事件、变更等流程的整个处理过程，将处理过程被划分成几个阶段，并对每个阶段的完成时限设定了目标，即目标解决时间。
9
紧急度
测量事件、问题或变更多久会对业务产生重大的影响。
例如，如果事件到年底才会影响业务，则影响大的事件可能紧急程度较低。
指定优先级时要考虑到影响度和紧急度。
10
影响度
事件、问题或变更对业务流程影响的一种测量，影响度通常基于服务级别会如何受影响。
指定优先级时要考虑到影响度和紧急度。
11
优先级
用于确定事件、问题或变更的相对重要性的类别。
优先级的依据是影响度和紧急度，用它来确定采取行动所需的时间。
例如SLA可以规定：
优先级2的事件必须在12小时内解决。
12
挂起
事件、变更等流程可能因非技术原因而无法进行下去，此时可以暂停计算流程处理时间，挂起的目的在于更加公正的统计流程处理时间等与流程处理人员相关的指标。
13
临时措施
也称“变通方案”，在还没有完全的解决方法时，减少或消除事件或问题的影响。
例如重新启动发生事件的配置项。
14
知识管理
负责收集、分析、保存和共享组织内部的知识和信息的流程。
知识管理的主要目的是通过减少重新发现知识的需要，从而提高效率。
15
知识库
一个逻辑数据库，其中包含了服务知识管理系统使用的数据。
3.角色和职责
角色
职责描述
对应岗位
报障人
●向服务台提交所发现的需要处理的事件。
●与服务台确认事件处理结果。
所有可以发起事件的人
服务台
●接听热线电话，响应用户报障需求，对用户进行初步相应的指导解决。
●响应用户通过邮件、微信以及手机APP等方式的报障需求。
●快速响应报障需求，为用户提供高效的远程服务。
●及时联系现场工程师为用户提供服务。
●及时联系二线支持人员为用户解决问题。
●在ITSM平台中准确并及时录入事件信息。
●对事件进行全程跟进，直到解决。
●负责在事件解决后生成问题单或录入知识库（FAQ）。
客服
二线指派工程师
●响应服务台派出的事件单，提供现场服务，包括备件更换安装服务。
●在ITSM平台中准确并及时录入事件处理详细信息。
●需要时发起服务请求单或变更单。
●负责升级必要的事件到三线工程师或者供应商。
●负责在事件解决后生成问题单或录入知识库。
三线指派工程师
●响应二线工程师升级的工单，提供现场服务，包括备件更换安装服务，系统支持服务，工程服务等。
●在ITSM平台中准确并及时录入事件处理详细信息。
●需要时发起变更单。
●负责在事件解决后生成问题单或录入知识库。
供应商
●负责响应由二线或三线升级的事件单。
●对事件单信息进行分析，并提供相应的解决方案。
外部设备供应商与服务提供商。
事件经理
●设计和改进事件管理流程。
●设定事件管理的绩效指标并考核指标完成程度。
●跟踪、监控各事件流转状态，抽查事件记录。
●收集汇总流程信息，编制管理报告，反映存在问题，提出改进建议，制定改进计划。
分管领导
●接收事件经理升级的重大事件。
●必要时与事件经理共同跟进重大事件，协调资源。
●审批重大事件报告。
4.输入
编号
输入项
来源
周期
1.
报障人提交的事件
通过热线电话、邮件、微信、APP等方式
发生时
5.输出
编号
输出项
去向
周期
1.
事件记录
流程内部
发生时
2.
变更请求
变更管理流程
发生时
3.
问题记录
问题管理流程
发生时
4.
服务请求
服务请求管理流程
发生时
5.
知识记录
知识管理流程
发生时
6.
重大事件报告
流程内部
发生时
7.
事件管理报告
服务报告管理
每月
8.
备件请求
备件管理流程
发生时
6.流程描述
6.1.管理定义
6.1.1.事件分类
序号
系统名称
故障类型
故障现象
所属范围
6.1.1.1.事件优先级
事件优先级分为4级，原则具体如下：
事件优先级
一级
二级
三级
四级
●事件分级在事件的生命周期中是可以改变的，但是关于更改事件分级的原因和行为应该在事件单中记录；
●分级的准确评定需要不断地回顾事件，从而优化事件的分类和设定准确的分级。
事件优先级：
事件优先级由发生事件所导致的严重程度及影响范围所确定，具体划分细则如下：
ØA级：
事件非常严重，系统不能正常运转，没有任何变通解决办法，要求立即采取行动。
这种故障通常与导致系统不能正常使用的系统崩溃有关。
系统或整个企业功能关闭或不能运行。
ØB级：
是指故障严重，系统能够运行，但需要使用人工流程或其他变通方法使业务能继续进行。
ØC级：
是性质不太严重的事件，影响（但未阻止）客户完成工作的能力。
ØD级：
是用户终端故障。
性质轻微的事件，影响（但未阻止）客户完成工作的能力，可以通过更换或重启外部设备解决。
6.1.2.处理时间要求
不同分级的事件对应不同的远程和现场的响应和解决时间，具体如下（供应商的解决时间由转出责任人来承担，并对供应商的解决时间进行评定）：
事件分级
一线转出时间
二线解决时间
升级解决时间
整体解决时间
一级事件
5分钟
10分钟
15分钟
30分钟
二级事件
5分钟
20分钟
20分钟
45分钟
三级事件
5分钟
25分钟
30分钟
60分钟
四级事件
5分钟
55分钟
60分钟
120分钟
其中主要考核时间为一线转出和二线解决时间，如果遇到需要升级给三线或者供应商的时候，一律统计为升级解决时间。
6.1.3.事件升级原则定义
事件升级原则定义的目的是为不同优先级的事件分配合适的资源，确保其在约定的时限内得到解决。
从事件单创建之后所经过的时间作为触发事件升级的时间标准。
事件升级方式包括：
技术升级和管理升级。
技术升级：
指基于技术能力要求而将事件转移给更高技术级别的运维支持团队。
包括从一线派单给二线，二线转移给三线，或二三线派单给供应商。
管理升级：
一、二级事件发生时，服务台需要立即通知事件经理，并由事件经理通知分管领导。
对于所有级别的事件，若未在规定时间内解决，服务台工程师需升级至事件经理。
事件分级
事件经理
分管领导
一级事件
立即、超时
立即
二级事件
立即、超时
立即
三级事件
超时
N/A
四级事件
超时
N/A
6.1.4.重大事件定义
事件级别为一级和二级的事件称为重大事件。
重大事件需要在第一时间通知事件经理，并由事件经理通知分管领导，由事件经理全程跟进。
事件解决后，需要对重大事件进行回顾，分析原因，并采取改进措施，需要由事件解决人提交《重大事件报告》，经事件经理审核后，上报分管领导。
除了一级与二级事件外，当出现以下情况下，可以由事件经理直接将事件升级为重大事件：
6.1.5.事件状态
“事件状态”表明事件当前所处的处理状态，具体定义如下：
状态代码
描述
服务台受理
一个事件已经被服务台记录或创建。
待响应
一个事件已经被分派，等待指派工程师受理。
受理中
指派工程师已响应被分派的工单，并对工单进行分析和处理。
挂起
事件信息不完整，或在某些情况下阻止事件处理人对事件进行处理，此时事件处理时间计算暂停，挂起的原因包括：
1.需要用户提供更详细的信息；
2.不能联系到用户；
3.自身无法解决需要提交供应商解决的工单；
4.不可抗拒力原因。
所有挂起过事件，须每月以报表形式由工具输出，由事件经理进行分析与检验。
升级处理中
事件由供应商或三线工程师进行处理，但当前指派工程师依然为主要责任人。
已解决
为一个事件找到解决方案或变通方法并已实施完成，等待关闭前确认。
已关闭
事件经用户确认已关闭。
6.1.6.事件解决
“事件解决”用来表示事件处理的结果，事件解决的代码包括以下几种：
解决代码
描述
成功解决
事件获得成功解决。
变通方法解决
事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步处理或根源分析，需要发起新的服务请求或事件，或变更，或问题记录。
事件消失
没有找到错误或不能重现事件，事件自行消失。
用户取消
用户要求关闭此故事件，例如：
误报、错报事件。
6.1.7.解决分类
“解决分类”用来表示事件具体通过怎样的方式进行解决处理的，例如：
更换设备、版本升级等。
6.1.8.用户满意度评价
用户可对事件处理结果进行评价，评价包括评分和文字性说明；其中“用户满意度评分”如下：
代码
评分
满意
3
一般
2
不满意
1
6.1.9.事件关闭
“事件关闭”用来表示事件关闭的方式，事件关闭的代码包括以下几种：
关闭代码
描述
手动关闭
与用户确认后关闭
自动关闭
用户无反馈，自动关闭（默认48小时无反馈则自动关闭）
6.1.10.事件单信息单
事件信息单建议包含如下事件信息项：
序号
信息项
信息描述
操作角色
1
事件编号
事件单流水号
服务台人员
（或系统自动分配）
2
事件状态
参见“事件状态”定义
服务台人员
二线人员、三线人员
3
事件登记时间
在服务台生成事件记录的时间
系统自动设置
4
事件登记人
事件开单人员姓名，也是整体责任人
服务台人员
（或系统自动设置）
5
事件来源
事件发起的来源，包括：
邮件、电话、APP、监控、Web
服务台人员
6
事件发生地点
事件发生的地点。
服务台人员、或二线与三线人员
7
报障单位
事件发生的单位或部门
服务台人员
（或系统自动设置）
8
客户联系人
事件发生的主要联系人名称
服务台人员
（或系统自动设置）
9
客户联系方式
事件发生客户的主要联系方式
服务台人员
（或系统自动设置）
10
事件描述
对于整个事件内容的详细描述
服务台人员填写，二线人员调整补充
11
事件分类
参见“事件分类”定义
服务台人员
二线人员
12
事件优先级
参见“事件分级”定义
系统自动设置
13
计划解决时间
对应每一个事件优先级，根据流程相关定义中“事件时限”设定最终的完成期限（系统自动产生）
系统自动设置
14
事件分配工作组
被分配的支持小组
服务台人员
二线人员
15
事件分配人员
被分配的支持小组内成员
服务台人员
二线人员
16
事件处理人
当前的实际事件处理人
事件指派责任人
系统自动设置
17
涉及第三方
第三方供应商名称
服务台人员
二线人员，三线人员
18
事件挂起时长
事件挂起时间长度，依据术语定义中的“挂起”定义计算得出
系统自动设置
19
事件工作日志
反映事件处理过程的信息（工具）
服务台人员
二线人员
20
解决方案/变通方法
事件解决方案/变通方法的描述
服务台人员
二线人员，三线人员
21
解决分类
记录事件具体解决方式
服务台人员
二线人员，三线人员
22
实际解决时间
记录事件状态为“已解决”的时间（系统自动产生）
系统自动设置
23
解决是否超时
参见“处理时间要求”定义（系统自动产生）
系统自动设置
24
关联主事件
标注该重复事件对应的主事件编号
服务台人员
二线人员，三线人员
25
关联的问题单
记录由事件引发问题时，关联的问题单号
服务台人员
二线人员，三线人员
26
关联的变更单
记录由事件引发变更时，关联的变更单号
服务台人员
二线人员，三线人员
27
关联的请求单
记录由事件引发服务请求时，关联的服务请求单号
服务台人员
二线人员，三线人员
28
用户满意度
用户对事件处理的满意程度。
参见“用户满意度评价”
用户
服务台
29
附件信息
事件相关附件信息
服务台人员
二线人员
30
事件关闭代码
参见“事件关闭”定义
服务台人员
（或系统自动设置）
31
事件关闭时间
记录事件状态为“结束”的时间（系统自动产生）
系统自动设置
6.2.管理策略
●所有已识别的事件都要被记录，所有事件都有整体责任人（服务台受理者），指派责任人（二线相关条线的主要负责人或受理人），以及当前执行人（具体负责该事件处理人），升级对象（三线或供应商）。
●事件首次响应的服务台（客服人员）负责在平台中记录此事件的详细信息，并进行初步支持，并作为此事件的最终负责人，负责跟踪事件处理的整个过程直至事件解决，以确保事件处理过程有专人及时跟进；
●原则上所有事件需要经过服务台。
监控所发现的事件暂时不经过ITSM系统进行管理；
●若因情况紧急无法及时记录时，可进行事后补单，但补单时间不得超过12小时；
●原则上，所有事件首先指派给二线，如事件指派不准确或正好遇上交接班时间，该事件可在二线团队中做转派。
如需要进一步支持，再由当前指派人升级给三线，二线三线都可以联系供应商解决，但只有三线可以进入ITSM系统操作（供应商不纳入ITSM使用者行列），当事件升级到三线后，二线的当前执行人仍为该事件的当前责任人。
●原则上，服务台、事件经理、指派工程师可根据实际情况对事件分类、分级等信息进行调整。
●服务台人员应在事件解决后2个工作日（48小时）内与报障人联系并关闭事件。
如果报障人收到通知，且在2个工作日（48小时）内未对事件处理结果未提出异议，默认事件报告人接受结果，事件可关闭；
●导致事件发生的根本原因未知，或者事件重复发生，以及发生了重大事件，指派人都应提交问题管理流程查找根本原因，以期找到解决方案和预防措施；
●所有指派责任人都有义务根据事件处理情况更新相关知识库。
6.3.管理流程
6.3.1.事件识别和记录
序号
步骤名称
责任人
说明
1.1
提交事件
报障人
报障人通过电话、微信、邮件或手机APP来进行报障。
1.2
识别和记录
服务台
服务台在ITSM平台中进行事件信息的记录，包括用户联系方式、事件描述、事件分类分级等；
若用户通过非电话的方式进行报障，服务台工程师可电话联系用户进行更多信息的确认和收集。
1.3
通知事件经理
服务台
事件经理
若事件级别判断为一、二级事件，需要升级至事件经理需要跟进事件的处理过程；
同时事件经理需要上报分管领导。
6.3.2.事件调查和诊断
序号
步骤名称
责任人
说明
2.1
初步处理
服务台
服务台对事件进行初步处理，进行远程调试或指导。
2.2
是否可以解决？
服务台
若可以解决，则直接处理解决，并进入3.2，与用户确认是否恢复；
若无法解决，则进入2.3寻求二线支持。
2.3
二线支持团队调查诊断，寻找解决方案
二线工程师
二线支持团队接受服务台升级的事件，并判断是否需要进行内部转派，如需要则说明转派理由，并进行转派，如不需要则对事件进行分析和处理，处理过程需要及时更新到平台中；
若需要执行变更，则触发变更管理。
2.4
是否找到解决方案？
二线工程师
若是，则进入2.5是否需要发起服务请求管理；
若否，则进入2.6寻求三线支持；
若否，则进入2.8寻求供应商支持。
2.5
是否需要发起服务请求管理
二线工程师
找到解决方案后，是否需要继续发起服务请求管理，寻求彻底解决：
若需要执行服务请求，则发出服务请求管理
若不需要，则进入3.1事件解决。
2.6
三线支持团队调查诊断，寻找解决方案
三线工程师
三线支持团队接受二线升级的事件，对事件进行分析和处理，处理过程需要及时更新到平台中；
若需要执行变更，则触发变更管理。
2.7
是否找到解决方案
三线工程师
若是，则进入3.1事件解决；
若否，则进入2.8寻求供应商支持。
2.8
供应商团队诊断调查，寻找解决方案
供应商
供应商接收来自二线和三线对的事件，并对事件进行分析诊断，给出最终解决方案。
2.9
提交解决方案
供应商
供应商将解决方案提交给相应的升级人员，由其去解决事件，并进入3.1事件解决
6.3.3.事件解决和关闭
序号
步骤名称
责任人
说明
3.1
事件解决
二线工程师、三线工程师
将事件的解决结果及时更新至平台中，并标记解决，必要时发起问题工单进一步分析，或发起服务请求单完成临时解决后尚需进一步完善的遗留状态，或将事件总结生成知识库条目。
3.2
是否恢复？
服务台
服务台与用户确认事件的恢复结果。
3.3
填写用户反馈和满意度
服务台
将用户反馈和满意度调查情况更新至平台中，并关闭工单。
7.关键绩效指标
绩效指标
目标值
衡量方式
负责人
事件总数
事件总数/周期（年，月，周，日）
服务台、二线工程师、三线工程师
事件关闭的数量/比率
关闭事件数量/周期
数量/事件总数×100%
服务台、二线工程师、三线工程师
事件自动关闭的数量/比率
自动关闭事件数量/周期
数量/事件关闭数量×100%
服务台
重大事件数量/比率
优先级为一/二级事件数量/周期
数量/事件总数×100%
事件经理
事件成功关闭的数量/比率
成功解决事件并关闭数量/周期
数量/事件关闭数量×100%
服务台、二线工程师、三线工程师
临时解决事件的数量/比率
变通方法解决事件并关闭数量/周期
数量/事件关闭数量×100%
二线工程师
超过规定时间响应的事件数量/比率
一线响应超时事件/周期
数量/事件总数×100%
服务台
超过规定时间解决的事件数量/比率
超时解决事件/周期
数量/事件总数×100%
二线工程师，三线工程师，供应商
首次派单成功率
未派回服务台重派单事件/事件总数×100%
服务台
平均响应时间
累计响应事件的时间/事件总数
服务台
平均解决时间
累加完成事件的时间/完成的事件数
二线工程师，三线工程师，供应商
一线解决率
一线解决事件数量/事件成功关闭总数×100%
服务台
二线解决率
二线解决事件数量/事件成功关闭总数×100%
二线工程师
用户满意度
事件记录中用户满意度分值总计/事件总数
服务台
8.相关文件和记录
名称
说明
负责人
事件管理报告（模板）
定期发布的事件管理报告
事件流程经理
重大事件报告（模板）
对重大事件单独的管理报告
事件流程经理
升级会员 