1. 文档介绍

《服务台及事件管理流程设计》是在对IT维护管理流程进行现状评估后，结合实际情况， 共同制定的服务台建设及事件管理的流程设计文档。通过制定该设计文档，可以帮助信息中心通过建立一个综合的服务台和梯队式的IT服务架构，重新组织原有的IT运维管理工作，有效地解决IT环境的突发事件，提高IT系统和服务的质量，并为信息中心今后进一步完善事件管理提供指南。

1.1. 文档范围

本文档描述了信息中心IT服务管理活动中服务台和事件管理流程的设计。

服务台的设计内容包括服务台的组织建设建议，担当职能以及相关流程定义，同时包括与事件管理活动集成的接口。

事件管理的流程设计部分，内容包括在信息中心实现事件管理控制的相关流程定义和部分平台实现时的代码设计。

1.2.文档用途

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

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

1. 减小突发事件对业务的影响
2. 最优化支持资源，提高工作效率
3. 根据业务轻重缓急解决事件，保障有效IT运营
4. 加强有形监控和及时反馈
5. 提升用户满意度
6. 提供管理信息

1.3. 文档结构

文档内容具体如下：

• 第一章 文档介绍

对文档目的和内容进行简单介绍，同时描述文档中用到的ITIL中的术语。

• 第二章 IT管理模式

 讨论在华星光电IT信息中心现有基础上应该建立一个什么样的IT管理模式，以适应IT服务管理的要求。

• 第三章 服务台建设建议

分析管理模式中的核心工具－－服务台――的组建原则，人员、工具要求，角色职责以及衡量标准。

• 第四章 服务台用户交互管理流程设计 

描述服务台用户交互流程设计内容，如：具体流程、流程代码等。

• 第五章 事件管理流程概述

简单描述事件流程，明确设计目的、范围、内容以及流程政策等。

• 第六章 事件管理流程设计 

描述事件流程设计内容，如：具体流程、流程代码等。

• 第七章 事件管理流程设计 

描述与服务台，突发事件流程相关的报表定义。

1.4. ITIL相关术语

下面是ITIL中相关的术语：

• 帮助台：即Help Desk

在ITSM中， 帮助台从根本上来说是提供了用户和IT部门的唯一接口。帮助台是面向突发事件的支持机构，其根本目的是管理、协调并尽快解决突发事件。

• 服务台：即ServiceDesk

服务台是更广义上的IT服务管理支持工具，它不仅包含帮助台功能（支持事件管理流程），同时也提供与其它流程的接口。

• 事件管理：即 Incident Management

是负责处理所有导致IT服务中断或服务质量下降的事件和用户请求的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，而不在于查找根本原因。

• 问题管理：即Problem Management

是负责解决重大紧急事件或具有相同特征的一组事件的运维流程。它的目的是找出产生这些事件的根本原因，并通过永久性解决方案防止类似事件的再次发生，同时问题管理流程也通过主动式管理降低事件发生的数量。

• 配置管理：即Configuration Management

是负责描述、跟踪和汇报所有IT基础架构中的每一个设备或系统的信息的运维流程。这些设备和系统被称为配置元素(CI) 。每一个CI必须有效管理、跟踪和控制以支持IT服务和基础设施正常运行。

• 配置管理数据库（CMDB）：即Configuration Management Database

是配置管理流程中用于记录企业所有IT相关配置元素及其相互关系信息的数据库。

• 变更管理：即Change Management

是负责控制和管理IT相关的变更的运维流程。它的目的是使变更可能将对生产环境产生的影响和风险降到最小，从而提高IT环境的整体稳定性。

• ITIL：即IT Infrastructure Library

是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT服务管理标准，惠普的ITSM管理思想是以此为核心基础的。

服务流程的总体构架和互相之间的关系如下：

2. IT管理模式（运维模式）

通过对信息中心业务和IT现状的调研和分析，我们发现，目前运维部门的运维工作主要集中在以下一些方面：

• 突发事件和请求
  包括故障申告和各种客户申请活动，此类活动的特点是，随机产生，有发起者，对处理时间和信息反馈有要求，处理不当容易影响业务质量或客户满意度下降。
• 日常维护工作
  定期或有计划的系统维护工作，如系统备份、磁盘空间维护、日志检查等，此类活动的特点是定期进行，无发起者，对业务质量或客户满意度无影响。
• 不定期的维护工作
  包括各种维护规范、规划、策略的制定。此类活动的特点是，不定期进行，有发起者（通常是部门领导），活动周期较长，对业务质量或客户满意度无太大影响，但对运维管理工作产生一定的影响。

