24 某市供电局ITIL事件管理策略
1. 文档介绍
1.1 文档简介
本文档介绍了事件管理的基本情况,描述了XX供电局实施事件管理的范围和策略。
1.2 文档目标
本文档能够帮助XX供电局更好的理解事件管理实施的原则,为其实施事件管理提供指南。
2. 概述
事件管理流程是负责解决IT服务的突发事件、问题和客户请求等的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务,所以它的特点往往是以解决表征现象为目的,而不在于查找根本原因。
东莞供电局事件管理流程应该包括:
- 接收、记录、优先级分配、事件分类;
- 一线解决或提交;
- 事件生命周期跟踪;
- 事件解决方案确认和关闭;
- 一线用户联络;
- 升级;
- 重大事件处理。
3. 范围
事件管理范围包括IT生产环境中的应用系统及相关的所有IT基础设施所产生的故障、服务请求及申述。
涉及的领域有:
- 桌面设备维护
- 业务系统维护
- 机房环境维护
- 信息平台维护
不包括:尚处于开发或测试环境的应用系统和基础设施引发的事件。
4. 定义
4.1 事件
Ø 事件是指任何不属于标准服务运营的,导致(或可能导致)服务的中断或服务质量降低的情况。事件不仅包括硬件和软件故障,还包括服务请求及申诉。
根据XX供电局的业务要求和管理要求,按照事件性质定义如下三类事件:
4.2 信息安全事件
信息安全事件由单个或一系列有害的或意外的信息安全事态组成,它们具有损害业务运作和威胁信息安全的极大可能性。
4.3 优先级
优先级是事件管理的一个关键要素,优先级决定处理事件的顺序及所需的资源,应考虑事件的影响度和紧急性。
影响度的定义如下:
编号 | 影响范围 | 影响程度 |
1 | 个别用户 (1-2个人) | 低 |
2 | 多用户(3-5人) | 中 |
3 | 大量用户 (6人以上) | 高 |
紧急度的定义如下:
编号 | 优先级 | 说明 |
1 | 紧急 | 信息安全事件、 重大事件 |
2 | 高 | 申诉、应用系统故障 |
3 | 中 | 桌面系统故障 |
4 | 低 | 服务请求、硬件第三方维保 |
优先级矩阵
优先级 | 影响度 | |||
低 | 中 | 高 | ||
紧急度 | 低 | 低 | 低 | 中 |
中 | 低 | 中 | 中 | |
高 | 中 | 中 | 高 | |
紧急 | 中 | 高 | 紧急 |
优先级及其时限
编号 | 优先级 | 时限 |
1 | 紧急 | 12小时 |
2 | 高 | 48小时 |
3 | 中 | 72小时 |
4 | 低 | 120小时 |
4.4 事件状态
事件状态表明事件所处的处理状态,本文规定的事件状态如下:
事件状态 | 描述 |
已登记 | 已由服务台登记, |
一线处理中 | 一线处理中 |
二线处理中 | 已分派到二线并接受 |
等待支持处理中 | 已查明问题,等待其他部门 |
三线处理中 | 三线技术支持/厂商处理 |
厂商处理中 | 已升级到厂商 |
已解决 | 已解决事件 |
结束 | 事件已关闭 |
4.5 事件分类
以下是事件分类表列举:
事件分类代码 | 说明 | |
UNIX 服务器 | 硬件 | 与服务器相关 |
系统软件 | ||
Windows 服务器 | 硬件 | |
系统软件 | ||
数据库 | Oracle | 与数据库相关 |
MS SQLServer | ||
Sybase | ||
防火墙 | 与防火墙相关 | |
网络 | 交换机 | 与网络相关 |
路由 | ||
线路 | ||
PC端网卡 | ||
客户端 | PC硬件 | 与客户端相关 |
系统软件 | ||
其他应用软件 | ||
Office软件 | ||
打印机 | ||
PKI应用安全插件(口令助手、CSP程序等) | ||
USB读卡器及其相关程序 | ||
智能卡口令问题 | ||
应用 系统 | 进程 | 与应用系统相关 |
数据 | ||
参数 | ||
代码 | ||
接口 | ||
机房环境 | 与环境相关 | |
服务请求 | 业务系统权限申请 | 与服务请求相关 |
其他请求服务 | ||
设备耗材申请 | ||
软件安装申请 | ||
投诉 | 与投诉相关 | |
其他 | 与其他相关 |
4.6 重大事件(特殊事件)
编号 | 重大事件(特殊事件) |
1 | 服务器宕机 |
数据库访问受阻 | |
信息安全事件 | |
信息机房电力故障 | |
服务接口不通畅(高于1小时) | |
业务系统应用故障(超过20人同时) | |
数据备份失效 | |
2 | 局领导/部门领导指派的事件 |
注:信息安全事件参见信息安全管理体系《信息安全事件管理程序》分类。
5. 事件处理
5.1 一般事件
一般事件按照标准流程处理。参见事件管理流程文件。
5.2 事件升级
系统将自动升级解决时间超过限制的事件(事件的紧急度对应相应的处理时间),超过解决时限的事件将通知相关工程师及事件经理,必要时由事件经理协调处理。
在解决时限内,一线人员可以升级自己无法解决的事件,请求二线、三线支持,仍然无法解决的事件,由事件经理协调处理。
5.3 重大事件处理
任命相应的岗位负责人为重大突发事件的责任人,负责对重大突发事件进行监控以及回顾,并通报事件经理。重大突发事件处理完成后,要进行相应的回顾和分析,并记录到服务改进报告中。
6. 事件记录和报告
6.1 事件记录和维护
所有接收到的事件(包含咨询及投诉)都必须记录到系统当中。
所有与某事件相关的人员都应该可以得到该信息。
6.2 事件报告
每月由服务报告流程生成一份服务台管理报告。
报告的阅读者为事件经理、问题经理、服务级别经理、管理体系负责人。
报告内容包括:
- 事件分类统计数;
- 各类事件平均解决时间;
- 各类事件平均响应时间;
- 服务台、一线支持人员、二线支持人员分别处理的事件数;
- 服务台满意度统计;
- 趋势分析及改进建议。
7. 流程接口
7.1 信息安全
安全信息事件分类标准参考《信息安全事件管理程序》事件分类文档,发生信息安全事件由系统通知安全经理,并按《信息安全事件报告流程》执行。
7.2 问题管理
经事件经理协调处理仍未解决的突发事件应立即提交问题管理流程。
重复发生的突发事件应确定是否作为问题提交问题管理流程。
业务影响范围高的重要突发事件也应确定是否作为问题提交问题管理流程。
8. 持续改进
改进的原因:
- 流程执行过程中发现的不足;
- 流程自检过程中发现的不足;
- 内部审核及外部审核中,发现的与ISO20000服务管理体系标准的不符合项;
- 管理评审过程中发现的服务/流程改进点。
改进方法:
- 组织流程改进讨论会议,与各方就改进需求、改进目标、改进方案沟通讨论;
- 组织人员根据讨论结果提出服务管理改进计划及方案;
- 服务管理体系负责人审批改进计划;
- 对服务改进过程进行监控,对人事和资源做出合理安排;
- 向管理体系负责人汇报改进结果;
- 根据服务改进结果安排相应的知识转移工作,包括文档的更新发放、培训课程的安排等。