事件管理流程文件doc.docx
《事件管理流程文件doc.docx》由会员分享，可在线阅读，更多相关《事件管理流程文件doc.docx（22页珍藏版）》请在冰豆网上搜索。
事件管理流程文件doc
事件管理程序
样式编号
编
制
审
核
批
准
密
级
内部
版
本
发布日期
2009年1月5日
信息技术有限责任公司
变更履历
序
版本更改处·更改内容更改人/日期审核人/日期批准人/日期
号
1新建
1.
1
2
3
4
5
目
录
1
简介......................................................
错误!
未定义书签。
目的.
...............................................
错误!
未定义书签。
适用范围............................................
错误!
未定义书签。
术语表..............................................
错误!
未定义书签。
引用文件............................................
错误!
未定义书签。
2
职责......................................................
错误!
未定义书签。
服务台..............................................
错误!
未定义书签。
一线（现场工程师）
/二线（专项工程师）...............
错误!
未定义书签。
外部资源............................................
错误!
未定义书签。
项目经理............................................
错误!
未定义书签。
3
流程图....................................................
错误!
未定义书签。
4
具体内容..................................................
错误!
未定义书签。
接受/
记录事件.......................................
错误!
未定义书签。
分级/
分类和初步支持
.................................
错误!
未定义书签。
调查和分析..........................................
错误!
未定义书签。
解决和恢复..........................................
错误!
未定义书签。
事件关闭............................................
错误!
未定义书签。
过程的跟踪监控......................................
错误!
未定义书签。
5
事件升级过程
..............................................
错误!
未定义书签。
事件严重程度定义....................................
错误!
未定义书签。
事件升级步骤........................................
错误!
未定义书签。
6
事件管理过程与其他流程的关系..............................
错误!
未定义书签。
事件管理过程与其他关系..............................
错误!
未定义书签。
7
事件管理过程的KPI........................................
错误!
未定义书签。
KPI定义............................................
错误!
未定义书签。
8输出的文件和记录..........................................错误!
未定义书签。
1简介
1.1
目的
事件管理过程提供日程支持服务的接口，以降低因
IT
事件带来的影响。
该过程关注
尽可能快的恢复服务以满足预定服务等级协议（
SLA）的要求。
1.2
适用范围
事件管理过程适用于记录、处理、关闭事件并监督整个过程的管理活动，事件管理过
程包括服务台和相应的支持组。
1.3
术语表
事件：
指服务的任何异常，并将导致或可能导致服务的中断或服务质量下降的事态。
服务请求：
来自客户对IT服务的信息、建议、标准变更或访问请求。
例如要求增加内存、安装
某个软件、账号申请、变更请求等。
变更通常不认为是一个事件，而是一个变更请求
（RFC）。
但两者的处理方式相近，因此在事件处理过程中也包括对服务请求的处理，
即事件包含服务请求。
事件关闭：
接到事件请求后，服务台不能当时解决问题，则将需要把事件分配给相应的支持组。
为尽可能快地恢复业务，可利用解决方案（永久性的）或临时措施。
当事件得到了解
决，并且服务也恢复到正常状态后，事件关闭。
另外事件还包括系统自动产生或例行
巡检所发现的某些事态，如硬盘空间超出设定值、机房
UPS告警等。
虽然这些事态不
会对服务的交付产生直接影响，但对这些事态的处理也包括在事件管理过程中。
事件处理过程：
事件发生后，通常服务台接受和尝试处理，当服务台未能快速解决时，派单给一线工
程师作为一线支持处理；当一线工程师未能快速解决时，事件从一线返回服务台重新
分配到二线；二线未能解决时，调用三线厂商支持，后续的二线或三线支持应具有更
高的技能和资源来解决事件。
事件从一线支持转到二线或后续支持线，通常称为“职
能升级”。
为表述方便，在《事件管理程序》中，把“职能升级”过程称为“事件处
理过程”。
事件升级过程：
如果事件未能及时按照预定的时间得以解决或未能满足用户要求，需要管理层参与，
以提供更多资源，则进行“垂直升级”。
按照问题的解决时间进度设置自动升级的时
间段，如果在预定时间段，问题没有解决，则自动进行“垂直升级”。
在设定预定时
间段时，应考虑留有足够的时间以进行管理升级采取必要措施（如引入第三方支持）。
因为技能或经验的缺乏，可以通过服务台或支持工程师进行人工要求进行“垂直升
级”。
为表述方便，在《事件管理程序》中，把“垂直升级”过程称为“事件升级
过程”。
事件分类
由于用户提供信息的不完整或不正确，可能导致开始的分类与最终的分类有很大的差
别。
首先对事件按照事件类型进行分类，各类可以对应到相应的支持组，以便准确分
配任务。
编号一级分类二级分类描述
包括视频会议、视频监控系统线路及外围设
视讯系统
备
网络
PC终端
PC服务器
1合同服务
小型机
存储系统
公司自主开发软件或由公司提供服务的第三
应用软件
方软件
基础设施电源、空调、门禁、KVM
2工程售后视讯系统
全球眼
网络
PC终端
PC服务器
小型机
存储系统
应用软件
基础设施
硬件送修
PC机
3公司资产维护
网络
前端应用系统公司协同办公、MIS系统服务
4业务咨询
5单次收费服务
事件分级
给事件分配优先级，以保证支持组对事件必要的重视。
分级应基于是事件的紧急程度
和影响面。
事件严重程度定义如下。
级别定义
事件级别
影响业务范围
影响业务程度
业务修复紧急程度
一级事件
客户业务中断，无法工作
80%以上客户业务受影响
非常紧急
二级事件
客户业务性能严重下降
50%以上客户业务受影响
紧急
三级事件
客户业务性能下降
20%以上客户业务受影响
普通
四级事件
问题请求，业务性能无下降
客户业务可能有潜在影响
与客户协商确定
事件状态
为方便事件状态的跟踪和查询，对事件状态定义如下。
编号状态描述
编号状态描述
1待处理已在系统中记录，未派单给工程师
2已派单已分配至工程师，工程师未处理
3处理中工程师正在处理过程中，事件未关闭
4挂起工程师正在处理，调用三线厂商支持或送外修，尚未完毕
5暂停工程师正在处理，因客户原因暂时无法处理
6待审核事件已关闭，等待项目经理审核
7已归档服务台已审核归档，服务台回访客户结束。
2职责
2.1
服务台
受理事件请求，自行解决事件或调度相关支持组解决事件。
服务等级协议（SLA）约定的服务范围内的事件报告和服务请求，服务台都应纳入事
件处理范围。
负责对相关数据进行统计分析。
2.2
一线（现场工程师）/二线（专项工程师）
接收服务台的事件处理请求，解决系统运维相关事件。
负责提供一线/二线支持，按照标准要求填写处理过程。
负责联络和管理外部三线支持。
2.3
外部资源
接收一线/二线的事件处理请求，配合解决系统运维相关事件。
2.4
项目经理
负责协调资源调度，保障业务尽快恢复。
负责和客户确认事件解决并最终关闭事件。
监控事件处理流程的效率和效果。
管理一线/二线支持组的工作。
为改进工作提供建议。
3流程图
事件处理过程
用
户
/
电话
EMAIL/WEB巡检
口头/书面
系统
客
户
/
系
统
服
务
台
监视、跟踪、沟通和管理
一
线
支
持事件检测和记录
分类和初步支持
已解决
解决和恢复
事件关闭
未解决
二
线
调查和分析
解决和恢复
支
持
三
线调查和分析
支
持
4具体内容
4.1接受/记录事件
4.1.1
用户、IT维护人员、公司合作伙伴可以通过电话、传真或电子邮件等方式向服务台
报告事件，IT维护人员的日常检查等获得事件信息。
4.1.2
IT维护人员应按《服务合同》的要求进行例行检查，并应在检查结束后，填写相应
的检查记录，对所发现的事件应告知服务台登记。
4.1.3
所有工程师（含服务组、技术组）接受的客户直接报修或工程师自身主动发现的事
件，告知服务台登记。
4.1.4
服务台接到事件报告和服务请求后，及时在事件管理系统内作好记录。
事件记录应
包括以下要素：
4.1.4.1
事件编号
4.1.4.2
事件报告的日期、时间
4.1.4.3
记录人
4.1.4.4
事件报告人员、用户及其联系方式
4.1.4.5
事件发生的日期和时间，受影响的配置项
（CI）信息
4.1.4.6
症状描述和任何错误代码（如果是服务请求，则该项为所请求的服务的详细信息）
4.1.4.7
已经产生的影响或可能导致的影响等级；
4.1.4.8
事件处理状态
4.1.5
服务台记录事件后，要分析事件是否在受理责任范围内。
如果不在受理范围内，则
由服务台告知事件报告人。
如客户仍需提供超出受理范围的支持服务，则由服务台
告知客户及销售部门，由销售部门决定是否进行服务。
4.2分级/分类和初步支持
4.2.1
在接受和记录事件之后，服务台首先根据的事件分级、分类准则对受理的事件进行
分级和分类以方便后续的监视和报告。
4.2.2
服务台要根据事件分类及性质确定应由哪个小组处理该事件，转到对应的一线或二
线支持组。
4.2.3如果发现人员安排紧张时，应优先安排紧急程度高的事件。
必要时，可以召回低紧
急度事件的工程师，应对紧急程度较高的事件。
4.2.4对于重大事件，在按上述步骤进行处理的同时，还应按照第5节“事件升级过程”
进行升级汇报。
4.3
调查和分析
4.3.1
接到事件处理请求的小组应立即着手对事件进行调查诊断，提供事件、问题解决方
案。
判断事件的分级分类是否合理。
4.3.1.1
如果事件派单错误（如网络故障事件被派单到应用组）
，则立即返回服务台重新派
单。
4.3.1.2
如果事件分级错误，则进行相应的调整，并告知服务台。
但原则上，原有分级不
得降低。
4.3.2
接到事件处理请求的小组收到转发过来的事件后，查看知识库，看以前是否有类似
事件发生。
4.3.3
如果类似事件发生过，查看知识库里是否已经有事件或类似事件的解决方案或是应
急措施等，如果有就参照这些方案组织实施以解决事件。
如没有发生过类似事件，
尝试解决。
4.3.4
如果接到事件处理请求的小组不能快速解决事件，或者事件处理要求已经超过他们
直接解决范围，则转入后续支持，如由一线通过服务台转到二线，或直接调用第三
方厂家支持，并告知服务台。
4.3.5
接到事件处理请求的小组不能快速解决事件时，应按事件的紧急程度，按照第
5节
“事件升级过程”进行升级汇报。
4.3.6
如果事件无法得到解决，或事件虽然得到暂时解决，但没有找到事件发生的根本原
因，则由IT服务工程师汇报项目经理及部门经理，
视其需要创建问题，进入问题管
理过程。
4.4
解决和恢复
4.4.1
接到事件处理请求的小组应着手解决事件和恢复服务。
4.4.2如果事件的处理需要在中心机房、或其他重要区域及系统进行操作，应遵照客户的
规定执行。
4.4.3如事件的解决方案涉及IT基础设施、配置变更的，由负责事件处理的小组按《变更
管理程序》的要求向项目经理提交变更请求，项目经理制订相应的变更计划并监控
实施。
4.5
事件关闭
4.5.1
工程师获得用户对事件解决的认可后，将事件转为“待审核”状态
关闭事件。
4.5.2
项目经理每天确认所对应的“待审核状态”的事件是否解决。
如果确认事件解决，
则终止该事件，将事件状态改为
“已归档”；否则事件管理活动需要在未解决的地方
重新开始处理。
4.5.3
项目经理应对所发生事件进行分析，对于需要进行问题管理的事件，按照《问题管
理程序》的要求进行管理。
4.5.4
项目经理负责事件记录以及最终分类和分级的准确性。
4.6
过程的跟踪监控
4.6.1
事件处理人员在实施过程中应按照中的状态定义，随时更新事件状态或向服务台报
告事件状态。
当天未能解决的事件
服务台应在每个工作日下班前
1小时告知项目
经理事件的处理状态，以及预期的行动。
4.6.2
项目经理负责对事件进展进行跟踪和监控，
根据服务等级协议（SLA）来监控事件处
理流程的效果和效率，在事件处理过程中要和客户保持良好沟通，及时通报事件处
理的进展情况，提高客户满意度。
当天未能解决的事件，应在当天下班前半小时告
知客户当前事件的处理状态，以及预期的行动。
4.6.3
服务台应每周对所有事件进行回访，并向项目经理通报回访结果。
5事件升级过程
5.1事件严重程度定义
5.1.1
如果事件未能及时按照一定的时间得以解决或未能满足用户要求，
需要管理层参与，
以提供更多资源，则负责处理事件的工程师和项目经理应按照事件的严重程度逐步
升级汇报。
事件严重程度定义按照中的定义执行。
5.2
事件升级步骤
5.2.1
当事件未能或预计未能按照服务等级协议（
SLA）的要求，得以修复时，将按照预定
的时间表自动（或由服务台）发起事件升级。
另当，用户或支持队伍认为有必要时，
可以要求发起事件升级。
5.2.2
事件升级时间表
汇报人
工程师
项目经理
事业部总监
一级事件
立即
立即
立即
二级事件
4小时内
6小时内
8小时内
三级事件
6小时内
8小时内
12小时内
四级事件
12小时内
24小时内
48小时内
升级至
项目经理
事业部总监
公司管理层
（时间表按照客户合同重新调整）
6事件管理过程与其他流程的关系
6.1事件管理过程与其他关系
6.1.1图2为事件管理过程与其他过程的之间关联关系。
在事件管理过程中，可能需要直
接触发其他管理过程，或直接向某些过程获取必要数据。
对于在事件管理过程没有
直接影响的其他管理过程，则不在本过程中进行描述。
查询
配置管理
更新
事件信息
事件管理过程问题管理
解决方案
·
接受和记录
·
分级/分类和
初步支持
·
调查和分析
·
解决和恢复
RFC
·
事件关闭
变更管理
解决方案
·
事件跟踪、监
控和沟通
SLA要求
服务水平管理
报告
6.1.2配置管理指服务台/一线/二线/三线支持在处理问题过程中，可能需要从配置数据库
中获取必要的配置项相关的信息，并在处理过程中对配置项的变更及时更新。
6.1.3问题管理指事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问
题；事件虽然得到解决，但可能存在未知错误时，应创建问题；重大事件，无论是
否得到解决，为防止再次出现，应创建问题；在事件分析报告中提出的存在趋势或
潜在隐患的可能问题，例如事件类型或数量的趋势分析存在问题。
创建问题后，启
动问题管理过程。
6.1.4变更管理过程指服务台/一线/二线/三线支持在处理问题过程中，可能需要提交变更
请求，以解决问题。
6.1.5服务等级管理指为服务台在接受/跟踪时，提供必要的服务等级协议（SLA）信息。
7事件管理过程的KPI
7.1KPI定义
7.1.1为保证事件管理过程的快速有效，发现潜在的问题，被加以改善是非常必要的。
为
此，定义以下关键指标：
7.1.1.1事件的总数
7.1.1.2对业务的影响
7.1.1.3未能满足服务等级协议（SLA）要求的比例
7.1.1.4平均花费的时间（按事件分类进行统计）
7.1.1.5一线解决问题的比例
7.1.1.6事件趋势分析
7.1.1.7重大事件分析。
8输出的文件和记录
文件和记录
文件属性
拟制部门
《事件记录表》
D
服务部
《服务月报》
D
服务部
《客户服务工作单》
D
服务部
升级会员 