20150708   淡然

目录

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

1.1             编写目的................................................................................................................. 5

1.2             适用范围................................................................................................................. 5

2.      术语、定义和缩略语.............................................................................................................. 6

3.      内容...................................................................................................................................... 7

3.1             流程介绍................................................................................................................. 7

3.1.1         流程解释.......................................................................................................... 7

3.1.2         业务价值.......................................................................................................... 7

3.1.3         流程机制.......................................................................................................... 7

3.1.4         事件单代码设计.............................................................................................. 14

3.1.5         角色介绍......................................................................................................... 21

3.1.6         事件流程负责人.............................................................................................. 22

3.1.7         事件经理......................................................................................................... 23

3.1.8         事件记录员..................................................................................................... 24

3.1.9         事件受理员（2/3/n线）................................................................................... 25

3.2             流程输入及输出..................................................................................................... 26

3.2.1         流程触发条件.................................................................................................. 26

3.2.2         输入................................................................................................................ 27

3.2.3         输出................................................................................................................ 27

3.2.4         流程关闭条件.................................................................................................. 27

3.3             流程描述................................................................................................................ 27

3.3.1         流程综述......................................................................................................... 27

3.3.2         作业流程图..................................................................................................... 29

3.3.3         流程活动说明.................................................................................................. 31

3.4             流程衡量指标及报表.............................................................................................. 34

4.      参考..................................................................................................................................... 36

4.1             相关流程................................................................................................................ 36

4.2             相关表单................................................................................................................ 36

4.3             事件分类表............................................................................................................ 37

1.   文档介绍
1.1   编写目的

本文档编写的目的是有效地解决运营总部通号中心IT运维服务部（以下简称“IT运维服务部”）在IT环境下的突发事件，提高IT系统运行的稳定性和服务的质量，为业务的快速发展提供更优质的IT服务，并且可以有效地帮助实施其他相关服务管理流程，如问题管理、变更管理等流程。                        ITSS培训

通过本文档的定义，将建立一个完整的事件管理系统，从而实现：

l  快速恢复服务

l  确保每个事件和服务请求都得到完满的处理

l  减小突发事件对业务的影响

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

l  根据业务轻重缓急解决事件，保障有效IT运营

l  加强有效监控和及时反馈

l  提升用户满意度

l  提供管理信息

1.2   适用范围

本流程适用于IT运维服务部的IT运维团队。本文档所规定的IT服务是指IT运维服务部的IT运维团队所提供的运维服务。

管理范围指的是IT运维服务部的IT运维团队的所辖范围内的运维，受理范围为辖内的客服上报的事件请求与主动监控事件。具体说明如下：

l  IT人员监测或检查到事件（如：值班人员主动监控发现的故障）

l  客服报告的事件（如：用户上报给客服的事件，再由客服转为IT运维团队的事件）

2.   术语、定义和缩略语

[td]

术语	缩略词	定义
事件	Incident	任何不符合标准操作且引起或可能引起服务中断和服务质量下降的事件。
事件管理	IM (Incident Management)	事件管理流程的目的是尽快解决事件与恢复服务。事件记录的信息决定了其它许多流程的效率。
重大事件		影响等级为一级的事件为重大事件。
影响等级		表明事件对服务所产生的业务影响，它是事件的处理优先级的一个重要影响因素。
临时措施	Workarounds	临时措施是解决事件的临时修复方法或技术，目的是使用替代措施暂时消除客户对服务的依赖和减少事件对客户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。通过临时措施，客户能够在没有中断的情况下继续使用服务。临时措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。

3.   内容
3.1   流程介绍
3.1.1 流程解释

事件管理流程设立的主要功能是尽快解决IT环境下的生产/运行中出现的事件，确保IT环境的稳定性。通过对事件进行登记、分类、分级、状态跟踪、关闭确认等手段建立一个事件管理流程的闭环，从而对事件的处理过程进行监控和优化，在成本允许的范围内尽快恢复服务，提高客户满意度。

事件管理流程还提供一个日常接口，提供关于服务状态的信息更新，定期对事件信息进行统计和分析，了解事件的分布和发展趋势，努力降低事件响应时间和解决时间，提供优质无间断的IT服务。

3.1.2 业务价值

l  用户业务尽快恢复

l  内部团队协作加强

l  服务质量控制和改进

l  减少与避免故障对业务所造成的影响

l  提高响应、团队、沟通和资源管理效率

l  加强对供应商的管理

l  集中精力管理关键业务信息

3.1.3 流程机制

l  在IT运维服务部的实际生产与运行环境中，所有发生的事件都会通过事件管理流程来进行处理，将通过流程中定义的标准、原则和机制进行管理。

