1. 综述

1.1 文档简介

本文档是XX公司和XX客户（以下简称XX客户）共同制定的事件管理流程的设计文档。通过该文档,可以帮助XX客户快速的解决IT环境的事件，为XX客户业务的快速发展提供更优质的IT服务。

本文档的内容是XX公司依据目前XX客户IT服务状况而制定的事件管理流程的说明，以后进一步的更新将由XX客户负责。

1.2 适用范围与对象

本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。

 1.3 重要参考资料

ITIL（IT Infrastructure Library ）V3.0。

《XX客户事件、变更级别说明》。

 1.4 相关术语

• ITIL（IT Infrastructure Library ）

是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。

• ISO20000

国际标准组织ISO/IEC在2005年底发布的全球IT服务管理标准，包括服务实施、控制、发布、解决、关系管理5个域13个流程，强调持续改进过程。ISO20000可以提供针对企业或部门的国际标准认证。

• 服务台（Service Desk）

服务台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。

• 事件管理（ Incident Management）

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

• 问题管理（Problem Management）

ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除根本原因从而使类似事件不再发生。同时问题管理流程也负责预防事件的发生。

• 配置管理（Configuration Management）

ITIL 流程之一，配置管理负责描述，跟踪和汇报IT基础架构中每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI)。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

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

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

• 变更管理（Change Management）

ITIL流程之一，变更管理通过控制和管理服务相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。

• 服务水平管理管理（Service Level Management）

服务级别管理流程通过签订和维护服务水平协议（SLA）的方式,确保以协定的质量和成本向客户交付既定的服务。同时该流程维护、监控和持续改进协定的服务级别。

• 日常运维管理（Operation and maintenance management）

日常运维管理用来支持运行维护人员需要定期重复或临时发起的，需要人工参与执行或检查的日常任务，使日常运维工作规范化，并最大程度实现自动化。 

• 知识管理（Knowledge management）

为日常使用、培训和丰富组织文化而设计的进行收集、组织、结构化和分发知识活动的集合，在整个服务生命周期中，通过提供充足、可信、可靠的知识，提升服务和组织决策的质量和效率。

2. 事件管理流程介绍

2.1 流程目的

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

2.2 流程主要内容

事件管理流程着眼于快速解决IT环境中的突发事件，并降低其对业务的影响度，流程内容如下： 

检测和记录  事件的主要来源包括监控系统自动上报和用户电话生成,所有事件都需要被记录。

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

服务台尝试解决  确定是否能由服务台解决，如果无法解决则由服务台分派给后线支持人员进一步诊断处理。 

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

服务台确认  对事件的解决方案进行确认，如未解决，根据情况重新分派。

结束   如果确认已解决，关闭记录，更新文档。

2.3 业务价值

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

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

提高客户满意度 – 事件管理流程通过记录和管理事件的集成系统来提供有效服务。同时，也提供了服务供应者和使用者的沟通渠道，加强了技术运维中心和用户之间的双向认同。

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

3. IT服务模式

XX客户的IT服务支撑工作由所内运维人员和外部厂商、服务商共同承担，按照职责和技能划分为服务台、一线、二线、三线的层级支撑结构，服务台作为面向用户的统一入口，主要负责事件的受理和分派；一、二、三线支持由所内技术人员和外部支持人员组成，负责解决事件。IT服务模式如下图所示：

4. 事件管理的策略与原则

4.1 常规原则

1. 服务台是IT部门向IT用户提供的单一联系点，(通过电话、邮件等)对事件进行集中响应；
2. 任何IT事件都必须执行事件管理流程。服务台提交事件单，所有事件或服务请求及其解决方案，都要记录在IT服务管理平台中；
3. 服务台是事件处理过程的监督人，负责跟踪事件的处理，确保事件能按时解决；
4. 定义服务台、一线支持、二线支持、三线支持人员，并落实到人员，使IT支持人员明确自己的角色和相关的责任，流程能够得到正确的执行，保证服务的质量，使IT人员变成服务人员。

4.2 沟通原则