基于以上分析，我们建议华星光电IT信息中心采用以服务台为中心的IT管理组织模式，并且建立梯队式的技术支持与服务团队，在整合服务资源的同时，建立规范的管理流程和方法，以满足从传统的IT运维管理方式向IT服务管理方式转变的需要。

由于服务台与事件管理流程的关联最为紧密，服务台的建设将在本设计文档中与事件管理流程一起讨论。

3. 服务台建设建议

3.1. 什么是服务台

服务台（Service Desk）在服务支持中扮演着一个极为重要的角色。完整意义上的服务台可以理解为其它IT部门和服务流程的“前台”，它可以在不需要联系特定技术人员的情况下处理大量的客户请求。对客户而言，服务台是他们与IT部门的唯一联络点，确保他们找到帮助其解决问题和请求的相关人员。

服务台有时也被称作“帮助台”（Help Desk），但这两个概念的意义并不完全一样。帮助台的主要任务是记录、解决和监控IT服务运作过程中产生的问题，主要和事故管理相关联。而服务台的概念则具有更广泛的内涵，它通过提供一个集中和专职的服务联络点促进了组织业务流程与服务管理基础架构的集成。

3.2. 服务台使命

服务台只是一项服务管理职能，因此，与其他服务管理流程不同，它没有严格有序的日常运作流程，而只是针对用户的请求或根据服务级别协议的要求进行一些日常运作活动。这些日常运作活动包括响应用户呼叫、为用户发布信息、客户需求管理和客户关系管理、日常运维管理、基础架构监控等：

• 响应用户呼叫

即对于用户发出的故障申告、服务请求、变更请求等事件进行记录和处理。这是服务台最主要的工作。

• 为用户发布信息

服务台是为用户提供IT服务信息的主要来源，一般可以采用布告栏、电子邮件、屏幕消息等方式为用户提供有关故障信息、故障或新增服务等方面的信息；

• 客户需求管理和客户关系管理

服务台不仅仅是客户请求响应中心，同时也是客户关系管理中心。因此服务提供方应采取必要的措施和使用适当的技术对服务台进行有效的管理，从而使服务台可以准确迅速的了解客户需求，改善客户体验，提高客户满意度。这些措施和技术包括结构化询问技术、详细了解客户和跟踪客户、维护客户数据库和在客户中推广服务台等；

• 日常维护管理

服务台可承载日常运作管理任务，包括数据备份与恢复、磁盘空间管理、用户口令管理等；

• 基础架构监控

利用相关工具对IT基础架构的运作情况进行监控，一旦检测到故障已经发生或即将发生，就应该立即评估这种故障对关键设备可能产生的影响，并在必要时将检测到的故障报告事故管理流程。

作为事件管理的有效实现手段，服务台是一种基于日志管理来记录事件并为业务（内部或外部）提供日常支持的服务平台；同时，它通过对流程，文档和岗位责任制的管理协调，来达到尽快解决事件的目的。它专注于处理出现在信息系统中或由用户报告的事件来尽快恢复服务的可用性，并管理和维系最终用户和服务提供者之间的日常服务接口。

3.3. 服务台角色与职责

3.3.1. 角色和职责

服务台主要提供帮助台和一线职责，其职责可包括：

• 一线支持与客户协调
• 记录，跟踪服务事件
• 事件进展的沟通（内，外）
• 事件影响的评估
• 分派，协调，升级事件
• 管理服务请求
• 客户/用户信息发布
• 沟通变更计划
• 提供管理信息

根据信息中心实际情况并结合ITIL，定义如下角色：

• 服务台经理
• 服务台人员

3.3.1.1. 服务台经理

职责：

• 确保服务台人员以良好专业知识和服务态度发挥服务台作用，提高用户的满意度。
• 负责管理服务台团队，监控和统计服务台的工作量和服务质量
• 协调和分配服务台人员日常工作，人员培训和能力建设
• 安排服务台值班人员
• 负责用户投诉的处理
• 配合事件，问题，变更，服务级别等流程经理的工作
• 制作管理报表

主要技能：

• 较强的口头表达能力和与客户沟通技巧
• 处理纠纷的能力
• 较强的领导能力
• 深刻了解服务台职能和其他IT服务管理流程
• 较强的组织和协调能力
• 具备一定企业管理知识

3.3.1.2. 服务台人员

职责：

• 通过与用户联系来注册交互。
• 将用户交互与突发事件、问题、已知错误或知识文档相匹配。
• 解决和关闭交互。
• 请求时向用户提供状态更新。
• 根据用户交互注册突发事件并将其分配到正确的支持组。
• 验证支持组提供的解决方案。
• 向用户报告解决方案并对其进行验证。
• 监控所有注册突发事件的服务级别协议 (SLA) 目标，并在必要时升级至突发事件分析员。
• 向所有用户通报服务中断的消息。