l  所有报告事件的部门/用户将会参与统一的事件管理管理流程，不应该有任何例外。

l  所有支持人员对优先级1和2的事件所采取的恢复服务的行动，相比其他任务具有优先权。

l  应该定期（每月）产生和回顾事件管理报表。对没有解决的问题，应该举行定期的问题管理会议，对这些问题进行评估。

l  应该定期（每半年）对流程进行回顾，以改进事件管理流程。

3.1.3.1          责任人机制

对事件进行有效管理的一个重要因素是定义责任人机制，以确保每个事件在任何时段都有适当的人员负责。

l  当一个事件被创建后，事件记录员负责记录与跟踪此事件单。

l  事件单被分派/转派后，事件受理员 (2/3线)负责接收此事件单，但是分派方（做出分派的事件记录员或是做出转派的事件受理员）有责任通知被分派的事件受理员并要求他接受或是拒绝此事件单。

l  事件单被分派/转派后，事件受理员（2/3线）接收此事件单后，即成为此事件单的当前责任人，但事件记录员仍是此事件的整体负责人，有义务对事件的处理状态进行跟踪和推动，并及时向用户反馈事件处理进展。

l  采用首问负责制，由事件的首要受理人或者创建人负责客户可能的查询。

3.1.3.2          分派机制

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

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

l  服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分类分派到相应二线支持人员。

l  支持人员如判断事件需要第三方支持，原则上不在系统中进行事件单的分派，事件单仍保持在相应的一线或二线支持人员处。第三方处理完毕后，由相应一线或二线支持人员负责更新事件单状态、解决方案等相关信息。

3.1.3.3          再分派机制

再分派又称转派，指第一次分派后被分派对象，将事件单分派给其他部门或个人。

再分派机制是另一项关键的原则，它确保事件单不被过于频繁的相互转派，以至于无法在规定时间内得到解决。

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

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

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

3.1.3.4          优先级划分

事件的优先级表明了该事件或问题对运维对象（游戏产品）的业务影响。它是评定事件处理优先等级的一个重要指标。所有事件都将分配到三个优先级中的一个。优先级从 1 (优先级最高) 到 3 (优先级最低) 。优先级的划分一般情况下，是由事件的“影响度”和“紧急度”共同决定。

影响度是指受影响业务系统的关键程度，通常根据受影响的客户数量，可能造成的业务损失程度，或是业务系统的重要程度来决定。紧急度是指解决事件所需要的速度。需要指出的是：一个高影响度的事件并不一定非常紧急，反之亦然。

除此之外，还可以参考下列因素中的一个或几个可以用来定义优先级：

l   服务中断的时间和范围

l   受影响的服务

l   发生的次数

l   问题没有解决的时间的长短

优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。根据IT运维服务部的业务实际情况，综合考虑影响度、紧急度等多方面因素，得出事件的优先级定义如下表所示：

说明：优先级为1的事件为重大事件。 优先级1、2、3分别对应重度、中度与轻度的故障等级定义；

[td]

优先级	定 义
1	会使在线业务系统立即停止服务的故障，或影响在线业务系统的服务，但不会使服务直接停止的故障
2	会使后台支持系统立即停止服务的故障
3	会影响后台支持系统的服务，但不会使服务直接停止的故障

3.1.3.5          目标解决时间机制

为了更好的控制事件的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。事件管理的目标时间如下表所示：

[td]

事件目标时间	一线响应时间 [创建-分派]（含初步支持）	事件被分派并得到接受 [分派-分派被接收]	事件得到解决时间 [接受分派-解决]
优先级1	5--10分钟	10--15分钟	30分钟
优先级2	10--15分钟	30分钟	1小时
优先级3	15分钟	30分钟	2小时

所有超出目标时间的事件单将体现在每周、每月的统计报表中。同时，事件经理将得到通知。

详细的事件目标解决时间可参考附件《4.3事件分类表》

3.1.3.6          升级机制

升级机制的目的是，对于不同优先级的事件，确保分配到合适的资源来解决。为了达到这个目的，定义了升级机制的时间框架。当达到下列时间时，如果事件还未解决，将触发升级机制。

从事件单被创建之后所经过的时间作为触发事件升级的标准。

事件升级机制	项目经理 /开发项目负责人	维护工程师 /开发工程师	维护经理
优先级1	10分钟	15分钟	30分钟
优先级2	5分钟	10分钟	30分钟
优先级3	10分钟	15分钟	1小时

3.1.3.7          通知机制

通知机制的目的是将影响到服务可用性的事件的有关信息及时通知给关键的IT人员和用户。通知将告知相关的IT员工和IT管理者，通知相关信息如下：

通知方式：

