事件管理制度模板Word文档格式.docx
- 文档编号:17873970
- 上传时间:2022-12-11
- 格式:DOCX
- 页数:14
- 大小:72.56KB
事件管理制度模板Word文档格式.docx
《事件管理制度模板Word文档格式.docx》由会员分享,可在线阅读,更多相关《事件管理制度模板Word文档格式.docx(14页珍藏版)》请在冰豆网上搜索。
工程师提供的软件和硬件技术支持,包括技术支持工程师、运维工程师
第三方工程师
指供应商或生产厂家提供的技术支持
重大事件
客户合同中规定的重大事件
2.2引用标准
1)GB/T28827.1—2012信息技术服务运行维护第1部分:
通用要求;
2)GB/T28827.2—2012信息技术服务运行维护第2部分:
交付规范;
3)GB/T28827.3—2012信息技术服务运行维护第3部分:
应急响应规范;
4)ITSS1-2015信息技术服务运行维护服务能力成熟度模型V1.0;
5)ISO/IEC27001:
2013信息技术-安全技术-信息安全管理体系要求;
3.适用范围
事件管理范围包括在运维服务工作中产生的操作咨询和故障处理,主要包括:
1)服务请求和技术咨询:
信息系统使用过程中,安装、配置和使用等技术咨询。
信息系统升级、扩容和改造等技术咨询活动。
2)故障处理:
对信息系统的软件和硬件故障进行处理。
4.过程定义
4.1输入
输入
来源
用户报修
客户
4.2输出
输出
去向
客服热线电话记录
运维系统服务记录
ServiceDesk
4.3职责权限
服务台经理
1)定义并维护事件管理流程文件及所需要的记录模板;
2)管理事件管理流程的实施;
3)确保事件管理流程目标的实现;
4)识别事件管理过程中存在的隐患并及时向运维中心主任提出;
5)定期向部门经理汇报实施过程中存在的问题;
定义并维护事件管理流程文件及所需要的记录模板;
6)负责知识库的扩充、完善和修改。
1)收集有关事件解决方案的历史数据;
2)事件的调查和诊断;
3)根据解决方案把事件的影响降到最小,并确保快速恢复到正常服务水平;
4)遇到事件无法解决,应及时派发工单给相关运维工程师,必要时进行事件升级,上报运维中心主任;
5)与服务请求的提交者或其他相关用户进行直接的沟通、跟踪、通报问题的处理情况;
6)将事件的解决步骤文档化,并录入后台;
7)事件解决后,让用户进行确认事件已解决;
8)结束事件,根据维护的实际情况更新相关信息。
1)负责解决服务台派发的工单,把事件的影响降到最小;
2)收集有关事件解决方案的历史数据;
3)事件的调查和诊断;
4)根据解决方案进行服务恢复;
5)对利用“替代方案”解决的事件,在资源及时间允许时应找到事件根源;
6)将事件的解决步骤文档化;
7)在无法解决事件时向服务台汇报并进行事件升级。
技术支持工程师
1)在规定的时间内解决事件;
2)对利用“替代方案”解决的事件,在资源及时间允许时应找到问题根源;
3)在需要时及时利用其它资源(如:
开发商,厂家)参与事件解决;
4)将事件的解决步骤文档化;
5)根据解决方案进行服务恢复;
6)协助运维工程师或服务台热线工程师完成事件分析和处理;
7)承担运维技术研发工作。
4.4过程重要控制点
需要转运维工程师支持、二线专业工程师支持解决,由服务台热线工程师负责跟踪,直到确认事件关闭。
5.过程策略
5.1责任人策略
用户通过电话,邮件,即时通讯工具,现场等方式向服务台或相关工程师报告事件,服务台当班人员或相关工程师接到事件报告和服务请求后,及时在运维系统内作好记录。
服务台或相关工程师记录事件后,要分析事件是否在受理责任范围内。
如果在受理范围内,根据工单分类派给相关事件处理人员,并通知事件处理人,要求事件处理人员回复对分派的事件单是否接受。
事件处理人负责向用户及时通报事件处理情况,事件解决后,服务台当前值班人员及时对申告人进行回访。
5.2分类策略
由于用户提供的信息或许不完整或不正确,可能导致开始的分类与最终的分类有很大的差别。
首先对事件按照基本事件类型进行分类,各类可以对应到相应的支持组,以便准确分配任务。
事件分类:
与服务目录分类保持一致
事件状态:
编号
状态
描述
1
待处理
已在系统中记录,未派单给工程师
2
已派单
已分配至工程师,工程师未处理
3
处理中
工程师正在处理过程中,事件未关闭
4
挂起
工程师正在处理,调用供应商技术支持工程师厂商支持或送外维修,尚未完毕
5
关闭
服务台确认,事件关闭
6
已归档
服务台回访客户结束。
5.3优先级策略
给事件分配优先级,以保证技术支持部对事件必要的重视。
分级应基于是事件的紧急程度和影响面。
所有事件都应划分到不同的优先级中,其中划分为一级的事件优先级为最高,
事件的紧急度分为三级:
紧急程度
备注说明
低
服务性能下降,但没有影响最终用户的正常业务
例如:
键盘大小写切换键失效、最终用户认为可以晚一些再恢复
中
部分服务不可用,最终用户正常业务受到影响
最终用户不能登陆业务系统
高
服务不可用,用户核心业务受到严重影响
重点最终用户、关键部门、领导层服务出现问题
事件的影响度分为三级:
影响程度
一般
信息系统运行维护过程中发生的已经影响或者即将影响个别最终用户
单一最终用户不能登录自己的台式机
严重
信息系统运行维护过程中发生的已经影响或者即将影响某部门或者某分支机构多数最终用户
机房的服务器或网络设备宕机及通讯线路中断4小时以内
重大
信息系统运行维护过程中发生的已经影响或者即将影响客户多数最终用户
发生火情、机房漏水等险情,以及机房的服务器或网络设备宕机及通讯线路中断4小时以上等
根据事件的影响度和紧急度确定事件的优先级,事件优先级分为四级:
事件级别
级别定义
影响业务范围
影响业务程度
业务修复紧急程度
整个系统或业务中断、某一业务或业务全省或全市中断
60%以上客户业务受影响
非常紧急
一级事件
业务或系统中断,客户部分业务瘫痪。
30%以上客户业务受影响
紧急
二级事件
业务或系统中断,小部分客户业务瘫痪。
10%以上客户业务受影响
普通
三级事件
系统内部发生故障但不影响客户正常使用,不影响业务。
无明显示影响
事件分类与故障等级与技术支持合同相关,如有合同定义,则以合同定义为准。
5.4目标解决时间策略和升级策略
为了更好的控制事件的解决,事件被分类分级,每类事件的解决都设定了目标时间。
目标解决时间表:
优先级
响应时间
目标解决时间
15分钟内响应
最快时间解决
4小时之内解决
30分钟内响应
8小时之内解决
60分钟内响应
16小时之内解决
升级策略的目的是确保不同优先级的事件分配到合适的资源来解决。
为了达到这个目的,定义了升级策略的时间框架。
当达到其时间界限时,如果事件还未解决,将触发升级机制。
事件升级时间表:
事件所处阶段
事件汇报人员范围
运维项目部经理(处理部门、服务台)
部门经理(处理部门、服务台)
分管副总
短信
电话
事件发现10分钟内
√
每30分钟或有新进展
事件恢复后10分钟内
一级
二级
事件发现30分钟内
每60分钟或有新进展
三级
目标解决时间*0.3
目标解决时间*0.5
目标解决时间*0.8
5.5裁剪策略
1)运维项目部经理应和客户商定事件的分类、分级标准,事件的升级机制。
2)运维项目部经理可根据项目环境裁剪本过程,报经运维中心主管批准。
6.事件流程
7.事件过程描述
7.1热线受理
客户通过热线电话、邮件、即时通讯报告事件,服务台热线工程师记录好相关信息,受理并进入事件处理流程。
服务台需要收集以下信息:
1)来电客户的单位名称、联系人、电话号码等基本信息。
2)影响业务的具体原因、故障现象以及所属优先级。
如果为重大事件,则需要上报给重大事件经理。
7.2事件记录和分类
对于来自热线电话、邮件、即时通讯收集的信息,服务台记录《运维记录单》,通过电话方式申告的需要询问客户详细的事件描述,然后根据用户的描述判断事件的分类、优先级等信息。
如果事件是关于供应商的问题,根据合同协议,直接转供应商技术支持工程师支持。
若事件比较重大且优先级为重大,则需要报告项目经理和部门经理。
7.3热线电话尝试解决
一线支持人员(服务台)受理事件后,首先根据用户所描述故障情况,参照知识库和配置库,对用户进行相应的指导解决。
一线支持人员(服务台)无法通过电话指导客户解决的事件,在征得客户同意的情况下,可以采用远程工具,登录客户计算机来操作解决。
7.4分派任务
经服务台尝试解决无果或经判断不属于服务台能力范围内的,提交运维工程师支持解决。
运维工程师直接远程支持或现场服务。
技术支持部:
负责研究解决运维中遇到的疑难问题,并分析其问题原因。
管理层:
负责运维人员新增、调配及各种配套服务设备添加、调配的审批,并牵头解决重大的故障或者服务中产生的纠纷问题。
7.5调查解决故障
运维工程师在现场通过标准配置进行比对等方法对故障进行分析,查找出故障原因。
技术服务人员根据故障分析结果确定解决方案,并与客户沟通执行解决方案所需要的时间,确定解决方案的可行性。
若发生的事件一时解决不了,需要与客户约定解决时间。
对于重大故障(故障等级为高或中)须做好数据备份。
事件解决后,运维工程师需对故障进行分析并写明解决办法,回复工单,并将新增的知识条目和配置变化情况提交到服务台。
7.6客户确认
待事件处理完毕,服务台需要与客户确认;
若是现场服务,还需要客户在《运维记录单》签字确认。
记录单上交到服务台
7.7资料归档
服务台将《运维记录单》进行归档。
7.8配置核对更新
当事件处理后配置项属性需要变更时,则由运维工程师提交配置管理员进行配置项修改,修改设备台账中系统配置信息。
7.9服务关闭
在服务台对用户进行回访后,根据回访情况决定该事件服务是否结束。
7.10客户回访
事件处理后3个工作日内,由服务台对客户进行回访,回访结果记录在《运维回访记录单》。
7.11服务报告
运维项目部经理按每月对事件进行总结和分析,并将报告发给运维部经理和运维中心主任进行评审,评审通过后的服务报告方可提交给客户。
事件报告内容包括(不限于):
1)本月事件总数。
2)本月服务响应总数。
3)解决事件总数。
4)与历史报告比较的趋势分析和预测。
8.重大事件处置流程
8.1流程图
8.2流程描述
1.服务台接收到来自项目的事件服务申请,根据相关指标识别为重大事件,需立即启动应急预案。
2.向应急小组报告情况,并每隔15分钟通报一次,直至事件关闭。
3.同时向技术支持部下发工单,要求立即启动预案,并提供现场所需的知识库、配置库、备件库相关信息。
3.技术支持部经理组建调查团队,并向现场的运维实施组了解情况。
4.通过分析,技术支持部拿出解决方案,提交应急小组审核。
5.若审核通过则交由现场的运维项目部进行实施,技术支持部监督并指导实施;
若审核不通过则技术支持部需进行制定方案。
6.实施后,由技术支持部对实施效果进行评审,出具评审报告并提交至服务台。
7.服务台接收评审报告并转发给应急小组。
8.服务台回访用户后即可关闭事件服务。
9.制作完结报告。
10.更新此次服务中所产生的知识条目、配置信息、备件信息。
9.衡量指标
(1)是否所有的事件都被记录、分类、分级、全程监控和跟踪;
(2)记录事件实际解决所需的时间,并按项目统计事件平均解决时间;
(3)记录事件总量、已解决事件量和未解决事件量,计算事件解决率;
(4)是否严格执行事件管理流程,包括事件的分优先级,分类,报告,升级以及改进等制度。
10.相关文件和记录
《问题管理制度》
《变更管理制度》
《配置管理制度》
《服务报告管理制度》
《知识库》
《运维记录单》
《满意度调查记录表》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 事件 管理制度 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)