事件管理流程文件

事件管理程序

样式编号

编

审

批

密

版

制

核

准

级内部

本

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/W

:B巡检

E

口头书面系统

服

务

台

一

线

支

持

调查和分析>解决和恢复

调查和分析

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

4.1.4.6

4.1.4.7

4.1.4.8

4.1.5

事件发生的日期和时间，受影响的配置项（CI）信息

症状描述和任何错误代码（如果是服务请求，则该项为所请求的服务的详细信息）

已经产生的影响或可能导致的影响等级；

事件处理状态

服务台记录事件后，要分析事件是否在受理责任范围内。如果不在受理范围内，则

由服务台告知事件报告人。如客户仍需提供超出受理范围的支持服务，则由服务台

告知客户及销售部门，由销售部门决定是否进行服务。

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小时告知项目经理事件的处理状态，以及预期的行动。

462项目经理负责对事件进展进行跟踪和监控，根据服务等级协议（SLA）来监控事件处

理流程的效果和效率，在事件处理过程中要和客户保持良好沟通，及时通报事件处理的进展情况，提高客

户满意度。当天未能解决的事件，应在当天下班前半小时告知客户当前事件的处理状态，以及预期的行

动。

4.6.3服务台应每周对所有事件进行回访，并向项目经理通报回访结果。

5事件升级过程

5.1

5.1.1

事件严重程度定义

如果事件未能及时按照一定的时间得以解决或未能满足用户要求，

以提供更多资源，则负责处理事件的工程师和项目经理应按照事件的严重程度逐步

升级汇报。事件严重程度定义按照中的定义执行。

需要管理层参与,

5.2

5.2.1

事件升级步骤

当事件未能或预计未能按照服务等级协议（SLA）的要求，得以修复时，将按照预定

的时间表自动（或由服务台）发起事件升级。另当，用户或支持队伍认为有必要时，可以要求发起事件升

级。

522事件升级时间表

汇报人工程师项目经理事业部总监

一级事件立即立即立即

二级事件4小时内

6小时内

6小时内

8小时内

8小时内

12小时内

三级事件

四级事件12小时内

项目经理

24小时内

事业部总监

48小时内

公司管理层升级至

（时间表按照客户合同重新调整）

6事件管理过程与其他流程的关系

6.1

6.1.1

事件管理过程与其他关系

图2为事件管理过程与其他过程的之间关联关系。在事件管理过程中，可能需要直

接触发其他管理过程，或直接向某些过程获取必要数据。

对于在事件管理过程没有

直接影响的其他管理过程，则不在本过程中进行描述。

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

7.1.1.4

7.1.1.5

7.1.1.6

未能满足服务等级协议（SLA要求的比例

平均花费的时间（按事件分类进行统计）

一线解决问题的比例

事件趋势分析

7.1.1.7重大事件分析。

8输出的文件和记录

文件和记录

《事件记录表》

《服务月报》

《客户服务工作单》

文件属性拟制部门

服务部

服务部

服务部

D

D

D