•      事件发生时，告知事件导致了服务的中断（描述受影响的服务以及预计恢复时间）

•      受影响服务恢复时，告知服务已恢复，回到可用状态

•      优先级1的将通过电话+email方式通知；

•      优先级2和3的将通过email方式通知                                                           ITSS认证

标准通知内容：

•      事件的简要描述

•      受到影响的服务

•      预计恢复服务的时间（尽可能准确）

•      联系服务台咨询以获取更多信息的方法

具体的事件通知机制如下：

事件通知机制	项目经理	维护经理	产品经理	副总监
优先级1	5-10分钟	15-20分钟	20-30分钟	30-60分钟
优先级2	10分钟	15分钟	30分钟	60分钟
优先级3	15分钟	30分钟	60分钟	90分钟

具体的事件通知矩阵如下：

状态	用户	事件记录员	事件受理员 （二线）	事件受理员 （三/N线）	事件经理	事件负责人
待处理	√	√
已分派			√	√
受理中		√		* （职能升级）	*（结构升级）
挂起		√
已解决	√	√
关闭	√

注：“*”表示选择性通知

3.1.3.8          重复机制

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控系统上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同时，则该事件被认为是重复的。

由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，应创建新的事件单，复制原有事件单内容，并标识为“重复”的事件，原始事件将被标注为“主事件”。在原有事件单得到解决时，所有的重复事件单也同时获得解决。

3.1.3.9          复发机制

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

3.1.3.10     事件关闭机制

事件被解决后，需要对此事件进行关闭操作。事件单的关闭应当符合以下原则：

l  事件单的关闭必须由一线支持（值班组工程师）负责完成，但是事件经理可以超越此规则（即事件经理可以干预事件处理并关闭事件单）。其他人无权关闭事件单。

l  事件关闭后，需由值班组组长负责对此事件的记录内容进行核实。

l  事件单的用户可以要求关闭此事件单，例如：误报、错报事件。但具体关闭动作应由对应的一线支持人员负责。

3.1.3.11     流程关联机制

file:///C:/Documents%20and%20Settings/ac05/%E6%A1%8C%E9%9D%A2/ISO20000/%E4%BA%8B%E4%BB%B6%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E6%89%8B%E5%86%8C123_files/image005.gif

和问题管理的关联

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

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

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

•      对重大事件或者“成功但有问题”关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。

和变更发布管理的关联

•      事件处理过程中，如果需要变更，必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。

和配置管理的关联

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

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

和服务级别管理的关联

•      事件处理过程中，依照用户签订的SLA及相应服务级别对事件进行诊断和恢复。

•      事件记录为服务级别管理中各项服务是否违背SLA中相关定义提供数据支持。

3.1.4 事件单代码设计
3.1.4.1          事件单信息项

事件单必须包含如下信息项，可以在此基础上扩充：

[td]

