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

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

文档信息

项目名称：项目编号：

项目经理：项目时期：

文档名称：文档编号：

文档起草人：起草日期：

当前版本编号：版本日期：

相关文档：

分发名单

来自From日期//Email

给To行动*截止日期//Email

*:行动类别:批准,复审,通知,存档,修改,其它［请指明）

版本记录

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

目录

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

1.1文档简介...............................................................5

1.2文档用途...............................................................5

13文档结构...............................................................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.事件升级原那么.................................................14

3.1.9.流程关联原那么..................................................14

3.2流程相关定义..........................................................15

3.2.1.事件信息项......................................................15

3.2.2.事件来源........................................................18

3.2.3.事件性质........................................................19

3.2.4.事件分类........................................................19

3.2.5.事件优先级......................................................20

3.2.6.事件时限........................................................21

3.2.7.事件状态........................................................22

3.2.8.事件终止代码....................................................22

3.3流程角色和职责定义....................................................23

3.3.1.事件流程负责人..................................................23

3.3.2.事件流程经理....................................................24

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

3.3.4.二线支持人员....................................................26

3.3.5.三线支持人员....................................................26

3.3.6.四线支持人员...................................................26

3.4流程概要设计.........................................................27

3.5流程详细设计..........................................................29

3.5.1.事件检测与记录..................................................29

3.5.2.事件分类和初步支持..............................................30

3.5.3.事件调资和诊断..................................................32

3.5.4.事件解决和复原..................................................33

3.5.5.事件关闭........................................................34

3.6与其他流程的关系......................................................36

3.7流程衡量指标及报表....................................................37

4.附录.........................................................................38

4.1事件治理流程相关表格..................................................38

图名目

图3-1XXX事件治理流程概览.................................................28

图3-2事件检测和记录.......................................................29

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

图3-4事件调查和诊断.......................................................32

图3-5事件解决和复原.......................................................33

图3-6事件关闭.............................................................34

图3-7XXX服务治理流程关系图...............................................36

表名目

表3-1事件升级机制.........................................................14

表3-2事件信息项...........................................................15

表3-3事件来源..............................................................18

表3-4事件性质..............................................................19

表3-5事件分类..............................................................19

表3-6事件紧急程度.........................................................20

表3-7事件优先级矩阵.......................................................21

表3-8事件时限.............................................................21

表3-9事件状态.............................................................22

表3-10事件终止代码........................................................22

表3”【事件治理KPI列表....................................................37

1.文档介绍

1.1文档简介

本文档【XXX事件治理流程设计手册』，是XXX信息技术总部（以下简称XXX）团队制定

的事件治理流程文档。通过制定该流程，能够关心XXX信息技术总部团队对主动监控发觉以

及用户上报的故障和服务要求进行快速响应和快速处理，尽快复原中断或受阻碍的用户业

务。通过该流程的规范，可进•步改进XXXIT服务向用户提供的服务水平和服务质量，确保

用户对服务价值的认同和确信。

本文档是依据目前XXX的【T服务状况而制定的事件治理流程,进一步的流程更新将移交

由XXX服务团队负责。

1.2文档用途

木文档既是木次IT服务治理项目事件治理流程的交付物，也可作为XXX服务团队进一步

改进事件治理流程的蓝本，读者时象为与事件治理流程相关的所有治理与技术人员.

本文档所描述的流程在IT服务治理中有许多作用，列举如下：

□减小突发事件对业务的阻碍；

□最优化支持资源，提高工作效率：

□屏蔽错误事件和服务要求；

□依照阻碍业务轻重缓急安排资源解决事件，保证有效二T运营；

□加强有形监控和及时反馈；

□提升用户对服务的认知度和中意度；

□提供治理信息；

1.3文档结构

本文档作为XXX事件治理流程设计手册,要紧包含针对XXX服务运营中对用户故障及用

户要求处理等相关人员及活动的定义和描述。各章节中内容概要如下：

□文档介绍