主要技能：

• 了解技术平台和技术环境
• 熟悉事件处理流程和服务台的职责
• 熟悉事件分类和每类派发人员
• 快速诊断事件和分类事件的能力
• 较强的人际沟通能力
• 较强的提问和倾听能力
• 良好的电话使用技巧
• 较强的记录技巧

3.4. 服务台组建原则

在组建服务台时，员工数量及类型决定于

• 服务的期望
• IT架构的复杂程度
• 客户的数量，电脑使用技能，以及客户的多样性 
• 事件的数量和紧急程度
• 事件的时间分布形态
• 服务级别协议/承诺
• 已有的人员技能， 流程以及工具

服务台人员结构应在实际使用过程中动态调整，此原则同样适用于今后服务台发展过程中对人员结构的考察

3.5. 服务台衡量标准

对于服务台服务工作的质量和绩效可以从以下指标考察：

• 电话接听率，接听电话的总量/ 用户拨入电话的总量 (需要其他设备记录拨入的电话数)
• 用户在线等待时间 
• 问题解决率 ，热线支持工程师在线解决的问题/ 总共接听的问题

• 用户满意度

还可以包括的一些指标包括：

• 电话的记录比率(需要其他设备记录拨入的电话数)
• 分配给突发事件分析员的服务请求
• 服务台接到的服务请求总数
• 优先级为最高的服务请求数量
• 结束的服务请求 (按照关闭代码分类)
• 超过解决期限x天仍未解决的服务请求
• 按服务呼叫类别统计的呼叫总数
• 事件平均解决时间（按优先级分类）

3.6. 服务台工具的功能

服务台的功能可能由一个或一组工具来实现，在使用工具实现服务台时应考虑以下方面的内容:

3.6.1. 呼叫管理

在服务台电话呼叫量大，人员多的情况下（比如人均每月的电话量超过200个电话），可以考虑使用电话自动分配系统 (ACD) ， 以达到：平衡电话分配，提供电话性能报告（如电话放弃比例，电话时长等），提供呼叫队列 状态信息的目的。

3.6.2. 知识管理

通过提供知识库，能够在服务台、突发事件分析员、系统管理员及最终用户间共享一些解决问题的关键信息，这些信息可以是一些临时的解决方案，脚本，补丁的参考信息，常见问题及答案等，并且能够按标题，现象等灵活查询。

3.6.3. 事件处理流程支持

事件处理流程是服务台支持的流程，它承接呼叫管理流程，完成新的服务请求或突发事件的处理。事件处理的工具需提供接受，跟踪和控制事件的界面，这就需要工具具备整合的事件/服务请求管理，配置管理， 服务级别管理的能力，应能做到：

• 对授权的用户可以访问到相应权限范围内的事件；
• 可以记录事件的状态；
• 可以记录事件的结果；
• 可以提供一系列的事件状态报告， 如按照事件类别，状态等

3.6.4. 客户沟通管理

与最终用户的沟通确认是一个很有价值的主动服务手段。它可以减少服务呼叫数量，降低服务台的工作量，节省人力。如果系统能自动为用户提供事件的状态，会大大改善服务台与用户之间的沟通。

3.6.5. 与监控管理工具集成 

服务台的事件管理工具提供与运营管理的监控工具集成的能力。

监控工具可以将告警事件自动输入到事件管理工具，并生成一个事件编号，自动的事件录入过程对事件管理工具有些隐含的要求：当服务台收到告警事件，需对其进行类别划分，优先级划分以及分派给合适的工作组，同时，要认定受影响的系统服务以及通过对配置管理数据库的搜索找出相关的配置项目；服务台坐席通过队列监控自动录入的事件管理系统；当事件被坐席关闭时， 最好能在监控系统中同时关闭事件。

由于网络监控工具日常发现的告警的数量较大， 为了保证服务台以及一线处理人员的工作效率， 需要 对监控工具转发到ITIL流程平台的告警进行精细的过滤。

4. 服务台用户交互流程设计

用户每次联系服务台都被记录为一次交互。用户交互管理是一个流程，用于处理用户与服务台的所有交互，这些交互通过邮件接收或直接通过服务台人员报告。交互类型可以包括用户报告的服务中断、服务请求、信息请求 (RFI) 或投诉。通过用户交互管理流程，可以轻松记录和解决简单的用户请求，并将其他请求升级为需要进一步操作的突发事件。

可以将多个用户交互链接到工具中的一个突发事件记录单。用户交互管理描述了注册新突发事件或变更时服务台需要执行的所有活动。服务台人员会执行必要的步骤并搜索相关知识记录、已知错误记录和现有突发事件或变更。

此流程简化了服务台活动，因此可以减少突发事件分析员的工作量。

