IT服务管理项目_事件管理流程设计手册

事件管理流程设计手册

事件管理流程手册

文档信息

项目名称： 项目经理： 文档名称： 文档起草人： 当前版本编号： 相关文档： 项目编号： 项目阶段： 文档编号： 起草日期： 版本日期： 分发名单

来自 From 日 期 电话/传真/Email

给 To 行 动* 截止日期 电话/传真/Email *：行动类别：批准，复审，通知，存档，修改，其它（请指明） 版本记录

版本号 版本日期 修改者 说 明 文件名

II

事件管理流程手册

目 录

1. 文档介绍 ................................................................................................................................... 5

1.1 文档简介 ....................................................................................................................... 5 1.2 文档用途 ....................................................................................................................... 5 1.3 文档结构 ....................................................................................................................... 5 1.4 术语 ............................................................................................................................... 6 2. 事件管理流程简介 ................................................................................................................... 7

2.1 流程基本概念 ............................................................................................................... 7 2.2 流程目的 ....................................................................................................................... 8 2.3 流程范围 ....................................................................................................................... 9 2.4 流程主要内容 ............................................................................................................... 9 2.5 流程业务价值 ............................................................................................................. 10 3. 事件管理流程设计 ................................................................................................................. 10

3.1 流程执行原则 ............................................................................................................. 10

3.1.1. 流程常规原则 ................................................ 10 3.1.2. 责任制原则 .................................................. 11 3.1.3. 事件分派原则 ................................................ 11 3.1.4. 事件重分派原则 .............................................. 12 3.1.5. 重复/复发事件原则 ........................................... 12 3.1.6. 事件关闭原则 ................................................ 12 3.1.7. 事件通报原则 ................................................ 13 3.1.8. 事件升级原则 ................................................ 13 3.1.9. 流程关联原则 ................................................ 14 3.2 流程相关定义 ............................................................................................................. 15

3.2.1. 事件信息项 ..................................................................................................... 15 3.2.2. 事件来源 ......................................................................................................... 19 3.2.3. 事件性质 ......................................................................................................... 20 3.2.4. 事件分类 ......................................................................................................... 20 3.2.5. 事件优先级 ..................................................................................................... 21 3.2.6. 事件时限 ......................................................................................................... 22 3.2.7. 事件状态 ......................................................................................................... 23 3.2.8. 事件结束代码 ................................................................................................. 23 3.3 流程角色和职责定义 ................................................................................................. 24

3.3.1. 事件流程负责人 ............................................................................................. 24 3.3.2. 事件流程经理 ................................................................................................. 25 3.3.3. 服务台支持人员（含1线、1.5线） .......................................................... 26 3.3.4. 二线支持人员 ................................................................................................. 27 3.3.5. 三线支持人员 ................................................................................................. 27 3.3.6. 四线支持人员 ................................................................................................. 28 3.4 流程概要设计 ............................................................................................................. 28

III

事件管理流程手册

流程详细设计 ............................................................................................................. 30 3.5.1. 事件检测与记录 ............................................................................................. 30 3.5.2. 事件分类和初步支持 ..................................................................................... 31 3.5.3. 事件调查和诊断 ............................................................................................. 33 3.5.4. 事件解决和恢复 ............................................................................................. 34 3.5.5. 事件关闭 ......................................................................................................... 35 3.6 与其他流程的关系 ..................................................................................................... 37 3.7 流程衡量指标及报表 ................................................................................................. 38 4. 附录 ......................................................................................................................................... 39

4.1 事件管理流程相关表格 ............................................................................................. 39

3.5

图目录

图 3-1 XXX事件管理流程概览 ........................................................................................... 29 图 3-2 事件检测和记录 ....................................................................................................... 30 图 3-3 事件分类和初步支持 ............................................................................................... 32 图 3-4 事件调查和诊断 ....................................................................................................... 33 图 3-5 事件解决和恢复 ....................................................................................................... 34 图 3-6 事件关闭 ................................................................................................................... 35 图 3-7 XXX服务管理流程关系图 ....................................................................................... 37

表目录

表 3-1 事件升级机制 ........................................................................................................... 14 表 3-2 事件信息项 ............................................................................................................... 15 表 3-3 事件来源 ................................................................................................................... 19 表 3-4 事件性质 ................................................................................................................... 20 表 3-5 事件分类 ................................................................................................................... 20 表 3-6 事件紧急程度 ........................................................................................................... 21 表 3-7 事件优先级矩阵 ....................................................................................................... 22 表 3-8 事件时限 ................................................................................................................... 22 表 3-9 事件状态 ................................................................................................................... 23 表 3-10 事件结束代码 ......................................................................................................... 23 表 3-11 事件管理KPI列表 ................................................................................................. 38

IV

事件管理流程手册

1. 文档介绍

1.1 文档简介

本文档『XXX事件管理流程设计手册』,是XXX信息技术总部（以下简称XXX）团队制定的事件管理流程文档。通过制定该流程，可以帮助XXX信息技术总部团队对主动监控发现以及用户上报的故障和服务请求进行快速响应和快速处理, 尽快恢复中断或受影响的用户业务。通过该流程的规范，可进一步改进XXXIT服务向用户提供的服务水平和服务质量,确保用户对服务价值的认同和肯定。

本文档是依据目前XXX的IT服务状况而制定的事件管理流程,进一步的流程更新将移交由XXX服务团队负责。

1.2 文档用途

本文档既是本次IT服务管理项目事件管理流程的交付物,也可作为XXX服务团队进一步改进事件管理流程的蓝本,读者对象为与事件管理流程相关的所有管理与技术人员.

本文档所描述的流程在IT服务管理中有许多作用,列举如下:  减小突发事件对业务的影响；  最优化支持资源，提高工作效率；  屏蔽错误事件和服务请求；

 根据影响业务轻重缓急安排资源解决事件，保障有效IT运营；  加强有形监控和及时反馈；  提升用户对服务的认知度和满意度；  提供管理信息；

1.3 文档结构

本文档作为XXX事件管理流程设计手册，主要包含针对XXX服务运营中对用户故障及用户请求处理等相关人员及活动的定义和描述。各章节中内容概要如下：

 文档介绍

主要对文档的目的、用途及结构进行简要描述，并就文档当中出现的术语进行了说明。  事件管理流程简介

5

事件管理流程手册