要紧对文档的目的、用途及结构进行简要描述，并就文档当中显现的术语进行了说明。

□事件治理流程简介

要紧对事件治理流程的差不多概念、目的和范畴进行了介绍。同时简单梳理了事件治理

流程中包含的要紧活动内容，最后对事件治理流程对组织及用户的业务价值进行了相关阐

述。

□事件治理流程设计

该部分为本文档的重点章自。在该章节.中，第一对事件治理流程的相关执行原那么和代

码进行了描述：其次，对事件流程相关角色的职责和技能要求进行了说明：基于流程原那么

和角色定义，进而对事件治理的概要设计流程及详细设计流程进行了充分定义，并给出了事

件治理流程的关键衡量指标，以保证对流程运行的监控、治理和改进。

□附录

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

1.4术语

□服务台

在ITIL中，服务台从全然上来说提供了用户和IT部门的唯独接口。此项功能常常通

过集中的服务台进行表达。服务台的全然目的是提供一线支持，并通过变通方法、解决方案

或升级到二线支持等手段关心用户复原到正常工作状态。

□事件治理

ITIL流程，是负责解决所有的IT事件、问题和用户要求等的治理流程。它的目的是尽

快复原被中断或受到阻碍的IT服务，因此它的特点往往是以解决表征现象为目的，而不在

于查找全然缘故。

□问题治理

ITIL流程，是负责对事件进行深入分析，找出全然缘故并提供解决方案的治理流程。

它的目的是主动防备，找出全然缘故并对其根除，因此它与事件治理流程有显著的不同，以

''治本"为最终目标。

□变更治理

ITIL流程，是负责对生产环境中支持IT服务的各种基础架构设备和应用系统的变更操

作进行记录、分类、评估、打匏和和谐的流程。它的目的是在权衡''风险"和''效率"的前

提下，对变更操作进行有效的操纵，以保证任何变更对IT环境和其所支撑的IT服务的阻

碍最小。

□公布治理

ITIL流程，是负责对应用系统上线过程的全局治理和操纵。治理范畴涉及测试环境、

预公布环境和生产环境等，旨在通过对公布单元的生命周期各个时期的操纵保证其安全稳妥

的进入生产环境，而不引入新的缺陷或故障。

□配置治理

ITIL流程，配置治理负面描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的

治理流程。这些设备和系统被称为配置元素(CI)o每一个C】必须有效治理，跟踪和操纵

以支持IT服务和基础设施成功运行。

□配置治理数据库(CMDB)

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

据库。

□ITIL

ITInfrastructureLibrary,是英国政府在1987年制定的有关IT服务治理的方法论,

现已成为事实上的IT治理标准。

2.事件治理流程简介

2.1流程差不多概念

事件治理流程通过提供服务台作为日常1T支持接口，由IT支持人员依照流程定义，快

速响应和解决1T用户的服务要求、突发事件、投诉反馈等，最大化地减少突发事件对用户

业务活动的阻碍，最终确保SLA目标的实现。

事件治理流程相关的几个关键词汇说明如下：

''日常支持接口”：即服务台，该接口将采纳集中服务方式，向所有IT用户提供唯独

服务窗口，按照业务需求，提供相应级别的支持服务。

"IT用户"：指的是指XKX服务的使用者，他们使用XXX提供的IT服务来支持相关日

常业务。

"IT支持人员"：指的是XXX服务团队中IT运维和支持人员的统称，包括一线人员和

二线人员等，可能涉及XXX体系中的相关的开发、支持和运维等团队。

''一线支持"：指服务台的通用座席，向IT用户提供一线支持服务，以下提到的服务

台人员即一线支持人员。

"L5线支持"：指机房值班人员（交易系统故障时）和桌面爱护人员（桌面故障时），

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

''二线支持"：要紧由各职能小组运维工程师组成，协助服务台一线人员参与事件处

理，相对一线支持人员，二线支持具有更高更专业的技能。