4.1. 流程代码定义

流程代码是服务台交互、事件管理流程不可或缺的一部分，是对服务台交互、事件管理流程关键环节的详细描述的必要准备。本章节将详细描述：信息项、分类、影响度、优先级、状态、关闭等代码，这些内容将在流程的具体描述中使用。

4.1.1. 信息项

信息项定义的是交互、事件管理流程需要的所有信息项，主要如下

4.1.2. 类别代码

根据的业务要求和管理要求，定义如下四种类型：

4.1.3. 领域，子领域

根据信息中心业务系统架构的事件，服务请求，投诉种类，故障比进一步划分为领域，子领域。领域和子领域的划分采用信息中心现有的分类：

CIM:

Planning:

4.1.4. 影响范围代码

影响范围用于衡量事件所影响业务的范围。影响范围通常通过所影响的人数、关键系统数以及服务故障所造成的损失来设定。

定义事件影响度等级的因素有：

• 是否影响了关键应用
• 所影响的用户范围
• 服务失效的影响范围

下表是当前定义的影响度，后续可根据实际变化进行调整。

4.1.5. 紧急程度代码

紧急程度决定事件需要处理的急迫程度。

4.1.6. 优先级代码

优先级(Priority)决定了处理次序和期限。 期限可以在运行的过程中适当的调整，并且主要目的是通过升级的机制，让高层领导及时的了解在IT运维过程中发生的问题。优先级根据事件的影响度和事件的紧急度代码计算决定。算法为：优先级=[(影响范围+紧急程度)/2]. “[]”表示取整。

4.1.7. 状态代码 

状态代码表明事件所处的处理状态。

缺省的状态如下：

注意：以上各个状态是对整个事件管理流程中可能的状态的总结，一个具体事件处理过程中，可能只是经过其中的几个状态。

4.1.8. 关闭代码

关闭代码说明了事件是在何种情况下关闭的。

结合信息中心的实际，将采用如下关闭代码：

4.2. 服务台用户交互概要设计

服务台用户交互概要流程是根据华星光电IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与IT信息中心人员的共同讨论最终确定的。服务台用户交互概要流程主要从整体上描述用户交互的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能的输入和输出。

4.2.1. 流程图例说明

根据流程设计要求， 我们将服务台用户交互管理流程的设计标号以SO0开头，比如SO1.X.X。SO是Service Operation的缩写。

4.2.2. 概要流程描述

IT信息中心服务台用户交互管理概要流程具体如下：

描述如下：

4.3. 服务台用户交互详细设计

服务台用户交互管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合服务台用户交互流程代码，把整个服务台用户交互流程具体处理过程详细描述。

4.3.1. （SO1.1）用户自助服务

用户自助服务流程环节SO1.1的细化流程如下图所示：

描述如下：

4.3.2. （SO1.2）用户交互处理

用户交互处理流程环节SO1.2的细化流程如下图所示：

描述如下：

4.3.3. （SO1.3）关闭交互

关闭交互流程环节SO1.3的细化流程如下图所示：

描述如下：

5. 事件管理流程概述

5.1. 什么是事件管理流程

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

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

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

事件基于相关配置元素的关键等级和影响度进行优先级分类。

事件管理的责任是记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。

5.2. 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务系统的稳定性，本期建设目的包括： 

• 针对本期项目范围内的IT系统，在IT信息中心建立统一的事件管理流程
• 在成本允许的范围内尽快恢复服务
  • 快速响应服务请求（电话，监控系统，..）
  • 沟通问题解决的状态
  • 确认事件的解决和用户满意度
• 进行事件控制
  • 按规范记录事件
  • 就事件的优先级，紧急性和严重性进行分类
  • 分析，诊断，必要时进行升级
  • 监视并结束事件
  • 进行定期服务回顾
• 提供一个日常接口
  • 从一个用户面对多个服务接口，转向统一服务接口面向多用户
  • 提供关于服务状态的受理、信息更新等日常工作
• 提供IT管理信息
  • 人力资源利用情况
  • 服务故障
  • 支持效率

5.3. 管理范围

IT生产环境发生的所有IT事件，包括试运行期间的IT事件，用户报告的请求、询问、置疑、报障等，同时还包括由监控系统检测发现的IT事件。它们都将由事件管理流程进行处理。

本次事件管理的范围包括所有与IT基础架构和业务相关的如下事件：

• 突发事件

来源主要是用户电话告知、IT维护人员日常检查或监控系统发现的故障。

• 服务请求

具体如：软件安装、咨询、安全事件、功能需求、等。在整个流程中对于服务请求，主要是记录和跟踪，涉及到的审批（如：帐号申请）等，不在本流程范围之内。