序号	信息项	说明
1	事件ID	系统为此事件生成的唯一 ID。
2	状态	显示突发事件的状态。 建议以下预置状态： • 打开 — 此突发事件已经打开，但目前没有得到处理。 • 关闭 — 此突发事件已得到解决，并且得到了客户的同意。 • 已解决 — 有一个解决方案，但未经客户验证。 • 正在处理 — 正在处理此突发事件。 •  待定变更 — 已打开一个相关紧急变更，正在等待关闭该变更。 • 暂停 — 客户同意将此突发事件暂停一段时间；记录单将不会在该时段出现在待办队列中。
3	联系人	联系人不一定是服务接收人。此字段可以确保合适的人员将会得到有关交互更新的通知。
4	代理人	指定处理此突发事件的人员的姓名。此人是所分配的支持组的成员。代理人可以属于一个或多个分配组。
5	分配组	指定处理此突发事件的支持组
6	受影响的服务	该服务受此突发事件影响。此字段由交互记录中的数据填充。
7	受影响的配置项	对服务产生负面影响的配置项 (CI)。此字段由交互记录中的数据填充。
8	配置项可操作（服务不会中断）	如果已选择（设置为 true） ，则表示配置项当前正在操作中，而且服务不会中断。默认情况下，打开一个针对配置项的突发事件时，该配置项标记为出现故障。如果该配置项仍然正常工作，则应该标记此字段。
9	事件来源	参见“事件来源”定义
10	服务中断开始时间	服务中断开始的日期和时间。服务中断的开始和结束时间用于衡量“服务级别协议” (SLA) 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但打开或关闭突发事件之前可能会经历几分钟或几小时，因此，需要变更该值，以报告实际的服务中断开始和结束的时间。例如，设备可能在夜间出现了故障，而且必有人报告该问题 之后，突发事件才会打开。在此情况下，默认的打开时间不能准确反映服务中断时间。
11	服务中断结束时间	服务中断结束的日期和时间。服务中断的开始和结束时间用于衡量 SLA 的可用性。如果配置项标记为出现故障，则可用性SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但需要变更该值以报告实际的服务中断结束时间。例如，重新启动配置项之后，可以对其进行操作，但可能要花数分钟或数小时，才能更新记录，以报告突发事件已关闭。在此情况下，默认的关闭时间不能准确反映实际的服务中断时间。
12	位置	报告突发事件的位置。此字段由已升级交互中的数据预先填充。此字段仅供参考。
13	标题	概述突发事件的简短描述。此字段由已升级交互中的数据预先填充。 此为必填字段。
14	描述	突发事件的详细描述。此字段由已升级交互中的数据预先填充。 此为必填字段。
15	类别	描述突发事件类型，由已升级交互中的数据预先填充。
16	区域	此字段由已升级交互中的数据预先填充。对此区域的选择取决于类别。
17	子区域	第三级交互分类，主要用于进行报告。此字段由已升级交互中的数据预先填充。
18	影响度	此字段由已升级交互中的数据预先填充。它指明了突发事件对业务产生的影响。 影响和紧急程度用于计算优先级。
19	紧急度	此字段由已升级交互中的数据预先填充。紧急程度表示此突发事件对于组织的紧 迫程度。紧急程度和影响用于计算优先级。
20	优先级	此突发事件相对其他突发事件的排列顺序。优先级值是根据初始影响和紧急程度来计算的。只有从交互更新或升级突发事件时，此字段才显示。
21	SLA目标日期	下一个“服务级别目标”(SLO) 到期的日期和时间。此字段基于与突发事件信息相匹配的 SLO 进行填充，所用日期是违反协议之前即将到期的 SLO。
22	解决代码	指定一个预定义的解决代码，用于说明如何解决突发事件。此字段的预置选项基于客户的参考数据。 建议以下预置解决代码： • 不可重现 • 超出范围 • 请求被拒 • 通过变更/ 服务请求解决 • 通过用户说明解决 • 通过应对措施解决 • 无法解决 • 被用户撤销
23	关闭代码	此项是在服务台质控员在回访时，同用户确定的最终结果
24	解决方案	提供对突发事件解决方案的说明。

3.1.4.2         事件分级

给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。

编号	事件级别	描述	响应时间	解决时限
1	VIP服务		<10分钟	<8小时
2	重大事件	重大事件指的是严重影响到业务连续性并且涉及多个用户（用户>100）。 例如：病毒爆发、核心网络中断。	<10分钟	<24小时
3	一般故障	一般故障指的是影响到业务连续性并且造成中断的故障且故障仅涉及少数用户（用户<100）， 例如： 蓝屏、死机、病毒感染、关键业务软件无法启动等等。	<30分钟	<48小时
4	微小故障	微小故障指的是不会影响业务连续性的故障，例如键盘鼠标损坏，无法连接INTERNET等故障。	<40分钟	<72小时

3.1.4.3         事件影响度

影响度编码	影响范围	描述
1-非常重要	领导	对领导造成影响
2-严重	多数用户	对公司多数用户造成影响
3-一般	多个用户	对多个用户造成影响
4-轻微	少数用户	对单个或几个用户造成影响

3.1.4.4         事件紧急度

紧急度编码	紧急时间标准	描述
1-非常紧急	8小时	服务需8小时内提供（恢复）
2-紧急	24小时	服务需24小时内提供（恢复）
3-一般	48小时	服务需48小时内提供（恢复）
4-略微紧急	72小时	服务需72小时内提供（恢复）

3.1.4.5         事件优先级

优先级		影响度
		1-非常重要	2-严重	3-一般	4-轻微
紧急度	1-非常紧急	1-最高	2	2	3
	2-紧急	2	2-高	3	3
	3-一般	2	3	3-中	4
	4-略微紧急	3	3	4	4-低

3.1.4.6         事件来源

给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。

编号	来源	描述
1	用户报告	用户通过电话或WEB报告的事件，帮助台人员手工创建事件单
2	监控告警	监控工具发现的告警事件
3	日常运维发现	信息部日常运维检查产生事件    ITSS考试

3.1.4.7         事件性质[td]

类别	信息项	说明
突发事件	访问	授权错误
突发事件	访问	登录失败
突发事件	数据	数据或文件损坏
突发事件	数据	数据或文件不正确
突发事件	数据	数据或文件丢失
突发事件	数据	超过存储限制
突发事件	失败	错误消息
突发事件	失败	不正常工作
突发事件	失败	作业失败
突发事件

本帖关键字：ITSS

20150708   淡然

目录

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