''三线支持"：指各职能小组组长，在复杂度较高事件或二线支持无法解决事件时负责

和谐小组内部人员进行事件处理，三线支持更多的强调治理和谐职能。

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

''事件"：指XXX在用户IT环境中发觉的所有非正常事件，对现有的服务造成阻碍或

中断。例如：服务器宕机、网络中断、应用不可用等。从来源上来分，要紧包括由信息技术

总部内部人员发起的事件以及有用户报告的事件等。

''服务要求"：指用户提出的关于标准服务、培训、文档、信息等方面的要求，以及

针对IT服务使用的咨询等，通常并没有发生IT组件方面的故障。例如：要求培训、寻求咨

询等。服务要求是一种专门类型的事件。

''投诉反馈"：指由用户提出的关于IT服务质量或服务方式的埋怨或改进建议，通过

服务台统一同意，并进行相应处理。

2.2流程目的

事件治理流程的要紧功能是尽快解决显现的事件，保持业务支掾系统的稳固性，其目的

包括：

□在成木承诺的范畴内尽快复原TT服务

-快速响应故障及服务要求

-用户在线获得关心

-沟通事件解决的状态

-和用户确认事件的解决

□进行事件操纵

-按规范记录事件

-就事件的优先级，阻碍度进行分类

-分析，诊断，必要时进行升级

-监视并终止事件

-进行定期服务流程回忆

□提供IT治理信息

-人力资源利用情形

-故障处理情形

-支持效率

2.3流程范畴

XXX事件流程治理范畴包括所有用户与XXX信息技术总部内部的事件、服务要求和投诉

反馈等。

其中：

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

□不包括用户关于信息类设备和应用系统的新需求

□不包括新系统开发需求

2.4流程要紧内容

事件治理流程始于事件的接收和报告，终止于事件的解决。该流程包含下述要紧内容：

□事件接收和记录

那个环节是事件治理流程的起点。所有监控系统或用户报告的IT事件必须由此步骤开

始。此步骤的目的是在事件发生时快速准确地发觉，以协助事件的诊断和解决并通知相关人

员。在此步骤中将会收集创建事件记录所需的信息。该环节的关健是信息的准确性和完整性。

□分类和初步支持

关于每个事件，需要确立优先级和分类。假设没自现成的解决方案(Solution)或变通

方法(Workaround),该事件将分配给合适的支持人员对此进行调查。

□调查和诊断

假设支持人员无法利用现成方案解决事件，可运用自身技能、知识库、诊断工具等进行

更加深入的分析以找到复原服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

□解决和复原

支持人员实施事件的解决方案,并将解决完毕的事件转向朋务台.由服务台通知用户解

决的结果，并得到用户的确认。

□事件升级

关于高优先级的事件，服务台应赶忙上报给事件经理和相关的治理层，由事件经理决定

事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期解决时限，应通知相关处理人员和治理层，以引起处理人员和治理

人员的重视和参与。

□终止事件

当用户确认事件解决后，可终止该事件。

2.5流程业务价值

XXX事件治理流程将在多个方面对''XXX服务"业务产生积极作用，具体表现在以下

儿个方面：

单一联系点-通过在团队内部建立服务台，作为与用户沟通联系的单•联系点。对用户方

发生的故障及用户上报的服务要求进行快速响应和统•治理,对内部服务支持资源进行合理

利谐和调配。同时，服务台作为IT服务窗口，也进一步爱护和加强了与用户的关系，为提

高用户体验和中意度起到了重要作用。

用户业务尽快复原-通过合埋调配资源，使用知识库等相关支持，具，对不同级别事件选

择各自的解决时限，对用户被中断或受阻碍的业务进行快速响应和复原。

内部团队协作加强-为服务支持团队成员分配角色，并清晰界定职责。通过事件治理流程

将团队成员进行有效的连接，加强内部团队协作利沟通的有效性利工作效率。

服务质量操纵和改进-通过定期提交流程相关指标和报表至治理层，以实现对流程的监控

