信息网络运行维护管理规范方案文档格式.docx
- 文档编号:16035885
- 上传时间:2022-11-17
- 格式:DOCX
- 页数:53
- 大小:1.23MB
信息网络运行维护管理规范方案文档格式.docx
《信息网络运行维护管理规范方案文档格式.docx》由会员分享,可在线阅读,更多相关《信息网络运行维护管理规范方案文档格式.docx(53页珍藏版)》请在冰豆网上搜索。
影响程度
问题造成对IT环境的影响X围,包括对其他IT系统,对相关人员等。
优先级
问题需要找到解决方法和处理措施的紧急程度。
重大故障
在各系统的系统故障分级中定义为一级故障的故障现象,均视为重大故障。
一般故障
在各系统的系统故障分级中定义为二、三级故障的故障现象,视为一般故障。
1.3角色与职责
本过程设立运维负责人、支持受理人、问题反映人、各系统管理岗,岗位设立AB角,负责信息系统运维事件的管理,具体职责要求如下:
序号
角色名称
定义/职责
1
运维负责人
1.全面负责运维各项工作。
2.审核审批各项运行维护制度规X和工作流程,负责协调各部门间的工作。
3.负责与其他部门间的协调工作。
4.负责建立健全本级运维与上级运维部门、本级运维与下级运维之间高级技术支持之间的顺畅沟通机制。
5.负责本级运维队伍的管理、培训工作。
6.负责落实上级运维部门提出的运行维护任务。
7.管理运行维护部门员工的工作。
8.通过呼叫中心事件管理报告,监控事件管理的效率,改善运维服务质量。
9.负责系统重大故障及紧急事件的处理,并负责组织进行相关事故原因的调查分析,形成事故分析报告和相应的解决方案。
10.在业务部门,信息中心领导,以及信息中心内部维持良好的沟通渠道。
11.完善和维护事件管理系统。
2
支持受理人
1.负责接收用户反映的信息系统问题,并对问题记录、整理。
2.负责对事件分类和提供初始的支持。
3.将问题的解决步骤文档化。
4.将服务请求分派给适当的工作组。
5.跟踪服务请求的处理过程以确保在规定的时间内解决问题,同时在系统里更新相应信息。
6.对于无法解答的技术问题,及时转送其他相关人员;
对于无法解答的业务问题,及时提交运维负责人。
7.与服务请求的提交者进行直接的沟通,通报事件的处理情况。
8.在结束事件之前要确认服务请求的提交者对事件的解决过程及结果是否满意。
9.作为事件的责任人,监控,跟踪所有的事件处理过程,并作为和客户沟通的唯一联系点。
10.编制管理信息报告。
3
问题反应人
1.对于本级运维解决有困难的问题,负责向上级运维中心、高级技术支持或国家电网运维部门及时准确地上报。
2.对于紧急、重大故障问题,负责向上级运维中心、高级技术支持或国家电网运维部门及时准确地上报。
3.负责全程配合、协助国家电网解决上报问题,并跟踪问题的进展、解决、落实过程。
4
系统管理员
1.在规定的时间内解决服务请求。
2.对利用“临时方案"
解决的服务需求,在资源及时间允许时应找到问题根源。
3.在需要时(有重大故障及升级需求时),及时利用其它资源(开发商或供应商)帮助用户解决问题。
4.将服务请求的解决方案的步骤文档化,并录入系统。
5.更新文档记录。
6.和主机管理人、存储管理人、数据库管理人、中间件管理人一道,对业务系统实行全方位的管理。
1.4工作流程与活动
参与事件管理、服务请求管理、重大故障处理、事件升级、一般事件处理、服务报告管理流程涉及的系统运维工作。
具体工作内容如下:
1.3.1事件管理
运维事件管理的总体流程如图1《问题响应管理总体流程》所示:
1.支持受理人接受来自各种渠道的服务请求、告警、故障事件等;
2.通过服务请求管理系统将事件进行记录、分类、确定优先级;
3.根据预定义的重大故障分类,判断是否启动《重大故障处理流程》(见图3);
4.如遇紧急事件,则直接执行《升级流程》(见图4),由运维负责人直接调用适当资源尽快处理;
一般事件则执行《一般事件处理流程》(见图5)。
(图1问题响应管理总体流程)
1.3.2服务请求管理
1.支持受理人接受来自各种渠道提交的有关信息系统运维的服务请求、告警、故障事件等;
2.确认事件请求人是否属于服务对象。
如果不是,则拒绝服务转交其它部门处理;
问题概要需要在《服务请求记录表》(见附录1)中进行详细的记录,如详细情况描述;
1)按照预定义的“系统服务分类”对事件涉及的系统进行分类,如:
网络系统,主机系统、营销系统等;
2)根据预定义的配置管理数据库的相关内容,将事件与配置项联系起来;
3)选择事件的影响程度:
低:
造成个别用户不能正常访问。
中:
局域网内超过5%的用户不能正常访问。
高:
营销系统、“95598”系统等核心业务系统大面积瘫痪,不能正常对公众提供服务,造成负面的社会影响。
4)选择优先级:
无优先级:
无时限要求,在方便的时候排除故障。
24小时内排除故障。
8小时内排除故障。
4小时内排除故障。
最高:
2小时内排除故障。
服务请求管理流程如图4所示。
(图2服务请求流程)
1.3.3重大故障管理
支持受理人完成服务请求流程后,如果事件是属于影响程度最高的故障,则即刻启动《重大故障处理流程》;
1.向最终用户发出服务中断通知;
2.支持受理人同时要尽快将故障情况向运维负责人汇报;
3.运维负责人应立刻通知相关领导以及灾难恢复领导小组(由主要业务部门领导,信息中心领导,主管领导等组成),决定本故障是否通过上级运维部门才能解决,如果是,则由问题反映者联系上级运维中心,上级运维部门根据有关流程予以解决;
4.如果不用上级运维部门解决,则根据恢复时间标准确定是否启动应急预案;
确定需要启动应急预案后,由应急预案小组执行恢复计划,使系统尽快恢复运作;
5.同时运维负责人要召集所有相关技术专家(项目组技术负责人,服务商,厂商以及各系统管理员)进行集中诊断,制定系统修复方案。
并由相关系统管理人联合服务商一起执行系统修复方案;
6.系统修复并经测试成功后,支持受理人发布系统服务恢复通告;
7.联合系统管理员在服务请求系统中将故障的所有信息进行更新,如解决方案,关闭代码,如果在呼叫登记阶段录入的配置项目,分类等有误,需要一并修正;
8.联合相关系统管理员准备“重大故障责任报告”并提出整改措施;
9.运维负责人负责审阅批准重大事件责任报告,并向相关领导分发此报告;
10.运维负责人负责跟进整改措施。
重大故障管理流程如图5所示。
(图(图3重大故障处理流程)
1.3.4事件升级
如果支持受理人接到紧急的服务请求(优先级最高),或在一般事件处理流程中,事件的完成时限超过了承诺的服务时限时,支持受理人可以启动升级流程。
1.支持受理人通知运维负责人,请求支持;
2.运维负责人协调相关资源解决问题;
3.支持受理人负责跟踪事件进度以及确定事件状态;
4.事件解决后,由支持受理人与服务请求者确认并更新事件记录;
5.支持受理人关闭事件。
事件升级流程如图4所示。
(图4事件升级流程)
1.3.5一般事件处理
1、支持受理人接受的服务请求如果不属于“重大故障”或“紧急事件”,按照《一般事件处理流程》完成事件的处理。
一般事件处理流程如图6所示。
2、如果服务请求属于指定工作组的责任,支持受理人直接将服务请求分派给各工作组。
对分派给指定工作组的事件,支持受理人要负责跟踪事件的解决状态,并定期监督相关服务人员尽快完成。
如果相关服务组在接近服务时限(可定为超过服务时限的80%的时间)仍没有确定的解决方案,支持受理人需请求相关专家协助完成。
对不能在服务时限内完成的事件,支持受理人应通过《升级流程》加快事件的解决速度。
事件解决后,支持受理人通过等方式与呼叫者进行确认,并更新事件记录,关闭事件。
3、对于非指定工作组处理的事件,支持受理人对事件进行诊断分析,尝试解决。
4、对不能在线及时解决的事件,支持受理人应先在运维管理知识库中查找相应解决方案,找到解决方案后,尽快完成服务请求。
不能解决的事件,请尽快根据服务X围职责划分(服务支持流程人员表),将事件升级给二线支持人员,并跟踪事件处理状态。
如果相关二线支持服务组在接近服务时限的最后期限(可定为超过服务时限的80%的时间)仍没有确定的解决方案,相应系统管理人则需判断是否需要报请上级运维部门予以解决。
如果需要,则通过问题反映者向上级运维部门报告,上级运维部门则按有关流程予以解决,如果不需要则请求三线支持人员协助完成。
对不能在服务时限内完成的事件,支持受理人应通过《升级流程》加快事件的解决。
事件解决后,支持受理人通过等方式与服务请求者进行确认,并更新事件记录,关闭事件。
(图5一般事件处理流程)
支持受理人是事件管理流程的一线支持。
各应用系统管理员、网络管理员、主机管理员等是事件管理流程的二线支持工程师。
开发商、集成商、设备供应商等外部服务专家是事件管理流程的三线支持。
1.3.6服务报告管理
服务主管每月利用服务记录表,按照服务管理的指标分类整理各类数据,形成服务请求管理报告,提交给运维负责人进行审阅。
运维负责人负责与相关部门及业务部门针对服务管理报告进行沟通,如果必要提出诸如用户培训、系统优化等建议,并负责跟进改进计划。
1.5管理原则
1、运维中心应设立呼叫中心,做为IT服务管理与用户的接口,受理并处理用户的服务请求。
没条件设立呼叫中心的服务机构应设立服务热线。
2、除非特别的服务说明,任何事件处理不应绕过服务热线来解决。
3、所有最终用户的服务请求应由统一的系统记录在案,并通过系统完成工作分派,监测跟踪,事件升级管理和质量管理。
4、呼叫系统应包含对事件处理进行跟踪及监控的流程。
5、负责呼叫系统的员工应尽最大可能在一线解决用户的问题。
6、对所有问题的解决方法应在呼叫系统所使用的系统工具中存档。
7、应尽量将服务请求与配置项目联系起来。
8、应及时向提交问题的最终用户通报问题的处理情况,系统维护服务的进度和情况也应由服务请求支持员工与最终用户进行沟通。
9、服务请求完成后应确定最终用户对事件解决方案的满意程度。
10、应完整的描述和记录当前信息中心为其它部门所提供的服务、服务级别、以及提供响应的流程文档。
1.6附录
1.6.1附表1服务请求记录表
服务请求记录表
请求信息
报修时间
故障地点
客户电话
IP地址
记录人
系统服务分类:
□网络系统□安全系统□主机系统□存储备份系统
□“95598”系统□营销系统□生产管理系统□OA系统
□人力资源系统□财务系统
事件影响程度:
□高□中□低
优先级:
□最高□高□中□低□无优先级
故障现象
处理过程:
信息系统网络管理规X
3.1适用X围
本规X适用于公司本部和基层单位主机房内的网络设备,包括各种路由器、交换机、防火墙、楼层交换机以及边界路由器和将来投入使用的网络设备的管理工作。
3.2定于与术语
网络事件
由于网络故障,如路由故障、交换故障、IP地址冲突,线路故障、网络设备故障等
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息网络 运行 维护 管理 规范 方案