主要对事件管理流程的基本概念、目的和范围进行了介绍。同时简单梳理了事件管理流程中包含的主要活动内容，最后对事件管理流程对组织及用户的业务价值进行了相关阐述。

 事件管理流程设计

该部分为本文档的重点章节。在该章节中，首先对事件管理流程的相关执行原则和代码进行了描述；其次，对事件流程相关角色的职责和技能要求进行了说明；基于流程原则和角色定义，进而对事件管理的概要设计流程及详细设计流程进行了充分定义，并给出了事件管理流程的关键衡量指标，以保证对流程运行的监控、管理和改进。

 附录

与事件管理流程相关的附属内容，都将在附录中进行补充说明。

1.4 术语

 服务台

在ITIL中， 服务台从根本上来说提供了用户和IT部门的唯一接口。此项功能常常通过集中的服务台进行体现。服务台的根本目的是提供一线支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。

 事件管理

ITIL流程，是负责解决所有的IT事件、问题和用户请求等的管理流程。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

 问题管理

ITIL流程，是负责对事件进行深入分析，找出根本原因并提供解决方案的管理流程。它的目的是主动防御，找出根本原因并对其根除，所以它与事件管理流程有显著的不同，以“治本”为最终目标。

 变更管理

ITIL流程，是负责对生产环境中支持IT服务的各种基础架构设备和应用系统的变更操作进行记录、分类、评估、计划和协调的流程。它的目的是在权衡“风险”和“效率”的前提下，对变更操作进行有效的控制，以保证任何变更对IT环境和其所支撑的IT服务的影响最小。

 发布管理

6

事件管理流程手册

ITIL流程，是负责对应用系统上线过程的全局管理和控制。管理范围涉及测试环境、预发布环境和生产环境等，旨在通过对发布单元的生命周期各个阶段的控制保证其安全稳妥的进入生产环境，而不引入新的缺陷或故障。

 配置管理

ITIL流程，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置元素（CI）。每一个CI必须有效管理，跟踪和控制以支持IT服务和基础设施成功运行。

 配置管理数据库（CMDB）

是在配置管理流程中用于记录企业所有IT相关配置元素信息及其相互关系而建立的数据库。

 ITIL

IT Infrastructure Library，是英国在1987年制定的有关IT服务管理的方，现已成为事实上的IT管理标准。

2. 事件管理流程简介

2.1 流程基本概念

事件管理流程通过提供服务台作为日常IT支持接口，由IT支持人员根据流程定义，快速响应和解决IT用户的服务请求、突发事件、投诉反馈等，最大化地减少突发事件对用户业务活动的影响，最终确保SLA目标的实现。

事件管理流程相关的几个关键词汇解释如下：

“日常支持接口”：即服务台，该接口将采用集中服务方式，向所有IT用户提供唯一服务窗口，按照业务需求，提供相应级别的支持服务。

“IT用户”：指的是指XXX服务的使用者，他们使用XXX提供的IT服务来支持相关日常业务。

“IT支持人员”：指的是XXX 服务团队中IT运维和支持人员的统称，包括一线人员和二线人员等，可能涉及XXX体系中的相关的开发、支持和运维等团队。

“一线支持”：指服务台的通用座席，向IT用户提供一线支持服务，以下提到的服务台人员即一线支持人员。

“1.5线支持”：指机房值班人员（交易系统故障时）和桌面维护人员（桌面故障时)，

7

事件管理流程手册

在桌面类和机房交易系统相关事件处理过程中实施IT支持服务；

“二线支持”：主要由各职能小组运维工程师组成，协助服务台一线人员参与事件处理，相对一线支持人员，二线支持具有更高更专业的技能。

“三线支持”：指各职能小组组长，在复杂度较高事件或二线支持无法解决事件时负责协调小组内部人员进行事件处理，三线支持更多的强调管理协调职能。

“四线支持”：指XXX开发团队和供应商等。

“事件”：指XXX在用户IT环境中发现的所有非正常事件，对现有的服务造成影响或中断。例如：服务器宕机、网络中断、应用不可用等。从来源上来分，主要包括由信息技术总部内部人员发起的事件以及有用户报告的事件等。

“服务请求”：指用户提出的关于标准服务、培训、文档、信息等方面的请求，以及针对IT服务使用的咨询等，通常并没有发生IT组件方面的故障。例如：请求培训、寻求咨询等。服务请求是一种特殊类型的事件。

“投诉反馈”：指由用户提出的对于IT服务质量或服务方式的抱怨或改进建议，通过服务台统一接受，并进行相应处理。

2.2 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

 在成本允许的范围内尽快恢复IT服务

 快速响应故障及服务请求  用户在线获得帮助  沟通事件解决的状态  和用户确认事件的解决  进行事件控制

 按规范记录事件

 就事件的优先级，影响度 进行分类  分析，诊断，必要时进行升级  监视并结束事件  进行定期服务流程回顾  提供IT管理信息

 人力资源利用情况  故障处理情况

8

事件管理流程手册

 支持效率

2.3 流程范围

XXX事件流程管理范围包括所有用户与XXX信息技术总部内部的事件、服务请求和投诉反馈等。

其中：

 不包括现有应用系统新增功能需求

 不包括用户对于信息类设备和应用系统的新需求  不包括新系统开发需求

2.4 流程主要内容

事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：  事件接收和记录

这个环节是事件管理流程的起点。所有监控系统或用户报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。该环节的关键是信息的准确性和完整性。

 分类和初步支持

对于每个事件，需要确立优先级和分类。若没有现成的解决方案（Solution）或变通方法（Workaround），该事件将分配给合适的支持人员对此进行调查。

 调查和诊断

若支持人员无法利用现成方案解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

 解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。

 事件升级

对于高优先级的事件，服务台应立即上报给事件经理和相关的管理层，由事件经理决定事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期解决时限，应通知相关处理人员和管理层，以引起处理人员和管理人员的重视和参与。

9

事件管理流程手册

 结束事件

当用户确认事件解决后，可结束该事件。

2.5 流程业务价值

XXX事件管理流程将在多个方面对“XXX服务”业务产生积极作用，具体表现在以下几个方面：

单一联系点 – 通过在团队内部建立服务台，作为与用户沟通联系的单一联系点。对用户方发生的故障及用户上报的服务请求进行快速响应和统一管理，对内部服务支持资源进行合理协调和调配。同时，服务台作为IT服务窗口，也进一步维护和加强了与用户的关系，为提高用户体验和满意度起到了重要作用。

