1. 文档介绍

1.1. 文档简介

本文档『突发事件管理流程设计报告』,是制定的突发事件管理流程的设计文档。通过该文档,可以帮助招行运行中心快速的解决IT环境的突发事件，为招行业务的快速发展提供更优质的IT服务。

本文档的内容是依据目前IT服务状况而制定的突发事件管理流程的说明，以后进一步的更新将由运行中心负责。

1.2. 文档用途

    本文档一方面作为本次ITIL项目的突发事件管理流程设计的交付物,也可作为进一步改进的蓝本,读者对象为与事件管理流程相关的所有技术与管理人员。

2. 突发事件管理流程介绍

2.1. 简介

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

2.2. 目的

事件管理流程的主要功能是尽快解决环境中出现的事件，保持IT服务的稳定性，其目的包括：

• 在成本允许的范围内尽快恢复服务
  • 快速响应服务请求（事件/服务请求/咨询等）
  • 用户在线获得帮助
  • 沟通故障解决的状态
  • 和客户确认事件的解决

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

• 提供IT管理信息
  • 人力资源利用情况
  • 故障处理情况
  • 支持效率

2.3. 范围

突发事件管理的范围主要可以从下面几个角度来看：

从突发事件管理涉及突发事件类别来看：

• 客户突发事件：客户主动联系服务台申报的突发事件，如：PC机故障、使用应用系统时遇到问题等等。
• 后台突发事件：通过综合告警平台发现的系统中的异常突发事件或运行中心运维人员发现的异常突发事件。

从突发事件管理涉及的组织范围来看：

• 系统运行室
• 系统管理室
• 网络室
• 系统支持室
• 南京灾备中心
• 安全室
• 信用卡室

从突发事件管理的上报渠道来看

• 电话
• 一事通
• 监控软件
• 电子邮件
• RTX
• 运维人员提交

2.4. 主要内容

突发事件管理流程着重于在快速解决IT环境中的突发事件，并降低其对业务的影响度。主要活动包括记录突发事件、分派突发事件、找出解决方案和结束突发事件等，其流程内容如下： 

• 检测和记录  突发事件通过系统管理软件检测出来或用户打电话进来产生的，所有突发事件记录进系统中。

• 判断并分派  确定是服务请求、突发事件、咨询还是投诉。如果是突发事件，进行突发事件的影响、收集信息等，尝试解决问题。

• 判断是否已解决  确定问题是否已解决，如解决，转5由服务台确认；如未解决，继续诊断，必要时转4由二线支持，三线（厂商和集成商、服务商等）进行支持解决等。

• 调查和诊断  二线支持和三线（厂商和集成商、服务商等）支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决突发事件。转3

• 服务台确认  对突发事件的解决方案进行确认，如未解决，根据情况采取相应动作，如转3继续，如解决，转6。

• 结束   如果确认已解决，关闭记录，更新文档; 必要时进行回顾。

• 定期产生报表   突发事件支持人员将根据管理要求定期产生相关报表。

2.5. 业务价值

突发事件管理流程将在多方面对IT服务产生积极作用，具体表现在：

提高服务可用性 –  不管什么原因，当用户不能使用IT提供的IT服务的时候(如咨询如何使用，设备宕机，网络过载等)，服务都是被认为不可用的，它影响了用户的生产率。突发事件管理流程通过保证突发事件、问题和请求等的快速处理来达到服务可用性的最大化。 

提高客户满意度 – 突发事件管理流程通过记录和管理突发事件的集成系统来提供有效服务以及一个集中的知识库。同时，也提供了服务供应者和使用者的沟通渠道，加强了信息中心和用户之间的双向认同。

集中化突发事件数据 – 通过突发事件管理流程和系统来统一收集突发事件数据，这些数据被其他流程所使用，如问题管理流程将分析这些数据以确定突发事件的根本原因，并确定纠正措施以消除再次发生的可能性。

3. 事件管理流程设计

3.1. 流程指导原则

咨询顾问和XX在事件管理流程咨询的设计阶段，一起共同设计事件管理流程遵循的原则。流程的原则是双方对流程的认识达成共识，是流程设计的基础和关键因素。下面是一些标准的事件管理流程遵循的原则：

• 指导原则 1：

突发事件管理流程中的服务台是运行中心向其他部门用户提供服务的单一联系点，服务台通过电话或Web对外提供服务，同时接受用户的查询请求；

• 指导原则2：

任何运行中心以外的部门要解决的突发事件不能绕过服务台来解决，所有需解决的突发事件要通过服务台向运行中心提交；

• 指导原则3：

任何突发事件，主单只是一个请求，必须创建任务子单，所有的处理过程在任务子单中完成；