和治理，同时为服务质量的改进奠定基础。

3.事件治理流程设计

3.1流程执行原那么

3.1.1.流程常规原那么

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

详细，包括事件处理交互过程，详细的解决方案和相关的附件等。

□事件处理过程中，在需要寻求第三方的情形下，遵循下述原那么：

-依照事件实际处理情形，各二线或三线支持查找相应供应商

-在供应商参与解决事件的过程中，事件当前处理责任仍保留在二线或三线人员处

□XXX服务支持体系是由信息技术总部全体人员共同组成的，事件的处理过程中必须

加强一线和二线的沟通，沟通的方式优先使用工具（服务治理平台），在需要的时

候必须辅助、短信、邮件等手段。

□所有支持人员优先处理优先级较高的事件。

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

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

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

服务台。

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

用变通方法解决的事件，应提交问题治理流程进行问题定义分析和解决，并定期对

这些事件进行评估跟踪。

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

进和优化事件治理流程。

3.1.2.责任制原那么

谎任制原那么用来确保银个事件在任何时段都有适当的人员负声.

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

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

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

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

单的关闭

□服务台职员换班时，由服务台值班经理进行事件重新分派，事件责任人也由此转移

□事件被服务台人员转至二线人员或第三方后，二线人员/第三方成为该事件的当前

责任人，但服务台人员仍旧是事件的整体负责人，有义务对事件处理状态按相应策

略进行监控，并及时反馈给用户，保证事件的处理过程对用户充分透亮。

3.1.3.事件分派原那么

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

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

一线支持人员进行处理

□服务台一线支持人员在规定的一线处理时限内不能解决事件时，原那么上依照事件

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

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

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

□桌面类故障导致事件直截了当由1.5线桌面运维小组进行处理

□开市期间交易系统故障，直截了当由1.5线机房座席接听处理。

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

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

3.1.4.事件重分派原那么

□一线支持同意服务台分派事件后，假如该事件不属于本人支持范畴或者自身能力无

法处理，二线人员需第•注明缘故，然后将事件返回到服务台，由服务台重新分配。

□为提高事件解决效率.应当尽量减少事件单重分派的几率。事件单的重分派次数不

应该超过2次。

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

□任何跨组的事件单再分派将会报告给事件经理；

□事件再分派超过2次，事件单将升级给事件经理：

3.1.5.重复/复发事件原那么

重复事件

假如被报告的事件与某个差不多创建且尚未解决的事件单症状相同，那么该事件被认为是重

复的。

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

件将被标注为‘'主事件"

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

假如报告的事件与差不多关闭的事件相同，该事件被认为是''复发"的事件单。这意味着为

了解决事件而采取的解决措施失败了（或失败或误再报）。现在，应当创建•个新的事件单,

复制原始事件单的内容，并说明这是复发的事件。

3.1.6.事件关闭原那么

□事件单的关闭必须由服务台对应1.5/1线支持人员完成，然而事件经理能够超越此

规那么。其他人无权关闭事件单。二线支持人员确定解决方案并解决事件后，必须

把事件返回到服务台。

□事件单的用户能够要求关闭此事件单，例如：误报、错报事件。关闭事件单由事件

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

□服务台人员关闭事件前，需获得客户对解决方案的确认和反馈。

□关闭事件时，依照实际解决情形填写事件的终止代码。

□已关闭的事件单不承着重开。假如事件重复发生，那么创建一个新的事件单，并标

识为复发事件。

□关于以''变通方法解决"或''不能重现"终止代码关闭的事件，需通知问题经理

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

供解决方案。

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

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

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

应至少每天主动与用户联系1次。假设3日后仍未得到用户有效反馈，系统将自动

关闭事件，并标识终止代码为''自动关闭"字样。

3.1.7.事件通报原那么

关于监控系统自动发觉的告警信息，服务台人员有责任对其进行识别。如确认为一条事

件，那么应第•在第•时刻通报相应用户和事件经理，然后在服务治理平台中进行记录。通

