1. 文档介绍

1.1 文档简介

 本文档是信息化中心调度室(以下简称调度室)制定的事件管理流程策略文件。通过制定该流程，可以帮助调度室管理IT运维，有效降低或消除相应突发事件的数量，提高IT系统和服务的质量，使运维部门向业务人员和相关用户提供更优质的IT服务，为用户提供更优质的IT服务，并且可以为有效地实施其他相关ITSM管理流程，如问题管理奠定基础。

1.2 文档用途

本文档作为事件管理流程的流程文件，读者对象为与事件管理流程相关的所有技术与管理人员。

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

• 减小突发事件对业务的影响
• 最优化支持资源，提高工作效率
• 屏蔽错误事件和服务请求
• 根据业务轻重缓急解决事件，保障有效IT运营
• 加强监控和及时反馈
• 提升用户满意度
• 提供管理信息

2. 概述

事件管理流程是为业务尽快恢复正常工作状态而设计，其关心的重点是快速响应、快速恢复，使故障对业务的影响最小化。

事件管理流程受事件触发和驱动，所谓事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、以及影响业务流程或违背服务水平协议的情况。事件也包括用户的日常服务请求。不是所有的事件都由用户产生，监控管理平台产生的告警也可引发事件。

通常由服务台负责记录事件相关信息，向用户提供对已知错误的处理方法，报告事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。

事件管理的责任是记录与分类、调查与诊断、解决与恢复、关闭事件、跟踪由事件产生的问题管理流程进度、最终解决事件。

2.1 流程目的

事件管理流程的主要功能是尽快解决事件恢复业务，保持各个IT业务系统的稳定性，满足事先与业务客户之间所约定的服务级别标准，其目的包括： 

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

• 快速响应服务请求（电话/Web/邮件等）
• 用户在线获得帮助
• 沟通问题解决的状态
• 和客户确认事件的解决

• 进行事件控制

• 按规范记录事件
• 就事件的优先级、紧急性和严重性进行分类
• 分析，诊断，必要时进行升级
• 监视并结束事件
• 进行定期管理流程分析回顾

2.2 事件策略

2.2.1 事件分类

表2-2-1 事件分类表

2.2.2 事件分级

事件分级结论

 S1为最高级需优先处理，S2为次高级第二处理，S3为严重级第三处理，S4为一般级第四处理，S5为最低级最后处理。

2.2.3 事件解决时间

2.2.4 事件升级

• 事件响应升级要求

• 事件上报时间 

目前只针对1-3级故障进行上报处理。

3. 流程范围

交付中心事件管理范围是对用户的IT生产环境中发生的问题进行管理，并采取主动性预防措施来降低事件数量。

4. 流程详述

4.1事件管理的主要流程

事件管理触发后，由调度员（服务台）担任事件的管理和协调的职责，负责事件的跟踪、协调资源、对违反SLA进行预警、事件升级。

4.2 事件接听与记录

本阶段描述事件的初始检测。事件可通过电话或电子邮件向服务台人员发出事件请求，也可以由监控管理系统的警报而引发。

所有事件都要进行记录，以便能够在它们的整个生命周期中跟踪、监视和更新它们。然后可将该信息用于问题管理、报告、流程优化和规划。

服务台作为事件单一的联系点，在事件整个生命周期中持续关注其执行情况。

4.3 分类与派单

服务台人员对事件进行初步分类并确定事件的优先级。然后指派合适的工程师进行处理，对于自己能够处理的事件也可以分派自己作为事件处理人。

4.4 事件调查与分析

一线维护人员受理(响应)事件请求，如有需要对事件进行重新分类，查询知识库，判断是否有文档记载的解决办法可以快速解决事件并关闭。如果没有，需要根据本身的知识技能对事件进行深入调查和诊断，尝试解决和恢复。

4.5 二线资源调度

一线维护人员在事件处理过程中如果需要分派技术主管或二线专家，需要先要和二线资源管理岗电话沟通（如果本团队有相应资源找交付经理，如果本团队没有资源找服务台），反应当前事件处理情况和对二线资源的需求。由二线资源管理岗协调、最终确定二线工程师的人选和时间安排。一线工程师将事件分派到该二线工程师。

