400-8615-123 
事件管理流程是ITIL主要流程之一，它的主要目标是尽快解决日常工作环境中出现的事件，保持IT服务的稳定性，监控事件的发展，并在事件得到解决之后将其关闭。
事件流程我们需要了解一常见术语：
术语 | 定义 | |
1 | 事件 | 服务的意外中断或服务质量的下降。尚未影响服务的配置项失效也是事件，例如镜像组中一块磁盘的失效。 |
2 | 服务请求 | 用户对信息、建议、标准变更或服务访问的请求。例如重置密码、为新用户提供标准的服务。服务请求通常由服务台处理。 |
3 | 重大事件 | 对业务有重大影响的事件，重大事件将导致重要业务的中断。一般事件影响度或优先级为1级的事件默认定义为重大事件。 |
4 | 升级 | 在需要时获得额外资源，以达到服务级别目标或客户期望的活动。任何服务管理流程内部都可以升级，但是升级常常与事件管理、问题管理和有关客户投诉的管理有关联。主要有两种类型的升级：技术升级和管理升级。 |
5 | 管理升级 | 通知更多的高级管理人员或使他们参与解决疑难问题升级。 |
6 | 技术升级 | 将事件、问题或变更转给具有更高技术的小组，以便进行疑难问题升级。 |
7 | 响应时间 | 一种衡量完成运营或交易所需时间的指标，在性能管理中一般用于测量 IT 基础架构的性能，但在事件管理中主要用于测量接起电话或开始诊断的时间。 |
8 | 目标解决时间 | 为了更好的控制事件、变更等流程的整个处理过程，将处理过程被划分成几个阶段，并对每个阶段的完成时限设定了目标，即目标解决时间。 |
9 | 紧急度 | 测量事件、问题或变更多久会对业务产生重大的影响。例如，如果事件到年底才会影响业务，则影响大的事件可能紧急程度较低。指定优先级时要考虑到影响度和紧急度。 |
10 | 影响度 | 事件、问题或变更对业务流程影响的一种测量，影响度通常基于服务级别会如何受影响。指定优先级时要考虑到影响度和紧急度。 |
11 | 优先级 | 用于确定事件、问题或变更的相对重要性的类别。优先级的依据是影响度和紧急度，用它来确定采取行动所需的时间。例如 SLA 可以规定：优先级 2 的事件必须在 12 小时内解决。 |
12 | 挂起 | 事件、变更等流程可能因非技术原因而无法进行下去，此时可以暂停计算流程处理时间，挂起的目的在于更加公正的统计流程处理时间等与流程处理人员相关的指标。 |
13 | 临时措施 | 也称“变通方案”，在还没有完全的解决方法时，减少或消除事件或问题的影响。例如重新启动发生事件的配置项。 |
14 | 知识管理 | 负责收集、分析、保存和共享组织内部的知识和信息的流程。知识管理的主要目的是通过减少重新发现知识的需要，从而提高效率。 |
15 | 知识库 | 一个逻辑数据库，其中包含了服务知识管理系统使用的数据。 |
事件流程中的主要角色和职责的说明：
角色 | 职责描述 | 对应岗位 |
报障人 | l 向服务台提交所发现的需要处理的事件。 l 与服务台确认事件处理结果。 | 所有可以发起事件的人 |
服务台 | l 接听热线电话，响应用户报障需求，对用户进行初步相应的指导解决。 l 响应用户通过邮件、微信以及手机APP等方式的报障需求。 l 快速响应报障需求，为用户提供高效的远程服务。 l 及时联系现场工程师为用户提供服务。 l 及时联系二线支持人员为用户解决问题。 l 在ITSM平台中准确并及时录入事件信息。 l 对事件进行全程跟进，直到解决。 l 负责在事件解决后生成问题单或录入知识库（FAQ）。 | 客服 |
二线指派工程师 | l 响应服务台派出的事件单，提供现场服务，包括备件更换安装服务。 l 在ITSM平台中准确并及时录入事件处理详细信息。 l 需要时发起服务请求单或变更单。 l 负责升级必要的事件到三线工程师或者供应商。 l 负责在事件解决后生成问题单或录入知识库。 | |
三线指派工程师 | l 响应二线工程师升级的工单，提供现场服务，包括备件更换安装服务，系统支持服务，工程服务等。 l 在ITSM平台中准确并及时录入事件处理详细信息。 l 需要时发起变更单。 l 负责在事件解决后生成问题单或录入知识库。 | |
供应商 | l 负责响应由二线或三线升级的事件单。 l 对事件单信息进行分析，并提供相应的解决方案。 | 外部设备供应商与服务提供商。 |
事件经理 | l 设计和改进事件管理流程。 l 设定事件管理的绩效指标并考核指标完成程度。 l 跟踪、监控各事件流转状态，抽查事件记录。 l 收集汇总流程信息，编制管理报告，反映存在问题，提出改进建议，制定改进计划。 | |
分管领导 | l 接收事件经理升级的重大事件。 l 必要时与事件经理共同跟进重大事件，协调资源。 l 审批重大事件报告。 | |
整体流程总共三大阶段：识别记录、调查诊断、解决关闭，各阶段详细说明如下：
一、事件识别与记录
步骤名称 | 责任人 | 说明 | |
1.1 | 提交事件 | 报障人 | 报障人通过电话、微信、邮件或手机APP来进行报障。 |
1.2 | 识别和记录 | 服务台 | 服务台在ITSM平台中进行事件信息的记录，包括用户联系方式、事件描述、事件分类分级等； 若用户通过非电话的方式进行报障，服务台工程师可电话联系用户进行更多信息的确认和收集。 |
1.3 | 通知事件经理 | 服务台 事件经理 | 若事件级别判断为一、二级事件，需要升级至事件经理需要跟进事件的处理过程； 同时事件经理需要上报分管领导。 |
二、事件调查与诊断
步骤名称 | 责任人 | 说明 | |
2.1 | 初步处理 | 服务台 | 服务台对事件进行初步处理，进行远程调试或指导。 |
2.2 | 是否可以解决？ | 服务台 | 若可以解决，则直接处理解决，并进入3.2，与用户确认是否恢复； 若无法解决，则进入2.3寻求二线支持。 |
2.3 | 二线支持团队调查诊断，寻找解决方案 | 二线工程师 | 二线支持团队接受服务台升级的事件，并判断是否需要进行内部转派，如需要则说明转派理由，并进行转派，如不需要则对事件进行分析和处理，处理过程需要及时更新到平台中； 若需要执行变更，则触发变更管理。 |
2.4 | 是否找到解决方案？ | 二线工程师 | 若是，则进入2.5 是否需要发起服务请求管理； 若否，则进入2.6寻求三线支持； 若否，则进入2.8 寻求供应商支持。 |
2.5 | 是否需要发起服务请求管理 | 二线工程师 | 找到解决方案后，是否需要继续发起服务请求管理，寻求彻底解决： 若需要执行服务请求，则发出服务请求管理 若不需要，则进入3.1 事件解决。 |
2.6 | 三线支持团队调查诊断，寻找解决方案 | 三线工程师 | 三线支持团队接受二线升级的事件，对事件进行分析和处理，处理过程需要及时更新到平台中； 若需要执行变更，则触发变更管理。 |
2.7 | 是否找到解决方案 | 三线工程师 | 若是，则进入3.1 事件解决； 若否，则进入2.8寻求供应商支持。 |
2.8 | 供应商团队诊断调查，寻找解决方案 | 供应商 | 供应商接收来自二线和三线对的事件，并对事件进行分析诊断，给出最终解决方案。 |
2.9 | 提交解决方案 | 供应商 | 供应商将解决方案提交给相应的升级人员，由其去解决事件，并进入3.1 事件解决 |
三、事件解决与关闭
步骤名称 | 责任人 | 说明 | |
3.1 | 事件解决 | 二线工程师、三线工程师 | 将事件的解决结果及时更新至平台中，并标记解决，必要时发起问题工单进一步分析，或发起服务请求单完成临时解决后尚需进一步完善的遗留状态，或将事件总结生成知识库条目。 |
3.2 | 是否恢复？ | 服务台 | 服务台与用户确认事件的恢复结果。 |
3.3 | 填写用户反馈和满意度 | 服务台 | 将用户反馈和满意度调查情况更新至平台中，并关闭工单。 |