报策略具体如下：

通报方式

□用户工作时刻内采纳正式的通知方式进行通报

□用户非工作时刻采纳邮件方式进行通报

□与用户通报相关的其他方式参考与用户签订的SLA中的具体定义

□采纳邮件的方式通知事件经理：

□假如由于用户缘故第一时刻无法完成通报，应第一在服务治理平台中登记一条事

件，并置于''挂起"状态，相关服务台人员有责任在开单后每隔5分钟主动尝试联

系用户3次。假设3次后仍无法取得联系，那么应在事件工作日志中注明''无法联

系到用户"的字样，并进行后续处理；假设3次内取得联系，那么在与用户确认故

障后，取消事件''挂起"状态并进行后续处理。

通报对象

□依照事件分类表中定义，向用户部门相关人员通报

□最后通报事件经理

通报内容

□事件简要描述

□可能受到阻碍的用户方业务（或范畴）

□确认是否为用户方运维操作导致

□可能导致事件的缘故

□估量解决事件的时刻点

3.1.8.事件升级原那么

制定升级原那么的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和

治理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。

□优先级为最高的事件.需要赶忙事件升级，同时，事件连续按事件治理流程进行快

速处理

□超出规定的响应或者解决时限之后，需要赶忙升级事件，同时，事件连续按流程进

行快速处理

□事件重复派单超过三次直截了当升级给事件经理

具体事件升级机制如卜表所示：

表3-1事件升级机制

事件升级机制小组技术经理事件经理运维经理技术总部领导公司领导

优先级15分钟5分钟10分钟10分钟15分钟

优先级21小时1小时1小时1.5小时

优先级32小时2小时

优先级44小时4小时

3.1.9.流程关联原那么

□和问题治理的关联

一线支持在解决事件的过程中，能够通过问题记录查找相应的解决方案

-通过分析事件记录，形成问题，并使该问题与相关用件建立关联

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

持沟通

对高优先级事件或者”变通方法解决"或''无法重现"关闭的事件，由问题治理

流程生成问题进行进一步分析，直到确定全然缘故，得到全然解决。事件单和问

题应建立美联。

□和变更公布治理的关联

-事件处理过程中，假如需要对相关IT组件进行变更（不在标准变更清单内的变

更），必须按照变更治理的定义，提交变更要求（变更单必须和事件单建立关联），

变更完成后，连续事件的处理。

-高优先级事件的处理过程中，假如需要对相关IT组件进行变更，必须按照变更

治理的定义，提出紧急变更要求，变更完成后，补录紧急变更单，并和事件单建

立关联。

□和配置治理的关联

-事件处理过程中，能够通过配置治理查询相关的配置项信息［专门是关系信息）

以及该配置项历史上发生的事件、问题或变更，来关心故障的定位

-事件处理过程中，假如能够将故障定位到某个配置项，那么必须将事件单与该配

置项关联

3.2流程相关定义

3.2.1.事件信息项

事件单必须包含如下事件苗息项，XXX服务团队能够在此基础上进行扩充:

表3-2事件信息项

序号信息项说明

1事件ID事件单流水号（系统自动产生）

事件申报人的信息,包括：姓名、公司、部门、电子邮件、办公、

2事件要求人

手机

3事件登记时刻在服务台生成事件记录的时刻（有统自动产生）

事件开单人的信息，包括职员姓名、职员1D、联系方式等（系统

\事件登记人

自动产生）

针对故障：指的是业务中断的实际时刻（可能早于登记时刻，自

5事件发生时刻动设置或者手工填写）：针对用户要求：缺省值等于登记时刻。

事件发生时刻必须早于或等于登记时刻。

6事件发生地点事件发生的位置信息

7事件来源参见“事件来源"定义

8事件标题事件的他要描述

9事件描述关于整个事件内容的详细描述

10事件性质参见“事件性质"定义

11事件分类参见"事件分类"定义