4.6 协作与升级二线

处理事件时，需要团队有非常好的协作。比如在处理过程中有重复的事件出现，需要各个工程师的处理步骤和经验共享。而且事件在处理过程中往往需要备件、供应商、二线的配合，共同完成。

如果在协调过程中超出工程师沟通范围，可以请求项目经理、交付经理介入，进行协调调度。

4.7 事件解决与恢复服务

工程师解决事件并恢复服务，记录解决的时间。需要详细记录解决执行的操作步骤或变通方法；实施完毕后对解决进行确认。

4.8 满意度调查后关闭事件

 对于已解决的事件，在和用户确认成功解决后，才可以关闭事件。同时对客户进行满意度调查，记录用户对这次服务的评价，记录客户需求与意见。为后续事件管理流程优化改进积累建议。

4.9 事件的超时与监控

  在事件处理过程中，由项目负责人、服务台负责对整体事件流程的超时、监控。及时和二线资源管理岗沟通，及时向领导层汇报。监控整个事件处理过程。

4.10 重大事件

重大事件过程——存在重大事件过程是为了处理那些需要超出常规事件过程所提供的响应的严重事件。虽然这些事件仍然遵循常规事件生命周期，但是重大事件过程的触发提供了这些高优先级的事件所需要的增强的协调、上报、沟通和资源。

重大事件的处理要求是：集中相关资源，优先处恢复服务，事后补单。

4.10.1 重大事件处理流程

4.10.2 重大事件的定义

重大事件过程在如下情况下提供附加的跨部门协调、资源、管理参与和沟通：即这些情况下的事件影响或潜在影响使得超出常规事件管理流程所提供的响应变得必要。事件管理过程中，优先级最高的事件被视为重大事件。

一旦确定某个事件是重大事件，事件经理应该立即通知涉及的所有各方：问题管理、可用性管理、服务级别管理、服务连续性管理、IT 管理、受影响的业务负责人以及中心领导值班人。

4.10.3 重大事件处理小组组长

重大事件处理小组组长负责在重大事件期间协调计划、资源和沟通。这是个临时性的职位，通常由分管副主任或者项目负责人担任。

扮演重大事件处理小组组长角色的职员需要满足下列条件：

• 能够处理重大事件期间产生的压力。
• 有权作出决定的副主任以上级别。
• 优秀的沟通者，能够与组织中的所有层次的技术 IT 职员、业务代表和客户交谈。
• 深入了解中心（包括信息化中心如何运作以及相关负责人）的公认人物。
• 准备加班工作，经常是随叫随到。
• 准备到现场并在需要时拜访客户现场，同样是随叫随到。

4.10.4 重大事件处理小组

处理小组组长，应该收集到目前为止可用的所有信息，并确认当前状况并负责组建处理小组。

调查和解决重大事件所涉及的技术团队称为“处理小组”。该小组通常包含一个或多个技术人员，由同时经过技能培训和问题解决技术培训的资深职员组成。这个核心小组应该接受使用中的所有关键战略技术的培训，当时如果特定事件要求不同的技能，可以由其他支持人员提供补充。资深支持人员应该在临时分配的基础上在整个核心小组中轮流。

4.10.5 重大事件恢复与沟通

处理小组组长应该主持一次与处理小组、已经参与处理事件的任何团队成员、受影响的经理和其他任何相关技术专家进行的初始计划会议。该会议的目标应该是同时就恢复计划和沟通计划达成一致。

处理小组组长应该与包含 IT 经理、受影响的业务经理和合作伙伴以及客户管理的管理小组一起定期复查进度。管理小组会议的目的应该是向所有各方通气，讨论进度，并在需要时提供管理升级上报。

管理小组和处理小组审查会议通常应该保持独立，以便每个小组集中于与他们的角色相关的问题。处理小组应该讨论技术问题，然后为管理小组提供进度报告，后者然后可以集中于资源、上报和沟通问题。

