20150827  淡然

目录

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          目标解决时间机制

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

[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方式通知

标准通知内容：

•      事件的简要描述

•      受到影响的服务

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

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

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

事件通知机制	项目经理	维护经理	产品经理	副总监
优先级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     流程关联机制

和问题管理的关联

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

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

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

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

和变更发布管理的关联

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

和配置管理的关联

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

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

和服务级别管理的关联

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

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

待续http://ITIL-foundation.cn/thread-52084-1-1.html

本帖关键字：ITSS

20150827  淡然

目录

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          目标解决时间机制

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

[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方式通知

标准通知内容：

•      事件的简要描述

•      受到影响的服务

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

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

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

事件通知机制	项目经理	维护经理	产品经理	副总监
优先级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     流程关联机制

和问题管理的关联

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

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

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

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

和变更发布管理的关联

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

和配置管理的关联

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

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

和服务级别管理的关联

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

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

待续http://ITIL-foundation.cn/thread-52084-1-1.html

本帖关键字：ITSS