用户业务尽快恢复 – 通过合理调配资源，使用知识库等相关支持工具，对不同级别事件选择各自的解决时限，对用户被中断或受影响的业务进行快速响应和恢复。

内部团队协作加强 – 为服务支持团队成员分配角色，并清晰界定职责。通过事件管理流程将团队成员进行有效的连接，加强内部团队协作和沟通的有效性和工作效率。

服务质量控制和改进 – 通过定期提交流程相关指标和报表至管理层，以实现对流程的监控和管理，同时为服务质量的改进奠定基础。

3. 事件管理流程设计

3.1 流程执行原则

3.1.1.

流程常规原则

 所有在流程范围内发生的事件，都应该被完整准确的记录下来，记录的信息应足够

详细，包括事件处理交互过程，详细的解决方案和相关的附件等。  事件处理过程中，在需要寻求第三方的情况下，遵循下述原则：

 根据事件实际处理情况，各二线或三线支持寻找相应供应商

 在供应商参与解决事件的过程中，事件当前处理责任仍保留在二线或三线人员处  XXX服务支持体系是由信息技术总部全体人员共同组成的，事件的处理过程中必须

加强一线和二线的沟通，沟通的方式优先使用工具（服务管理平台），在需要的时候必须辅助电话、短信、邮件等手段。  所有支持人员优先处理优先级较高的事件。

 对于来自于服务台转入的事件（包括故障/服务请求/咨询/投诉建议），首次接听电

话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件在XXX

10

事件管理流程手册

范围内的责任人，确保事件在在XXX内部得到有效跟踪、解决，并将解决结果反馈给服务台。

 每月定期产生事件管理报表，分析服务质量，对重大事件、重复发生的事件或者利

用变通方法解决的事件，应提交问题管理流程进行问题定义分析和解决，并定期对这些事件进行评估跟踪。

 建议每三个月对流程进行回顾，包括流程执行效率和流程支持工具的有效性，以改

进和优化事件管理流程。

3.1.2.

责任制原则

责任制原则用来确保每个事件在任何时段都有适当的人员负责。

 由监控系统上报的事件，对故障进行识别并在系统中记录的服务台人员是该事件的

责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭

 由用户电话上报的事件，首次接听电话并进行支持的服务台人员负责在系统中进行

登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭

 服务台员工换班时，由服务台值班经理进行事件重新分派，事件责任人也由此转移  事件被服务台人员转至二线人员或第三方后，二线人员/第三方成为该事件的当前

责任人，但服务台人员仍然是事件的整体负责人，有义务对事件处理状态按相应策略进行监控，并及时反馈给用户，保证事件的处理过程对用户充分透明。

3.1.3.

事件分派原则

事件分派原则是确保事件在服务目标时段内处理和解决的重要因素。

 服务台一线支持人员在规定的一线处理时限内，可按情况选择转给其他在值服务台

一线支持人员进行处理

 服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分

类分派到相应二线支持人员。

 在特定情况下，比如二线支持人员的非工作时间内，服务台一线支持人员在派单后

利用电话方式通知二线人员相关事宜。

 桌面类故障导致事件直接由1.5线桌面运维小组进行处理  开市期间交易系统故障，直接由1.5线机房座席接听处理。

 服务台一线支持人员在判断事件为交易系统故障后，应第一时间按策略通报机房处

理，不能明确界定是否是交易系统故障，亦应交机房处理。

11

事件管理流程手册

3.1.4. 事件重分派原则

 二线支持接受服务台分派事件后，如果该事件不属于本人支持范围或者自身能力无

法处理，二线人员需首先注明原因，然后将事件返回到服务台，由服务台重新分配。  为提高事件解决效率，应当尽量减少事件单重分派的几率。事件单的重分派次数不

应该超过2次。

 同组的事件单再分派不被监控；

 任何跨组的事件单再分派将会报告给事件经理；  事件再分派超过2次，事件单将升级给事件经理； 3.1.5.

重复/复发事件原则

重复事件

如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。

将会为此重复的事创建新的事件单，并标注此单为“重复”并与原始事件单相关联。原始事件将被标注为“主事件”

复发事件（3天内同一用户，同一件事）

如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了（或失败或误再报）。此时，应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。 3.1.6.

事件关闭原则

 事件单的关闭必须由服务台对应1.5/1线支持人员完成，但是事件经理可以超越此

规则。其他人无权关闭事件单。二线支持人员确定解决方案并解决事件后，必须把事件返回到服务台。

 事件单的用户可以要求关闭此事件单，例如：误报、错报事件。关闭事件单由事件

单对应一线支持人员负责。

 服务台人员关闭事件前，需获得客户对解决方案的确认和反馈。  关闭事件时，根据实际解决情况填写事件的结束代码。

 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并标识

为复发事件。

 对于以“变通方法解决”或 “不能重现”结束代码关闭的事件，需通知问题经理

对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。

 所有优先级为最高的事件在关闭后，需通知问题经理对此类事件进行分析并在必要

时生成问题，通过问题流程对问题进行根源分析并提供解决方案。

12

事件管理流程手册

 对于未及时取得用户反馈的已解决事件，系统将对其保留3日。3日内服务台人员

应至少每天主动与用户联系1次。若3日后仍未得到用户有效反馈，系统将自动关闭事件，并标识结束代码为“自动关闭”字样。

3.1.7.

事件通报原则

对于监控系统自动发现的告警信息，服务台人员有责任对其进行识别。如确认为一条事件，则应首先在第一时间通报相应用户和事件经理，然后在服务管理平台中进行记录。通报策略具体如下： 通报方式

 用户工作时间内采用正式的通知方式进行通报  用户非工作时间采用邮件方式进行通报

 与用户通报相关的其他方式参考与用户签订的SLA中的具体定义  采用邮件的方式通知事件经理；

 如果由于用户原因第一时间无法完成通报，应首先在服务管理平台中登记一条事

件，并置于“挂起”状态，相关服务台人员有责任在开单后每隔5分钟主动尝试联系用户3次。若3次后仍无法取得联系，则应在事件工作日志中注明“无法联系到用户”的字样，并进行后续处理；若3次内取得联系，则在与用户确认故障后，取消事件“挂起”状态并进行后续处理。