不包括：

• 在开发和测试环境中的设备或系统产生的事件；
• 周期性、计划性的日常维护工作；

5.4. 主要内容

事件管理流程不一定必须找到问题发生的根本原因，着重于在IT信息中心快速解决IT环境中的事件，恢复已经中断的IT服务，并降低其对业务的影响度。主要活动包括记录事件、分派事件、找出解决方案和结束事件等。其流程内容如下： 

• 检测和记录

事件通过IT维护人员日常检查或系统监控软件检测出来，用户打电话进来通告或直接请求，所有事件记录进系统中。

• 判断并分派

服务台初步分析，确定是事件，还是服务请求。如果是服务请求，依照服务请求处理；如不是，进行事件的影响、收集信息等，并尝试解决。如果不能解决，升级到突发事件分析员。

• 调查和诊断

突发事件分析员支持人员利用自身技能和相关工具，力图在规定的时间内提出解决方案，尝试解决事件。必要时升级给厂商或集成商（统称为三线）

• 服务台确认

对事件的解决方案进行确认，如未解决，根据情况采取相应动作，如确认被否，需继续处理，转回原事件处理支持人员;如解决，则转至关闭记录。

• 结束 

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

• 定期产生报表

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

5.5. 业务价值

事件管理流程将在多方面对IT信息中心的IT服务产生积极作用，具体表现在：

• 提高服务可用性 

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

• 提高客户满意度 
• 集中化事件数据

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

5.6. 政策与建议

IT信息中心认识到建立以ITIL为指导的IT服务管理流程对公司IT运维的重要性和必要性，并能够支持所必要的IT服务流程、角色职责和服务质量考核的变革工作。

IT信息中心在具体的事件管理流程执行过程中，应能够遵守如下的流程政策：

• 规定1：

服务台是信息中心向用户提供的单一联系点(通过电话或Email)，包括接受故障申告， 回答产品咨询和分享信息等。

• 规定2：

任何用户要解决的问题不能绕过服务台来解决，所有需解决的突发事件要通过服务台提交。

• 规定3：

服务台所接受到的所有事件或服务请求及其解决方案，都要记录在服务台的事件管理系统中。

• 规定4： 

创立事件记录的服务台员工是该事件的责任人，必须确保事件、问题解决和质量管理得到有效跟踪与解决。根据事件管理流程，事件在传递以后，责任人就是当前的处理人员，但服务台员工需要负责跟踪此事件是否得到解决。

服务台将事件升级给二线后，被指派的人员同样有类似服务台的首问负责似的责任，即使事件以后被传递给三线或其他二线人员，首次被指派人员有责任跟踪该事件并与服务台沟通

在交接班时服务台人员如果没有处理完手中的工作，应该升级为突发事件，并分配给下一班值班长，由下一班值班长指定新的服务台人员跟踪处理

• 规定5：

在整个事件的解决过程中，应及时向提交问题的最终用户通报问题的处理情况，使用户可以知道事件的解决状态；通过主动式服务所处理问题的进度和情况也应由服务台员工与最终用户进行沟通。

• 规定6：

为了确保重要事件的及时解决，应严格执行重大事件升级流程。

• 规定7：

事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。

• 规定8：

事件必须在得到确认后，才能关闭记录。

• 规定9：

服务台应全面了解到内部变更的情况，包括近期完成的变更及变更计划的安排。

• 规定10：

服务台有责任通知最终用户变更的计划及变更实施的详细情况。

• 规定11：

定义和明确服务台及突发事件分析员的角色和责任，使人员明确自己的角色和相关的责任，流程能够得到正确的执行，保证服务的质量。

• 规定12：

明确定义服务台和事件管理的流程并进行归档，有章可寻，有制度可依，有流程可遵循。

• 规定13：

对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。

• 规定14：

规范事件处理的描述和记录。

• 规定15：

建立定期的服务回顾和检查制度，定义潜在的流程改进计划。根据流程的不断完善和对服务质量的提高，对服务台支持人员应该进行必要的培训工作。

• 规定16：

服务台应具备识别已知问题的能力，及完善的与问题管理功能衔接的接口。

• 规定17：

当事件经理不在岗位时，有相应人员代理执行其职责。

5.7. 与其它流程的关系​

• 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。如果优先级为一二级的事件，在事件解决并恢复服务后，必须做为问题进行进一步的分析和处理。

• 和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

• 和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。

• 和知识管理流程的关系

事件管理流程中成功解决事件的解决方案作为知识进入知识库， 供运维人员使用。

6. 事件管理流程设计

6.1. 前提约定

6.1.1. 概念约定

为了方便后续内容的理解，对一些比较关键的概念解释如下：

• “用户”