• 指导原则4：

来自“一事通”的突发事件，由服务台热线在“一事通”中完成分单操作，并对主申请单进行跟踪、处理；

运行中心内部员工提交的突发事件，如果提交人知道如何分单，则将主申请单处理人指定为自己，并指定任务单的处理人，由系统根据指定的任务单处理人自动生成任务子单；如果提交人不知道如何分单，则由提交人转发突发事件单给服务台，由服务台来分单；

• 指导原则5：

对突发事件进行分单的员工是该事件的责任人，必须确保将突发事件正确的拆分成一个或者多个任务子单；确保将这些任务子单正确的分派给相应的处理人；对突发事件的解决进度和质量进行有效跟踪与协调；

• 指导原则6：

在整个突发事件的解决过程中，分单的员工应及时向用户通报突发事件的处理情况，使用户可以知道突发事件的解决状态；服务台员工也应该及时了解掌握突发事件处理的进度和情况，以方便跟用户进行沟通，或者接受用户查询；

• 指导原则7：

突发事件必须在得到用户的确认后，才能关闭记录。结合招行目前运维状况，一期目标是由系统将突发事件处理结果通过邮件发送给用户，用户如果在5个工作日内未反馈，则认为用户已经确认。

• 指导原则8：

突发事件的主申请单由分单人跟踪处理并关闭，任务子单由处理人直接关闭。

3.2. 一事通接口

结合本次项目的需求和运行中心对一事通中请求处理的实际情况，HP建议本期项目一事通接口采用以下方案：

从来源上看，可将目前一事通中的所有的请求分为以下两种类型来处理：

• 运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。

此类请求将不再使用一事通平台，而是直接由发起人在新的HPSM平台中按照新的流程提交，并由系统自动转发给相关的处理人，中间不再经由服务台进行分派工单、审批等。

• 需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情

这其中又细分为以下两种情形：

    a.运行中心发起中间需要其他部门参与的

这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。

    b.其他部门发起需要运行部审批或者处理的

这种请求运行部人员在一事通提交请求，全部审批（包括运行部人员的审批）完成后，服务台在一事通中完成分单操作后，系统通过接口将请求主单和子单信息一起转入新的HPSM平台按照新的流程处理。

以上a,b两种情况，最后具体落实处理的部门可能是运行中心，也可能不是运行中心。

3.3. 分派机制

针对上一个章节设计的两种来源的服务请求和突发事件，分别有以下的分派机制：

• 运行中心内部的突发事件/服务请求，跟其他任何部门都没有关系，流程始终在运行部内部流转。

运行中心内部的服务请求和突发事件，包括服务台通过电话或者EMAIL或者RTX接受到的服务请求或者突发事件。

系统会根据服务目录的定义，自动分配给一线或者二线，如果在服务目录中没有清晰的定义，则由请求或者突发事件的提交人将请求分派给一线处理，如果一线人员无法处理则升级分派到二线。

• 需要其他部门参与的突发事件/服务请求，甚至其他项目管理等等事情

申请人在一事通中提交服务请求和突发事件，由服务台在一事通中完成分派操作，所有的服务请求和突发事件首先分派给一线中负责相关业务的人员，如果一线人员无法处理则升级分派到二线。

3.4. 技术平台相关代码定义

3.4.1. 信息项

• 各个流程的通用属性：

• 突发事件特有属性：

3.4.2. 突发事件分类

对突发事件的进行分类，主要目的在于方便各个突发事件处理组之间的信息沟通，为突发事件的诊断和处理提供信息，并产生相关的管理信息报表，从而达到优化提高IT服务质量，提高突发事件处理效率的目标。

具体分类原则、标准和方法是：

各个流程，包括事件、问题、变更等分类统一规划，遵循统一的原则和标准，分类的层次为4级：

第一个层次： 类别

第二个层次： 子类别

第三个层次： 流程模块

第四个层次： 操作类型

例如：

详情参见《流程分类表》

3.4.3. 影响度、紧急度和优先级

突发事件在提交到运行中心以后，因为数量很多，HP建议使用“影响范围”和“影响程度”两个纬度来计算每个突发事件的“优先级”，这个优先级跟《招商银行信息系统紧急突发事件管理办法》规定的P1-P5相对应，突发事件处理人员将根据此优先级的高低来决定处理的先后顺序。

• 优先级

• 影响范围

影响范围定义中的业务系统列表，参见附录一。

• 影响程度

优先级用来指导运维人员确定突发事件处理的先后次序，优先级高的请求先处理，优先级低的后处理。为了能够客观的评价一个突发事件的优先级，可以使用“影响范围”和“影响度”两个维度来综合计算优先级。

