文档更改14 某公司IT服务管理ITIL服务台和突发事件管理流程设计分册

由 superadmin 于 2024/10/29, 10:10 最后修改

从版本< 24.1 >

由superadmin编辑
在2024/10/29, 10:08上

到版本

由superadmin编辑
在2024/10/29, 10:07上

< >

修改评论上传新附件1730167651416-536.png

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -751,783
          +751,4 @@
  [[image:图片2.jpg]]
--描述如下：
--
--|**序号**|**步骤名称**|**责任人**|**流程描述**
--|SO1.3.1|检查解决方案的完整性|服务台人员|服务台人员检查交互的解决方案。
--|SO1.3.2|服务台人员是否接受解决方案？|服务台人员|如果是，请转至 SO1.3.4。如果不是，请转至 SO1.3.3。
--|SO1.3.3|重新打开突发事件| |服务台人员将重新打开突发事件记录以进行深入调查和诊断。
--|SO1.3.4|是否向用户回电？|服务台人员|如果用户想要通过电话得到通知，请转至 SO1.3.6，否则请转至 SO1.3.5。
--|SO1.3.5|向用户发送电子邮件通知|服务台人员|用户会自动接收到交互关闭的电子邮件,用户可以检查此解决方案，并可以在两周内拒绝此解决方案。
--|SO1.3.6|通过用户验证解决方案|服务台人员|服务台人员会联系用户并传达解决方案。用户应当验证此解决方案并确认已解决突发事件、已对问题或投诉作出回答或已执行服务请求。
--|SO1.3.7|用户是否接受解决方案？|服务台人员|如果是，请转至 SO1.3.9。如果不是，请转至 SO1.3.8。
--|SO1.3.8|重新打开或重新创建突发事件|服务台人员|提供的解决方案可能无法解决所有用户的问题。如果解决方案无法解决所有用户的问题，服务台人员必须重新打开现有突发事件或创建新的突发事件，然后关联未解决的交互。
--|SO1.3.9|关闭交互|服务台人员|服务台人员关闭交互。
--
--=   =
--
--=   =
--
--= **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. 与其它流程的关系** ==
--
--[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml516584\wps1.png]]
--
--(% style="text-align:center" %)
--[[image:图片3.jpg]]
--
--* 和问题管理流程的关系
--
--事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势。如果优先级为一二级的事件，在事件解决并恢复服务后，必须做为问题进行进一步的分析和处理。
--
--* 和配置管理流程的关系
--
--需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
--
--* 和变更管理流程的关系
--
--服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
--
--* 和知识管理流程的关系
--
--事件管理流程中成功解决事件的解决方案作为知识进入知识库， 供运维人员使用。
--
--=   =
--
--
--= **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. 事件必须有责任人，一般情况下事件的责任人由服务台人员担任。
--1. 事件必须由事件责任人关闭。
--1. 采用两段式关闭策略，事件处理人员解决事件后，将状态改为“已解决”，相关服务台人员联系用户确认关闭，确保事件处理的闭包（Closed-Loop)
--1. 对于确实因为条件不具备无法解决的事件或请求，用户坚持不同意的关闭的，升级给服务台经理和突发事件经理，服务台经理与事件经理协商后，联系用户解释后以关闭代码”无法解决”关闭。
--
--结合IT信息中心的具体情况，定义了以下关闭事件的原则：
--
--* 对于非重大事件，由服务台与用户确认并关闭问题。
--* 对于重大事件，如特殊事件，可由具体重大故障负责人与用户直接确认，服务台直接关闭该事件。
--
--**为落实首问责任制中的事件跟踪、闭环规范，现给出事件闭环操作指导。**
--
--* 已在电话或邮件中与用户确认解决的事件
--
--      **规范的操作：**关闭相应的交互单和突发事件单.
--
--* 给出了解决方案，但不确定一定解决，还未得到用户确认的事件
--
--      **规范的操作：**
--
--    （1）突发事件分析员将突发事件状态置为”已解决“。
--
--    （2）服务台在事件**”已解决”后的三个工作日内**电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。
--
--* 服务台/突发事件分析员自己解决不了，传递给专家或者其他技术支持的事件
--
--   **   规范的操作：**
--
--     （1）事件传递后要确定责任人已收到事件传递的通知（确定方式包括但不限于邮件和电话），保证事件及时处理，并将联系技术支持处理的过程记录到活动历史中；
--
--     （2）已收到”已解决“通知后，紧急或者影响大的事件（如：网络不通），要立即联系用户确认解决情况，确认解决后将事件闭环。其余事件必须在事件**Resolved后的三个工作日内**电话或邮件联系用户，确认事件解决情况，用户确认解决后，将事件闭环。
--
--     （3）如果下班时紧急或者影响大的事件还未解决（如：网络不通），需在下班后将事件号和事件的当前进展通过邮件发送给下一班次的值班人员，并与下一班次的值班人员进行当面交接。
--
--* 跟踪、闭环要求：
--
--     （1）将每次跟踪的记录、用户确认解决的闭环信息必须写入活动历史中;
--
--     （2）传递给别人的事件闭环后事件单关闭
--
--备注：不限制跟踪的次数，关注闭环结果，除了联系不上用户外，其他在三个工作日内未闭环的均不合格。
--
--**重分配原则：**
--
--事件的重分配规则具体描述如下：
--
--1. 事件的及时、正确分配和接受处理是确保事件在解决时限内解决的关键因素。
--1. 一线和突发事件分析员可以根据重分配原则重新分配不属于自己运维范围的事件。
--
--**升级原则：**
--
--制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案
--
--1. 服务台/一线支持应及时将不能解决的事件升级到其后一级的支持人员，若未及时升级，事件经理应及时介入，负责协调升级处理
--1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台应将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
--1. 应遵从华星光电的事件升级通报规范
--
--**重复事件原则**
--
--重复事件是指在一个较短时间段（通常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信息中心事件管理概要流程具体如下：
--
--突发事件管理
--
--(% style="text-align:center" %)
--[[image:图片4.jpg]]
--
--
--描述如下：
--
--|**序号**|(% style="width:121px" %)**步骤名称**|(% style="width:163px" %)**责任人**|(% style="width:994px" %)**流程描述**
--|SO2.1|(% style="width:121px" %)突发事件记录|(% style="width:163px" %)服务台人员|(% style="width:994px" %)突发事件将根据其来源和性质作为交互管理流程的一部分或事件管理流程的一部分启动和记录。如果突发事件是通过服务台人员记录的，则大多数突发事件详细信息都已在交互记录中提供。如果突发事件由操作员记录，并且通常使用系统管理工具，则操作员可以根据适用的突发事件模板记录突发事件。
--|SO2.2|(% style="width:121px" %)突发事件分配|(% style="width:163px" %)服务台人员/突发事件协调员|(% style="width:994px" %)突发事件协调员监控突发事件队列，审核处于打开状态的突发事件，并根据提供的信息确定是接受还是拒绝突发事件记录。接受突发事件记录后，会将其分配给突发事件分析员以进行进一步调查和诊断。
--|SO2.3|(% style="width:121px" %)突发事件调查和诊断 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)突发事件分析员执行分析和诊断任务来找到事件的根本原因和解决方案。
--|SO2.4|(% style="width:121px" %)突发事件解决和恢复 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)突发事件分析员需要在应用可能的解决方案前对其进行识别和评估，并根据需要升级突发事件。必要时，突发事件分析员会将突发事件（包括那些需要变更的突发事件）升级到突发事件协调员。如果突发事件分析员没有实施变更所需的权限级别，他/她需要将突发事件重新分配给其他可以实施解决方案的组。
--|SO2.5|(% style="width:121px" %)突发事件关闭 |(% style="width:163px" %)突发事件分析员|(% style="width:994px" %)关闭突发事件时，必须对其进行检查以确认初始突发事件分类是否正确。如果类别不正确，则必须使用正确的类别更新记录。如果突发事件记录中缺失信息，则必须将缺失的信息添加到记录中以确保突发事件记录的完整性。突发事件关闭过程的最后一步是确定突发事件重复发生的可能性，并相应地选择关闭类别。如果突发事件可能重复发生，将突发事件记录标记为“问题候选项”
--|SO2.6|(% style="width:121px" %)突发事件升级 |(% style="width:163px" %)突发事件协调员|(% style="width:994px" %)当突发事件调查和诊断流程或突发事件解决和恢复流程超出服务级别协议目标时或如果不能达到这些目标，将升级突发事件。
--|SO2.7|(% style="width:121px" %)监控服务级别协议 |(% style="width:163px" %)服务台人员|(% style="width:994px" %)服务级别协议 (SLA) 包含突发事件解决情况的标准。此过程对突发事件从初始化到解决的过程中要监控的所有与突发事件相关的交互的活动进行了描述。SLA 监控还可确定是否符合突发事件解决的时间目标，并根据关联的 SLA 指示是否需要升级以符合目标解决日期。
--|SO2.8|(% style="width:121px" %)OLA 和 UC 监控 |(% style="width:163px" %)突发事件协调员|(% style="width:994px" %)突发事件协调员会监控分配给支持组和相应供应商的所有突发事件。在没有按照指定的协议日期和时间解决或升级突发事件前，将会一直跟踪执行情况。OLA 和 UC 的目标日期通常取决于突发事件的优先级和类别。如果已超过或即将超过目标时间，突发事件协调员可以将突发事件升级给突发事件经理。
--|SO2.9|(% style="width:121px" %)投诉处理 |(% style="width:163px" %)服务台经理|(% style="width:994px" %)当服务台经理收到“突发事件”或“任务”队列中的已分配的投诉类型的突发事件时，他将接受该突发事件。并且通过评估相关信息以及与相关人员进行交流来调查投诉原因。他还将搜索答案或解决方案以满足投诉用户的要求，并使用协定过的详细信息更新突发事件记录，然后关闭突发事件记录。
--
--==   ==
--
--== **6.6. 事件管理流程详细设计** ==
--
--事件管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合事件流程代码，把整个事件流程具体处理过程详细描述。
--
--
--=== **6.6.1.（SO2.1）突发事件记录** ===
--
--突发事件记录流程环节SO2.1的细化流程如下图所示：
--
--(% style="text-align:center" %)
--[[image:1730167336482-691.png]]
--
--描述如下：
--
--|**序号**|**步骤名称**|(% style="width:109px" %)**责任人**|(% style="width:888px" %)**流程描述**
--|SO2.1.1|升级交互为突发事件|(% style="width:109px" %)服务台人员|(% style="width:888px" %)用户交互无法在第一次联系即得以解决，将升级到突发事件管理流程。交互将会与新创建的突发事件自动关联。服务台人员根据交互创建突发事件。
--|SO2.1.2|是否分类为投诉？|(% style="width:109px" %)服务台人员|(% style="width:888px" %)此突发事件是否分类为服务台人员无法解决的投诉？如果是，请转至 SO2.1.5。如果不是，请转至 SO2.1.3。
--|SO2.1.3|将突发事件分配给组/人|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件会根据分类和受影响的服务分配到相应的支持组或人。CIM部门的突发事件同时要求电话确认分配人。
--|SO2.1.4|为用户提供交互编号|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。
--|SO2.1.5|将投诉突发事件分配给服务台组|(% style="width:109px" %)服务台人员|(% style="width:888px" %)最初会将分类为投诉的突发事件分配给服务台组。
--|SO2.1.6|为用户提供交互编号和服务级别协议目标|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。另外，服务台人员还将根据 SLA 提供目标解决日期。
--|SO2.1.7|将突发事件分配给服务台经理|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件保存后，将其分配给服务台经理（请参见 SO2.9 投诉管理）。
--|SO2.1.8|审核突发事件信息|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件可能会由于分配错误或信息不完整被分配组拒绝。在这种情况下，服务台人员需要审核记录的注释并更正信息或分配。
--|SO2.1.9|信息是否完整？|(% style="width:109px" %)服务台人员|(% style="width:888px" %)如果不是，请转至 SO2.1.10。如果是，请转至 SO2.1.3。
--|SO2.1.10|收集所需信息|(% style="width:109px" %)服务台人员|(% style="width:888px" %)收集丢失的必需信息，并使用这些信息更新突发事件。如果有必要，请与用户联系。
--|SO2.1.11|创建新的突发事件|(% style="width:109px" %)服务台人员|(% style="width:888px" %)从监控系统发现突发事件，根据实际情况，服务台手动登记突发事件记录或由监控系统集成自动打开突发事件记录。
--|SO2.1.12|选择合适的突发事件模板|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员从列表中选择突发事件模板
--|SO2.1.13|按照模板说明操作|(% style="width:109px" %)服务台人员|(% style="width:888px" %)服务台人员将根据突发事件模板中的说明记录突发事件详细信息。
--|SO2.1.14|提供描述/配置项|(% style="width:109px" %)服务台人员|(% style="width:888px" %)为突发事件提供适当的描述。这可以是基于事件文本得出的。如果可能，应选择受影响的配置项。
--|SO2.1.15|选择类别和优先级|(% style="width:109px" %)服务台人员|(% style="width:888px" %)通过选择适用的影响级别和紧急程度选择适当的类别和优先级。
--|SO2.1.16|将突发事件分配给组|(% style="width:109px" %)服务台人员|(% style="width:888px" %)突发事件会根据分类和相关受影响的服务自动分配到相应的支持组。
--
--注意：
--
--* 事件创建的时候，将会遇到重复事件的问题。
--
--重复事件一般可分为三类：一，同一个用户在处理时限内提交的重复事件；二，不同用户反映的同一个问题，并且第一个用户反映的问题还在处理时限范围内；三，超过处理时限，同一用户提交的重复事件。
--
--一般来说，用户告知的事件都是要新建记录的，但对于不同具体情况，可选择不同的处理方式：
--
--对于第一类，不用建立新的事件，但如果用户描述的现象与之前记录的内容不一致，还是新建；
--
--对于第二类，如果能够确信几个用户描述确实是一个问题，可不新建，将之于现有交互或突发事件关联；
--
--对于第三类，可不新建，此类情况应该可以避免发生，之前处理过程中，应该与用户主动沟通。
--
--总的来说，建议服务台除非能够明确判断事件的重复性，否则还是新建事件。
--
--如果是真正的重复，可以通过统计，分析出用户的实际忍受时限，便于优化处理时限；如果不是真正的重复，可避免故障的遗漏。
--
--* 设置分配组和分配用户的原则
--
--如果服务台人员不能解决， 则转给相应突发事件分析员（二线）进行处理；
--
--* 事件通知
--
--通过服务管理平台派发事件的方式，能够很好的记录日常处理的事件，但同时也会面临响应延迟的问题。响应延迟的问题主要体现在事件分配后，被分配人员因为某种原因，不能及时登录服务管理平台查询需要自己处理的事件，导致延迟处理事件。
--
--响应延迟可能存在多种原因，如：正在处理一个事件；正在开会，不具备条件，不能够马上登陆服务管理平台察看并处理；正在休假；不能察看邮件等等。随着事件管理流程的执行，可能还会有其它的原因。但都不是流程能够解决的问题，需要制定管理制度，并有效执行才能解决。
--
--当前为避免该问题发生的建议如下：
--
--* 当前每次事件的分派前电话通知被分派人员，同时通过服务管理平台邮件；
--* 如果被分派人员未联系上，直接联系突发事件协调员，由突发事件协调员协调处理；
--* 及时更新各个系统具体负责的运维人员相关信息，并通知服务台人员。
--
--后续随着事件管理流程的运转，通过服务台把各种情况记录下来，定期统计分析，发现响应延迟的根本原因，再进一步完善弥补响应延迟的措施。如果是管理制度不完善，如：休假制度、出差制度，则完善相应的制度；如果是资源配置不合理，如：工作量大但只有一个人负责，则合理增配运维人员。后续各个流程在分派响应问题上可参考此处描述，不再复述。
--
--===   ===
--
--=== **6.6.2. （SO2.2）突发事件分配/再分配** ===
--
--突发事件分配流程环节SO2.2的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167403847-523.png]]
--
--描述如下：
--
--|序号|步骤名称|(% style="width:129px" %)责任人|(% style="width:920px" %)流程描述
--|SO2.2.1|审核突发事件信息|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员监控突发事件队列并审核所有传入的突发事件。
--|SO2.2.2|突发事件信息是否完整并分配到正确的组？|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员验证突发事件记录中是否提供了足够的信息以诊断突发事件，并验证突发事件是否已分配给正确的支持组。如果是，请继续 SO2.2.3。如果不是，请转至 SO2.2.8。
--|SO2.2.3|将突发事件分配或再分配给突发事件分析员|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员接受突发事件，并将其分配或再分配给突发事件协调员组中的某位突发事件分析员，以便进行进一步调查和诊断。
--|SO2.2.4|审核突发事件信息|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员对分配给他/她自己的突发事件的队列进行监控，并审核传入的突发事件。
--|SO2.2.5|是否能解决突发事件？|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员审核分配的突发事件以确定他/她是否能够解决该突发事件。如果是，请继续 SO2.2.6。如果不是，请转至 SO2.2.7。
--|SO2.2.6|接受突发事件|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员通过将状态更改为“已接受”接受突发事件。
--|SO2.2.7|拒绝突发事件|(% style="width:129px" %)突发事件分析员|(% style="width:920px" %)突发事件分析员通过将“分配人”字段设置为突发事件协调员并提供一个更新来拒绝突发事件，拒绝原因在更新中陈述。然后，将突发事件返回到突发事件队列中，以待突发事件协调员重新进行分配。
--|SO2.2.8|拒绝突发事件|(% style="width:129px" %)突发事件协调员|(% style="width:920px" %)突发事件协调员拒绝突发事件，然后将其重新分配给服务台。
--
--===   ===
--
--=== **6.6.3. （SO2.3）突发事件调查和诊断** ===
--
--突发事件调查和诊断流程环节SO2.3的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167464291-929.png]]
--
--描述如下：
--
--|序号|步骤名称|(% style="width:136px" %)责任人|(% style="width:1000px" %)流程描述
--|SO2.3.1|审核突发事件|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员对分配给他/她自己的突发事件的队列进行监控，并审核传入的突发事件
--|SO2.3.2|是否请求信息？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员评估突发事件以查看是否已将其分类为服务请求。如果是，请继续 SO2.3.11。如果不是，请转至 SO2.3.3。
--|SO2.3.3|调查和诊断|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员开始调查和诊断突发事件原因。突发事件的状态被设置为“正在处理”。
--|SO2.3.4|是否再现突发事件？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员尝试是否可以重现突发事件。如果是，请继续 SO2.3.5。如果不是，请转至 SO2.3.8。
--|SO2.3.5|是否与未决问题/已知错误匹配？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员搜索问题数据库中是否存在为此突发事件定义的问题或已知错误。如果是，请继续 SO2.3.9。如果不是，请转至 SO2.3.6。
--|SO2.3.6|突发事件是否由变更引起？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员搜索变更知识库以查看是否由于最新变更而导致服务中断。如果列出了与此突发事件相关联的配置项，则突发事件分析员还可以查看最近根据此配置项执行的所有变更。此外，突发事件分析员还可以查看配置项树以确定突发事件是否由相关配置项引起。如果是，请继续 SO2.3.10。如果不是，请转至 SO2.3.7。
--|SO2.3.7|是否找到解决方案？|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将检查已知错误/知识库来获得此突发事件的应对措施或解决方案，或尝试查找解决方案。如果是，请继续 SO2.3.8。如果不是，请返回至 SO2.3.3
--|SO2.3.8|记录解决方案/应对措施|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将在突发事件记录中记录解决方案或应对措施。
--|SO2.3.9|将突发事件与问题/已知错误相关联|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)如果突发事件与未决问题/已知错误相匹配，则突发事件记录与此问题/已知错误记录相关联。在应对措施可以使用前，突发事件一直处于挂起状态。
--|SO2.3.10|将突发事件与变更相关联|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)如果突发事件由先前变更引起，则突发事件记录与此变更记录相关。但是，仍然需要找到一个解决方案来解决突发事件。
--|SO2.3.11|搜索/收集信息|(% style="width:136px" %)突发事件分析员|(% style="width:1000px" %)突发事件分析员将搜索相关信息，以为用户提供请求的信息。
--
--注意：
--
--在事件处理中要注意最后期限的要求，并按照事件通知和升级机制， 通知相关人员。在以下处理过程中不再重复描述。
--
--===   ===
--
--=== **6.6.4. （SO2.4）突发事件解决与恢复** ===
--
--突发事件解决与恢复流程环节SO2.4的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167509731-690.png]]
--
--描述如下：
--
--|序号|步骤名称|(% style="width:134px" %)责任人|(% style="width:892px" %)流程描述
--|SO2.4.1|审核突发事件|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员会审核突发事件信息，以获得所提供的解决方案或应对措施。
--|SO2.4.2|是否需要变更来解决突发事件？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员确定提供的解决方案是否需要通过变更来实施。如果是，请转至 SO2.6。如果不是，请继续 SO2.4.3。
--|SO2.4.3|突发事件分析员是否有权实施解决方案？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员必须判断他/她是否有权实施解决方案。如果是，请继续 SO2.4.4。如果不是，请转至 SO2.4.7。
--|SO2.4.4|实施解决方案|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)突发事件分析员在生产环境中测试和实施解决方案。验证完成后将状态标记为”已完成。
--|SO2.4.5|是否出现错误？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)如果在实施解决方案过程中出现错误，突发事件分析员将撤销解决方案，突发事件将返回到调查和诊断阶段。如果是，请转至 SO2.4.6。如果不是，请继续 SO2.5。
--|SO2.4.6|是否需要升级？|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)确定是否需要解决过程中的此位置升级到突发事件协调员。如果是，请转至突发事件升级过程。如果不是，请转至 SO2.3.3。
--|SO2.4.7|重新分配给其他组|(% style="width:134px" %)突发事件分析员|(% style="width:892px" %)当突发事件分析员没有被授予实施解决方案的权限时，突发事件分析员必须将突发事件重新分配到可以实施解决方案的支持组。
--
--
--
--=== **6.6.5. （SO2.5）突发事件关闭** ===
--
--突发事件关闭流程环节SO2.5的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167543852-131.png]]
--
--描述如下：
--
--|序号|步骤名称|责任人|流程描述
--|SO2.5.1|监控状态为“已解决”突发事件队列|服务台人员|服务台人员通过队列定期检查标记为”已解决“状态的突发事件
--|SO2.5.2|验证并确认解决方案|服务台人员|服务台人员验证解决方案是否正确且完整，然后与用户联系确认是否已经解决。
--|SO2.5.3|用户确认已解决？|服务台人员|用户确认已解决？如果是，请继续 SO2.5.4。如果不是，请转至 SO2.5.7。
--|SO2.5.4|关闭突发事件|服务台人员|关闭突发事件并选择合适的关闭代码。
--|SO2.5.5|突发事件是否由监控系统触发？|服务台人员|突发事件是否由监控系统触发？如果是，则必须通过监控系统确认事件(Event)。如果不是，请转至 SO2.5.6。
--|SO2.5.6|突发事件是否通过交互引起？|服务台人员|突发事件是否由交互引起？如果是，请继续进行关闭交互过程。如果不是，请停止。
--|SO2.5.7|重新打开变更？|服务台人员|解决方案是否是通过变更实施的？如果是，请继续进行重新打开变更过程。如果不是，请转至 SO2.5.8。
--|SO2.5.8|重新打开服务请求？|服务台人员|解决方案是否是通过服务请求实施的？如果是，请继续进行重新打开变更过程。如果不是，请转至突发事件分配过程。
--
--
--=== **6.6.6. （SO2.6）突发事件升级** ===
--
--突发事件升级流程环节SO2.6的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167571864-309.png]]
--
--描述如下：
--
--|序号|步骤名称|(% style="width:128px" %)责任人|(% style="width:949px" %)流程描述
--|SO2.6.1|确定如何解决突发事件|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员从突发事件分析员处收集有关突发事件解决状态的信息，然后根据信息确定解决突发事件的最佳方式。
--|SO2.6.2|是否需要升级？|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)是否需要升级来解决突发事件？如果是，请继续 SO2.6.7。如果不是，请转至 SO2.6.3。
--|SO2.6.3|是否需要服务请求？|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)是否可以通过服务请求解决突发事件？如果是，请继续 SO2.6.5。如果不是，请转至 SO2.6.4。
--|SO2.6.4|让突发事件分析员解决突发事件|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员可以让突发事件分析员只关注突发事件的解决，并为他们提供所有必要的方法，以加快解决速度。
--|SO2.6.5|请求服务请求|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)突发事件协调员通过请求执行流程完成服务请求以实施建议的解决方案
--|SO2.6.6|确定预期解决时间|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理会验证预期解决时间是否符合服务级别协议 (SLA) 目标。
--|SO2.6.7|确定并执行升级操作|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理确定要在目标时间内解决突发事件需要执行的操作，并指定发生升级时的升级联系人。这样可以包括确定是否需要服务台将信息公告发送给受影响的用户和利益相关者。
--|SO2.6.8|是否需要紧急变更？|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)如果是，请转至 SO2.6.9。如果不是，请转至 SO2.6.10。
--|SO2.6.9|注册紧急变更|(% style="width:128px" %)突发事件协调员|(% style="width:949px" %)根据突发事件经理请求，突发事件协调员将注册紧急变更请求，与变更经理联系，将请求通知给他/她，然后启动紧急变更处理过程。
--|SO2.6.10|是否需要重新分配？|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)是否需要将突发事件重新分配给经验更为丰富的支持组（即功能升级）？如果是，请继续 SO2.6.11。如果不是，请停止。
--|SO2.6.11|重新分配突发事件|(% style="width:128px" %)突发事件经理|(% style="width:949px" %)突发事件经理将突发事件重新分配给二线或三线支持组。
--
--
--=== **6.6.7. （SO2.7）监控SLA** ===
--
--(注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)
--
--监控SLA流程环节SO2.7的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167600213-711.png]]
--
--
--描述如下：
--
--|序号|步骤名称|责任人|流程描述
--|SO2.7.1|监控队列|服务台人员|通过查询或相关视图查询SLA监控队列
--|SO2.7.2|是否违反 SLA？|服务台人员|是否已超过此交互的 SLA 目标日期/时间？如果是，请启动突发事件升级过程 (SO2.6.7)。如果不是，请转至 SO2.7.3。
--|SO2.7.3|1 小时内发生 SLA 违约|服务台人员|是否需要在距 SLA 目标日期/时间还有 1 小时之前解决交互？如果是，请转至 SO2.7.4。如果不是，请转至 SO2.7.7。
--|SO2.7.4|与突发事件协调员协商能否按时解决|服务台人员|联系相关突发事件协调员。确定如果没有进一步的支持该组是否能够按时解决突发事件。
--|SO2.7.5|能否按时解决？|服务台人员|如果是，请转至 SO2.7.6。如果不是，请转至 SO2.6.7，立即升级突发事件。
--|SO2.7.6|通报受影响用户|服务台人员|识别受相关突发事件影响的用户或用户组。将突发事件状态和预期解决时间通报给所有受影响的用户。
--|SO2.7.7|4 小时内发生 SLA 违约？|服务台人员|是否需要在距 SLA 目标日期/时间还有 4 小时之前解决交互？如果是，请转至 SO2.7.9。如果不是，请转至 SO2.7.8。
--|SO2.7.8|1 天内发生 SLA 违约？|服务台人员|是否需要在距 SLA 目标日期/时间还有 1 天之前解决交互？如果是，请转至 SO2.7.9。如果不是，请转至 SO2.7.11。
--|SO2.7.9|了解事件处理进度|服务台人员|通过查看事件单中的工作日志或联系相关人员了解进度
--|SO2.7.10|能否按时解决|服务台人员|判断是否能够按时解决，如果是，转SO2.7.1,如果不是，转SO2.7.4
--|SO2.7.11|相关事件是否已关闭？|服务台人员|如果是，则不需要进一步执行任何操作。如果不是，请转至 SO2.7.1。
--
--
--=== **6.6.8. （SO2.8）监控操作级别协议（OLA）和支持合同（UC）** ===
--
--(注：此处涉及到的与SLA/SLO相关的时间为示例，具体时间待服务级别管理流程确定后再更新)
--
--监控OLA和UC流程环节SO2.8的细化流程如下图所示：
--
--
--
--(% style="text-align:center" %)
--[[image:1730167627857-667.png]]
--
--描述如下：
--
--|序号|步骤名称|责任人|流程描述
--|SO 2.8.1|检查突发事件的状态和进度|突发事件协调员|检查突发事件解决的状态和进度。验证是否将在适用的操作级别协议 (OLA) 和支持合同 (UC) 中指定的目标日期和时间之前解决突发事件。
--|SO 2.8.2|分配的突发事件分析员在工作？|突发事件协调员|外部环境（例如，工作班次结束、疾病或假期）可能导致找不到已分配的突发事件分析员。
--|SO 2.8.3|是否需要重新分配？|突发事件协调员|如果是，请转至 SO 2.2.3。如果不是，请转至 SO 2.8.4。
--|SO 2.8.4|是否违反OLA 或 UC？|突发事件协调员|如果是，请启动突发事件升级过程 (SO 2.6.7)。如果不是，请转至 SO 2.8.5。
--|SO 2.8.5|在 1 小时内发生 OLA/UC 违约？|突发事件协调员|如果是，请转至 SO 2.8.6。如果不是，请转至 SO 2.8.8。
--|SO 2.8.6|从事件分析员或供应商那里获取状态更新|突发事件协调员|与已分配的突发事件分析员联系，以接收突发事件的状态更新。如果已将突发事件报告给供应商，则联系供应商以获取状态更新。
--|SO 2.8.7|能否按时解决突发事件？|突发事件协调员|突发事件协调员估计是否仍然能够按时解决突发事件。如果是，请转至 SO 2.8.1。如果不是，请转至 SO 2.6.7 以立即升级突发事件。
--|SO 2.8.8|在 4 小时内发生 OLA/UC 违约？|突发事件协调员|是否需要在距 OLA/UC 目标日期/时间还有 4 小时之前解决突发事件？如果是，请转至 SO2.8.9。如果不是，请转至 SO2.8.11。
--|SO2.8.9|从事件分析员或供应商那里获取状态更新|突发事件协调员|与已分配的突发事件分析员联系，以接收突发事件的状态更新。如果已将突发事件报告给供应商，则联系供应商以获取状态更新。
--|SO2.8.10|如果需要，执行跟进操作|突发事件协调员|突发事件协调员根据 OLA/UC 确定是否需要执行跟进操作来解决突发事件。如果需要，突发事件协调员将执行所需操作。
--|SO2.8.11|在 1 天内发生 OLA/UC 违约？|突发事件协调员|如果是，请转至 SO2.8.9。如果不是，请转至 SO2.8.12。
--|SO2.8.12|突发事件是否已关闭？|突发事件协调员|如果是，则不需要进一步执行任何操作。如果不是，请转至 SO2.8.1。
--
--
--=== **6.6.9. （SO2.9）投诉处理** ===
--
--投诉处理流程环节SO2.9的细化流程如下图所示：
--
--
--(% style="text-align:center" %)
--[[image:1730167651416-536.png]]
--
-- 描述如下：
--
--
--|序号|步骤名称|责任人|流程描述
--|SO2.9.1|审核投诉信息|服务台经理|服务台经理监控突发事件队列并审核已分配的突发事件。服务台经理检查投诉内容。
--|SO2.9.2|接受投诉|服务台经理|服务台经理接受突发事件记录，以调查投诉原因。
--|SO2.9.3|调查投诉原因|服务台经理|服务台经理通过查看相关信息并与相关人员进行交流来调查投诉原因。服务台经理还将寻找解决方案，让提交投诉的用户满意。
--|SO2.9.4|采取措施来与用户调解|服务台经理|服务台经理联系用户以解决用户的问题，并尝试达成协议。
--|SO2.9.5|更新和关闭投诉|服务台经理|服务台经理使用协定过的详细信息更新突发事件记录，然后关闭突发事件记录。
--
--
--
--
--= **7. 报表** =
--
--有了有效的、适合使用的流程，还要加强相应的管理才能获得最佳效果。对于服务台、事件流程的管理分析主要集中在：呼叫、事件的分布和处理情况、流程运行效率、各角色执行效率、人员分布及技能水平情况等方面。管理者（事件经理和运维主管）需要综合这些信息适时的对流程、人员组织的情况进行动态调整，以持续改善、提高事件管理流程的效率和能力。
--
--
--|报表名称|模块|描述
--|首次解绝率|服务台|在没有请求其他支持人员的情况下，首次联系即被服务台人员关闭的交互的百分比
--|用户满意度|服务台|客户满意度调查返回的平均结果
--|本人名下未关闭交互单|服务台|本人处理，由于升级到突发事件而未关闭的交互单
--|在 SLA 目标时间内关闭的突发事件的百分比|突发事件|在 SLA 目标时间内关闭的突发事件的数量（相对于在给定时间段内关闭的所有突发事件）
--|重新打开的突发事件的百分比|突发事件|由于解决方案不被客户接受而重新打开的已关闭突发事件的数量（相对于在给定时间段内关闭的所有突发事件的数量）。
--|月度故障解决率|突发事件|本月故障的服务台/二/三线解决率。
--|本月交互，故障分类统计|服务台，突发事件|本月各个分类出现的交互，突发事件次数统计。
--|各分类当前未解决事件统计|突发事件|反映当前正在处理中的事件分布情况
--|当前各个状态的事件统计|突发事件|当前各个状态的事件统计
--|当前所有未关闭事件列表|突发事件|用于服务台查看当前需要解决的事件的详细信息
--|当前分配给自己的未解决事件|突发事件|用于服务台以及支持人员查看需要自己解决事件。 此列表中包括分配给本组， 且未制定支持人员的事件。
--|高优先级突发事件列表|突发事件|需要优先解决的突发事件列表
--|超时的事件列表|突发事件|用于事件经理了解目前急需解决的事件。此列表可以包括即将超时的事件。
--|问题管理备选事件列表|突发事件|列出支持人员标注的问题管理备选事件， 在事件管理流程回顾时进行分析， 进入问题管理流程。
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司