指的是XXIT信息中心内部的所有服务提供者（运维支持人员）和外部的所有服务使用者。

•  “客户”

指的是使用XXIT信息中心提供的各种服务的所有使用者。

• “IT维护人员”

指的是XXIT信息中心IT服务的提供者，具体来讲，就是运维部门的支持、运维人员；也包括第三方的支持人员。

• “角色”

角色是ITIL从实际工作中抽象出来的具体流程环节的执行者，具备一定的职能，被要求一定的能力，并设置相应的考核指标。

一个事件管理流程中可具备多种角色，如：用户、服务台（一线）、突发事件分析员（二线，三线）、事件经理等等，角色把流程要求的各个环节的工作合理的划分、细分，使得资源配置合理，进而流程执行起来更加流畅，并被有效的监督。

角色的划分使得工作责权明确，便于开展IT运维工作。

• “角色与具体IT维护人员关系”

角色的定义来源于具体的运维人员，但在流程设计和描述中与具体IT维护人员没有直接关系，即流程中描述的是每个角色的具体操作环节和角色之间的关系，在具体流程执行时，将会在具体IT运维人员与流程的角色之间做映射。

一般来说一个运维人员对应一个角色，根据实际的情况，一个具体IT运维人员也可以对应多个角色。如：一个IT运维人员负责日常检查，当发现问题的时候，作为“用户”需要马上电话通知“服务台”的人员记录和分配该突发事件，如果该IT运维人员负责问题发生的系统，那么又将以“一线”的角色开始处理问题。

• “流程设计”

基于ITIL的事件管理流程设计，是把XXIT信息中心实际情况作为输入，通过ITIL指导和加工处理，最终输出基于ITIL的符合XXIT信息中心实际情况的事件管理流程的过程。

一般来说，用户的输入是一个空白或已有的具体人员和流程混合在一起的实际流程。经过ITIL处理，把实际工作和人员抽象化，经过讨论和设计，变成与具体人员无关的角色和各种必需的操作环节结合体的流程；最终在流程执行时，把流程中的角色和具体的IT运维人员映射，具体IT运维人员再按照设计出来的流程执行。

整个输入、处理、输出的过程，是顾问和XXIT信息中心配合人员共同讨论完成的，这样有助于知识的转移和后续的流程自我优化。

• “变通方法”

“变通方法”是相对“根本解决方法”而言的，是指没有根本解决一个事件引起的故障，但恢复了事件影响的服务（或业务）的方法。“变通方法”定义本身也说明了：事件管理流程的目的是在规定时间内恢复服务（或业务），而不完全是针对事件本身。比如：用户不能够打印文档，只要提供一台备用打印机就可以恢复打印服务，用户原有的打印机还是故障状态。因此，具体事件管理流程执行时，需要把握好尺度：规定时间内，在服务（或业务）恢复的前提下，再尽可能的去完善方法。

6.1.2. 原则约定

(注：此处涉及的时间需要待服务级别流程确定后再更新，三天为示例)

事件关闭原则：

ITIL中要求，事件的建立和关闭都要由服务台进行，这就是事件管理的闭环原则。

事件的关闭原则具体描述如下：

1. 事件必须有责任人，一般情况下事件的责任人由服务台人员担任。
2. 事件必须由事件责任人关闭。
3. 采用两段式关闭策略，事件处理人员解决事件后，将状态改为“已解决”，相关服务台人员联系用户确认关闭，确保事件处理的闭包（Closed-Loop)
4. 对于确实因为条件不具备无法解决的事件或请求，用户坚持不同意的关闭的，升级给服务台经理和突发事件经理，服务台经理与事件经理协商后，联系用户解释后以关闭代码”无法解决”关闭。

结合IT信息中心的具体情况，定义了以下关闭事件的原则：

• 对于非重大事件，由服务台与用户确认并关闭问题。
• 对于重大事件，如特殊事件，可由具体重大故障负责人与用户直接确认，服务台直接关闭该事件。

为落实首问责任制中的事件跟踪、闭环规范，现给出事件闭环操作指导。

• 已在电话或邮件中与用户确认解决的事件

      规范的操作：关闭相应的交互单和突发事件单.    

• 给出了解决方案，但不确定一定解决，还未得到用户确认的事件

      规范的操作：

    （1）突发事件分析员将突发事件状态置为”已解决“。

    （2）服务台在事件”已解决”后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

• 服务台/突发事件分析员自己解决不了，传递给专家或者其他技术支持的事件