在重大事件期间，沟通的处理本身经常变得非常困难。沟通计划的目标应该是在事件生命周期中提供所有沟通的协调。

4.10.6 重大事件的终结

随着重大事件的推进，处理小组组长应该确保定位、分配和协调任何附加资源要求。

重大事件过程应该继续伴随常规事件管理流程，直至重大事件终结。在事件的最后阶段，当已经采取解决操作时，解除处理小组的部分任务也许是可能的，不过要了解到如果解决方案被证明不成功，他们将被重新召集。

在重大事件终结时，将处理过程记录、方案补录入系统。

重大事件终结之后，处理小组组长需要对事件的发生、处理过程、结果，进行回顾总结经验。作为汇报依据和经验积累。

5. 人员和角色

流程的实现是通过不同的流程角色及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员。事件管理流程主要分为以下几个职责/角色，分别简述如下：

5.1 事件管理流程负责人

事件流程负责人从宏观上监控流程，确保事件流程被正确的执行。当流程不能够适应实际运维情况时，流程负责人必须及时的对此进行分析，找出缺陷，进行改进，从而实现可持续提高。

职责:

1. 确定管理流程的衡量指标
2. 确保事件流程能够取得管理层的参与和支持
3. 确保事件流程符合公司实际状况和公司 IT发展战略
4. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
5. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进（例如增加或合并流程的角色），从而实现可持续提高
6. 保持与其他流程负责人的定期沟通

5.2 部门受理人

部门受理人负责事件解决过程中的协调和监控，以及故障升级的判断、升级过程中的具体执行和协调。

职责：

1. 检查事件记录的处理进度，保持与事件报告人的联系
2. 将事件分派给最合适的工程师来处理
3. 负责对事件的解决协调资源，保证故障的最终排除；
4. 当事件优先级为紧急且需要协调处理时，负责按照紧急事件处理方法对事件进行处理，确保有效协调资源，促进支持工程师快速恢复正常服务
5. 审核事件处理流程的合理性
6. 确保和问题管理流程经理的有效合作
7. 确保正确和广泛地收集和分析事件数据，为问题管理提供来源

5.3 服务台人员

服务台人员负责接收所有的事件，对事件进行初步的记录，并根据实际情况将事件分派到合适的工程师。

职责：

1. 在指定的响应时间内响应所有服务台热线电话、邮件、传真、告警信息等事件报告
2. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
3. 为事件进行适当的分类
4. 审核事件记录信息的完整和正确性
5. 负责7×24的电话支持和系统监控

5.4 一线、二线资源

工程师负责提供对服务台人员无法解决的事件进一步进行调研，找出解决方案并尽快恢复服务。

一线工程师负责处理事件，如果是设备损坏需要更换设备的，使用备件库资源，进行更换。

二线资源含二线工程师及二线专家。二线工程师的技术能力一般要强于一线工程师，平时大部分也参与项目中，事件一般由一线工程师处理，有难度或者处理不了的升级到二线工程师处理。二线专家是公司在某技术方向的专家，一般不参与项目的具体工作，当二线工程师不能解决时或该方向没有二线工程师才会参与到事件的解决中。

职责:

1. 验证事件的描述和信息，进一步收集相关信息
2. 对于事件信息不正确和不完整的工单，可以和服务台沟通后进行补充。
3. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动。
4. 对于需要由供应商进行解决的事件，联系供应商参与事件处理。
5. 根据优先级提供有效的解决方案。
6. 实施事件解决方案。
7. 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件。
8. 更新事件记录，确保事件状态代码真实反映事件状态。
9. 当事件优先级为需要协调处理时，提请事件经理根据协调处理。
10. 进行事件的深入调查研究。
11. 对于分派不正确的事件，转回服务台重新分派。

5.5 部门负责人

二线资源管理岗对二线资源的调度负责。二线工程师对应资源调度岗为交付经理，二线专家资源调度岗为服务台。

职责:

