事件管理过程.docx
《事件管理过程.docx》由会员分享，可在线阅读，更多相关《事件管理过程.docx（15页珍藏版）》请在冰点文库上搜索。
事件管理过程
事件管理过程
事件管理过程
文件编号
版本
编制
编制日期
审核
审核日期
批准
批准日期
变更记录
日期
版本
编制/修改者
修订类型
描述
注：
修订类型：
A——增加，M——修改，D——删除
一、简介
1.1目的
事件管理过程负责发现各类事件，及时报告并协调合适资源，并以最短时间恢复正常服务，最大程度地降低IT运维服务的负面影响与损失，进而确保能够保持最好的服务质量与可用性级别；同时，通过对相关服务请求、故障与业务诉求的汇总与分析，有利于推动过程工作且不断改善客户服务体验。
事件管理过程提供日程支持服务的接口，以降低因服务事件带来的影响。
该过程关注尽可能快的恢复服务以满足预定服务等级协议（SLA）的要求。
其目标包括：
Ø快速响应故障及服务请求；
Ø在成本允许的范围内尽快恢复服务；
Ø用户在线获得帮助；
Ø沟通事件解决的状态；
Ø和用户确认事件的解决；
Ø进行事件控制；
Ø按规范在过程管理工具中登记完整事件记录、事件回访记录和事件管理报告；
Ø就事件的优先级，影响度进行分类；
Ø分析，诊断，必要时进行升级；
Ø监视并结束事件；
Ø进行定期服务流程回顾；
Ø故障处理情况和支持效率。
1.2范围
从事件管理的来源来讲，事件管理过程的范围包括服务环境中产生的故障和服务请求及服务咨询等。
既是本次IT服务管理项目事件管理过程的交付物,也可作为运维服务部门进一步改进事件管理过程的蓝本,对象为与事件管理过程相关的所有管理与技术岗人员，用于记录、处理、关闭事件并监督整个过程的管理活动。
本文档所描述的过程在IT服务管理中有许多作用,列举如下:
❑减小突发事件对业务的影响；
❑最优化支持资源，提高工作效率；
❑屏蔽错误事件和服务请求；
❑根据影响业务轻重缓急安排资源解决事件，保障有效IT运营；
❑加强有形监控和及时反馈；
❑提升客户对服务的认知度和满意度。
1.3术语定义
术语
定义
服务台
服务台从根本上讲提供了客户和运维部门的唯一接口（日常支持接口）。
此项功能常常通过集中的服务台进行体现。
服务台的根本目的是提供一线支持，并通过变通方法、解决方案或升级到二、三线支持甚至与专家团队等手段帮助用户恢复到正常工作状态。
事件管理
是负责解决所有的事件、问题和用户请求等的管理流程。
它的目的是尽快恢复被中断或受到影响的服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
用户
指的是指运维服务的使用者，他们使用运维服务单位提供的运维服务来支持相关日常业务。
服务支持人员
指的是运维服务团队中运维和支持人员的统称，包括一线人员和二线人员等，可能涉及运维服务体系中的相关的开发、支持和运维等团队。
一线支持
指服务台的通用座席，向用户提供一线支持服务，以下提到的服务台人员即一线支持人员。
二线支持
主要由各职能小组运维工程师组成，协助服务台一线人员参与事件处理，相对一线支持人员，二线支持具有更高更专业的技能。
三线支持
指各职能小组组长，在复杂度较高事件或二线支持无法解决事件时负责协调小组内部人员进行事件处理，三线支持更多的强调管理协调职能。
事件
指运维过程中在用户运维环境中发现的所有非正常事件，对现有的服务造成影响或中断。
例如：
服务器宕机、网络中断、应用不可用等。
从来源上分类，主要包括由运维服务内部人员发起的事件以及有用户报告的事件等。
服务请求
指用户提出的关于标准服务、培训、文档、信息等方面的请求，以及针对运维服务使用的咨询等，通常并没有发生组件方面的故障。
例如：
请求培训、寻求咨询等。
服务请求是一种特殊类型的事件。
投诉反馈
指由用户提出的对于运维服务质量或服务方式的抱怨或改进建议，通过服务台统一接受，并进行相应处理。
1.4角色职责定义
角色
职责描述
事件经理
负责对具体过程的规划、实施、监督、改进；改进识别、分析、规划、报告、沟通、监控等服务活动；监控过程绩效；批准过程相关文档；对过程结果负责；协调和其他过程的关系。
服务台
响应、记录事件，对事件进行分类并设定优先级；尝试使用工具、初步诊断、分析相关信息等方式解决问题；将服务台不能解决的事件分配给合适的二线、三线支持小组/人员来处理；跟踪、协调二、三线对事件的处理；监控和跟踪事件处理过程；检查事件记录的处理进度，适时通知事件处理进展，与事件报告人确认事件解决方案，关闭事件。
二线支持人员
快速、有效地解决服务台无法解决的事件，必要时提供现场支持；验证事件的描述和信息，与客户直接进行沟通，补充相关信息到过程中；
确认事件分派合理性；实施事件解决方案；更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件；为三线人员提供未解决事件的解决过程和测试结果记录；提供解决方案给问题经理进行审核。
三线支持人员
对二线支持人员无法解决的问题进一步调研并找出解决方案；根据设定的事件优先级，及时响应事件分派；根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效行动；必要时引入第三方的支持；
更新事件记录，记录事件解决日志和最终解决方案；将无法在规定时限内解决的事件升级到事件经理；提供解决方案给问题经理进行审核。
二、管理流程
2.1事件管理流程图
图1事件管理流程图
详细流程说明如下：
表1事件管理流程说明一览表
序号
步骤名称
责任人
说明
1.1
事件受理
服务台
❑无论是用户还是监控系统上报的事件，经信息收集和核实后，应由服务台人员创建相应事件记录
❑记录事件时，应对用户信息、故障描述进行填写，同时，应在配置管理数据库中查找并关联发生故障的配置项
❑对事件性质即事件的类型进行划分：
申告/报障/咨询/投诉等
❑记录完毕后进入1.2
1.2
事件分类
服务台
❑服务台人员对事件的分类进行设置
❑服务台人员基于事件影响程度和紧急程度设置事件的优先级
❑具体确认参照事件优先级判读标准
❑不同优先级事件对应其响应和解决时限不同
1.3
是否有现成的解决方案？
服务台
❑是否找到现成的解决方案或变通方法。
如找到，则转1.4;如未找到，则转1.5进一步尝试解决
1.4
与用户沟通解决方案
服务台
❑服务台或二线人员就事件的解决方案或变通方法与用户进行沟通
1.5
分派给二线工程师
服务台
❑服务台人员根据事件分类和二线人员的忙闲状态，合理选择一名二线支持人员进行事件单的转派
❑分派事件前应首先电话沟通，缩短二线人员对事件单的响应时间，提高事件的分派成功率
1.6
是否接受事件单
二线支持
❑二线支持人员在了解事件情况后，可依据自身能力和资源情况对是否接受事件单进行选择。
如接受，则进入1.9;如不接受，则进入1.7
1.7
填写原因
二线支持
❑二线支持人员如不接受事件单，应在事件单上注明原因，并提供下次分派的建议，供服务台人员参考。
1.8
重新分派
服务台、事件经理
❑在接受二线支持人员拒绝派单原因后进行事件单的再次分派
❑重派单超过3次的由事件经理参与进行分派
1.9
是否有解决方案？
三线支持
❑若找到解决方案或变通方法，则进入1.4进行实施
❑若未找到解决方案或变通方法，则进入2.1判断是否重新派单？
1.10
是否重新分派
服务台、事件经理
❑是则进入1.8重新分派
❑否则进入1.19标记本次事件失败
1.11
是否得到客户认可
用户
❑判断此解决方案实施结果是否能接受，是则进行1.12实施、否则进入1.10重新派单进行处理
1.12
实施解决方案
服务台/二、三线支持
❑服务台或二、三线人员对事件的解决方案或变通方法进行实施
1.13
是否超时
服务台/二、三线支持
❑如实施过程中事件超时，则进入1.14
❑未超时则进入1.16
1.14
事件升级
服务台/二、三线支持
❑升级至事件经理处对资源进行协调和支持
1.15
与用户沟通并实施补救/解决方案
服务台/二、三线支持/事件经理
❑事件经理负责与用户沟通补救/解决方案
❑服务台或二、三线人员对事件的解决方案或变通方法进行实施
1.16
用户是否满意
用户
❑与用户沟通，对事件处理结果进行判断。
❑如用户认可解决结果，则进入1.17。
❑如用户不认可解决结果，则进入1.10重新派单解决。
1.17
是否需要更新知识库
服务台
❑审核事件记录和相关解决方案，判断是否需要记录相关解决方案，否则关闭事件
1.18
更新知识库
服务台
❑对于一些有价值的方案信息，服务台人员可将其提交至知识库
1.19
标记失败
服务台
❑确认此次事件失败
1.20
关闭事件
服务台
❑服务台人员按处理结果填写结束代码后关闭事件
❑对于超过反馈期限未得到用户确认的事件，系统自动设置结束代码为“自动关闭”
❑对于重大事件，或者结束代码为“变通方法解决”/“不成功”的事件，服务台人员应通知问题流程基于事件创建问题记录进行根源分析调查
❑服务台人员通过电话或邮件形式对用户进行回访，进行满意度调查。
2.2过程主要内容
事件管理过程始于事件的接收和报告，结束于事件的解决。
该过程包含下述主要内容：
❑事件接收和记录
这个环节是事件管理过程的起点。
所有监控系统或用户报告的IT事件必须由此步骤开始。
此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。
在此步骤中将会收集创建事件记录所需的信息。
该环节的关键是信息的准确性和完整性。
❑分类和初步支持
对于每个事件，需要确立优先级和分类。
若没有现成的解决方案（Solution）或变通方法（Workaround），该事件将分配给合适的支持人员对此进行调查。
❑调查和诊断
若支持人员无法利用现成方案解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
❑解决和恢复
支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。
❑事件升级
对于高优先级的事件，服务台应立即上报给服务台经理和相关的管理层，由事件经理决定事件的处理方式，确保其得到最快速的解决。
当事件处理超过预期解决时限，应通知相关处理人员和管理层，以引起处理人员和管理人员的重视和参与。
❑结束事件
当用户确认事件解决后，可结束该事件。
2.3事件等级定义
事件级别
级别定义
影响业务范围
影响业务程度
业务修复紧急程度
一级事件
用户业务中断，无法工作
80%以上用户业务受影响
紧急
二级事件
用户业务性能严重下降
50%以上用户业务受影响
高
三级事件
用户业务性能下降
20%以上用户业务受影响
中
四级事件
问题请求，业务性能无下降
用户业务可能有潜在影响
低
2.4事件分级
影响度：
衡量时间对业务的影响程度，主要是影响范围、数量和重要程度。
紧急度：
主要根据业务对IT需求和依赖程度以及可以忍受的时限。
紧急度
紧急度时间标准
紧急
1小时
高
2小时
中
4小时
低
8小时
结合事件发生时的影响程度和紧急程度，可以通过下表确定事件的优先级：
事件优先级矩阵
优先级
影响度
高
中
低
紧急度
紧急
1
2
3
高
2
3
3
中
3
4
4
低
3
4
4
2.5事件升级
制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。
❑优先级为最高的事件，需要立即事件升级，同时，事件继续按事件管理过程进行快速处理
❑超出规定的响应或者解决时限之后，需要立即升级事件，同时，事件继续按过程进行快速处理
❑事件重复派单超过三次直接升级给事件经理
表2事件升级机制表
事件升级机制
技术支持组组长
事件经理
运维项目经理
运行维护部门经理
公司领导
优先级1
5分钟
5分钟
10分钟
10分钟
15分钟
优先级2
1小时
1小时
1小时
1.5小时
优先级3
2小时
2小时
优先级4
4小时
4小时
2.6满意度调查机制
1、针对事件的客户满意度调查在每次事件关闭后一周内进行。
2、由运行维护部门和质量管理部门经理负责组织满意度的调查与汇总测评工作；收集用户对服务态度、服务质量等方面的意见和建议。
对调查测评结果按发现的问题位置，问题类型进行分类整理、统计、汇总和分析，报总经理和副总经理审阅，同时报送运行维护部门限期进行处理回复。
3、运行维护部门应根据满意度调查结果，针对客户提出的意见和建议，制定相应的纠正和预防措施，组织实施，加以改进。
如果确实是在解决能力之外的可报相关部门进行协商处理或对用户进行解释，由质量管理部门负责检查和监督落实情况。
4、客户满意度的调查有：
①通过运行维护部门座机电话、电子邮箱接收用户的服务监督及投诉；
②通过现场服务人员及项目负责人，直接反馈信息；
③服务台人员通过电话、短信或邮件回访等形式征询用户意见或建议，收集有关信息并记录。
表3事件解决评估机制
序号
衡量指标
指标计算说明
1
事件总数
数量：
在事件单中根据以下条件过滤
1. 【重复事件标记】为空
2. 【事件结束代码】不等于„消失‟or„误报‟or„可忽略‟
3. 【事件发生时间】在统计周期内
2
服务台
解决率
数量：
在事件总数中过滤所有【事件解决人角色】＝„服务台‟
比率：
数量 / 事件总数 × 100 %
3
服务台平台响应时间
响应时间：
（【实际开始时间】－【登记时间】）
总响应时间：
在事件总数中统计各（【实际开始时间】－【登记时间】）
平均响应时间：
总响应时间/事件总数
4
二线解决率
数量：
在事件总数中过滤所有【事件解决人角色】＝„一线‟
比率：
数量 / 事件总数 × 100 %
5
事件平均解决时间
解决时间：
（【实际开始时间】－【完成时间】）
总解决时间：
在事件总数中统计各（【实际开始时间】－【完成时间】）
平均解决时间：
总解决时间/事件总数
升级会员 