1.1             编写目的................................................................................................................. 5

1.2             适用范围................................................................................................................. 5

2.      术语、定义和缩略语.............................................................................................................. 6

3.      内容...................................................................................................................................... 7

3.1             流程介绍................................................................................................................. 7

3.1.1         流程解释.......................................................................................................... 7

3.1.2         业务价值.......................................................................................................... 7

3.1.3         流程机制.......................................................................................................... 7

3.1.4         事件单代码设计.............................................................................................. 14

3.1.5         角色介绍......................................................................................................... 21

3.1.6         事件流程负责人.............................................................................................. 22

3.1.7         事件经理......................................................................................................... 23

3.1.8         事件记录员..................................................................................................... 24

3.1.9         事件受理员（2/3/n线）................................................................................... 25

3.2             流程输入及输出..................................................................................................... 26

3.2.1         流程触发条件.................................................................................................. 26

3.2.2         输入................................................................................................................ 27

3.2.3         输出................................................................................................................ 27

3.2.4         流程关闭条件.................................................................................................. 27

3.3             流程描述................................................................................................................ 27

3.3.1         流程综述......................................................................................................... 27

3.3.2         作业流程图..................................................................................................... 29

3.3.3         流程活动说明.................................................................................................. 31

3.4             流程衡量指标及报表.............................................................................................. 34

4.      参考..................................................................................................................................... 36

4.1             相关流程................................................................................................................ 36

4.2             相关表单................................................................................................................ 36

4.3             事件分类表............................................................................................................ 37

1.   文档介绍
1.1   编写目的

本文档编写的目的是有效地解决运营总部通号中心IT运维服务部（以下简称“IT运维服务部”）在IT环境下的突发事件，提高IT系统运行的稳定性和服务的质量，为业务的快速发展提供更优质的IT服务，并且可以有效地帮助实施其他相关服务管理流程，如问题管理、变更管理等流程。                        ITSS培训

通过本文档的定义，将建立一个完整的事件管理系统，从而实现：

l  快速恢复服务

l  确保每个事件和服务请求都得到完满的处理

l  减小突发事件对业务的影响

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

l  根据业务轻重缓急解决事件，保障有效IT运营

l  加强有效监控和及时反馈

l  提升用户满意度

l  提供管理信息

1.2   适用范围

本流程适用于IT运维服务部的IT运维团队。本文档所规定的IT服务是指IT运维服务部的IT运维团队所提供的运维服务。

管理范围指的是IT运维服务部的IT运维团队的所辖范围内的运维，受理范围为辖内的客服上报的事件请求与主动监控事件。具体说明如下：

l  IT人员监测或检查到事件（如：值班人员主动监控发现的故障）

l  客服报告的事件（如：用户上报给客服的事件，再由客服转为IT运维团队的事件）

2.   术语、定义和缩略语

[td]

术语	缩略词	定义
事件	Incident	任何不符合标准操作且引起或可能引起服务中断和服务质量下降的事件。
事件管理	IM (Incident Management)	事件管理流程的目的是尽快解决事件与恢复服务。事件记录的信息决定了其它许多流程的效率。
重大事件		影响等级为一级的事件为重大事件。
影响等级		表明事件对服务所产生的业务影响，它是事件的处理优先级的一个重要影响因素。
临时措施	Workarounds	临时措施是解决事件的临时修复方法或技术，目的是使用替代措施暂时消除客户对服务的依赖和减少事件对客户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。通过临时措施，客户能够在没有中断的情况下继续使用服务。临时措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。

3.   内容
3.1   流程介绍
3.1.1 流程解释

事件管理流程设立的主要功能是尽快解决IT环境下的生产/运行中出现的事件，确保IT环境的稳定性。通过对事件进行登记、分类、分级、状态跟踪、关闭确认等手段建立一个事件管理流程的闭环，从而对事件的处理过程进行监控和优化，在成本允许的范围内尽快恢复服务，提高客户满意度。

事件管理流程还提供一个日常接口，提供关于服务状态的信息更新，定期对事件信息进行统计和分析，了解事件的分布和发展趋势，努力降低事件响应时间和解决时间，提供优质无间断的IT服务。

3.1.2 业务价值

l  用户业务尽快恢复

l  内部团队协作加强

l  服务质量控制和改进

l  减少与避免故障对业务所造成的影响

l  提高响应、团队、沟通和资源管理效率

l  加强对供应商的管理

l  集中精力管理关键业务信息

3.1.3 流程机制

l  在IT运维服务部的实际生产与运行环境中，所有发生的事件都会通过事件管理流程来进行处理，将通过流程中定义的标准、原则和机制进行管理。

l  所有报告事件的部门/用户将会参与统一的事件管理管理流程，不应该有任何例外。