1. 接受来自服务台或者二线的事件请求
2. 进行事件的深入调查研究
3. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
4. 提供事件根源和最终解决方案

5.6 厂商

厂商支持人员是相关领域的专家，负责提供对二线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责:

6. 与其他流程的关系

服务台

服务台充当许多 IT 流程的初始入口，包括事件管理流程。对于许多其他 IT 流程，服务台只是向它们传递请求；但是对于事件管理流程，服务台和事件管理流程之间的联系要紧密得多。

服务台充当业务和 IT 之间的接口，在此处是充当业务和事件管理流程之间的接口。

服务台值班员负责事件管理流程的日常协调。服务台执行记录、分类和事件管理的初始支持阶段。然后，当事件分配到问题解决小组时，服务台通过监视和跟踪所有事件保留所有权职责。

如果服务台运作成功，则许多服务请求和事件可以得到处理和解决而无需越过服务台功能之外。

就事件管理流程的客户满意度而言，服务台是一个关键组件。

问题管理

事件与问题管理关系密切，但是在支持组织内，各自的侧重点却大相径庭。

事件管理关注尽可能快地还原常规服务，而问题管理却侧重于识别并解决基础问题及其根本原因。

事件管理为问题管理提供识别根本问题的存在性所需要的许多信息。问题管理会分析事件统计数字，从而识别所发生的多个事件或特定类型的事件的增长趋势。

相应地，问题管理寻求解决这些事件的根本原因以防止它们再次发生。

问题管理还会维护有关现有问题和已知错误的信息，包括已知的应对方案和解决办法。事件管理利用该信息提供更快的事件解决。

问题管理还负责在主要事件得到解决后，对其进行审查。在这些审查期间，目标是识别根本原因根源以便防止任何事件重现，识别可用于对任何事件重现给出提前警告的触发因素，以及识别事件的解决质量以便改进今后的反应。

变更管理

当事件管理识别出需要配置项变更的解决操作时，这些变更将在变更管理流程的控制下进行部署。

变更管理流程提供的控制可减少所需撤销的更变数量，并能确保在需要时，记录有关的撤销计划。协调的变更测试减少了由变更部署导致的后续事件的机会。

变更管理还为事件管理提供关于最近的变更、受影响的配置项和变更原因的有用信息。

配置管理

配置管理提供在整个事件管理流程中使用的至关重要的信息。配置管理数据库 (CMDB) 包含可用于以下用途的信息：

• 提供和检查请求者详细信息。
• 提供关于配置项 (CI) 的信息。
• 通过指示受特定 CI 的故障影响的服务和 SLA 协助事件分类。
• 识别 CI 间的关系和依赖性。
• 识别完全相同或相似的 CI 以用于比较目的。
• 识别其它途径及应对方案。
• 记录由于 RFC 导致的配置项变更。

发布管理

事件管理识别出的有些解决操作要求需要作为发布进行整合和实施的变更。这些发布由发布管理流程协调和管理。

与变更管理类似，发布管理提供有效的计划、测试和协调，确保这些发布能够在产生最少事件的情况下实施。

服务级别管理

服务级别管理为事件管理提供正确分类型事件所需要的至关重要的信息。关于业务关键性和服务级别指标的信息允许事件管理流程设置事件优先级，并准确定位最需要的支持资源。

事件管理为服务级别管理提供关于服务指标违背的信息。

7. 衡量指标

为了较好地控制事件管理流程的质量，必须为事件管理流程设置考核指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

事件管理流程的关键衡量指标如下：

8. 流程持续改进

每个流程的改进计划由流程经理初步整理后，与各交付经理沟通协商，了解个交付经理的的新需求。运用运维工具，提高事件处理的解决率，加强工具的投入，提高事件的平均解决时间，将报告汇总到服务改进计划中。

9. 相关文件和记录

TSD10 《运维服务问题管理程序》

TSD06 《运维服务配置管理程序》

TSD08 《运维服务发布管理程序》

TSD12 《运维服务变更管理程序》

《项目服务总结报告》