• 
  
  •   规范的操作：

     （1）事件传递后要确定责任人已收到事件传递的通知（确定方式包括但不限于邮件和电话），保证事件及时处理，并将联系技术支持处理的过程记录到活动历史中；

     （2）已收到”已解决“通知后，紧急或者影响大的事件（如：网络不通），要立即联系用户确认解决情况，确认解决后将事件闭环。其余事件必须在事件Resolved后的三个工作日内电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。

     （3）如果下班时紧急或者影响大的事件还未解决（如：网络不通），需在下班后将事件号和事件的当前进展通过邮件发送给下一班次的值班人员，并与下一班次的值班人员进行当面交接。

• 跟踪、闭环要求：

     （1）将每次跟踪的记录、用户确认解决的闭环信息必须写入活动历史中;

     （2）传递给别人的事件闭环后事件单关闭

备注：不限制跟踪的次数，关注闭环结果，除了联系不上用户外，其他在三个工作日内未闭环的均不合格。

重分配原则：

事件的重分配规则具体描述如下：

1. 事件的及时、正确分配和接受处理是确保事件在解决时限内解决的关键因素。
2. 一线和突发事件分析员可以根据重分配原则重新分配不属于自己运维范围的事件。

升级原则：

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案

1. 服务台/一线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理
2. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
3. 应遵从华星光电的事件升级通报规范

重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人、多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

• 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
• 如果服务台/一线支持判断到重复事件，则由服务台/一线支持需要将新建的交互单关联到已有的突发事件单

6.2. 事件通知与升级机制

事件升级的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

事件升级的分类：

技术升级，技术升级意味着会涉及更多的技术专家来帮助事件的解决， 这往往会涉及到不同的部门或小组，比如一个事件一开始分配给一线支持来解决，但一线支持的工程师在分析事件的过程中，发现需要突发事件分析员的网络专家来解决。 

管理升级，管理升级意味着公司或IT部门的管理层的介入， 这很有可能是由于资源不足或重大事件引起的。对管理层升级不代表需要管理层直接操作事件处理。

事件升级的方式：电话、邮件和短信等多种方式结合。其中电话确认是必须的。

无论是技术升级还是管理升级，需要通过合适的途径让服务台知晓。

升级规定请参考<<WI-IT-CIM-00011 信息中心IT故障管理规范Ver.01>>

6.3. 事件管理流程角色和职责

6.3.1. 角色和职责

根据XXIT信息中心实际情况并结合ITIL，定义如下角色：

• 事件经理
• 突发事件协调员
• 突发事件分析员（二，三线人员）
• 服务台经理， 请参见3.3.1.1
• 服务台人员，请参见3.3.1.2

6.3.1.1. 事件经理

职责：

• 确保有效协调资源，通过事件支持专家快速恢复正常服务。 
• 确保事件管理支持人员的适当技能水平和绩效表现。
• 确保和问题经理及外部供应商等部门的有效合作。
• 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
• 通过服务台的作用及良好的服务态度来确保客户的满意。
• 确保有关IT服务和客户支持的管理信息的可获得性。
• 确保流程满足实际的需要，角色职责明确，流程各环节合理
• 接收各方意见和建议，改进和提高事件管理流程的有效性和效率
• 制定和解释事件流程的相关内容
• 处理由突发事件协调员升级的突发事件

主要技能：

• 熟悉技术架构和技术环境
• 较强的领导能力
• 深刻了解事件管理流程
• 熟悉各个业务系统的运维
• 较强的流程规划和制定能力
• 较强的组织和协调能力
• 具备一定企业管理知识

6.3.1.2. 突发事件协调员

职责：

• 审核并接受或拒绝分配给支持组的突发事件。
• 处理由突发事件分析员升级的突发事件。
• 监控支持组的操作级别协议 (OLA) 和支持合同 (UC) 目标。

主要技能：

• 熟悉技术架构和技术环境
• 处理纠纷的能力
• 较强的领导能力
• 较强的组织和协调能力
• 熟悉突发事件分析员能力水平和日常安排
• 熟悉事件管理流程

6.3.1.3. 突发事件分析员

职责：

• 在规定的时间内解决事件（突发事件，服务请求等）
• 对利用“变通方法"解决的事件，在资源及时间允许时应找到问题根源或将之标记为”问题候选项”
• 必要时升级到三线或突发事件协调员
• 将事件的解决步骤文档化，并将解决方案录入服务台系统中
• 根据解决方案进行服务恢复
• 必要时现场支持

主要技能：

• 熟悉所负责的技术平台和技术环境.
• 很强的技术能力
• 较强的解决问题的能力
• 较强的分析能力

6.4. 事件流程代码定义

参见4.1， 事件流程与交互使用同样地代码定义有利于将交互直接升级成突发事件，保证两个模块直接信息的一致性。

6.5. 事件管理流程概要设计

事件管理概要流程是根据IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与IT信息中心人员的共同讨论最终确定的。事件管理概要流程主要从整体上描述事件的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能的输入和输出。