12事件状态参见“事件状态"定义

13事件阻碍范畴参见”事件阻碍范畴"定义

14再件紧急程度参见”事件紧急程度"定义

15事件优先级参见”事件优先级”定义

对应每一个事件优先级，系统依照流程相关定义中”事件解决时

16事件完成期限

限”自动设定最终的完成期限（系统自动产生）

17事件分配工作组被分配的支持小组

序号信息项说明

18事件分配人员被分配的支持小组内成员

19事件工作日志反映事件处理过程的信息

解决方案/变通方

20事件解决方案/变通方法的描述

法

21事件解决人事件的最终解决人

22事件解决人角色参见”事件解决人角色”定义

23事:件解决时刻记录事件状态为"已解决"的时刻（系统自动产生）

24处理是否超时参见”处理是否超时"定义（系统自动产生）

25涉及第三方支持XXX和第三方集成商名称

26关联配置项记录显现故隙的线路编号或者CPE设备编号

27关联的问题单号记录由事件引发问题时，关联的M题单号

28关联的变更单号记录由事件引发变更时，关联的变更单号

29事件终止代码参见”事件终止代码"定义

30事件关闭时刻记录事件状态为"终止"的时刻［系统自动产生）

31重豆事件标记标记为重豆事件

事件如来自于监控系统告警，那么填写对应告警的ID：假设为用

32对应告警ID

户自动上报，此处为空不填

用户对事件处理的中意程度。分值从5分至1分，分别对应专门

33用户中意度

中意、比较中意、一样，不太中意及专门不中意

34用户反馈信息用户对事件处理过程及结果的意见或建议

35附件信息事件相关附件信息

IT运维事件单

〔含事件、信息咨询、服务要求〕

事件单编号：（例如：200708220001）

受理事件差不多信息

■受理时刻2007年月日时分■受理人

用户所属部门

申报人

申报人申报人EMAIL

申报方式□□邮件□工作台口现场口其他

受理人依照事件形成事件信息

服务分类口故障□问题□改进□咨询口业务需求□投拆口其他

序号信息项说明

桌面终端类：DPC机故障口局域网故障

□软件故障口外设故障

基础设施类：口硬件故障口操作系统

/DB/系统软件故障口网络故障口机房

事件分类

环境故障（空调、UPS等）

应用系统类：口可用性口响应速度口

汾能性□易用性（应用系统列表选

择）阻碍度：

报障人员分类□VIP1DVIP2□一般阻碍度；

受阻碍人员分类口单内部客户口单部门

口2个部门以上阻碍度：

人员分类

□单外部客户口单营业部

□2-4个营业部口4个

营业部以上阻碍度：

□关键设备（列表选择）□非关键设备

关键设备阻碍度：

口未知

典型事件分类口典型事件（列表选择）□无对应典型事件

事件描述

事件阻碍度

口1-危险（5分钟）口2-紧急（高,20分钟）口3-紧急（中，2小时）口4-

事件紧急度

紧急（低,4小时）口5-一般（4小时以上）

事件处理优先级

事件完成打算时刻

受派人员

处理人员记录

响应时刻一月—F1一时____分处理人员

服务方式□DEmail□现场□远程终端口送修口其它

缘故及故障分析：

解决方法：

是否需要发起技术问题处□是口否（去除？）

理完成时刻—日—时—分

用户反馈

（用户填写）

处理结果□全部解决□部分解决口未解决

中意度评判□专门中意□较中意□中意□不中意

用户意见（可选）

序号信息项说明

事件优先级升级记录

□自动终止□客户确认终止口转为其它口事件经

事件终止方式理终止

事件对应其它流程编号（转为口转为同工具其它流程（对应编号）□转为NOTES

其它时填写）其它流程（流程名称（列表）+对应编号）

最终事件分类（服务台填报）

□故障类型

口问题类型

口咨询类型

□需求类型

口投拆

□其他

知识库评判口有对应完善知识库口知识库需完善口无对应知识库