3.4.4. 优先级和解决时限

与优先级相对应，我们定义一个事件处理的时限要求（deadline）和响应时限要求。下表列出了通常与各优先级对应的时限：

注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置

解决时限的定义：事件单的实际完成时间（状态为已解决） － 事件单的分派时间（状态为处理中）

响应时限的定义：事件单的响应时间（状态处理中）－ 事件单的创建时间（状态为待处理）

3.4.5. 升级通告路径的定义

当事件创建以后，需要相关工程师对事件进行响应和处理，为了保证事件能够及时被分派并且被处理，在事件管理流程中需要对不同级别的事件设定不同的响应时限，如果，违背了响应时限，系统将根据事件的优先级自动向相关事件处理人和事件经理发起通告，由事件经理负责协调资源，并督促事件能够及时被响应和处理。

在不同优先级别/影响程度的事件有不同的升级通知路径，在通告的每个过程中，相关人员都需要执行相应的动作来报障事件能够在规定的时间限制内解决：

注：以上时限设置，仅供参考，项目上线后，可做为参数灵活配置

3.4.6. 事件状态

3.4.7. 事件结束代码

3.4.8. 事件来源

3.4.9. 服务台满意度 

3.4.10. 技术支持满意度   

3.4.11. 工作子单状态代码

当工程师在处理突发事件单时，有时需要其它工程师协调处理，或者需要征得其它同事的同意或认可，则可以在当前的突发事件单上发起工作子单并分派给相关的人员，所以，工作子单也有生命周期，即对应的各种状态：

3.4.12. 工作子单分类

其它的流程如问题、配置、变更都会产生相应的工作单，所以最终工作单的分类应该综合各个流程产生的需求。

3.5. 事件管理的人员角色和职责

结合ITSM最佳实践，在事件管理流程中推荐的主要角色有：事件经理、服务台主管、服务台热线支持、服务台一线支持、服务台现场支持以及二线和三线支持等。

3.5.1. 事件经理

事件经理职责:

• 确保有效协调资源,通过事件支持专家快速恢复正常服务。 
• 确保事件管理支持人员的适当技能水平和绩效表现。
• 确保和问题管理流程经理及外部供应商等部门的有效合作。
• 确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题。
• 通过服务台的作用及良好的服务态度来确保客户的满意。
• 确保有关IT服务和客户支持的管理信息的可获得性。
• 改进和提高事件管理流程的有效性和效率。

事件经理技能:

• 深刻了解事件管理流程
• 较强的领导能力
• 了解技术架构和技术环境
• 较强的口头表达能力和与客户沟通技巧
• 处理纠纷的能力

3.5.2. 二线支持

二线支持职责：

• 接受一线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
• 在规定的时间内解决事件和服务请求
• 对利用“替代方案"解决的事件，在资源及时间允许时应找到问题根源
• 在需要时及时利用其它资源(开发中心,开发商, 厂家) 参与事件解决
• 将事件的解决步骤文档化，并将解决方案录入服务台系统中

• 根据解决方案进行IT服务恢复
• 向现场服务人员提供必要的技术支持和协助
• 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认
• 负责跟开发中心、集成商和供应商之间的接口
• 为VIP用户提供在线或现场支持

二线支持技能：

• 熟悉技术平台和技术环境.
• 很强的技术能力
• 较强的解决事件的能力
• 较强的分析能力

3.5.3. 三线支持

对于运行中心来说，三线支持主要是指开发中心和厂商，在事件处理流程中二线支持专家，来协调三线人员来帮助处理突发事件或者服务请求。处理的结果由二线人员录入系统，并通过结束代码注明由三线解决。

三线支持厂商人员职责：

• 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
• 在规定的时间内解决事件和服务请求
• 负责协调厂商、开发商内部资源

三线支持开发人员职责：

• 接受二线支持升级的事件或服务请求，验证事件的描述，进一步收集相关信息
• 在规定的时间内解决事件和服务请求
• 负责协调开发中心内部资源

三线支持技能：

• 很强的资源协调能力
• 熟悉技术平台和技术环境.
• 较强的分析能力

3.5.4. VIP支持

VIP支持职责：

• 当接收到VIP客户的服务要求时，及时准确地为VIP客户提供服务；
• 随时关注VIP客户的满意度，积极调动资源为VIP客户提供服务；
• 二线支持工程师的所有职责。

VIP支持技能要求：

• 较强的沟通能力；
• 较强的倾听能力；
• 熟悉事件处理流程和服务台的职责；
• 较强的协调能力，能够迅速协调相关的二线团队为VIP提供服务；
• 二线支持的所有技能

