1. 综述

1.1文档目的

本文档是结合XX移动网管中心IT集中运维管理的特点，制定的事件管理流程设计报告。本文档的目的是分析XX移动网管中心事件管理流程的现状和存在的问题；针对XX移动网管中心IT集中运维管理发展需要和日常维护需求，设计事件管理流程。

本文档是依据目前XX移动网管中心的IT集中运维管理发展需要和日常维护需求而制定的，以后进一步的更新和优化将由浙江移动网管中心IT维护室负责。

1.2 相关术语

• 事件

指包括任何使服务中断或可能使服务中断的事件； IT 服务的意外中断或 IT 服务质量的下降。尚未影响服务的配置项失效也是事件，如镜像组中一块磁盘的失效。

• 告警工单

指通过告警管理平台标准化处理过以后的告警信息，并由此产生的事件工单。 

• 紧急事件

指由于影响范围和紧急程度都非常高的事件，此类事件可以通过紧急事件处理流程进行解决，待解决后再进行补填工作单。

2. 目标和范围

2.1 目标

1. 尽快解决事件，提升IT技术支持的效率，减小对业务的影响。
2. 客观准确记录工作，辅助IT维护室领导了解IT运维状况，促进IT运维的持续改进。
3. 对事件处理进行全过程跟踪，进行有效控制。

2.2 范围

1. 业务范围：IT维护室纳管设备所属业务系统相关的IT事件。
2. 专业范围：IT维护室各专业组所负责的领域，包括：服务器、刀片、Oracle、Informix及其他数据库、网络、存储六个专业方面的故障处理。

3. 事件管理流程

3.1 流程概要设计

事件管理概要流程图如下：

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

3.2 流程详细设计

3.2.1 事件受理子流程

流程描述如下：

3.2.2 事件处理子流程

流程描述如下：

3.2.3 事件关闭子流程

流程描述如下：

3.2.4 监控告警事件子流程

流程描述如下：

3.2.5 紧急事件子流程

流程描述如下：

3.3 角色与职责

3.3.1 事件管理流程负责人

主要职责：

1. 确定事件管理流程的衡量指标;
2. 确保事件管理流程符合IT维护室实际状况和发展战略;
3. 在总体上管理和监控流程，建立事件管理流程实施、评估和持续优化机制;
4. 确保事件管理流程实用、有效、正确地执行;
5. 保持与其他流程负责人的定期沟通。

技能要求：

1. 拥有多年IT运维经验； 
2. 精通ITIL最佳实践； 
3. 全面了解IT维护室的业务情况和组织架构； 
4. 了解事件管理的相关规则和制度； 
5. 具有良好的管理和协调能力。

3.3.2 事件经理

主要职责：

1. 确保事件流程能够取得管理层的参与和支持;
2. 对事件的挂起协办等请求进行审批； 
3. 负责对事件的解决协调资源，保证故障的最终排除;
4. 当事件优先级为紧急或者超过规定的时限，负责对事件处理进行督办，并协调资源，督促快速恢复正常服务;
5. 确保和问题经理的有效合作;
6. 正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。

技能要求：

1. 拥有多年IT运维经验； 
2. 精通ITIL最佳实践； 
3. 全面了解IT维护室的业务情况和组织架构； 
4. 了解事件管理的相关规则和制度； 
5. 具有良好的沟通能力和准确表达能力； 
6. 具有良好的管理和协调能力；

3.3.3 事件受理人

主要职责：

1. 创建新的事件单,完整记录所接收的事件信息，包括：记录事件报告人的详细联系方式、事件表现、描述、发生时间等； 
2. 帮助事件提交人创建事件单； 
3. 查询解决方案，尝试解决事件； 
4. 将紧急事件提交至事件经理； 
5. 将事件工单分配至合适的处理人员； 
6. 跟踪、监督、督促事件的解决过程； 
7. 将超时事件升级至事件经理； 
8. 根据事件单处理结果关闭事件。

技能要求:

1. 具备相关的IT专业技能； 
2. 熟悉ITIL最佳实践； 
3. 具有良好的沟通能力和准确表达能力； 
4. 全面了解IT维护室业务情况和组织架构。