1. 事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。在事件解决过程中，服务台应及时向最终用户通报事件的处理情况，使用户了解事件的解决状态；
2. 对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。

 4.3 事件升级原则

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

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

4.4 事件关闭原则

1. 事件的关闭遵循谁开单谁关闭的原则；（由IT用户申报的事件单，关闭必须由服务台完成）
2. 紧急程度较低的事件可设定自动关闭时间，在解决一段时间后由系统自动关闭。

 4.5 定期回顾原则

建立定期的服务回顾和检查制度。

1. 回顾本周期内的故障记录，分析是否需要提出问题；
2. 回顾正在进行中的故障（查看故障处理记录，工作日志、处理状态等等），分析是否存在优先级较高的待解决的故障，需要协调解决。

4.6 流程关联原则

• 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。 

• 和配置管理流程的关系

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

• 和变更管理流程的关系

服务台应了解变更管理流程中目前正在进行的变更信息。在事件的解决过程中，涉及变更都需要发起变更请求来解决事件。

事件的处理涉及启动变更流程RFC。

• 和知识管理流程的关系

常见故障的解决方案可以升级为知识，或用户常用的服务呼叫和技术咨询类的流程规范和操作手册等都将是知识管理流程的入口。

事件流程查询知识库知识信息，为事件处理提供支持。

4.7 紧急事件处理原则

当发生事件优先级为特大或者重大的事件后，服务台应立即通知事件经理，由事件经理通知相关领导共同协调相关资源，启动紧急事件流程（参见《大连商品交易所信息系统应急处置报告流程》），待事件处理完毕后再由事件处理人登陆系统补录事件信息。

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

XX客户事件管理流程设计的角色包含事件经理、服务台及一线、二线、三线支持。

5.1 事件管理流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程被正确执行。当流程不能够适应技术运维中心的维护要求时，流程负责人必须及时分析、找出缺陷、进行改进，从而实现流程的可持续提高。

职责：

1. 确保事件流程能够取得管理层的参与和支持；
2. 总体上管理和监控流程，对事件管理流程的规划、实施、监督、改进负责；
3. 保持与其他流程负责人的定期沟通；
4. 定期召开部门级别的流程回顾会议（如每个季度1次）；
5. 进行流程优化的发起，负责决定优化活动的负责人，并检查跟踪执行情况。

技能要求：

1. 深刻理解事件管理流程；
2. 理解业务对于事件管理的需求；
3. 良好的沟通技能，能够取得公司高层的支持，获得所需资源。

5.2 事件经理

事件经理负责事件解决过程中的协调和监控，事件升级的判断以及具体执行。

职责:

1. 负责协调资源，保证事件得到最终解决；
2. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题；
3. 确保和问题管理流程经理的有效合作；
4. 参与流程改进活动，提出流程改进建议。

技能要求:

1. 深刻了解事件管理流程；
2. 较强的领导能力；
3. 了解技术架构和技术环境；
4. 了解维护支撑架构和人员岗位分工；
5. 较强的口头表达能力和客户沟通技巧；
6. 处理纠纷的能力。

5.3 服务台

服务台人员负责接收所有事件，对事件进行初步处理，不能处理的事件分派到合适的一线支持或者二线支持人员。

职责：

1. 受理不同来源的事件，包括电话、邮件等；
2. 对事件进行分析和诊断，尝试提供解决方案；
3. 事件解决后，在关闭事件前向用户进行确认事件已解决；
4. 结束事件，更新信息。

技能要求：

1. 熟悉技术平台和技术环境；
2. 熟悉事件管理流程；
3. 熟悉维护支撑架构和人员岗位分工；
4. 良好的工作素养和服务态度；
5. 一定的技术能力；
6. 较强的沟通能力。

5.4 一线支持

一线支持人员负责对服务台分派的事件进行分析，提出解决方案，并在必要时提供现场支持。

职责：

1. 验证事件的描述，进一步收集相关信息；
2. 在规定的时间内解决事件；
3. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；
4. 根据解决方案进行IT服务恢复；
5. 向服务台人员提供必要的技术支持和协助；
6. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。

技能要求：

1. 熟悉技术平台和技术环境；
2. 较强的技术能力；
3. 较强的分析能力。