l  所有支持人员对优先级1和2的事件所采取的恢复服务的行动，相比其他任务具有优先权。

l  应该定期（每月）产生和回顾事件管理报表。对没有解决的问题，应该举行定期的问题管理会议，对这些问题进行评估。

l  应该定期（每半年）对流程进行回顾，以改进事件管理流程。

3.1.3.1          责任人机制

对事件进行有效管理的一个重要因素是定义责任人机制，以确保每个事件在任何时段都有适当的人员负责。

l  当一个事件被创建后，事件记录员负责记录与跟踪此事件单。

l  事件单被分派/转派后，事件受理员 (2/3线)负责接收此事件单，但是分派方（做出分派的事件记录员或是做出转派的事件受理员）有责任通知被分派的事件受理员并要求他接受或是拒绝此事件单。

l  事件单被分派/转派后，事件受理员（2/3线）接收此事件单后，即成为此事件单的当前责任人，但事件记录员仍是此事件的整体负责人，有义务对事件的处理状态进行跟踪和推动，并及时向用户反馈事件处理进展。

l  采用首问负责制，由事件的首要受理人或者创建人负责客户可能的查询。

3.1.3.2          分派机制

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

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

l  服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分类分派到相应二线支持人员。

l  支持人员如判断事件需要第三方支持，原则上不在系统中进行事件单的分派，事件单仍保持在相应的一线或二线支持人员处。第三方处理完毕后，由相应一线或二线支持人员负责更新事件单状态、解决方案等相关信息。

3.1.3.3          再分派机制

再分派又称转派，指第一次分派后被分派对象，将事件单分派给其他部门或个人。

再分派机制是另一项关键的原则，它确保事件单不被过于频繁的相互转派，以至于无法在规定时间内得到解决。

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

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

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

3.1.3.4          优先级划分

事件的优先级表明了该事件或问题对运维对象（游戏产品）的业务影响。它是评定事件处理优先等级的一个重要指标。所有事件都将分配到三个优先级中的一个。优先级从 1 (优先级最高) 到 3 (优先级最低) 。优先级的划分一般情况下，是由事件的“影响度”和“紧急度”共同决定。

影响度是指受影响业务系统的关键程度，通常根据受影响的客户数量，可能造成的业务损失程度，或是业务系统的重要程度来决定。紧急度是指解决事件所需要的速度。需要指出的是：一个高影响度的事件并不一定非常紧急，反之亦然。

除此之外，还可以参考下列因素中的一个或几个可以用来定义优先级：

l   服务中断的时间和范围

l   受影响的服务

l   发生的次数

l   问题没有解决的时间的长短

优先级在事件的生命周期中是可以改变的。关于更改事件单优先级的原因和行为应该在事件单中记录。根据IT运维服务部的业务实际情况，综合考虑影响度、紧急度等多方面因素，得出事件的优先级定义如下表所示：

说明：优先级为1的事件为重大事件。 优先级1、2、3分别对应重度、中度与轻度的故障等级定义；

[td]

优先级	定 义
1	会使在线业务系统立即停止服务的故障，或影响在线业务系统的服务，但不会使服务直接停止的故障
2	会使后台支持系统立即停止服务的故障
3	会影响后台支持系统的服务，但不会使服务直接停止的故障

3.1.3.5          目标解决时间机制

为了更好的控制事件的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。事件管理的目标时间如下表所示：

[td]

事件目标时间	一线响应时间 [创建-分派]（含初步支持）	事件被分派并得到接受 [分派-分派被接收]	事件得到解决时间 [接受分派-解决]
优先级1	5--10分钟	10--15分钟	30分钟
优先级2	10--15分钟	30分钟	1小时
优先级3	15分钟	30分钟	2小时

所有超出目标时间的事件单将体现在每周、每月的统计报表中。同时，事件经理将得到通知。

详细的事件目标解决时间可参考附件《4.3事件分类表》

3.1.3.6          升级机制

升级机制的目的是，对于不同优先级的事件，确保分配到合适的资源来解决。为了达到这个目的，定义了升级机制的时间框架。当达到下列时间时，如果事件还未解决，将触发升级机制。

从事件单被创建之后所经过的时间作为触发事件升级的标准。

事件升级机制	项目经理 /开发项目负责人	维护工程师 /开发工程师	维护经理
优先级1	10分钟	15分钟	30分钟
优先级2	5分钟	10分钟	30分钟
优先级3	10分钟	15分钟	1小时

3.1.3.7          通知机制

通知机制的目的是将影响到服务可用性的事件的有关信息及时通知给关键的IT人员和用户。通知将告知相关的IT员工和IT管理者，通知相关信息如下：