3.2.2.事件来源

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

表3-3事件来源

事例来源描述

电子邮件服务台通过电子邮件收到一个要求。

服务台通过收到一个要求。

服务台工具服务台通过Web系统（流程治理平台）收到一个要求。

（HelpDesk）

来访用户直截了当到电脑部工作间找相关工程师报障

主动监控服务台通过系统网络治理工具主动监控得到的要求。

3.2.3.事件性质

事件性质用来说明事件的概要类型，具体能够包含以下几种:

表3-4事件性质

要求类型描述

事件显现对服务造成阻碍的不正常现象

信息咨询对与业务或IT相关杂项信息（联系人、号码，状态查询等）的要求

服务要求对外宣布的服务（不含新业务需求）

3.2.4.事件分类

事件分类代码用于标识故障或申告的具体缘故，由支持人员在处理过程中填写。当事件

发生时，应该由服务台初步分析和定位事件的分类，一方面便于与历史事件/问题或者知识

库的匹配，另一方面也便于选择合适的二线或者第三方进行分配。事件最终分类可由后续支

持人员作进一步的确认，并在事件关闭前进行调整。

事件的分类层次设计不超过三层，第一级分类，称之为''类别"，第二级分类，称之为

''子类"，第三级分类，称之为‘'条目"。

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

表3-5事件分类

使

系统二线三线四线

流模块/模块/子用备

/类典型事件责任责任责任

程子类类说明部注

别人人人

门

处理

该事

各应应用使用

件的

用系系统该校填写差不多原那么：客

模块业务工程

统名的模块的户化语言描诉

功能说明师或

称块名业务

职能

称部门

小组

3.2.5.事件优先级

优先级是事件治理的一个关键要素，优先级决定处理事件的顺序及所需的资源。在XXX

服务中,事件优先级可分为四级：P1（最高）、P2（高）、P3（中）、P4（低）。为方便服务支

持关于事件优先级的判定，XXX建议从事件阻碍程度和事件紧急程度两维来进行优先级定

位。

事件的阻碍程度要紧是对事件发生的关键程度以及事件发生后的阻碍范晡综合考虑得

出。在XXX业务中，要考虑以下几个方面：

□用户身份

□受阻碍用户数量和范畴

□受阻碍设备

□受阻碍系统

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

事件的紧急程度要紧由事件本身是否涉及关键业务系统来进行判定，如事件涉及关键业

务系统，那么认为紧急程度较高，需要尽快复原；如事件不涉及关键业务系统，那么认为紧

急程度较低，可优先处理紧急程度较高的事件。在XXX业务中，事件紧急程度定义具体如下：

表3-6事件紧急程度

紧急度紧急度时刻标准备注

1-危险30分钟

2-紧急（高）2小时

3-紧急（中）4小时

4-紧急（低）8小时

5一般8小时以上

结合事件发生时的阻碍程度和紧急程度，能够通过下表确定事件的优先级:

表3-7事件优先级矩阵

阻碍度

事件优先级

高中低

1•危险123

2-紧急（高）233

紧急度3-紧急（中）344

4-紧急（低）344

5-一般444

注：关于用户上报的服务要求，一样建议按优先级为P4（低）进行处理。

3.2.6.事件时限

在事件处理过程中，关于事件应有响应时刻限制、分派时刻限制和解决时刻限制，以保

证事件处理过程的高效执行。假如该事件的响应、一线分派、解决超过了时限，需要通告事

件经理.，同时也要依照具体情形通告给其他相关治理人员。

响应时限指的是事件发生到在系统中登记所通过的时刻；

一线分派时限指事件登记时刻到转给二线/第三方所通过的时刻：

解决时限指的是事件登记时刻到事件状态变为''己解决"所通过的时刻。

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

具体如下：

表3-8事件时限

事件目标时刻一线响应时刻事件被分派并得到同意事件得到解决的时刻备注

优先级13分钟5分钟30分钟

优先银25分钟10分钟