6.5.1. 流程图例说明

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

6.5.2. 概要流程描述

IT信息中心事件管理概要流程具体如下：

突发事件管理

描述如下：

6.6. 事件管理流程详细设计

事件管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合事件流程代码，把整个事件流程具体处理过程详细描述。

6.6.1.（SO2.1）突发事件记录

突发事件记录流程环节SO2.1的细化流程如下图所示：

描述如下：

注意：

• 事件创建的时候，将会遇到重复事件的问题。

重复事件一般可分为三类：一，同一个用户在处理时限内提交的重复事件；二，不同用户反映的同一个问题，并且第一个用户反映的问题还在处理时限范围内；三，超过处理时限，同一用户提交的重复事件。

一般来说，用户告知的事件都是要新建记录的，但对于不同具体情况，可选择不同的处理方式：

对于第一类，不用建立新的事件，但如果用户描述的现象与之前记录的内容不一致，还是新建；

对于第二类，如果能够确信几个用户描述确实是一个问题，可不新建，将之于现有交互或突发事件关联；

对于第三类，可不新建，此类情况应该可以避免发生，之前处理过程中，应该与用户主动沟通。

总的来说，建议服务台除非能够明确判断事件的重复性，否则还是新建事件。

如果是真正的重复，可以通过统计，分析出用户的实际忍受时限，便于优化处理时限；如果不是真正的重复，可避免故障的遗漏。

• 设置分配组和分配用户的原则

如果服务台人员不能解决， 则转给相应突发事件分析员（二线）进行处理；

• 事件通知

通过服务管理平台派发事件的方式，能够很好的记录日常处理的事件，但同时也会面临响应延迟的问题。响应延迟的问题主要体现在事件分配后，被分配人员因为某种原因，不能及时登录服务管理平台查询需要自己处理的事件，导致延迟处理事件。

响应延迟可能存在多种原因，如：正在处理一个事件；正在开会，不具备条件，不能够马上登陆服务管理平台察看并处理；正在休假；不能察看邮件等等。随着事件管理流程的执行，可能还会有其它的原因。但都不是流程能够解决的问题，需要制定管理制度，并有效执行才能解决。

当前为避免该问题发生的建议如下：

• 当前每次事件的分派前电话通知被分派人员，同时通过服务管理平台邮件；
• 如果被分派人员未联系上，直接联系突发事件协调员，由突发事件协调员协调处理；
• 及时更新各个系统具体负责的运维人员相关信息，并通知服务台人员。

后续随着事件管理流程的运转，通过服务台把各种情况记录下来，定期统计分析，发现响应延迟的根本原因，再进一步完善弥补响应延迟的措施。如果是管理制度不完善，如：休假制度、出差制度，则完善相应的制度；如果是资源配置不合理，如：工作量大但只有一个人负责，则合理增配运维人员。后续各个流程在分派响应问题上可参考此处描述，不再复述。

6.6.2. （SO2.2）突发事件分配/再分配

突发事件分配流程环节SO2.2的细化流程如下图所示：

描述如下：

6.6.3. （SO2.3）突发事件调查和诊断

突发事件调查和诊断流程环节SO2.3的细化流程如下图所示：

描述如下：

注意：

在事件处理中要注意最后期限的要求，并按照事件通知和升级机制， 通知相关人员。在以下处理过程中不再重复描述。

6.6.4. （SO2.4）突发事件解决与恢复

突发事件解决与恢复流程环节SO2.4的细化流程如下图所示：

描述如下：

6.6.5. （SO2.5）突发事件关闭

突发事件关闭流程环节SO2.5的细化流程如下图所示：

描述如下：

6.6.6. （SO2.6）突发事件升级

突发事件升级流程环节SO2.6的细化流程如下图所示：

描述如下：

6.6.7. （SO2.7）监控SLA

(注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)

监控SLA流程环节SO2.7的细化流程如下图所示：

描述如下：

6.6.8. （SO2.8）监控操作级别协议（OLA）和支持合同（UC）

(注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)

监控OLA和UC流程环节SO2.8的细化流程如下图所示：

描述如下：

6.6.9. （SO2.9）投诉处理

投诉处理流程环节SO2.9的细化流程如下图所示：

 描述如下：

7. 报表

有了有效的、适合使用的流程，还要加强相应的管理才能获得最佳效果。对于服务台、事件流程的管理分析主要集中在：呼叫、事件的分布和处理情况、流程运行效率、各角色执行效率、人员分布及技能水平情况等方面。管理者（事件经理和运维主管）需要综合这些信息适时的对流程、人员组织的情况进行动态调整，以持续改善、提高事件管理流程的效率和能力。