通知方式：

•      事件发生时，告知事件导致了服务的中断（描述受影响的服务以及预计恢复时间）

•      受影响服务恢复时，告知服务已恢复，回到可用状态

•      优先级1的将通过电话+email方式通知；

•      优先级2和3的将通过email方式通知                                                           ITSS认证

标准通知内容：

•      事件的简要描述

•      受到影响的服务

•      预计恢复服务的时间（尽可能准确）

•      联系服务台咨询以获取更多信息的方法

具体的事件通知机制如下：

事件通知机制	项目经理	维护经理	产品经理	副总监
优先级1	5-10分钟	15-20分钟	20-30分钟	30-60分钟
优先级2	10分钟	15分钟	30分钟	60分钟
优先级3	15分钟	30分钟	60分钟	90分钟

具体的事件通知矩阵如下：

状态	用户	事件记录员	事件受理员 （二线）	事件受理员 （三/N线）	事件经理	事件负责人
待处理	√	√
已分派			√	√
受理中		√		* （职能升级）	*（结构升级）
挂起		√
已解决	√	√
关闭	√

注：“*”表示选择性通知

3.1.3.8          重复机制

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控系统上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同时，则该事件被认为是重复的。

由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，应创建新的事件单，复制原有事件单内容，并标识为“重复”的事件，原始事件将被标注为“主事件”。在原有事件单得到解决时，所有的重复事件单也同时获得解决。

3.1.3.9          复发机制

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

3.1.3.10     事件关闭机制

事件被解决后，需要对此事件进行关闭操作。事件单的关闭应当符合以下原则：

l  事件单的关闭必须由一线支持（值班组工程师）负责完成，但是事件经理可以超越此规则（即事件经理可以干预事件处理并关闭事件单）。其他人无权关闭事件单。

l  事件关闭后，需由值班组组长负责对此事件的记录内容进行核实。

l  事件单的用户可以要求关闭此事件单，例如：误报、错报事件。但具体关闭动作应由对应的一线支持人员负责。

3.1.3.11     流程关联机制

file:///C:/Documents%20and%20Settings/ac05/%E6%A1%8C%E9%9D%A2/ISO20000/%E4%BA%8B%E4%BB%B6%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E6%89%8B%E5%86%8C123_files/image005.gif

和问题管理的关联

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

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

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

•      对重大事件或者“成功但有问题”关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。

和变更发布管理的关联

•      事件处理过程中，如果需要变更，必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。

和配置管理的关联

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

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

和服务级别管理的关联

•      事件处理过程中，依照用户签订的SLA及相应服务级别对事件进行诊断和恢复。

•      事件记录为服务级别管理中各项服务是否违背SLA中相关定义提供数据支持。

3.1.4 事件单代码设计
3.1.4.1          事件单信息项

事件单必须包含如下信息项，可以在此基础上扩充：

[td]