3.6. 流程角色和人员对应

3.7. 事件处理逻辑流程

根据流程设计要求, 我们将事件管理流程的设计标号以100开头,  比如100.X.

流程图相关符号说明：

3.7.1. 一事通请求处理逻辑流程

根据具体情况, 同时结合ITSM的最佳经验, 建议在本次项目中，对目前一事通中的请求（这些请求包括服务请求、突发事件和变更），由服务台进行初步审核确认并组织审批，然后通过接口进入本次项目引进的HPSM系统，按照新的服务请求、突发事件和变更流程来处理。

具体来看，一事通中请求处理的逻辑流程如下图：

3.7.2. 突发事件管理逻辑流程

3.8. 事件处理物理流程

在上面的章节中描述了突发事件管理的逻辑流程，在下面两个章节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。

3.9. 一事通请求管理物理流程

在3.7节中描述了突发事件管理的逻辑流程，在本节会结合突发事件的逻辑流程，针对“一事通”中的请求展开对流程的详细描述，我们称之为物理流程。

3.9.1. 产生请求单100.1

此流程在“一事通”中实现。

3.9.2. 审核请求 100.2

此流程在“一事通”中实现。

3.9.3. 审批请求 100.3

此流程在“一事通”中实现。

3.9.4. 分单 100.4

此流程在“一事通”中实现。

3.9.5. 创建突发事件 100.5

具体描述如下：

3.9.6. 创建变更 100.6

具体描述如下：

3.9.7. 创建服务请求 100.7

具体描述如下：

3.10. 突发事件管理物理流程

在3.7节中描述了事件管理的逻辑流程，在本节会结合逻辑流程中的主要环节进行展开描述，我们称之为物理流程。

3.10.1. 产生记录 102.1

具体描述如下：

3.10.2. 收集信息 102.2

具体描述如下：

3.10.3. 分派任务子单 102.3

具体描述如下：

3.10.4. 服务台尝试解决 102.4

具体描述如下：

3.10.5. 升级转单至一线 102.5

具体描述如下：

3.10.6. 一线响应 102.6

具体描述如下：

3.10.7. 一线尝试解决 102.7

具体描述如下：

3.10.8. 升级转单至二线 102.8

具体描述如下：

3.10.9. 二线响应 102.9

具体描述如下：

3.10.10. 二线尝试解决 102.10

具体描述如下：

3.10.11. 联系三线解决 102.11

具体描述如下：

3.10.12. 关闭任务子单 102.12

具体描述如下：

3.10.13. 关闭事件 102.13

具体描述如下：

3.10.14. 用户确认 102.14

具体描述如下：

4. 事件流程与其他流程的关系

4.1. 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。问题管理流程中的问题经理可以主动的对事件管理流程中记录和处理的重复发生或者重大而未彻底解决的事件进行分析，并从中创建一些问题工单纳入问题管理流程做深入分析和研究。

另外，事件管理流程中的服务台经理和二线支持专家可以主动的将一些潜在的问题通报给问题经理，结合招行的实际情况，惠普建议如下的操作方式：

1. 服务台组长和事件经理将那些在一段时间内频繁发生的重复事件标志为“潜在问题”
2. 二线支持专家将那些未在规定期限中找到根本解决方案的事件标志为“潜在问题”

服务平台将自动将这些标识事件的相关信息以邮件的形式通知问题经理，以便其在问题管理流程中对这些事件进行着重关注和诊断，必要时升级为一个问题。

4.2. 和配置管理流程的关系

一般而言，服务台和事件管理流程需要从配置管理数据库中查询配置项的属性和配置项间的关联关系，以帮助事件的分析与诊断。

4.3. 和变更管理流程的关系

服务台和二线支持专家在处理服务请求和事件的过程中如果涉及变更，可以依据解决方案发起一个变更请求（RFC），该请求一旦发出将进入变更管理流程进行一系列运作，最终满足客户的请求或恢复中断的服务。服务台和二线支持专家有义务监控整个变更的过程，以保证最终达到方案预定的效果。

5. 附录一：重要业务系统

重要业务系统是指：

6. 附录二：重大事件处理子流程

其中黄色部分是需要进一步明确的。

6.1. 优先级P1事件处理流程

6.1.1. 外部环境导致

6.1.2. 信息系统缺陷导致

6.2. 优先级P2事件处理流程

6.2.1. 全行范围重要业务系统不可用

6.2.2. 分行范围所有业务系统不可用

6.3. 优先级P3事件处理流程

6.3.1. 总行重大隐患

6.3.2. 分行范围内重要业务系统不可用

7. 附录三：重大事件通知联络表