3.3.4 事件处理人

主要职责：

1. 响应事件的分派;
2. 验证事件的描述和信息，与用户直接进行沟通，补充相关信息； 
3. 对于事件进行处理，包括分派、等待、接单、解决等操作； 
4. 为第三方厂商提供未解决事件的解决过程和测试结果记录； 
5. 提交事件/告警解决方案； 
6. 为无法找到根本原因的事件创建问题单，并提交问题单；

技能要求：

1. 具备专业IT运维能力； 
2. 拥有多年IT运维经验； 
3. 熟悉ITIL最佳实践； 
4. 全面了解IT维护室的业务情况和组织架构； 
5. 了解事件管理的相关规则和制度； 
6. 具备强大的专业运维技能； 
7. 具有良好的沟通能力和准确表达能力；

3.3.5 第三方厂商

主要职责：

• 验证事件的描述和信息，进一步收集相关信息； 
• 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动； 
• 提供有效的解决方案； 
• 执行解决方案，并关闭事件单；
• 更新事件解决过程信息。

技能要求：

• 具有专业的IT技能和问题处理能力。

3.4 角色人员映射列表 

4. 流程执行原则

4.1.1 常规原则

1. 所有IT维护室业务范围内发生的故障，都应该记录在事件管理流程平台中，记录的信息应足够详细，包括故障处理交互过程，详细的解决方案和相应的附件。
2. 每月将事件管理相关指标生成报表，并对所发生的故障及处理过程进行总结和评估。
3. 每半年对事件管理流程进行评估和改进。

4.1.2 受理原则

1. 受理时，事件受理人判断是否属于IT维护室管理范围，如果不属于，则退回。
2. 受理时，判断是否需要人为处理，如果不需要则直接退回，如果需要，录入事件单。
3. 判断事件级别，如是紧急事件，则进入紧急事件子流程；
4. 监控告警工单的事件受理工作，由监控告警管理人员执行。

4.1.3 预处理原则 

1. 事件受理人在接到机房值班、巡检、和业务反馈的事件工单时，需要首先参考现有处理方案或经验，进行预处理。
2. 如果预处理后故障未恢复或者无法处理，则进行首次分派。
3. 如果预处理后，故障消失或者相关告警解除，则进行工单关闭。

4.1.4 分派原则 

1. 事件受理人可以将工单分派给事件处理人。
2. 同一专业组内的事件处理人可以将工单再分派一次，不同专业组之间转派工单，需要先转回事件受理人，再由事件受理人分派至其他专业组事件处理人。
3. 事件工单默认发送给专业组内所有人员，同时指定第一处理人和第二处理人，原则上第一处理人优先负责处理，在第一处理人无效情况下由第二处理人负责处理
4. 在试运行阶段，工单派给事件的第一处理人时，如果处理人无法处理，可以将工单继续分派给其他事件处理人，并且对分派不做限制。
5. 监控告警自动生成工单需按照告警中的业务或者专业方面的负责人信息，准确进行派发。
6. 节假日的所有告警生成事件单派发至负责人时，需增加短信息提醒，对于优先级为高和极高的事件工单，进行电话通知。

4.1.5 所有权原则 

1. 所有用户都可以提交事件申请。
2. 事件工单的责任人是事件受理人，负责跟踪事件处理的全过程。

4.1.6 重复事件原则 

1. 同一故障由于多次上报，而导致的多个事件单，需要标识，并合并处理与关闭。
2. 同一故障（相同症状）的多次发生（三次以上），必须生成问题，并提交问题单。
3. 属于重复事件的多个事件单，当其中任一事件单关闭时，其余重复关联的事件单同时关闭。

4.1.7 升级原则 