通报对象

 依照事件分类表中定义，向用户部门相关人员通报  最后通报事件经理 通报内容

 事件简要描述

 可能受到影响的用户方业务（或范围）  确认是否为用户方运维操作导致  可能导致事件的原因  预计解决事件的时间点 3.1.8.

事件升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。

13

事件管理流程手册

 优先级为最高的事件，需要立即事件升级，同时，事件继续按事件管理流程进行快

速处理

 超出规定的响应或者解决时限之后，需要立即升级事件，同时，事件继续按流程进

行快速处理

 事件重复派单超过三次直接升级给事件经理 具体事件升级机制如下表所示：

表 3-1 事件升级机制

事件升级机制 小组技术经理 事件经理 运维经理 技术总部领导 公司领导 优先级1 优先级2 优先级3 优先级4 5分钟 1小时 2小时 4小时 5分钟 1小时 2小时 4小时 10分钟 1小时 10分钟 1.5小时 15分钟 3.1.9.

流程关联原则

 和问题管理的关联

 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案  通过分析事件记录，形成问题，并使该问题与相关事件建立关联

 通过事件单和问题单的关联，服务台人员对问题的解决状况进行跟踪并和用户保持沟通

 对高优先级事件或者“变通方法解决”或“无法重现”关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。  和变更发布管理的关联

 事件处理过程中，如果需要对相关IT组件进行变更（不在标准变更清单内的变更），必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。

 高优先级事件的处理过程中，如果需要对相关IT组件进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和事件单建立关联。  和配置管理的关联

 事件处理过程中，可以通过配置管理查询相关的配置项信息（尤其是关系信息）以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位

14

事件管理流程手册

 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联

3.2 流程相关定义

3.2.1. 事件信息项

事件单必须包含如下事件信息项，XXX服务团队可以在此基础上进行扩充：

表 3-2 事件信息项

序号 1 2 3 4 信息项 事件ID 事件请求人 事件登记时间 事件登记人 说明 事件单流水号（系统自动产生） 事件申报人的信息，包括：姓名、公司、部门、电子邮件、办公电话、手机 在服务台生成事件记录的时间（系统自动产生） 事件开单人的信息，包括员工姓名、员工ID、联系方式等（系统自动产生） 针对故障：指的是业务中断的实际时间 （可能早于登记时间，自5 事件发生时间 动设置或者手工填写）；针对用户请求：缺省值等于登记时间。 事件发生时间必须早于或等于登记时间。 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 事件发生地点 事件来源 事件标题 事件描述 事件性质 事件分类 事件状态 事件影响范围 事件紧急程度 事件优先级 事件完成期限 事件分配工作组 事件分配人员 事件工作日志 解决方案/变通方事件发生的位置信息 参见“事件来源”定义 事件的简要描述 对于整个事件内容的详细描述 参见“事件性质”定义 参见“事件分类”定义 参见“事件状态”定义 参见“事件影响范围”定义 参见“事件紧急程度”定义 参见“事件优先级”定义 对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生） 被分配的支持小组 被分配的支持小组内成员 反映事件处理过程的信息 事件解决方案/变通方法的描述 15

事件管理流程手册

序号 法 21 22 23 24 25 26 27 28 29 30 31 32 信息项 说明 事件解决人 事件解决人角色 事件解决时间 处理是否超时 涉及第三方支持 关联配置项 关联的问题单号 关联的变更单号 事件结束代码 事件关闭时间 重复事件标记 对应告警ID 事件的最终解决人 参见“事件解决人角色”定义 记录事件状态为“已解决”的时间（系统自动产生） 参见“处理是否超时”定义（系统自动产生） XXX和第三方集成商名称 记录出现故障的线路编号或者CPE设备编号 记录由事件引发问题时，关联的问题单号 记录由事件引发变更时，关联的变更单号 参见“事件结束代码”定义 记录事件状态为“结束”的时间（系统自动产生） 标记为重复事件 事件如来自于监控系统告警，则填写对应告警的ID；若为用户自动上报，此处为空不填 用户对事件处理的满意程度。分值从5分至1分，分别对应非常满意、比较满意、一般，不太满意及很不满意 用户对事件处理过程及结果的意见或建议 事件相关附件信息 33 34 35 用户满意度 用户反馈信息 附件信息 IT运维事件单 （含事件、信息咨询、服务请求） 事件单编号： （示例：200708220001） 受理事件基本信息 ■ 受理时间 用户所属部门 2007年 月 日 时 分 申报人电申报人 申报方式 话 申报人 ■受理人 EMAIL □电话 □邮件 □工作台 □现场 □其他 16

事件管理流程手册

