文档更改22 项目ITIL事件管理过程

由 superadmin 于 2024/10/30, 21:15 最后修改

从版本< 2.1

由superadmin编辑
在2024/10/30, 21:15上

到版本

由superadmin编辑
在2024/10/30, 21:11上

修改评论上传新附件1730293916430-298.png

Raw
已渲染

Summary

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

Details

Page properties

标题

...	...	@@ -1,1 +1,0 @@
1		-22 项目ITIL事件管理过程

父

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

Content

@@ -1,320
          +1,0 @@
--= **1. 前言** =
--
--== **1.1 目的** ==
--
--事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
--
--* 在成本允许的范围内尽快恢复服务
--** -   ~-~- 快速响应服务请求（电话/Web/邮件等）
--** -   ~-~- 沟通事件解决的状态
--** -   ~-~- 和客户确认事件的解决
--* 进行事件控制
--** -   ~-~- 按规范记录事件
--** -   ~-~- 就事件的优先级，影响度 进行分类
--** -   ~-~- 分析，诊断，必要时进行升级
--** -   ~-~- 监视并结束事件
--** -   ~-~- 进行定期服务流程回顾
--* 提供 IT 管理信息
--** -   ~-~- 人力资源利用情况
--** -   ~-~- 故障处理情况
--** -   ~-~- 支持效率
--
--
--== **1.2 适用范围** ==
--
--包括xxx项目相关的所有 IT 生产环境系统所产生的申告、故障、咨询。包括需求人员驻点，收集到的客户提出的申告、故障和咨询
--
--本事件管理范围不包括尚处于开发或测试环境的系统和应用引发的事件。
--
--
--
--== **1.3 名词解释** ==
--
--|**术语**|**解释**
--|ITIL|信息技术基础设施库（Information Technology Infrastructure Library），ITIL归纳了IT服务产业内的最佳实践
--
--
--== **1.4 参考资料** ==
--
--|**编号**|**资料名称**|**作者**
--|1|IT服务管理基于ITIL的全球最佳实践|Jan Van Bon
--|2|XX业务支撑网网管系统运维管理流程梳理项目-运维管理流程概要设计|HP
--
--
--
--
--= **2. 角色与职责** =
--
--|**角色**|**职责**|**备注**
--|高层领导（总监以上级别高层管理人员）|(((
--高层领导（总监以上级别高层管理人员）
--
--从宏观上对事件管理流程进行指导、协调。
--
--
--)))|
--|事件经理|(((
--**事件经理是事件管理流程的负责人，目前暂定为运维主管**
--
--职责包括
--
--一、事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
--
--1. 负责对事件的解决协调资源，保证事件的最终排除。处理各环节上报的问题和需要跟进的事宜。
--1. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源,促进支持工程师快速恢复正常服务
--1. 确保正确和广泛地收集和分析事件数据，发现 IT 和业务相关的问题
--
--
--二、从宏观上监控流程，确保在事件流程在项目范围内被正确的执行。当流程不能够适应工作需要的时候，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
--
--
--)))|
--|服务台|(((
--**BSS拓展支撑部运行维护室**
--
--运维人员负责将xxxIT运维支撑管理平台中属于XXX项目的工单登记在ITIL上，在ITIL上登记后提交运维组其他同事处理。部分平台工单外的事件，如电话问题，监控异常，也在ITIL平台建单跟进。
--
--现场可马上解决的问题，也仍然建议做好登记，可以事后在平台补单。
--)))|
--|一线|(((
--**BSS拓展支撑部运行维护室**
--
--一般来说，运维故障，xxxIT运维支撑管理平台工单、电话反馈，监控异常，先交运维内部处理。无法处理情况，提交XXX版本开发室协助。
--
--BSS拓展支撑部运行维护室，接收客户反馈问题，无法解决，直接联系XXX版本开发室处理。可以在ITIL上登记事件单，转给XXX版本开发室跟进。
--)))|
--|二线|(((
--**XXX版本开发室、研发测试室、信息系统部**
--
--运维人员，对于无法解决的问题，提交开发组、测试组、信息系统部，进行后续的问题解决。
--)))|
--
--
--
--= **3. 输入** =
--
--|活动编号|对应输入
--|4.1|登记事件单
--|4.2|非紧急事件单
--|4.3|非紧急事件单
--|4.4|非紧急事件单
--|4.5|非紧急事件单
--|4.6|非紧急事件单
--|4.7|非紧急事件单
--|4.8|紧急事件单
--
--
--
--= **4. 流程图** =
--
--(% style="text-align:center" %)
--[[image:1730293916430-298.png]]
--
--=   =
--
--=   =
--
--= **5. 过程描述** =
--
--== **5.1 事件登记和分类** ==
--
--* 事件单来源：
--** 客户的投诉和问题，如通过热线、邮件、电话、面谈等方式提交的各种客户投诉或问题。
--** WEB系统的工单，如xxxIT运维支撑管理平台等平台的客户提交处理的工单。
--** 系统故障的告警或问题报告。运维人员实施监控发现的故障或问题、系统告警等
--** 测试漏洞扫描发现的异常
--* 登记人，详细记录相关信息，并转交一线处理；
--* 一般，为了能获取客户反馈投诉、故障的完整信息，建议登记人自行处理的投诉、故障、问题也进行登记，可直接填写执行情况并直接关闭。
--* 对于初步判断为紧急的事件马上升级，由事件经理组织处理。
--** 事件优先级/影响度/紧急度定义，参见附录
--
--
--== **5.2 初始支持** ==
--
--1. 属于运维职责范围内可以处理的事件，运维人员应尝试解决，如果无法解决及时升级到一线处理（运维组），一线人员无法处理的，再直接分配到二线处理（开发组、测试组、信息系统部）
--1. 对于需要事件经理跟踪的事宜，转发事件经理。
--
--
--== **5.3 一线尝试解决** ==
--
--1. 运维组在接受到由服务台派发的事件后，进行调查诊断,尝试解决方案。
--1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态。
--1. 需要事件经理跟踪的事宜，转发事件经理。
--1. 判断为紧急的事件马上升级，由事件经理组织处理。
--
--==   ==
--
--== **5.4 二线尝试解决** ==
--
--1. 二线支持人员（开发组、测试组、信息系统部）接受事件，进行调查诊断，尝试解决方案
--1. 对于需要通过变更解决的事件。转入缺陷处理、需求处理流程（可争取到外需的情况）
--1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
--1. 判断为紧急的事件马上升级，由事件经理组织处理。
--1. 需要事件经理跟踪的事宜，转发事件经理。
--
--
--== **5.5 记录解决方案细节** ==
--
--1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息。
--1. 对于变通解决的事件，可由处理人员按照实际情况，服务台在关闭时触发新事件进行后续跟踪，并进行关联。也可以生成问题单，后续的跟进。
--
--
--== **5.6 关闭事件** ==
--
--1. 事件提出人确认事件是否已得到解决，如果解决或暂时解决，事件以成功解决或变通方法解决而关闭。
--1. 涉及客户的事件，建议与客户确认后再关闭。
--
--
--== **5.7 事件处理的监控与分析** ==
--
--1. 事件经理负责监控和跟踪整个流程的运行情况，及时跟进各种问题和告警信息。协调资源，保证各类事件处理满足客户的标准和要求，并获得最终解决。
--1. 对重复事件进行分析。
--
--
--
--== **5.8 紧急事件处理** ==
--
--1. 事件经理负责协调紧急事件的处理
--1. 紧急事件处理过程，按照实际需要，对必要信息进行发布
--
--【注】
--
--紧急事件包括：
--
--1) 来自客户或重要干系人（如高层领导）的需求中明确要求紧急处理的;
--2）可能或已经影响核心业务正常使用
--3）可能或已经引起大量（>50单）用户投诉的
--
--4）由事件经理识别为紧急事件的
--
--
--
--= **6. 输出** =
--
--|活动编号|对应输出
--|4.1|事件单
--|4.2.|非紧急事件单
--|4.3|非紧急事件单
--|4.4|非紧急事件单
--|4.5|非紧急事件单
--|4.6|非紧急事件单
--|4.7|非紧急事件单
--|4.8|紧急事件单
--
--
--
--= **7. 事件管理流程指标** =
--
--事件处理及时率 （参见SLA的工单处理及时率）
--
--
--
--
--= **8.附录** =
--
--1、事件定义：
--
--|类型|说明
--|咨询|用户询问XXX系统相关业务功能的事件。
--|请求|用户对XXX系统相关数据的提取、变更等请求的事件
--|投诉|用户针对XXX系统运维服务质量的事件
--|故障|(((
--由于XXX系统引起的故障的事件：
--
--1. 接口故障
--1. 配置故障
--1. 外部系统故障
--1. 硬件故障
--1. 资料故障
--1. 应用程序故障
--1. 其他故障
--)))
--|信息安全事件|与XXX系统信息安全相关的事件（参见《信息安全事件管理程序》）
--
--
--2、根据事件的影响度定义优先级如下：
--
--|(% colspan="3" %)**影响度**|(% rowspan="2" %)**处理期限**
--|**重大**|**严重**|**一般**
--|黑色故障、红色故障|橙色故障| |12小时
--| | |黄色故障、轻微故障|24小时
--| |投诉|请求|24小时
--| | |咨询                        |48小时
--
--XXX系统故障共分为黑色故障、红色故障、橙色故障、黄色故障和轻微故障等五个级别，其中轻微故障和黄色属于一般故障，橙色故障属于严重故障，红色和黑色故障属于重大故障；
--
--各级故障定义标准如下：
--
--**1.黑色故障**
--
--以下几种情形之一的故障将定义为黑色故障：
--
--* 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在100万以上或达到总承载用户规模的80%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
--* 当次故障累计用户投诉达到1000单——以客户提供的投诉数为准；
--* 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过1小时或系统切离线时间超过10小时（不包括计划内工程操作）；
--* 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过12小时（不包括计划内的出账延迟）；
--
--**2.红色故障**
--
--以下几种情形之一的故障将定义为红色故障：
--
--* 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在50万以上或达到总承载用户规模的50%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
--* 当次故障累计用户投诉达到500单——以客户提供的投诉数为准；
--* 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过30分钟或系统切离线时间超过5小时（不包括计划内工程操作）；
--* 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过8小时（不包括计划内的出账延迟）；
--
--**3.橙色故障**
--
--以下几种情形之一的故障将定义为橙色故障：
--
--* 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在20万以上或达到总承载用户规模的20%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
--* 当次故障累计用户投诉达到100单——以客户提供的投诉数为准；
--* 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过5分钟或系统切离线时间超过2小时（不包括计划内工程操作）；
--* 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过5小时（不包括计划内的出账延迟）；
--* 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部考核扣分；
--
--**4.黄色故障**
--
--以下几种情形之一的故障将定义为黄色故障：
--
--* 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在5万以上或达到总承载用户规模的10%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
--* 当次故障累计用户投诉达到50单——以客户提供的投诉数为准；
--* 由XXX系统故障引起的导致关键业务（语音、数据和短信业务使用）短时间中断（介于1分钟与5分钟之间）或系统切离线且时间不超过2小时（不包括计划内工程操作）；
--* 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过2小时（不包括计划内的出账延迟）；
--* 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部通报批评；
--
--**5.轻微故障**
--
--以下几种情形之一的故障将定义为轻微故障：
--
--* 当次故障累计用户投诉达到20单——以客户提供的投诉数为准；
--* 由于数据下发不及时或下发数据错误导致与周边系统接口异常；
--* 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部问责；
--* 由于违规性操作导致系统运行异常但对业务未产生实质性影响的故障；
--* 由于业务突变、版本变化或参数错误等原因导致系统部分进程/功能异常退出但对业务为产生实质性影响的故障；
--
--
--3、根据事件的紧急度定义处理优先级如下:
--
--|**紧急度**|**说明**
--|**高**|1)来自客户或重要干系人（如高层领导）的需求中明确要求紧急处理的;
--2）可能或已经影响核心业务正常使用
--3）可能或已经引起大量（>50单）用户投诉的
--|**中**|(((
--1）可能或已经引起非核心业务正常使用的
--2）可能或已经引起用户投诉的
--
--3）来自客户的需求，但未明确要求紧急处理的
--)))
--|**低**|不涉及业务使用，也不涉及用户投诉的普通事件
--
--
--4、事件的升级机制
--
--事件升级主要是针对类型为故障和投诉的事件，涉及以下几种情形之一将对该事件级别进行升级处理：
--
--* 故障发生后没有根据故障通报管理要求及时进行故障通报，则在故障级别定义标准定义的故障级别基础上，对本次故障级别进行升一级处理，最高可以升级到黑色故障；
--* 故障持续时间和影响范围进一步恶化，已经达到更高级别故障级别定义标准，则自动升级到更高级别的故障级别，最高可以升级到黑色故障；
--* 由于故障影响比较恶劣，被客户投诉到公司副总或以上级别管理层，则在故障级别定义标准定义的故障级别基础上，对本次故障级别进行升一级处理，最高可以升级到黑色故障；
--* 由于故障影响比较恶劣，被投诉到媒体或网络，在社会上引起极其负面的影响，则在故障级别定义标准定义的故障级别基础上，直接升级到红色或黑色故障；
--* 由于服务质量问题，被客户投诉到公司副总或以上级别管理层，则该投诉升级为严重事件。

粤ICP备17056641号

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