序号	信息项	说明
1	事件ID	系统为此事件生成的唯一 ID。
2	状态	显示突发事件的状态。 建议以下预置状态： • 打开 — 此突发事件已经打开，但目前没有得到处理。 • 关闭 — 此突发事件已得到解决，并且得到了客户的同意。 • 已解决 — 有一个解决方案，但未经客户验证。 • 正在处理 — 正在处理此突发事件。 •  待定变更 — 已打开一个相关紧急变更，正在等待关闭该变更。 • 暂停 — 客户同意将此突发事件暂停一段时间；记录单将不会在该时段出现在待办队列中。
3	联系人	联系人不一定是服务接收人。此字段可以确保合适的人员将会得到有关交互更新的通知。
4	代理人	指定处理此突发事件的人员的姓名。此人是所分配的支持组的成员。代理人可以属于一个或多个分配组。
5	分配组	指定处理此突发事件的支持组
6	受影响的服务	该服务受此突发事件影响。此字段由交互记录中的数据填充。
7	受影响的配置项	对服务产生负面影响的配置项 (CI)。此字段由交互记录中的数据填充。
8	配置项可操作（服务不会中断）	如果已选择（设置为 true） ，则表示配置项当前正在操作中，而且服务不会中断。默认情况下，打开一个针对配置项的突发事件时，该配置项标记为出现故障。如果该配置项仍然正常工作，则应该标记此字段。
9	事件来源	参见“事件来源”定义
10	服务中断开始时间	服务中断开始的日期和时间。服务中断的开始和结束时间用于衡量“服务级别协议” (SLA) 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但打开或关闭突发事件之前可能会经历几分钟或几小时，因此，需要变更该值，以报告实际的服务中断开始和结束的时间。例如，设备可能在夜间出现了故障，而且必有人报告该问题 之后，突发事件才会打开。在此情况下，默认的打开时间不能准确反映服务中断时间。
11	服务中断结束时间	服务中断结束的日期和时间。服务中断的开始和结束时间用于衡量 SLA 的可用性。如果配置项标记为出现故障，则可用性SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但需要变更该值以报告实际的服务中断结束时间。例如，重新启动配置项之后，可以对其进行操作，但可能要花数分钟或数小时，才能更新记录，以报告突发事件已关闭。在此情况下，默认的关闭时间不能准确反映实际的服务中断时间。
12	位置	报告突发事件的位置。此字段由已升级交互中的数据预先填充。此字段仅供参考。
13	标题	概述突发事件的简短描述。此字段由已升级交互中的数据预先填充。 此为必填字段。
14	描述	突发事件的详细描述。此字段由已升级交互中的数据预先填充。 此为必填字段。
15	类别	描述突发事件类型，由已升级交互中的数据预先填充。
16	区域	此字段由已升级交互中的数据预先填充。对此区域的选择取决于类别。
17	子区域	第三级交互分类，主要用于进行报告。此字段由已升级交互中的数据预先填充。
18	影响度	此字段由已升级交互中的数据预先填充。它指明了突发事件对业务产生的影响。 影响和紧急程度用于计算优先级。
19	紧急度	此字段由已升级交互中的数据预先填充。紧急程度表示此突发事件对于组织的紧 迫程度。紧急程度和影响用于计算优先级。
20	优先级	此突发事件相对其他突发事件的排列顺序。优先级值是根据初始影响和紧急程度来计算的。只有从交互更新或升级突发事件时，此字段才显示。
21	SLA目标日期	下一个“服务级别目标”(SLO) 到期的日期和时间。此字段基于与突发事件信息相匹配的 SLO 进行填充，所用日期是违反协议之前即将到期的 SLO。
22	解决代码	指定一个预定义的解决代码，用于说明如何解决突发事件。此字段的预置选项基于客户的参考数据。 建议以下预置解决代码： • 不可重现 • 超出范围 • 请求被拒 • 通过变更/ 服务请求解决 • 通过用户说明解决 • 通过应对措施解决 • 无法解决 • 被用户撤销
23	关闭代码	此项是在服务台质控员在回访时，同用户确定的最终结果
24	解决方案	提供对突发事件解决方案的说明。

3.1.4.2         事件分级

给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。

编号	事件级别	描述	响应时间	解决时限
1	VIP服务		<10分钟	<8小时
2	重大事件	重大事件指的是严重影响到业务连续性并且涉及多个用户（用户>100）。 例如：病毒爆发、核心网络中断。	<10分钟	<24小时
3	一般故障	一般故障指的是影响到业务连续性并且造成中断的故障且故障仅涉及少数用户（用户<100）， 例如： 蓝屏、死机、病毒感染、关键业务软件无法启动等等。	<30分钟	<48小时
4	微小故障	微小故障指的是不会影响业务连续性的故障，例如键盘鼠标损坏，无法连接INTERNET等故障。	<40分钟	<72小时

3.1.4.3         事件影响度

影响度编码	影响范围	描述
1-非常重要	领导	对领导造成影响
2-严重	多数用户	对公司多数用户造成影响
3-一般	多个用户	对多个用户造成影响
4-轻微	少数用户	对单个或几个用户造成影响

3.1.4.4         事件紧急度

紧急度编码	紧急时间标准	描述
1-非常紧急	8小时	服务需8小时内提供（恢复）
2-紧急	24小时	服务需24小时内提供（恢复）
3-一般	48小时	服务需48小时内提供（恢复）
4-略微紧急	72小时	服务需72小时内提供（恢复）

3.1.4.5         事件优先级

优先级		影响度
		1-非常重要	2-严重	3-一般	4-轻微
紧急度	1-非常紧急	1-最高	2	2	3
	2-紧急	2	2-高	3	3
	3-一般	2	3	3-中	4
	4-略微紧急	3	3	4	4-低

3.1.4.6         事件来源

给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。

编号	来源	描述
1	用户报告	用户通过电话或WEB报告的事件，帮助台人员手工创建事件单
2	监控告警	监控工具发现的告警事件
3	日常运维发现	信息部日常运维检查产生事件    ITSS考试

3.1.4.7         事件性质[td]

类别	信息项	说明
突发事件	访问	授权错误
突发事件	访问	登录失败
突发事件	数据	数据或文件损坏
突发事件	数据	数据或文件不正确
突发事件	数据	数据或文件丢失
突发事件	数据	超过存储限制
突发事件	失败	错误消息
突发事件	失败	不正常工作
突发事件	失败	作业失败
突发事件

本帖关键字：ITSS