5.5 二线支持

二线支持人员是技术领域的专家。处理一线支持人员无法解决的事件，实施解决方案。

职责：

1. 验证事件的描述，进一步收集相关信息；
2. 在规定的时间内解决事件；
3. 在需要时及时利用其它资源(开发商, 厂家) 参与事件解决；
4. 根据解决方案进行IT服务恢复；
5. 向服务台人员提供必要的技术支持和协助；
6. 需要时根据解决方案发起变更请求RFC，监控变更请求过程并对解决结果进行确认。

技能要求：

1. 某项技术领域的专家；
2. 资深技术背景和技术能力；
3. 较强的分析能力。

5.6 三线支持

对于XX客户运维中心来说，三线支持主要是外部厂商，在事件处理流程中，由一线或二线支持专家，来协调三线人员协助处理事件。

职责：

1. 验证事件的描述，进一步收集相关信息；
2. 在规定的时间内解决事件；
3. 负责协调厂商、开发商内部资源；

技能要求：

1. 熟悉术平台和技术环境；
2. 相关技术领域专家；
3. 较强的分析能力。

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

 6.1 事件单信息项

 6.2 任务单信息项

维护任务单包含如下信息项：

6.3 所属系统

6.4 事件分类

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

6.5 影响度、优先级

通过事件的“影响程度”来评估每个事件的“优先级”。 

• 优先级

• 影响程度

6.6 优先级和解决时限

对于不同的事件优先级，事件处理的解决时限要求和响应时限要求不同。

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

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

6.7 事件通告路径

对于特大和重大的事件，需要及时通告事件经理。如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。具体定义如下表：

超出和即将超出时限的通告定义

 6.8 事件状态

 6.9 事件结束代码

6.10 事件来源

6.11 事件支持满意度 

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

事件管理概要设计流程说明：

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

8.1 (100.1)事件记录和分类

流程描述如下：

 8.2 (100.2)初始事件支持

 流程描述如下：

8.3 (100.3)（100.4） 一、二线尝试解决

流程描述如下：

 8.4 (100.3.5) 子任务分派

8.4.1 (100.3.5.1)分派任务子单

具体描述如下：

8.4.2 (100.3.5.2)任务处理

具体描述如下：

8.4.3 (100.3.5.3)关闭任务单 

具体描述如下：

 8.5 (100.5)三线尝试解决

 流程描述如下：

8.6 (100.6)记录解决方案细节

流程描述如下：

 8.7 (100.7)关闭事件

流程描述如下：

8.8 (100.8)事件处理监控

流程描述如下：

9. 事件管理流程关键指标

为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

10. 流程持续改进机制

运维流程必须经过持续地调整和优化，才能满足不断变化的业务及服务要求。流程的持续改进的具体方法，可以参考上述流程持续改进模型。

• 评估及改进研讨
  • 根据设定的ITSM基准线对流程的原则与目标、流程责任与授权、管理目标达成情况、与其他流程的关联及相关流程工具等方面进行评估；
  • 根据评估结果，通过研讨，发现已在或潜在的差距和风险，并针对这些差距和风险提出改进建议。根据改进建议的实施成本、风险和耗时等因素，对改进建议进行优先级别排序；
  • 改进原因还可能来自于日常服务管理工作中发现的不足；
  • 生成评估结果及改进建议方案。
• 制定流程改进计划
  • 分析改进建议的相关性，并进行有效合理的分类和组合；
  • 针对不同的改进建议组制定具体的改进计划，将具体的改进计划分解成更详细的改进任务和动作，定义改进时间点、责任人、改进成功条件等；
• 实施具体的改进活动
  • 根据改进计划的要求，实施具体的流程改进活动；
  • 跟踪改进活动，及时更新改进计划，并上报改进活动进展及成果；
• 根据业务及服务变化，进行定期评估
  • 根据业务及服务的变化，对事件管理流程进行相关性评估，以满足业务和服务需求；
  • 除业务及服务变化可触发流程评估外，流程负责人还应定期组织对管理流程的评估和改进；

定期生成流程改进报告（如季度或半年度）。