事件管理过程.docx
- 文档编号:27334308
- 上传时间:2023-06-29
- 格式:DOCX
- 页数:11
- 大小:158.20KB
事件管理过程.docx
《事件管理过程.docx》由会员分享,可在线阅读,更多相关《事件管理过程.docx(11页珍藏版)》请在冰豆网上搜索。
事件管理过程
1事件管理的定义
突发事件是指在IT服务中的一个无计划中断或IT服务本身服务性能的降低,包括系统崩溃、硬件或软件故障、任何影响用户当前业务使用和系统正常运作的故障以及影响业务流程或违背服务级别协议的情况。
突发事件管理流程是为企业业务系统尽快恢复正常工作状态而设计的,其所关心的重点是如何达到快速响应、快速恢复,使故障对企业业务的影响最小化。
事件管理的责任是记录、分类、调查与诊断、解决已知问题、监控跟踪事件,与用户和问题管理流程交互并最终解决事件。
2事件管理的目的
事件管理流程的主要功能是尽快解决出现的事件,保持企业业务系统的稳定性。
例如,中国移动10086的服务控制台接线员会去负责记录突发事件的相关信息,并向用户提供对已知问题的处理方法,报告事件到相关的技术支持部门和尽快恢复用户的服务。
解决突发事件的目的是获得尽可能高的事件解决率,其主要目的包括:
(1)在成本允许的范围内尽快恢复服务
提供电话或网络在线沟通与帮助,通过自动监控和快速响应系统对故障进行及时告警等环节来保证服务能够尽快被恢复。
(2)事件控制和监控
记录任何事件,并对事件的优先级进行分类和处理。
服务控制台工作人员要对当前事件进行分析和诊断,必要时把事件升级到相关的技术部门去处理,而且服务控制台工作人员要对事件的全称进行监控,直到事件得到圆满的解决。
(3)提供事件统计信息给IT管理层
可以对事件进行分类统计,比如可以通过Parato分析法分析出哪些事件是经常发生的,这些信息可以提供给管理层进行决策分析。
管理者会关注那些主要的事件或缺失环节,并采取相应的措施对服务环节进行调整和提高。
3事件管理的范围
事件管理是和该公司的IT基础架构与具体的商业业务相关的。
突发事件可以包括服务故障申告、业务咨询、业务投诉和业务处理等。
一般的事件产生会有两类:
一类是由监控管理平台(如Tivoli监控软件)自动发现并产生的告警事件,另一类是由用户/IT运维人员报告的事件。
突发事件管理流程不一定必须找到问题发生的根本原因,其重点在于如何在尽量短的时间内,恢复已经中断的IT服务,并提高服务的可用性。
4事件的优先级定义
优先级是事件管理的一个关键要素,优先级决定处理事件的顺序及所需的资源。
事件优先级可分为四类,如下表1所示:
表1事件优先级定义
级别定义
描述
一级
IT系统/设备宕机,服务网络不可用,业务不可用,或大批用户在使用上出现问题
二级
服务业务或服务网络的性能出现问题,一个以上的设备出现严重警告信息
三级
紧急的用户请求或投诉处理
四级
一般常规的用户受理或服务请求
服务控制台的工作人员在接到来及监控管理平台的告警事件或终端用户报告的事件时,迅速根据事件相关IT系统/设备、网络的关键级别及事件的性质,定义该事件的优先级别。
如果为紧急和棘手的事件,应立即升级到相关的技术或业务部门。
事件升级的目的的是确保事件在解决时限内及时通知有关技术人员和领导,引起更多的重视,提供合适的资源,从而快速找到解决事件的方案。
可根据所要求的处理时间定义事件优先级升级规则,包括不同等级的事件在不同的事件被升级到不同级别的人员。
当技术或业务部门接受到服务控制台升级上来的事件后,会根究具体的事件级别在规定的事件内解决。
与事件优先级对应的事件解决时限参考表如下表2所示:
表2事件解决时限参考表
优先级
一级
二级
三级
四级
解决时限(小时)
4
8
24
48
5事件升级
如果某一事件不能在规定的时间内由一线支持小组解决,那么更多有经验的人员和有更高权限的人员将不得不参与进来。
这就是升级,它可能发生在时间解决过程的任何时间和任何支持级别。
升级分为职能性升级和结构性升级。
两者的区别如下:
职能性升级(又称为水平升级、技术升级):
职能性升级意味着需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决。
这种升级可能会超越部门界限而且可能会包括外部支持着。
结构性升级(又称为垂直升级、管理升级):
结构性升级意味着当经授权的当前级别的机构不足以保证事件能及时、满意地得到解决时,需要更高级别的机构参与进来。
事件管理经理对事件管理流程负有全部责任,他的目标是要为满足一个事件的职能性升级的需要做好预备工作,以避免结构性升级的发生。
事件的处理流程线路是由所需的专业等级、紧急度和权限等因素决定的。
1线支持通常由服务台来提供、而2线支持则通常由管理部门提供;3线支持则多由软件开发人员和系统结构人员提供;4线支持由供应商提供。
公司(组织)越小,则可供升级的级别数就越少。
在较大的公司(组织)里,事件管理经理可在相关部门指定故障协调人来支持自己的工作。
例如,协调人在整个事件管理过程与处于各线的支持机构之间可充当接口的角色。
每一个协调人协调他本身所在的支持团队。
图5-1描述了升级的过程。
图5-1事件升级过程
6事件管理的流程
事件管理流程应起始于事件的接受和报告,结束于事件的解决和关闭。
该流程包含下述主要内容:
(1)记录和接受事件
是事件流程的起点,所有用户或系统报告的IT事件必须由此开始,目的是快速准确地发现事件,以协助事件的诊断和解决并通知相关人员。
在此步骤中将会收集创建事件记录所需的信息。
该环节的关键是信息的准确性和完整性。
在执行突发事件管理流程时,所需要记录的事件信息项如下表6-3所示:
表6-3事件信息表项
信息项
信息项具体说明
录入方式
时间流水号
事件工单号码
系统生成的唯一编号
用户信息
本次事件报告人的联络信息,包括:
姓名、省份、城市、电子邮件、手机
根据用户呼入号码或名字信息来自动获取用户的详细信息
生成时间
在服务控制台生成事件记录的时间
系统抓取当前的系统
地点
事件发生的地点
手工录入
发生时间
事件发生的实际时间
手工录入
事件性质
从事件所属性质的角度来确定其处理流程,如故障申告、业务咨询、业务投诉等
手工选择
事件来源
指事件工单产生的途径,有人工产生、系统自动产生两类
由监控管理平台自动产生的,可自动填写
事件影响度
事件影响度用于衡量事件所影响业务的严重程度。
严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。
手工选择
事件优先级
事件优先级决定了事件的解决时限和处理次序,通过综合衡量配置项的关键级别和其他相关信息得出
手工选择
事件分类
从事件从属的系统或技术架构的类型来进行分类,如数据库、服务器和网络等
手工选择
事件标题
事件的标题
有监控管理平台自动产生的,可自动填写
事件描述
对于整个事件内容的详细描述
有监控管理平台自动产生的,可自动填写
事件解决确认人
在服务控制台得到用户确认的有关人员
手工选择
事件状态
整个事件在处理的生命周期中的不同状态,比如触发事件、解决事件和关闭事件等状态
手工选择
指定人
被分配的技术支持组或人员
手工选择
事件日志
反映事件处理过程中的事件处理信息,包括任何的历史处理记录、人员和时间等信息
手工录入
是否超时
事件处理时间是否超出解决时限
系统生成
解决时间
事件得到解决的时间
手工录入
解决方案描述
事件解决方案的描述
手工录入
关联配置项
关联问题单号
关联变更单号
备注:
事件性质、事件来源、所属系统类型、事件分类、事件优先级、事件响应时限和解决时限、事件影响度、事件状态、事件结束代码、事件解决人角色等字段定义可参考《中国移动IT管理流程手册》
(2)分类和初步支持
事件可以是一个服务请求、信息请求或故障,对于每个事件,需要确立优先级和分类。
若没有发现现成的解决方案或临时解决措施,该事件将分配给合适的支持人员对此进行调查。
而该环节的关键是需要事件知识库的支持和正确的事件派分。
(3)匹配
检查一下事件是否是已知的,或是可能与某一现存事件、问题或已知错误有关的,看看是否有解决方案或应急措施。
(4)调查和诊断
若支持人员无法解决事件,可运用自身技能、知识库、诊断工具等进行更加深入地分析,以找到恢复服务的临时措施,必要时将寻求很多支持人员的参与,以寻求有效的解决措施。
(5)解决和恢复
支持人员实施事件的解决方案,并将解决完毕的事件转回服务控制台;由服务控制台通知用户解决的结果,并得到用户的最终确认信息。
(6)紧急事件和事件升级
对于紧急事件,服务控制台应立即提交给二线或三线的技术/业务支持人员,由二线或三线人员就目前的事件情况进行合理的判断,在必要的时候上报给事件经理。
由事件经理决定紧急处理的方式,以确保紧急事件能够得到最快速的解决。
当事件处理超过预期时限,将自动升级或由运维人员升级,以引起相关人员和高层管理人员的重视并参与事件的处理。
(7)结束事件
当用户确认事件解决后,此时可结束该事件的处理,并在事件处理系统中关闭该事件,若用户对此解决方案不满意,则对该事件继续进行处理,不能关闭。
对一个比较有价值的事件解决方案,要放到事件知识库中,以备以后事件处理时参考。
事件管理过程的流程如图6-2所示:
图6-2事件管理的流程
7事件管理流程的主要角色
在执行事件管理流程之前,就要先明确定义执行该事件流程的主要角色。
下面对以下几个职责/角色进行分别描述。
(1)服务台工作人员
a)在指定的时间内响应所有服务控制台热线电话、邮件、传真、网络即时聊天等事件请求;
b)完整地记录所有接受的事件信息;
c)对事件进行适当的分类,并根据已定义好的优先级别来为事件设定合适的优先级别;
d)通过使用相关诊断工具或查阅历史经验数据库去分析和解决当前的事件;
e)如果不能做到及时解决这个事件,服务控制台工作人员应将该事件升级到二级技术或业务部门去处理;
f)定期检查事件记录的处理进度,保持与事件报告人的紧密联系,适时向事件报告人通知事件处理进展情况;
g)在与事件报告人或用户确认事件已经解决后,关闭事件。
(2)二线技术/业务支持人员
二线技术/业务支持人员负责对服务控制台工作人员无法解决的事件进行快速有效的分析,并提出解决方案以确保能够尽快地恢复服务。
a)验证从服务控制台工作人员那里升级过来的事件的描述信息,并进一步收集相关数据或信息来界定事件发生的根源;
b)根据事件的根源分析来决定需要采取何种措施恢复服务;
c)根据事件的优先级来决定具体措施或解决方案的执行时间;
d)实施事件解决方案,在必要的时候提供现场支持;
e)更新事件解决信息,并将已解决的事件转回给服务控制台,由服务控制台工作人员通知事件报告人或用户,并关闭事件;
f)如果二线技术人员不能解决这个事件,应当选择把事件转给三线技术或业务支持人员去处理。
(3)三线技术/业务支持人员
三线技术/业务支持人员是相关问题领域的专家,负责提供对二线支持人员无法解决的问题进行更深入的调研,找出解决方案并尽快恢复服务。
当然不是所有的三线支持人员对所有的问题都很精通,所以可以考虑按照所维护的应用、系统进行分组,如网络组、服务器组、存储组等。
a)进行事件的深入调查研究;
b)根据以往的经验和专业技能来决定需要采取何种措施恢复服务;
c)及时提供和实施有效的解决方案;
d)必要时寻求服务供应商的维保支持;
e)更新事件解决信息,并将已解决的事件转回给服务控制台,由服务控制台工作人员通知事件报告人或用户,并关闭事件;
f)如果三线不能在解决时限内解决这个问题,应当将事件及时升级到管理层。
(4)事件经理
事件经理是管理层对事件管理的直接授权人。
作为事件管理流程的负责人,具体职责如下:
a)负责制定流程的策略、规范和具体实施办法;
b)调度有效资源,并协调解决跨部门的事件;
c)指导并监管日常业务操作服务,以确保流程的执行符合预定的要求和规范;
d)建立对流程执行的度量指标;
e)根据已定义的度量指标来采集数据,并进行报表分析;
f)定期与用户、服务提供商和管理层沟通流程的使用情况;
g)对流程的变更和服务流程改进计划负有完全责任。
8绩效指标
评估流程的绩效需要明确定义目标以及为实现这些目标所设定的可测量的指标。
这些指标通常被称为绩效指标。
绩效指标由事件经理定期(如每周)报告,以获得一些可据此判断事件发展趋势的历史数据。
事件管理流程的关键绩效指标举例如下:
●事件的总数;
●平均解决时间;
●按优先级计算的平均解决时间;
●在SLA的目标之内解决的时间所占的百分比;
●由一线支持解决(不将事件转交)的时间所占的百分比;
●每个事件的平均支持成本;
●每个服务台工作站或每个服务台员工平均解决的事件数;
●不需拜访用户就解决的事件数;
●初步分类正确的事件数量(或所占比例);
●正确转交的时间数量(或所占的比例)。
9事件管理改进的问题提出
事件管理的最主要目的就是通过对所有事件的生命周期的管理,尽快把由于突发事件所造成的非正常的服务恢复正常,从而把突发事件对商业服务的影响最小化。
如何迅速有效的对各种情况下的突发事件进行响应,并以适合的能力和资源进行处理,是事件管理过程的关键点。
现有的数据库技术,可以高效的实现数据的录入、查询、初步统计等功能,但无法发现数据中存在的关系和规则,无法根据现有的数据预测未来的发展趋势,无法从海量的数据中发现减少事件发生次数、提高事件解决效率、持续改进服务的方法,而这些都是事件管理的真正价值所在。
人工处理无法保证处理时间和准确率的情形迫切要求高效决策支持方法的诞生。
科技部门所管理的IT资产、IT系统数量众多,每天都会产生大量的事件,这些数据对于检测、分析、评估、监控、预测和关联各种事件有着非常重要的价值。
本课题旨在使用数据挖掘技术对这些数据进行深层次的分析,从中发现有价值的信息,形成知识存放在知识库中,从而提高事件管理过程的效率,提高服务质量、提升服务管理的水平。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 事件 管理 过程
![提示](https://static.bdocx.com/images/bang_tan.gif)