序号 信息项 说明 受理人根据事件形成事件信息 服务分类 □故障 □问题 □改进 □咨询 □业务需求 □投拆 □其他 桌面终端类：□PC机故障 □局域网故障 □软件故障 □外设故障 基础设施类：□硬件故障 □操作系统事件分类 /DB/系统软件故障 □网络故障 □机房环境故障(空调、UPS等) 应用系统类：□可用性 □响应速度 □功能性 □易用性 （应用系统列表选择） □VIP1 □VIP2 □普通 □单内部客户 □单部门 □2个部门以上 □单外部客户 □单营业部 □2－4个营业部 □4个营业部以上 影响度： 影响度： 影响度： 报障人员分类 受影响人员分类 人员分类 影响度： □关键设备(列表选择) □非关键设备 □未关键设备 知 典型事件分类 事件描述 事件影响度 □典型事件（列表选择） □无对应典型事件 □1-危急(5分钟) □2-紧急(高,30分钟）□3-紧急(中,2小时) □4-紧急事件紧急度 (低,4小时) □5-普通(4小时以上) 事件处理优先级 事件完成计划时间

影响度： 17

事件管理流程手册

序号 受派人员 处理人员记录 响应时间 服务方式 信息项 说明 月 日 时 分 处理人员 □电话 □Email □现场 □远程终端 □送修 □其它 原因及故障分析： 解决办法： 是否需要发起技术问题处理 用户反馈 （用户填写） 处理结果 满意度评价 用户意见(可选) 事件优先级升级记录 □是 □否 (去除？） 完成时间 日 时 分 □全部解决 □部分解决 □未解决 □非常满意 □较满意 □满意 □不满意 □自动结束 □客户确认结束 □转为其它 □事件经理结束 □转为同工具其它流程（对应编号） □转为NOTES事件结束方式 事件对应其它流程编号(转为其它时填写） 18

事件管理流程手册

序号 信息项 说明 其它流程（流程名称(列表)＋对应编号） 最终事件分类（服务台填报） □故障类型 □问题类型 □咨询类型 □需求类型 □投拆 □其他 知识库评价

3.2.2. 事件来源

□有对应完善知识库 □知识库需完善 □无对应知识库

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：

表 3-3 事件来源

事例来源 描 述 电子邮件 服务台通过电子邮件收到一个请求。 电话 服务台通过电话收到一个请求。 服务台工具 （Help Desk） 服务台通过Web系统（流程管理平台）收到一个请求。 来访 用户直接到电脑部工作间找相关工程师报障 主动监控 服务台通过系统网络管理工具主动监控得到的请求。 19

事件管理流程手册

3.2.3. 事件性质

事件性质用来表明事件的概要类型，具体可以包含以下几种：

表 3-4 事件性质

请求类型 描 述 事件 出现对服务造成影响的不正常现象 信息咨询 对与业务或IT相关杂项信息（联系人、电话号码，状态查询等）的请求 服务请求

3.2.4. 事件分类

对外宣布的服务（不含新业务需求） 事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。当事件发生时，应该由服务台初步分析和定位事件的分类，一方面便于与历史事件/问题或者知识库的匹配，另一方面也便于选择合适的二线或者第三方进行分配。事件最终分类可由后续支持人员作进一步的确认，并在事件关闭前进行调整。

事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为“子类”，第三级分类，称之为“条目”。

XXX事件分类表分为三大类：桌面类、网络类、系统类

表 3-5 事件分类

流 程 系统/类别 模块/子类 模块/子类说明 使用部门 使用模块业务功能说明 该模块的业务部门 填写基本原则：客户化语言描诉 典型事件 二线责任人 处理该事件的工程师或职能三线责任人 四线责任人 备 注 各应 用系统名称 应用系统的模块名称 20

事件管理流程手册

小组

3.2.5. 事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源。在XXX服务中，事件优先级可分为四级：P1（最高）、P2（高）、P3（中）、P4（低）。为方便服务支持对于事件优先级的判断，XXX建议从事件影响程度和事件紧急程度两维来进行优先级定位。

事件的影响程度主要是对事件发生的关键程度以及事件发生后的影响范围综合考虑得出。在XXX业务中，要考虑以下几个方面：

 用户身份

 受影响用户数量和范围  受影响设备  受影响系统

具体影响程度判定可直参考附件中的影响度判读资料。

事件的紧急程度主要由事件本身是否涉及关键业务系统来进行判定，如事件涉及关键业务系统，则认为紧急程度较高，需要尽快恢复；如事件不涉及关键业务系统，则认为紧急程度较低，可优先处理紧急程度较高的事件。在XXX业务中，事件紧急程度定义具体如下：

表 3-6 事件紧急程度

紧急度 1-危急 30分钟 紧急度时间标准 备注 2-紧急（高） 2小时 3-紧急（中） 4小时 4-紧急（低） 8小时 21

事件管理流程手册

5-普通 8小时以上 结合事件发生时的影响程度和紧急程度，可以通过下表确定事件的优先级：

表 3-7 事件优先级矩阵

事件优先级 1-危急 1 影响度 高 2 中 3 低 2-紧急（高） 2 3 3 紧急度 3-紧急（中） 3 4 4 4-紧急（低） 3 4 4 5-普通 4 4 4 注：对于用户上报的服务请求，一般建议按优先级为P4（低）进行处理。 3.2.6. 事件时限

在事件处理过程中，对于事件应有响应时间、分派时间和解决时间，以保证事件处理过程的高效执行。如果该事件的响应、一线分派、解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

响应时限指的是事件发生到在系统中登记所经过的时间； 一线分派时限指事件登记时间到转给二线/第三方所经过的时间； 解决时限指的是事件登记时间到事件状态变为“已解决”所经过的时间。

在XXX业务中，不同的事件优先级对应了不同的响应时限、一线分派时限及解决时限，具体如下：

表 3-8 事件时限

事件目标时间 一线响应时间 事件被分派并得到接受 事件得到解决的时间 备注 优先级1 优先级2 优先级3 3分钟 5分钟 10分钟 5分钟 10分钟 20分钟 30分钟 2小时 4小时 22

事件管理流程手册

优先级4 10分钟 30分钟 8小时

3.2.7. 事件状态

事件状态代码表明事件所处的处理状态，事件状态如下：

表 3-9 事件状态

状态代码 待处理 已分派 受理中-1线 受理中-1.5线 受理中-2线 受理中-3线 受理中-4线 挂起 事件信息不完整，或在某些情况下阻止事件受理员对事件进行处理，等待的原因为： • • • • • • 已解决 已关闭 需要客户提供更详细的信息 优先级为1、2必须由事件经理挂起 不能联系到用户人员 升级到供应商处理 采购定单的批准 不可抗拒力原因 一个事件被记录或创建 一个事件已被分派给一线支持人员、二线支持人员或事件经理； 任何一个服务台1/1.5/2线支持人员或第三方（供应商、开发部）接受了事件并开始处理事件 描述 为一个事件找到解决方案或变通方法 事件经用户确认已关闭

3.2.8. 事件结束代码

事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：

表 3-10 事件结束代码

事件关闭代码 描 述 23

事件管理流程手册

成功 事件被正常解决 成功但有问题 事件已通过变通方法解决掉，但是需要进行更进一步的根源分析。 不能重现 没有找到错误或不能重现故障 操作错误 用户错误（如操作错误、理解存在误差等） 失败 已知的错误、变通方法或已实施的变更失败，不能解决这个事件或问题 3.3 流程角色和职责定义

3.3.1. 事件流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程XXX服务团队范围内被正确的执行。随着业务需求和IT环境的改变，流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改进，从而实现服务能力的可持续提升。

职责定义:

 确定管理流程的衡量指标

 确保事件流程能够取得管理层的参与和支持  确保事件流程符合业务实际状况和业务发展战略  总体上管理和监控流程，建立事件流程运行机制  确保事件流程实用、有效、正确地执行  保持与其他流程负责人的定期沟通 专业技能：

 理解内部和外部业务环境  理解业务规划及发展战略  理解用户需求

 充分理解业务相关IT、操作过程和标准  流程的评估和设计能力  良好的分析和规划能力

24

事件管理流程手册

 理解事件管理流程  理解服务水平承诺 处事技能：

 良好的矛盾管理技巧  确定问题和趋势发现的能力  良好的口头和书面表达能力  工作主动性和领导能力  决策能力

3.3.2. 事件流程经理

事件流程经理负责事件解决过程中的协调和监控，以及事件升级的判断以及升级过程中的具体执行或协调。

职责定义：

 监控事件流程运行状况

 负责对事件解决过程的资源协调，跟踪事件的解决进展

 当事件超时升级或重大事件升级时，负责或参与资源协调，解决事件  确保和问题管理流程的有效合作

 基于事件处理状况，发现IT或业务相关的问题 专业技能：

 充分理解业务相关IT、操作过程和标准  基本了解业务系统环境  具有流程的知识  了解用户需求  分析技能  理解服务水平承诺  用户关系技能 处事技能：

 良好的口头和书面表达能力  矛盾管理技巧

25

事件管理流程手册

 监控和管理流程的能力  谈判技巧

 确定问题和趋势发现的能力  管理经验

 良好的团队工作能力

3.3.3. 服务台支持人员（含1线、1.5线）

用户的主要联系人，作为用户组织和服务团队之间的纽带。作为事件的整体负责人，负责创建事件单，并跟踪、协调事件的解决。

职责定义：

 按监控流程和规范进行主动监控工作，并对告警进行筛选和识别  响应所有用户事件，包括通过电话、邮件、WEB等渠道的事件

 完整记录所有接收的事件信息，包括：IT用户信息、事件描述、发生时间和地点等  负责处理事先确定的服务请求

 为事件进行适当的分类、为事件分配优先级等属性

 使用知识库等手段对事件进行初步诊断和分析，尝试解决问题  必要时联系供应商和现场服务人员，参与事件处理  如果不能解决事件，应当将事件分配给合适的二线支持

 检查事件记录的处理进度，保持与用户的联系，适时通知事件处理状况  与用户确认事件解决方案，关闭事件 专业技能：

 了解用户和供应商信息

 基本理解业务相关IT、操作过程和标准  用户关系技巧  服务的基本知识和技能  沟通技巧  分析诊断能力  电话响应技能 处事技能：

 出色的口头和书面沟通能力（必要时多语种支持）

26

事件管理流程手册

 客户至上的理念  责任心  承受压力的能力

3.3.4. 二线支持人员

二线支持人员具有某个领域的技术技能，负责对服务台无法解决的事件进行进一步快速有效的分析，提出解决方案以尽快恢复服务。

职责定义：

 验证事件的描述和处理状况，进一步收集相关信息

 根据专业技能和知识库等，确定并实施有效解决方案或临时变通方法  必要时联系供应商和现场服务人员参与事件处理

 更新事件记录和解决方案，确保事件状态代码真实反映事件状态  必要时与其他二线支持人员合作，确定解决方案或临时变通方法  已解决的事件转回服务台，由服务台进行用户确认并关闭事件 专业技能：

 基本理解业务相关IT、操作过程和标准  理解相关的操作过程和工作指导

 IT基础架构和操作环境中某一方面的较高的技术知识  用户关系技能  分析技能 处事技能：

 良好的口头和书面沟通能力  基本的决策能力  客户至上的理念  承受压力的能力 3.3.5. 三线支持人员

在XXX的的三线为各职能小组组长，其主要职责是调度和安排复杂度较高的事件处理。 鉴于其管理职能偏重，且各小组的技能要求出入很大，此处不再做具体要求。

27

事件管理流程手册

3.3.6. 四线支持人员

四线支持人员是指除运维团队外的技术层面XXX可以调集的事件处理人员，包括：

 开发人员  业务单位对口人员  供应商

3.4 流程概要设计

流程概要设计是从逻辑层面对事件管理流程进行的描述总结，结合XXX具体情况，给出如下流程设计： ＝子流程 ＝ 判断 ＝结束或节点

＝其他流程 ＝文档 事 件 管 理 流 程角色阶段用 户0线 (机房)热线 (一线)二线支持团队三线 (开发)四线 (供应商)事件经理备 注事件查明IM1事件识别、记录、分类和初步支持呼叫服务台否识别和验证客户基本信息事件记录初步支持解决？否派单给0线？否派单给2/3/4线包括基本信息、关联资产、类别、影响度、紧急度、优先级自行解决？是事件记录和关闭事件单接受派单？否重派单是如热线派单三次仍未成功，则升级给事件经理派单是关闭IM2事件调查和诊断IM3事件解决和恢复现场调查需要2/3/4线支持？否调查和诊断是确定解决方案或变通方法解决方案/变通方法现场处理记录处理结果实施解决方案或变通方法记录处理结果接受关闭请求？IM4事件关闭是更新知识库？否是知识管理关闭关闭事件 28

事件管理流程手册

图 3-1 事件流程角色与流程总体对应流程图

事事事事事事事事用户/nView请求Web提交一线支持人员呼叫服务台IM1事件识别与记录已记录事件IM1分类和初步支持存在解决方案/变通方法已解决IM3解决和恢复IM4事件关闭分派事件单2/3线支持人员关联配置项参考知识记录IM2调查与诊断找到了解决方案/变通方法其它服务支持/提供流程配置管理知识管理问题管理变更管理问题管理知识管理服务水平管理

图 3-2 XXX事件管理流程概览

事件管理概要设计流程说明 序号 步骤名称 责任人 说明  服务台人员通过监控系统进行主动监控，发现告警后对告警进行监控和跟踪，如识别确为故障，则通报相应用户，并同时在服务管理平台上登记一条事件记录进行跟踪和处理。  服务台人员除主动发现事件外，也接受来自用户上报1 事件识别和记录 服务台 的故障以及各类服务请求。在充分搜集事件信息后，服务台人员在服务管理平台上登记一条事件记录进行跟踪和处理  如果是一条重复事件，则新建该事件记录后，更新原有事件为“主事件”，并建立重复事件与原有事件的关联关系。  服务台人员对事件进行分类，并分配优先级。 2 分类与初步支持 服务台  服务台应尝试解决事件，如果无法解决需及时升级到二线支持

29

事件管理流程手册

序号 步骤名称 责任人 说明  服务台人员找到解决方案或变通方法后，转3.1  二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决，必要时可联系第三方供应商协助处理。 3 调查与诊断 二线支持  对于无法找到解决方案或者变通方法的事件，二线人员可转回服务台请求重新分派  二线支持人员找到解决方案或者变通方法后，转3.1  服务台或二线支持人员详细记录解决方案或变通方法 4 解决与恢复 服务台/二线支持  如解决方案或变通方法涉及变更，则由服务台或二线支持人员发起变更请求（RFC），并对变更管理流程进行监控和跟踪  服务台人员对已解决的事件与用户进行确认  如用户业务确认被恢复，则关闭事件 5 事件关闭 服务台  事件必要时可由服务台人员提交至知识管理  重大事件/变通方法解决事件/不成功解决的事件可由交由问题流程成为问题记录，进行深入分析

3.5 流程详细设计

3.5.1. 事件检测与记录

1.1 事事事事事事事事事事事事事事事请求控制台/查找知识库事件查明新建Web自助1.1能够自行解决？客户Yes关闭No服务台受理支持人员（1线、2线）呼叫服务台新的1.2识别和验证客户基本信息1.3客户信息正确？Yes1.4新请求还是已有的事件？已有的1.5关联到已有的事件记录1.6记录事件概要和备注1.7事件经理否其他外部流程配置管理

30

事件管理流程手册

图 3-3 事件检测和记录

详细流程说明如下： 序号 1.1 步骤名称 能否自行解决 责任人 用户 说明  这里的用户包含业务用户和XXX内部IT人员  自行处理解决后直接在服务管理平台关闭事件  服务台接受来自用户和监控系统上报的事件 1.2 识别和验证客户信息 服务台  服务台对于用户的信息进行识别和记录  服务台对用户上报事件进行相关信息收集  确认用户身份，并核实相关信息  在配置信息列表中修正相关用户和设备信息  判断事件是新事件还是重复事件  若是新事件，则进入1.6;若是重复事件，进入1.5  更新原有事件记录为“主事件”，并设置原有事件与重1.3 用户信息是否正确 服务台 新事件还是重复事件？ 1.4 服务台 1.5 更新原有事件记录 服务台 复事件的关联关系  完成设置后，进入1.6  无论是用户还是监控系统上报的事件，经信息收集和核实后，应由服务台人员创建相应事件记录 1.6 记录事件 服务台  记录事件时，应对用户信息、故障描述进行填写，同时，应在配置管理数据库中查找并关联发生故障的配置项  记录完毕后进入1.7

3.5.2. 事件分类和初步支持

31

事件管理流程手册

1.1 事事事事事事事事事事事事事事事3.23.13.4事事Yes1.61.7事事事事事事事事事事事事事事事事1事事2事事1.8事事事事事/事事事/事事事1.9事事事事事事事事1.10事事事事事事?No1.11 事事事事事NO1.13事事事事事事事事事事事事事事事事事事事事事事事事事事事1.12事事事事事事事事事事Yes2.1事事事事事事事1.14事事事2.3

图 3-1 事件分类和初步支持

详细流程说明如下： 序号 1.7 步骤名称 确认事件类型 责任人 服务台 说明  服务台在创建事件后，对事件性质即事件的类型进行划分：故障/服务请求/咨询/投诉等  服务请求性质的事件对应优先级建议设置为“低”  服务台人员对事件的分类进行设置 1.8 确定事件分类和优先级  服务台人员基于事件影响程度和紧急程度设置事件的服务台 优先级  具体确认参照事件优先级判读标准  不同优先级事件对应其响应和解决时限不同 1.9 查找解决方案 是否有现成的解决方案/变通方法？ 服务台  服务台在事件或问题历史记录或知识库中查找是否有与当前事件匹配的解决方案或变通方法  是否找到现成的解决方案或变通方法。如找到，则转1.10 服务台 3.1;如未找到，则转1.11进一步尝试解决  服务台人员根据事件分类和二线人员的忙闲状态，合1.11 分派事件 服务台 理选择一名二线支持人员进行事件单的转派  分派事件前建议首先电话沟通，缩短二线人员对事件单的响应时间，提高事件的分派成功率  二线支持人员在了解事件情况后，可依据自身能力和1.12 是否接受事件单 二线支持 资源情况对是否接受事件单进行选择。如接受，则进入3.1;如不接受，则进入1.13 1.13 写明原因 二线支持  二线支持人员如不接受事件单，应在事件单上注明原 32

事件管理流程手册

序号 步骤名称 责任人 说明 因，并提供下次分派的建议，供服务台人员参考。  在接受二线支持人员拒绝派单原因后进行事件单的再1.14 重派单 服务台、事件经理 次分派  重派单超过3次的由事件经理参与进行分派

3.5.3. 事件调查和诊断

1.2 事事事事事事事4.53.2Yes事事事事事事事事事事1事事2事事3.11.122.1事事事事事事事2.2事事事事事事事事事事事?No2.3事事事事事事事?No2.4事事事事事事事事事事事Yes事事事事事事事事事事1.14事事事事

图 3-2 事件调查和诊断

详细流程说明如下： 序号 步骤名称 责任人 说明  二线支持人员接受来自1.12服务台分派的事件单  二线支持人员基于事件单信息在事件、问题历史数据记录或知识记录中进行匹配 2.1 信息收集和诊断 服务台、二线支持  二线支持人员在必要时对事件信息作进一步的收集。  二线支持人员对事件进行分析诊断，可借助配置管理数据库中的线路或设备信息进行辅助  分析诊断过程中如发生解决时间超时，系统应升级通报到事件经理处请求资源支持 2.2 找到解决方案/变通方法？ 服务台、二线支持  若找到解决方案或变通方法，则进入3.1进行实施  若为找到解决方案或变通方法，则进入2.3判断是否 33

事件管理流程手册

序号 步骤名称 责任人 重新派单？ 说明  服务台与二线人员一起判定是否需要请求重新派单 2.3 是否重新派单？ 服务台二线支持  如二线支持人员自身能力无法提供方案，且事件尚未超时，则应选择进入1.14请求重派单。否则，由该二线人员继续对事件进行标记失败提请服务台关闭。 2.4 标记失败 服务台  确认此次事件失败

3.5.4. 事件解决和恢复

1.3 事事事事事3.4事事事事事事事事事事事事事事事?YesNo事事1.11事事事事事事事事事事1事事2事事事事事1.103.1事事事事事事?2.21.102.1No3.3事事事事事事事事事事事事事事3.5事事事事事事3.6事事事事事事事事?Yes3.7事事事事事事No事事事事YesYes3.2事事事事?No4.1

图 3-3 事件解决和恢复

详细流程说明如下： 序号 步骤名称 责任人 说明  服务台人员找到解决方案或变通方法后，在事件单上应详细记录解决方案或变通方法信息  二线支持人员找到解决方案或变通方法后，在事件单3.1 是否需要审批 服务台/二线支持 上应详细记录解决方案或变通方法信息服务台或二线支持依据解决方案或变通方法判断是否需要进行变更  如需要进行表更，则进入3.2填写变更请求单（RFC），并将变更请求单转至变更管理流程进行计划和实施  如无需进行变更，则进入3.3对方案进行实施 3.2 审批通过？ 事件经理、服务台  服务台与事件经理提交RFC给变更管理  变更管理通过进入3.3，如审批未通过则进入1.10再次查找其他解决方案或进入2.1重新收集事件信息补 34

事件管理流程手册

序号 步骤名称 责任人 充变更请求记录 说明  服务台或事件经理对变更过程进行监控和跟踪  服务台或二线人员对事件的解决方案或变通方法进行3.3 沟通和实施解决方案/变通方法 服务台/二线支持 实施  如实施过程中事件超时，则应升级至事件经理处对资源进行协调和支持 3.4 方案得到客户认可 用户 服务台/二线支持 服务台/二线支持 服务台/二线支持  判断此解决方案实施结果是否能接受，能则进行3.5记录、否则进入1.11重新派单进行处理  对经客户认可的事件处理结果进行记录  根据事件优先级判断是否需要将结果告知事件经理，3.5 记录解决方案 3.6 需要通知事件经理？ 原则上优先级1、2的事件都应该告知，不需告知直接进入4.1，告知进入3.7  将事件处理结果告知事件经理 3.7 通知事件经理

3.5.5. 事件关闭

1.4 事事事事事4.4事事事事事事?事事事4.5事事事事事事?事事事事事事事事事事事事1事事2事事3.63.74.1事事事事事事事事4.2事事事事事事事事事事?2.1事4.3事事事事事事4.6事事事事事事事?4.7事事事事事事事事事事事事事事事事事事Yes事事事事

图 3-4 事件关闭

详细流程说明如下：

35

事件管理流程手册

序号 4.1 步骤名称 责任人 说明  服务台基于二线人员的反馈或历史记录，对事件的分验证分类的正确性 服务台 是否需要请用户关闭事件 类的正确性进行验证，必要时对分类进行调整  服务台来判断此事件是否需要得到用户认可方能关4.2 服务台 闭，是进入4.3，否进入4.6  服务台在确认事件解决方案和变通方法等信息填写完4.3 请求关闭事件 服务台 整后，并确认方案已得到实施后，与用户联系，确认是否可以关闭事件  与用户沟通，对事件处理结果进行判断。 4.4 接受关闭请求？ 用户  如用户认可解决结果，则进入4.6。  如用户不认可解决结果，或无反馈，则进入4.5作进一步判断  与用户沟通，对服务是否恢复进行判断 4.5 报告其它问题 用户  如服务未得到恢复存在其它问题，则进入2.1，  客户无反馈进入4.6  审核事件记录和相关解决方案，判断是否需要记录相4.6 需要更新知识库 服务台 关解决方案，，否则关闭事件  对于一些有价值的方案信息，服务台人员可将其提交至知识库  服务台人员按处理结果填写结束代码后关闭事件  对于超过反馈期限未得到用户确认的事件，系统自动4.7 关闭事件 服务台 设置结束代码为“自动关闭”  对于重大事件，或者结束代码为“变通方法解决”/“不成功”的事件，服务台人员应通知问题流程基于事件创建问题记录进行根源分析调查 36

事件管理流程手册

3.6 与其他流程的关系

图 3-5 XXX服务管理流程关系图

和知识库的关系

事件管理流程中，服务台及二线人员利用知识库帮助诊断和分析事件，并参考知识库中相关信息生成解决方案或变通方法。同时，事件管理流程中部分事件信息也可被提交给知识库成为知识记录，成为知识库的重要输入之一。 和问题管理流程的关系

事件管理流程将提供详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。尤其是重大事件、变通方法解决的事件、不成功解决的事件以及不可重现的事件，都应主动通报问题管理流程协调相关资源对其进行分析诊断等一系列后续处理，以避免事件的频繁发生。

37

事件管理流程手册

和配置管理流程的关系

事件管理流程需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来帮助定位故障和快速恢复用户业务。 和变更发布管理流程的关系

服务台应了解变更发布管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时服务台或二线支持人员可以发起变更请求来解决事件。

3.7 流程衡量指标及报表

为了控制流程的质量，提高用户体验，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。基于对XXX业务的认识和了解，事件管理流程KPI指标具体建议如下：

表 3-11 事件管理KPI列表

序号 1 衡量指标 事件总数 1. 2. 指标计算说明 数量：在事件单中根据以下条件过滤 【重复事件标记】为空 【事件发生时间】在统计周期内 2 事件关闭的数量/比率 数量 ：在事件总数中过滤【事件状态】＝‘关闭’ 比率：数量 / 事件总数 × 100 % 数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ 比率：数量 / 事件总数 × 100 % 数量：在事件总数中过滤【事件结束代码】＝‘自动关闭’ 比率：数量 / 事件总数 × 100 % 数量：在事件总数中过滤【处理是否超时】＝‘未超时’and 【事件结束代码】＝‘成功解决’or‘变通方法解决’ 比率：数量/事件总数 × 100 % 数量：在事件总数中过滤（【事件登记时间】－【事件发生时间】）< 优先级对应的响应时限 比率：数量/事件总数 × 100 % 平均响应时间：累计响应事件的时间（【事件登记时间】 - 【事件发生时间】）/ 事件总数 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解3 事件成功关闭的数量/比率 事件自动关闭的数量/比率 规定时间内解决的事件数量/比率 4 5 6 规定时间内响应的事件数量/比率 7 XXX平均响应时间 8 XXX平均解决时间 决’or ‘关闭’，同时【事件解决人角色】=‘一线’or‘二线’的事件 38