Changes for page 27 某地铁信息化基础架构平台建设IT服务标准化管理咨询ITIL事件管理流程设计说明书

Last modified by superadmin on 2024/11/01, 21:20

From version < 11.1 >

edited by superadmin
on 2024/11/01, 21:19

To version < 8.1 >

edited by superadmin
on 2024/11/01, 21:15

< >

Change comment: 上传新附件1730466916388-384.png

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 1 removed)
- 1730466981326-640.png

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-27 某地铁信息化基础架构平台建设IT服务标准化管理咨询ITIL事件管理流程设计说明书

Parent

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,880
          +1,0 @@
--= **1. 目标** =
--
--事件管理流程的主要功能是尽快解决出现的事件，保持关键业务系统的稳定性，其目标包括：
--
--* 在成本允许的范围内尽快恢复IT服务
--** 快速响应用户请求（通过电话）
--** 用户在线获得帮助
--** 沟通事件解决的状态
--** 和客户确认事件的解决
--* 进行事件控制
--** 按规范记录事件
--** 就事件的优先级，影响度进行分类
--** 分析，诊断，必要时进行升级
--** 监视并结束事件
--** 进行定期服务流程回顾
--* 提供IT管理信息
--** 人力资源利用情况
--** 故障处理情况
--** 支持效率
--
--(% class="wikigeneratedid" %)
--=   =
--
--(% class="wikigeneratedid" %)
--=   =
--
--= **2. 流程范围** =
--
--事件管理流程包括：
--
--* 企业用户申报的故障或咨询
--
--涉及的基础架构和业务系统包括：
--
--1. 包括以下基础架构－－主机、存储、网络、PC、终端、打印机。
--1. 包括以下业务系统――（参考服务目录）。
--
--* 监控系统触发的告警事件
--* 日常运维过程中发现的所有故障
--
--
--
--= **3. 流程主要内容** =
--
--事件管理流程主要活动包括以下几个方面：
--
--事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：
--
--* 事件接受和记录
--
-- 这个环节是事件管理流程的起点。所有通过用户交互或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。
--
--该环节的关键是信息的准确性和完整性。
--
--* 分类和在线支持
--
--事件可以是一个故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
--
--该环节的关键是必要的问题库支持和正确的事件分派。
--
--* 调查和诊断
--
--若支持人员无法解决事件，可运用自身技能、问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
--
--* 解决和恢复
--
--支持人员实施事件的解决方案，书写解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。
--
--* 结束事件
--
--当用户确认事件解决后，此时可结束该事件。
--
--* 事件升级
--
--当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。
--
--==   ==
--
--==   ==
--
--= **4. 流程执行原则** =
--
--流程执行原则是流程实施的策略，它作用于各个流程活动，指导流程活动的正确执行。这些执行原则同时也协助流程设计，并作为流程执行的输入。若没有经过很好设计的流程执行原则，将会使流程既不能满足客户的期望，也不能满足服务实施的标准。
--
--事件管理流程的执行原则包含了以下7个方面：
--
--==   ==
--
--== 4.1 常规原则 ==
--
--* 所有事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理过程，详细的解决方案和相应的附件；
--* 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别；
--* 各支持组组长应该每周检查相关的事件记录，以确保事件记录的完整和合理；
--* 事件经理应该每月产生事件管理报表。对反复发生的事件和变通方法解决的事件，举行定期的事件管理会议对这些事件进行评估，决定是否发起问题单以从根本上解决某些事件；
--* 事件经理每半年对流程进行回顾，回顾内容包括流程关键衡量指标和流程执行效率，以改进事件管理流程。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.2 流程关联原则 ==
--
--* 和问题管理的关联
--** 对于根本原因未明、采用变通方法解决的事件，应该产生问题记录并建立关联，或者与现有的问题进行关联；
--** 远程员和二线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案。
--* 和变更管理的关联
--** 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更申请单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理。
--* 和服务请求管理的关联
--** 事件处理过程中，如果需要提出服务请求，必须按照服务请求管理的定义，提交服务请求申请单（请求单必须和事件单建立关联），请求完成后，继续事件单的处理。
--* 和配置管理的关联
--** 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位；
--** 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.3 所有权原则 ==
--
--* 所有权原则用来确保每个事件在任何时段都有适当的人员负责，协调员和事件经理必须确保事件得到有效跟踪与解决，并统一由质控员负责对事件单进行验证后关闭。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.4 重分派原则 ==
--
--* 事件的重分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单重分派的几率，事件单的重分派次数不应该超过3次。
--** 协调员可以将事件单重新分配给远程员或其他二线支持人员；
--** 事件重分派时要求协调员进行重分派原因的沟通。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.5 重复事件原则 ==
--
--重复事件是指在一个较短时间段（通常是1小时内），由监控平台上报的同一个配置项上现象相同的事件；或者一人/多人报告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单也获得解决。
--
--* 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标；
--* 由远程员或二线支持人员负责标识重复事件。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.6 补单原则 ==
--
--* 紧急事件在处理完成后必须补录事件单，记录详细解决过程及方案；
--* 重大事件也要在处理完成后，总结回顾处理过程，在事件单补录详细的处理信息、解决方案及相关改进点。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.7 关闭原则 ==
--
--所有事件单必须由交互流程的质控员验证通过后关闭。
--
--* 事件处理人员在解决完成事件时，根据实际解决情况填写事件解决代码。由交互流程质控员负责和最终用户确认事件的关闭；
--** 由最终用户认可获得关闭的事件单的结束代码为“已完成”；
--** 已解决的事件单如果没有得到最终用户的认可，则首先关闭该事件单，结束代码修改为“未完成”，同时创建一个新的事件单重新分配到原处理人员继续处理。
--* 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单；
--* 对于已解决事件单，如果在确认时如无法联系用户，由质控员判断并决定是否关闭交互并关闭该事件。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 4.8 升级原则 ==
--
--制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
--
--* 优先级为紧急的事件，协调员应立即升级到事件经理，由事件经理再次确认，如果优先级的确为紧急，则通知相应的管理层，并由事件经理启动紧急事件处理流程；
--* 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，系统应自动将事件信息通报相关人员，由协调员负责协调资源，并督促事件能够及时被响应和处理；
--* 远程员应及时将不能解决的事件升级到二线支持人员，若未及时升级，协调员应及时介入，负责协调升级处理；
--* 远程员和二线支持人员在必要时通知协调员，将事件升级为紧急事件；
--* 只有协调员和事件经理才能变更事件的优先级。
--
--==   ==
--
--
--= **5. 流程详述** =
--
--== 5.1 事件管理流程概要设计 ==
--
--(% style="text-align:center" %)
--[[image:1730466396820-943.png]]
--
--
--流程活动：
--
--|序号|活动|说明|输入|输出|负责部门|角色
--|8.2.1|分派事件单|所有事件单首先分派到协调员，由协调员判断给远程员或二线支持人员进行解决|交互/监控告警/日常运维升级的事件单|待办事件单|IT运维部|协调员
--|8.2.2|调查和诊断|(((
--1. 接受事件单后，首先要根据自身经验对事件单信息进行更新，包括事件描述、事件分类、紧急度、影响度等；
--1. 调查事件原因，查找相关的问题或变更，判断是否能独自解决故障；
--)))|待办事件单|更新的事件单信息|IT运维部|(((
--一线、
--
--二线支持
--)))
--|8.2.3|记录解决方案|(((
--1. 初步确定解决故障的方式
--1. 如果需要借助问题管理流程才能找到解决方案，则写明分析情况并转单给协调员判断是否新建问题单；
--1. 如果解决方案需要通过发起一个变更请求才能实施，则新建一个变更单转变更主管审批
--1. 如果解决方案需要通过发起一个服务请求才能实施，则新建一个服务请求单转请求主管审批
--1. 记录详细的解决方案；
--)))|更新的事件单|事件解决方案|IT运维部|(((
--一线、
--
--二线支持
--)))
--|8.2.4|实施解决方案|(((
--1. 实施解决方案
--1. 由一二线支持人员对用户故障进行远程或现场处理，如果是应用类故障，则初步尝试解决；
--1. 实施过程中如出现错误，需要判断是否转单给其他支持组处理；
--)))|事件解决方案|事件处理结果|IT运维部|(((
--一线、
--
--二线支持
--)))
--|8.2.5|关闭事件|支持人员确认解决故障后，更新解决方案，然后关闭事件单|事件处理结果|关闭的事件单|IT运维部|(((
--一线、
--
--二线支持
--)))
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 5.2 分派事件单 ==
--
--
--(% style="text-align:center" %)
--[[image:1730466442850-906.png]]
--
--流程活动：
--
--|序号|活动|说明|输入|输出|负责部门|角色
--|8.2.1.1|初审事件信息|初审事件单的关键信息|交互/监控告警/日常运维升级的事件单|无|IT运维部|协调员
--|8.2.1.2|信息是否完整？|检查事件单信息是否足够|事件单信息|无|IT运维部|协调员
--|8.2.1.3|拒绝事件|如发现事件单信息不完整，可退回服务台完善。|事件单信息|拒绝事件单|IT运维部|协调员
--|8.2.1.4|分派事件|根据实际情况分派事件单给一线或二线处理|事件单信息|分派事件|IT运维部|协调员
--
--
--== 5.3 调查和诊断 ==
--
--
--(% style="text-align:center" %)
--[[image:1730466471229-405.png]]
--
--流程活动：
--
--|序号|活动|(% style="width:611px" %)说明|(% style="width:133px" %)输入|(% style="width:151px" %)输出|(% style="width:102px" %)负责部门|(% style="width:185px" %)角色
--|8.2.2.1|是否接受|(% style="width:611px" %)是否接受事件单的分派？|(% style="width:133px" %)待办事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.2|收集信息及调查原因|(% style="width:611px" %)收集事件的相关信息，检查事件单是否与其他问题单变更单有关联， |(% style="width:133px" %)事件单信息|(% style="width:151px" %)更新的事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.3|由变更引起？|(% style="width:611px" %)判断是否与其他正在处理的变更单相关|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.4|关联相关变更|(% style="width:611px" %)如果相关，需要把事件单与其关联|(% style="width:133px" %)事件单|(% style="width:151px" %)关联的变更单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.5|与未决问题匹配？|(% style="width:611px" %)判断是否与其他正在处理的问题单相关|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.6|关联相关问题|(% style="width:611px" %)如果相关，需要把事件单与其关联|(% style="width:133px" %)事件单|(% style="width:151px" %)关联的问题单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--|8.2.2.7|是否超时？|(% style="width:611px" %)系统会实时自动判断事件单在支持人员处理的过程中是否超时，如超时会分派给协调员处理|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)协调员待办事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)系统
--|8.2.2.8|是否能自行解决？|(% style="width:611px" %)在充分调研后，尽快判断是否能自行解决事件，如不能处理需要转派回协调员|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)接受或拒绝事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
--
--
--== 5.4 记录解决方案 ==
--
--
--(% style="text-align:center" %)
--[[image:1730466522660-947.png]]
--
--流程活动：
--
--|序号|活动|说明|输入|输出|负责部门|角色
--|8.2.3.1|确定解决事件的方式|确定用什么方式解决事件|更新的事件单|无|IT运维部|一线二线支持
--|8.2.3.2|借助问题管理？|判断是否要借助问题管理彻查原因|更新的事件单|无|IT运维部|一线二线支持
--|8.2.3.3|注明转问题单原因|如果认为需要通过问题管理才能彻底解决故障，可以注明原因，转回协调员安排升级问题|更新的事件单|转问题单原因|IT运维部|一线二线支持
--|8.2.3.4|发起变更？|判断是否要发起变更|更新的事件单|变更单|IT运维部|一线二线支持
--|8.2.3.5|发起请求？|判断是否要发起请求|更新的事件单|请求单|IT运维部|一线二线支持
--|8.2.3.6|记录解决方案|记录初步的故障解决方案|更新的事件单|解决方案|IT运维部|一线二线支持
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 5.5 实施解决方案 ==
--
--
--(% style="text-align:center" %)
--[[image:1730466550951-594.png]]
--
--流程活动：
--
--|序号|活动|说明|输入|输出|负责部门|角色
--|8.2.4.1|是否有权实施？|判断是否有足够的权限独自实施解决方案|更新的事件单|无|IT运维部|一线二线支持
--|8.2.4.2|实施解决方案|如权限足够，则直接实施解决方案|更新的事件单|实施解决方案|IT运维部|一线二线支持
--|8.2.4.3|是否发生错误？|在实施解决方案的过程发生了错误？|实施解决方案过程|无|IT运维部|一线二线支持
--|8.2.4.4|是否需要升级？|判断是否要对错误升级|实施解决方案|无|IT运维部|一线二线支持
--|8.2.4.5|重分派给其他人或支持组|针对权限不足或者处理过程发生错误的情况，都应及时把事件单转回协调员处理|实施解决方案|转派的事件单|IT运维部|一线二线支持
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 5.6 关闭事件单 ==
--
--
--(% style="text-align:center" %)
--[[image:1730466575075-826.png]]
--
--流程活动：
--
--|序号|活动|说明|输入|输出|负责部门|角色
--|8.2.5.1|确认并更新解决方案|确认已解决用户故障，更新解决方案内容|故障处理结果|更新的解决方案|IT运维部|一线二线支持
--|8.2.5.2|关闭事件单|关闭事件单|更新的事件单|关闭的事件单|IT运维部|一线二线支持
--|8.2.5.3|事件由监控系统引起？|事件单关闭后，系统会自动判断事件单是否来自监控系统告警|关闭的事件单|事件解决状态|IT运维部|系统
--|8.2.5.4|事件由日常运维引起？|事件单关闭后，系统会自动判断事件单是否来自日常运维单，如果是则返回事件单状态给日常工单。|关闭的事件单|事件解决状态|IT运维部|系统
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== 5.7 紧急/重大事件处理子流程 ==
--
--制定紧急/重大事件处理子流程的目标：
--
--* 当紧急/重大事件发生时，尽可能采取措施减少对于业务带来的影响
--* 确保对紧急情况的有效管理
--** 加快紧急事件的响应和处理速度
--** 对紧急情况中的人员及采取的行动加强管理
--** 加强处理人员与用户之间的沟通和反馈
--** 对紧急情况妥善处理
--
--流程原则：
--
--* 制定各系统应急处理预案
--
--为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：
--
--1. 应急预案启动条件
--1. 应急处理小组负责人和成员联系名单和联系方式
--1. 应急处理步骤
--1. 应急信息报告
--1. 应急善后处理
--1. 应急保障措施（人员、培训、演习、场地等）
--
--* 紧急/重大事件需要及时上报信管部，II级或I级事件协调归口业务部门共同解决。
--* 紧急/重大事件判断原则
--
--根据应用系统的安全事件的分类及处置流程，只要达到此标准“导致Ⅳ级以上系统服务停止时间超过8小时，但能在24小时内恢复的事件”，均需启动紧急/重大事件子流程进行处理。详细说明参考“安全事件的分类及处置流程”及7.2事件影响度的描述。
--
--
--(% style="text-align:center" %)
--[[image:图片2.jpg]]
--
--
--                                                                                                                                                                图7紧急/重大事件处理子流程
--
--
--流程活动：
--
--|序号|活动|(% style="width:894px" %)说明|(% style="width:240px" %)角色
--|8.2.6.1|召集应急工作组，讨论决策|(% style="width:894px" %)事件经理主持会议，并组织讨论、分析紧急/重大事件的级别和处理方案|(% style="width:240px" %)(((
--事件经理
--
--重大事故评定委员会
--)))
--|8.2.6.2|是否有应急预案？|(% style="width:894px" %)根据紧急事件现象和所属系统，检查是否有相应系统的应急预案？|(% style="width:240px" %)重大事故评定委员会
--|8.2.6.3|按照应急预案处理|(% style="width:894px" %)根据各系统制定的应急预案中的实施步骤，处理紧急事件|(% style="width:240px" %)重大事故评定委员会
--|8.2.6.4|是否II级或I级事件？|(% style="width:894px" %)判断事件级别，确定是否需要归口业务部门参与处理。|(% style="width:240px" %)重大事故评定委员会
--|8.2.6.5|组织信管部人员共同分析、制定恢复计划并实施方案|(% style="width:894px" %)(((
--如III级、IV级事件，重大事故评定委员会负责组织管部与相关供应商共同分析紧急事件，制定相应的恢复计划和处理方案，处理方案在实施前应得到重大事故评定委员会和相关领导的认可；
--
--事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
--)))|(% style="width:240px" %)(((
--重大事故评定委员会
--
--信管部归口人
--)))
--|8.2.6.6|组织信管部及归口业务部门人员共同分析、制定恢复计划并实施方案|(% style="width:894px" %)(((
--如II级、I级事件，重大事故评定委员会负责组织信管部、归口业务部门与相关供应商共同分析紧急事件，制定相应的恢复计划和处理方案，处理方案在实施前应得到重大事故评定委员会和相关领导的认可；
--
--事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
--)))|(% style="width:240px" %)(((
--重大事故评定委员会
--
--信管部归口人
--
--归口业务部门
--)))
--|8.2.6.7|事件解除？|(% style="width:894px" %)确定故障是否已排除，如已解除，转善后处理流程；如未解除，则需要由事件经理继续协调研究解决方案。|(% style="width:240px" %)(((
--事件经理
--
--重大事故评定委员会
--)))
--|8.2.6.8|善后处理和通报|(% style="width:894px" %)(((
--事件解决后，信管部和重大事故评定委员会应向用户、公司相关领导报告事件处理过程，解决方法，事件解除时间，业务恢复情况。
--
--事件处理人在流程平台确定事件解决时间，填写解决方案。
--
--事件处理人需要创建一个新问题，将紧急/重大事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析
--)))|(% style="width:240px" %)(((
--重大事故评定委员会
--
--信管部归口人
--)))
--
--
--
--= **6. 关键角色、职责定义** =
--
--|角色|职责|建议人员或岗位
--|事件经理|(((
--* 监控交互流程的运行状况；
--* 监控事件流程的运行状况；
--* 负责对事件解决过程中的资源协调，保证故障的最终排除；
--* 当事件超时升级或重大事件升级时，负责或参与资源协调、解决事件；
--* 确保和问题管理流程的有效合作；
--* 基于事件处理状况，发现IT或业务相关的问题；
--* 事件处理过程中，解决方案的审批及提出RFC。
--* 技能要求：
--** 充分理解业务相关IT政策、操作过程和标准；
--** 基本了解业务系统环境；
--** 具有流程的知识；
--** 了解用户需求；
--** 分析技能；
--** 理解服务水平承诺；
--** 用户关系技能。
--)))|
--|一线(远程员)、二线支持人员|(((
--* 验证事件的描述和处理状况，进一步收集相关信息；
--* 根据专业技能和知识库等，确定并实施有效解决方案或临时变通方法；
--* 更新事件记录和解决方案，确保事件状态代码真实反映事件状态；
--* 远程员负责远程解决用户故障；
--* 二线支持人员负责现场解决用户故障以及远程员无法解决的故障；
--* 已解决的事件转回质控员，由质控员进行用户确认并关闭事件；
--* 技能要求：
--** 基本理解业务相关IT政策、操作过程和标准；
--** 理解相关的操作过程和工作指导；
--** IT基础架构和操作环境中某一方面的较高的技术知识；
--** 用户关系技能；
--** 分析技能。
--)))|
--|协调员|(((
--* 审核并接受或拒绝分配给支持组的突发事件
--* 协调交互单及事件单的分派；
--* 负责ITSM系统日常维护工作；
--* 负责每周及每月通过ITSM系统及CTI系统进行运维数据收集和整理，向事件经理提交运维数据；
--* 收集、整理和汇总各运维组提交的周报和月报，结合信息运维数据，撰写信息运维周报及信息运维月报，提交至事件经理审核。
--* 每日对事件处理过程及事件状态（事件单是否受理、事件单是否响应超时、事件单是否处理超时、设备送修情况等）进行跟踪与检查，每天向事件经理提交检查日志。
--
--* 技能要求：
--** 基本理解业务相关IT政策、操作过程和标准；
--** 理解相关的操作过程和工作指导；
--** IT基础架构和操作环境中某一方面的较高的技术知识；
--** 分析技能。
--)))|
--|重大事故评定委员会|(((
--* 根据紧急/重大事件的现象和所属系统，检查相应的应急预案，并组织人员按照应急预案中的实施步骤，处理故障；
--* 评定事件级别，负责组织信管部、归口业务部门与相关供应商共同分析紧急事件，共同制定相应的恢复计划和处理方案；
--* 事件解决后，重大事故评定委员负责向用户、公司相关领导报告事件处理过程，解决方法，事件解除时间，业务恢复情况；
--)))|IT运维部
--|质控员|合并至交互流程质控员|
--
--
--
--= **7. 流程相关定义** =
--
--== 7.1 事件单信息项 ==
--
--事件单必须包含如下信息项，可以在此基础上扩充：
--
--|序号|信息项|说明
--|1|事件ID|系统为此事件生成的唯一 ID。
--|2|状态|(((
--显示突发事件的状态。
--
--建议以下预置状态：
--
--• 打开 — 此突发事件已经打开，但目前没有得到处理。
--
--• 关闭 — 此突发事件已得到解决，并且得到了客户的同意。
--
--• 已解决 — 有一个解决方案，但未经客户验证。
--
--• 正在处理 — 正在处理此突发事件。
--
--•  待定变更 — 已打开一个相关紧急变更，正在等待关闭该变更。
--
--• 暂停 — 客户同意将此突发事件暂停一段时间；记录单将不会在该时段出现在待办队列中。
--)))
--|3|联系人|联系人不一定是服务接收人。此字段可以确保合适的人员将会得到有关交互更新的通知。
--|4|代理人|指定处理此突发事件的人员的姓名。此人是所分配的支持组的成员。代理人可以属于一个或多个分配组。
--|5|分配组|指定处理此突发事件的支持组
--|6|受影响的服务|该服务受此突发事件影响。此字段由交互记录中的数据填充。
--|7|受影响的配置项|对服务产生负面影响的配置项 (CI)。此字段由交互记录中的数据填充。
--|8|配置项可操作（服务不会中断）|如果已选择（设置为 true） ，则表示配置项当前正在操作中，而且服务不会中断。默认情况下，打开一个针对配置项的突发事件时，该配置项标记为出现故障。如果该配置项仍然正常工作，则应该标记此字段。
--|9|事件来源|参见“事件来源”定义
--|10|服务中断开始时间|(((
--服务中断开始的日期和时间。服务中断的开始和结束时间用于衡量“服务级别协议” (SLA) 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但打开或关闭突发事件之前可能会经历几分钟或几小时，因此，需要变更该值，以报告实际的服务中断开始和结束的时间。例如，设备可能在夜间出现了故障，而且必有人报告该问题
--
--之后，突发事件才会打开。在此情况下，默认的打开时间不能准确反映服务中断时间。
--)))
--|11|服务中断结束时间|服务中断结束的日期和时间。服务中断的开始和结束时间用于衡量 SLA 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但需要变更该值以报告实际的服务中断结束时间。例如，重新启动配置项之后，可以对其进行操作，但可能要花数分钟或数小时，才能更新记录，以报告突发事件已关闭。在此情况下，默认的关闭时间不能准确反映实际的服务中断时间。
--|12|位置|报告突发事件的位置。此字段由已升级交互中的数据预先填充。此字段仅供参考。
--|13|标题|(((
--概述突发事件的简短描述。此字段由已升级交互中的数据预先填充。
--
--此为必填字段。
--)))
--|14|描述|(((
--突发事件的详细描述。此字段由已升级交互中的数据预先填充。
--
--此为必填字段。
--)))
--|15|类别|描述突发事件类型，由已升级交互中的数据预先填充。
--|16|区域|此字段由已升级交互中的数据预先填充。对此区域的选择取决于类别。
--|17|子区域|第三级交互分类，主要用于进行报告。此字段由已升级交互中的数据预先填充。
--|18|影响度|(((
--此字段由已升级交互中的数据预先填充。它指明了突发事件对业务产生的影响。
--
--影响和紧急程度用于计算优先级。
--)))
--|19|紧急度|(((
--此字段由已升级交互中的数据预先填充。紧急程度表示此突发事件对于组织的紧
--
--迫程度。紧急程度和影响用于计算优先级。
--)))
--|20|优先级|此突发事件相对其他突发事件的排列顺序。优先级值是根据初始影响和紧急程度来计算的。只有从交互更新或升级突发事件时，此字段才显示。
--|21|SLA目标日期|下一个“服务级别目标”(SLO) 到期的日期和时间。此字段基于与突发事件信息相匹配的 SLO 进行填充，所用日期是违反协议之前即将到期的 SLO。
--|22|解决代码|(((
--指定一个预定义的解决代码，用于说明如何解决突发事件。此字段的预置选项基于客户的参考数据。
--
--建议以下预置解决代码：
--
--• 不可重现
--
--• 超出范围
--
--• 请求被拒
--
--• 通过变更/ 服务请求解决
--
--• 通过用户说明解决
--
--• 通过应对措施解决
--
--• 无法解决
--
--• 被用户撤销
--)))
--|23|关闭代码|此项是在服务台质控员在回访时，同用户确定的最终结果
--|24|解决方案|提供对突发事件解决方案的说明。
--
--
--== 7.2 事件影响度 ==
--
--|(% rowspan="2" %)**影响度**|(% rowspan="2" %)**定义**|(% colspan="5" %)**判断依据**
--|**系统级别**|**停止时间**|**恢复时间**|**大面积报障类型**|**影响范围**
--|(% rowspan="4" %)1级-特别重大|(% rowspan="2" %)造成系统完全损坏或严重损坏，数据全部或大部分损坏，且无法进行系统修复或容灾切换的，必须重建系统，备份恢复数据方可恢复正常服务|I级|N/A|N/A|N/A|N/A
--|II级|N/A|N/A|N/A|N/A
--|(% rowspan="2" %)信息系统数据丢失或被窃取、篡改、假冒，对公司形象造成负面影响，可能对社会稳定构成威胁的|I级|N/A|N/A|N/A|N/A
--|II级|N/A|N/A|N/A|N/A
--|(% rowspan="6" %)2-严重|(% rowspan="6" %)因重大系统故障引发的，造成系统服务停止，或系统大量重要数据损坏，且一定时间内无法恢复系统正常运行的|(% rowspan="2" %)I级|(% rowspan="2" %)>1小时|(% rowspan="2" %)>4小时|(% rowspan="2" %)网络故障|同一栋楼或五名以上用户
--|同一线路有三个或以上车站
--|(% rowspan="2" %)II级|(% rowspan="2" %)>2小时|(% rowspan="2" %)>8小时|I、II级系统故障|两个或以上用户
--|III级系统故障|三个或以上用户
--|III级|>4小时|>16小时|N/A|N/A
--|IV级|>8小时|>24小时|N/A|N/A
--|(% rowspan="2" %)3-一般|(% rowspan="2" %)(((
--能够导致较小影响或破坏的事件；
--
--影响少部分客户；
--
--监控工具产生一般告警
--)))|N/A|N/A|15天内|设备故障|三个或以上用户
--|N/A|N/A|1天内|病毒问题|三个或以上用户
--|(% rowspan="2" %)4-微小|(% rowspan="2" %)微小故障指的是不会影响业务连续性的故障。例如键盘鼠标损坏，无法连接INTERNET等故障。|N/A|N/A|二周内|桌面|五个或以上用户
--|N/A|N/A|5分钟内|基础架构预警信号|一个或以上
--
--
--== 7.3 事件紧急度 ==
--
--|紧急度编码|紧急时间标准|描述
--|1-非常紧急|8小时|服务需8小时内提供（恢复）
--|2-紧急|24小时|服务需24小时内提供（恢复）
--|3-一般|48小时|服务需48小时内提供（恢复）
--|4-略微紧急|72小时|服务需72小时内提供（恢复）
--
--
--== 7.4 事件优先级 ==
--
--|(% colspan="2" rowspan="2" %)优先级|(% colspan="4" %)影响度
--|1-特别重大|2-严重|3-一般|4-轻微
--|(% rowspan="4" %)紧急度|1-非常紧急|1-最高|2|2|3
--|2-紧急|2|2-高|3|3
--|3-一般|2|3|3-中|4
--|4-略微紧急|3|3|4|4-低
--
--
--== 7.5 事件来源 ==
--
--给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。
--
--|编号|来源|描述
--|1|用户报告|用户通过电话、邮件或WEB报告的事件，服务台人员手工创建事件单
--|2|监控告警|监控工具发现的告警事件
--|3|日常运维发现|IT运维部日常运维检查产生事件
--
--
--== 7.6 事件性质 ==
--
--|类别|信息项|说明
--|突发事件|访问|授权错误
--|突发事件|访问|登录失败
--|突发事件|数据|数据或文件损坏
--|突发事件|数据|数据或文件不正确
--|突发事件|数据|数据或文件丢失
--|突发事件|数据|超过存储限制
--|突发事件|失败|错误消息
--|突发事件|失败|不正常工作
--|突发事件|失败|作业失败
--|突发事件|失败|系统故障
--|突发事件|硬件|硬件故障
--|突发事件|硬件|丢失或被盗
--|突发事件|性能|性能降低
--|突发事件|性能|系统或应用程序挂起
--|突发事件|安全|违反安全性
--|突发事件|安全|安全事件/ 消息
--|突发事件|安全|病毒警报
--
--
--== 7.7 事件分类 ==
--
--|类别|子类|一级模块
--|(% rowspan="72" %)应用系统|(% rowspan="6" %)外部网站（含子公司网站）|招贤纳才
--|招标投标
--|乘客服务
--|企业概况
--|企业商务
--|新闻中心
--|(% rowspan="2" %)企业内部门户|UUV用户管理
--|SSO应用系统管理
--|(% rowspan="6" %)财务管理系统|总帐管理
--|应付管理
--|应收管理
--|固定资产管理
--|项目会计管理
--|预转资管理
--|资金管理系统|
--|(% rowspan="7" %)合同管理系统|范本管理
--|合同计划
--|合同招标
--|合同台账
--|合同管理
--|合同支付
--|系统管理
--|运营设备维修系统|
--|运营施工调度管理系统|
--|运营物流管理系统|需求管理
--| |计划管理
--| |采购寻源管理
--| |采购订单管理
--| |物资库存管理
--|票务管理系统|
--|GIS系统|
--|(% rowspan="7" %)数字认证平台|部门管理
--|用户管理
--|系统日志查询
--|验证选项
--|证书管理
--|印章制作
--|证书审计查询
--|SPS平台|
--|IT运维系统|
--|办公自动化系统（新）|
--|办公自动化系统（旧）|
--|合同管理系统（新）|
--|档案管理系统（新）|
--|P3E|
--|档案管理系统（旧）|
--|统一通讯平台|
--|视频会议系统|
--|基建物流管理系统|
--|人力资源管理系统|
--|财务管理系统|
--|原OA系统|
--|立项管理系统（原OA）|
--|企业内部门户|
--|工程设计管理系统|
--|内部专家评标系统|
--|内部网站（含信息专区）|
--|交流园地|
--|WCM|
--|内部网站后台|
--|外部网站后台|
--|外部网站招聘管理|
--|外部网站招投标管理|
--|资产标识码系统|
--|企业统计报表系统|
--|运营日报|
--|MAXIMO系统|
--|施工调度管理系统|
--|工作证管理系统|
--|车站收益系统|
--|系统开发服务|
--|系统培训服务|
--|桌面终端| |
--|服务器| |
--|存储和备份系统| |
--|网络| |
--|其他| |
--
--
--== 7.8 事件关闭代码 ==
--
--|编号|代码|描述
--|1|已完成|设备、业务系统等故障已得到修复；
--|2|未完成|(((
--故障没有被修复，需要再次进行处理；
--
--对于该类事件，需要重新开单，并分配给原来处理该事件的人员进行处理。
--)))
--
--
--
--= **8. 与其他流程的关系** =
--
--
--(% style="text-align:center" %)
--[[image:1730466916388-384.png]]
--
--* 和交互管理流程的关系
--
--用户交互流程作为事件管理流程的入口之一，统一由服务台接收用户各种需求如故障申报、服务请求等，然后再分别转到事件管理流程处理故障。
--
--* 和问题管理流程的关系
--
--事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。
--
--* 和配置管理流程的关系
--
--需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
--
--* 和变更管理流程的关系
--
--在事件的解决过程中，必要时需要发起变更请求来解决事件。
--
--* 和服务请求管理流程的关系
--
--在事件的解决过程中，必要时需要发起服务请求来解决事件。
--
--* 和日常运维管理流程的关系
--
--在日常运维的过程中，如检测到有潜在风险或已发生的故障，需要发起事件单进行处理。
--
--* 和服务级别管理流程的关系
--
--事件管理流程中的优先级根据服务级别协议来确定，事件管理流程产生的故障中断时间等数据是服务级别管理的数据来源之一。
--
--
--
--
--
--= **9. 关键流程衡量指标** =
--
--流程的考核指标是为了判断流程的效率和有效性，利用整合的指标数据来确定流程改进的机会，以确保流程的有效性和效率。下面是有效测量用户交互管理流程输出的典型指标：
--
--|衡量指标|统计方法
--|事件总数|(((
--数量：在事件单中根据以下条件过滤
--
--【重复事件标记】为空
--
--【事件解决代码】不等于‘消失’or‘误报’or‘可忽略’
--
--【事件发生时间】在统计周期内
--)))
--|事件关闭的数量|数量 ：在事件总数中过滤【事件状态】＝‘关闭’
--|事件成功关闭的数量/比率|(((
--数量：在事件总数中过滤【事件关闭代码】＝‘已完成’
--
--比率：数量 / 事件总数  × 100 %
--)))
--|规定时间内解决的事件数量/百分比|(((
--数量：在事件总数中过滤(（【实际完成时间】－【登记时间】）<【事件完成期限】)and 【事件关闭代码】＝‘已完成’
--
--比率：数量/事件总数 × 100 %
--)))
--|规定时间内响应的事件数量/百分比|(((
--数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
--
--比率：数量/事件总数 × 100 %
--)))
--|平均解决时间|(((
--完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
--
--平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
--)))
--|超时未解决的事件数量|数量：在事件总数中过滤(（【实际完成时间】－【登记时间】）<【事件完成期限】)and 【事件状态】！＝‘关闭’
--|事件的一次解决率|(((
--数量1：在事件总数中过滤【事件关闭代码】＝‘已完成’
--
--数量2：在事件总数中过滤【事件关闭代码】＝‘未完成’
--
--比率：（数量1－数量2 ） / 数量1  × 100 %
--)))
--
--
--
--= **10. 功能性需求** =
--
--* ITSM平台与监控平台集成，监控系统生成的告警事件自动在ITSM平台生成事件单，并由协调员分派处理人员；
--* 分派和转派事件单、创建变更单或请求单等人员转换的节点需要有短信通知提醒；
--
--=   =
--
--=   =
--
--= **11. 流程质量控制** =
--
--
--(% style="text-align:center" %)
--[[image:1730466981326-640.png]]
--
--流程活动：
--
--|序号|(% style="width:126px" %)活动|(% style="width:1049px" %)说明|(% style="width:330px" %)角色
--|1|(% style="width:126px" %)现有流程评估|(% style="width:1049px" %)通过对KPI的完成程度，事件历史记录等数据进行差距、趋势分析，定期对事件管理流程的实施有效性、服务质量和用户满意度进行回顾；生成差距分析评估报告、趋势分析报告|(% style="width:330px" %)流程经理、流程执行人员
--|2|(% style="width:126px" %)制定改进计划|(% style="width:1049px" %)根据差距分析评估报告、趋势分析报告总结待改进项，制定改进计划，改进计划中包括：流程的待改进项和改进机会、改进收益、执行改进计划可能带来的影响和风险、所需资源、测试和培训计划、实施计划、相关的支持文档等内容|(% style="width:330px" %)流程经理、流程执行人员
--|3|(% style="width:126px" %)审批改进计划|(% style="width:1049px" %)事件经理协调改进涉及到的相关人等对改进计划进行评估审批；提交RFC|(% style="width:330px" %)流程经理
--|4|(% style="width:126px" %)执行改进计划|(% style="width:1049px" %)调动资源，组织相关人员执行被批准的改进计划|(% style="width:330px" %)流程经理、流程执行人员
--|5|(% style="width:126px" %)回顾|(% style="width:1049px" %)对改进后的结果进行回顾，评估改进计划是否成功，存在哪些待改进项；依据PDCA方法论再次执行步骤1对现有流程进行评估，对流程进行持续改进，起到对流程质量控制的作用|(% style="width:330px" %)流程经理、流程执行人员
--
--* 需要调整的既有文件及调整要求
--
--|**序号**|**既有文件名**|**调整内容**
--|1|《大面积报障定义》|
--
--
--
--= **附录 评审修改记录** =
--
--
--|(% colspan="2" %)(((
--**文件收到时间：2012年7月18日**
--
--**通过评审时间：2012年X月XXx日    **
--)))
--|(((
--项目报告
--
--名称：
--)))|XX地铁XXXX年信息化基础架构平台建设项目_ ITIL咨询阶段成果
--|报告内容摘要：|事件管理流程设计
--|质量控制小组（含运维）评审意见及修改记录|(((
--1.紧急/重大事件与应急预案的衔接关系
--
--解答： 在紧急/重大事件子流程对应急预案的启动节点作了说明，同时简单描述了应急预案应涵盖的内容。
--
--
--2.信管部在紧急/重大事件流程上的体现
--
--解答：已重新制订紧急/重大事件流程图，明确标示信管部的活动节点。
--
--
--3.大面积报障的优先级定义，要和事件管理流程的影响度匹配。
--
--解答：已在7.2事件影响度加入了大面积报障的定义。
--
--
--4.紧急、重大事件需要补单
--
--解答：已增加补单原则。
--
--
--)))
--|项目总监评审意见及修改记录|
--|(% colspan="2" %)(((
--**评审结论：**
--
-- [√ ] 通过                      [ ]不通过
--
--
--质量控制小组组长签字：                           项目总监签字：
--
--年    月    日                                   年    月    日
--)))
--
--

1730466981326-640.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-40.8 KB

Content

粤ICP备17056641号

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