1. 如果确认事件为紧急事件，则立即升级到事件经理，并由事件经理通知相应的管理层，由事件经理启动紧急事件处理流程。
2. 如果事件单超出了解决时限，通报事件经理，由事件经理协调资源并督促事件解决。
3. 如果事件处理过程中，由于客观原因（例如等待备件等）需要申请将事件单挂起。
4. 事件升级需要事件经理的确认，否则不允许进行升级。
5. 事件受理人负责提醒和督办超时或已超时的工单，当工单处理时限还剩1小时，通过邮件和短信息的形式对事件处理人进行提醒，并监督剩余处理进程；当到达工单处理时限时，通过邮件、短信息和电话通知事件处理人，并由事件经理督办。
6. 可以通过督办解决的事件单，不允许挂起。

4.1.8 关联原则 

1. 事件解决过程如果需要变更操作，则关联变更管理流程，进行变更处理。
2. 标识为重复事件和紧急事件的事件单，应创建或关联问题单，并关联到问题管理流程。
3. 事件单转入变更流程时，需要得到事件经理的确认。
4. 事件处理过程中，所有涉及风险的操作，全部通过变更管理流程执行。
5. 当事件处理结束，但业务尚未恢复时，由事件经理决定是否允许将工单转入问题管理流程。
6. 当事件工单转入其他流程进行处理时，工单自动挂起。
7. 通过变通方式解决和未解决的事件单，应创建或关联问题单，并关联到问题管理流程。
8. 属于同一故障源的事件工单应进行关联，并标记为重复事件。 
9. 由于现阶段系统平台限制，暂不对关联工单进行自动化处理。

4.1.9 关闭原则 

1. 事件单的关闭前，需要得到事件提交人的确认。
2. 事件单的关闭代码若为成功解决，必须有具体的处理措施。
3. 事件单由事件受理人负责关闭。
4. 处理结果包含完整填写的处理工单各个字段以及必要的解决方案或者处理报告附件。
5. 如果事件单未解决并关闭，需要由事件经理进行确认。
6. 来自告警自动派单的事件单，由事件处理人报结，由监控管理人员确认关闭。

4.1.10 典型事件原则

1. 首次发生，且没有完善的标准处理方法。
2. 与业务或者其他类型设备有较强的关联性。
3. 有较重大或重大的潜在风险。
4. 符合以上条件的事件单均需要提交事件处理报告，请参考模板。

4.1.11 持续改进原则 

1. 流程负责人负责每半年对事件管理流程的执行情况进行评审，提出改进建议和方案。
2. 每周召开例会，对事件管流程的KPI报表进行讨论，提出改进建议。
3. 每月召开例会，与其他各流程经理讨论并调整影响服务效率和质量的因素。
4. 事件经理在例会中组织针对典型事件进行讨论，并制定标准解决方案。

4.1.12 紧急事件判定原则

1. 已经产生重大经济损失的事件。
2. 对于已经严重影响生产系统的事件。
3. 事件的紧急程度极高，必须在7X24小时范围内立即进行处理。
4. 满足以上条件的事件为紧急事件，必须进入紧急事件流程进行处理。

4.1.13 紧急事件处理原则 

1. 来自监控管理人员电话通知的紧急事件，需要告知事件经理，同时按照紧急事件处理流程进行线下处理。
2. 所有紧急事件可以进行线下处理，处理完毕后，由事件受理人根据处理情况进行补充记录。
3. 紧急事件执行首问责任制，即首先接到事件的人负责整个事件的处理过程。

5. 基础数据定义

5.1.1 事件来源

5.1.2 事件分类

业务系统分类：

5.1.3 事件影响度

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

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

1. 是否影响了关键/核心业务；
2. 所影响的用户范围；
3. 服务失效的影响范围。

5.1.4 事件紧急度

5.1.5 事件优先级

事件优先级定义了事件优先获得资源并得到处理的优先顺序。事件优先级是与事件影响度和紧急度是相互对应的，其决定了事件的最终处理期限。

5.1.6 事件状态

5.1.7 事件挂起

5.1.8 事件单响应和解决时限

5.1.9 关闭代码

6. 表单设计

7. 关键流程衡量指标

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

8. 附录：高紧急度事件参考表

8.1.1 刀片服务器类

8.1.2 网络类

8.1.3 存储类

8.1.4 Oracle数据库类

8.1.5 Informix数据库类

8.1.6 主机类