精选运营支撑保障管理规程.docx
- 文档编号:520198
- 上传时间:2022-10-10
- 格式:DOCX
- 页数:28
- 大小:196.55KB
精选运营支撑保障管理规程.docx
《精选运营支撑保障管理规程.docx》由会员分享,可在线阅读,更多相关《精选运营支撑保障管理规程.docx(28页珍藏版)》请在冰豆网上搜索。
精选运营支撑保障管理规程
运营支撑保障管理规程
(Version1.0)
2009年7月
基本信息
文档名称
运营支撑保障管理规程
文档编号
当前版本
1.0
发布版本
1.0
起草时间
2009年6月
定稿时间
2009年6月
编制
姓名
部门
电话
电子邮件
郭海涛
运营管理部
曾宪龙
运维中心
林杰
技术应用部
丁继承
IT管理部
王秀双
产品管理部
审核
蔡高伟
备注
审阅人
修订记录
序号
修改时间
修改人
主要修改
存档版本
1
2
3
4
5
6
7
8
9
11
12
13
1.概述
随着公司用户规模的不断扩大、公司合作区域的不断拓展和公司新产品、新应用的不断推出,运营维护及服务保障的压力越来越大,对各后台支撑部门的保障能力及部门间的协作提出了更高的要求,为规范公司的运营保障流程、加强运营支撑部门的分工协作、提高运维保障水平、提高用户故障响应及服务质量,从而确保为用户提供及时、准确、到位的运营支撑服务,特制定本规程。
本规程界定了运营支撑保障体系的架构及相关部门人员的职责分工、部门间的协作流程、主动运维规范、故障受理及处理反馈流程、割接管理规范、问题管理规范等涉及公司整体运营支撑保障的各环节流程及规范。
本规程适用于对已投入运行维护的各种业务承载网络、业务应用系统、业务服务系统以及各类支撑系统(包括已承载业务的在建网络系统和已有大量测试用户的测试系统)所涉及的运营保障支撑工作。
本规程主要分为如下几个部分:
一、运营支撑保障体系架构及分工协作
二、主动运维管理规范
三、故障管理(受理及处理)规范
四、割接管理规范
五、问题管理规范
2.运营支撑保障体系架构
2.1.体系架构图
采用四级技术支撑体系架构,分现场支持(合作城市运维部门)、一线支持(指运维中心)、二线支持(指后台各相关专业部门)、三线支持(指设备、系统的厂商及产品开发部门)。
2.2.各部门职责
1、合作城市运维部门
●负责受理当地客户的故障申告
●负责本地业务网络的运维
●负责本地业务系统的硬件维护
●负责配合运维中心完成故障的现场排查
2、运维中心(一线)
●负责公司所有已移交上线运营的各产品及应用系统的运行监控(7×24小时)
●负责割接调度、割接的对外通知和确认
●负责对所有上线运营系统的故障统一受理,对故障进行测试、初步判断,对故障调度,跟踪故障处理情况,汇总处理结果,回复结果给故障投诉人,使故障处理形成闭环;
●通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况;
3、二线支持
二线支持部门主要包括:
技术应用部、IT管理部、应用支持部、运维中心的各二级部门及其它后台支撑部门或业务部门。
●运行管理:
对系统和网络进行日常主动巡检、性能分析、优化改造
●故障管理:
负责所有一级支持部门转交的网络故障投诉的处理,重大故障的分析
●问题管理:
以找到问题根源、提出解决方案,避免故障重复发生的机制,对问题在各个二线、三线支持部门的处理进行跟踪管理
●技术支持:
对公司各类业务相关网络和系统运行中出现的热点难点问题,为其它部门进行技术支援;
4、三线支持
三线支持部门主要包括:
产品开发部、应用支持部(自主开发的部分)及厂商。
●此层面包括设备、系统的最终技术支持层面
●受理网络、系统运行过程的技术咨询及对一、二线支持提供培训
●为产品使用方提供远程和现场技术支持
●负责对网络、系统运行中的发现的,无法定位的问题进行原因查明,并提供解决方案
2.3.运营支撑各层面间的分工协作
1、各部门的主要职责及分工
责任人、部门
主要职责
时间节点及要求
公司分管领导(何总、蔡总)
Ø对一级、二级重要故障的处理指导与监督
Ø对一级重大故障的协调与督办
其它公司领导
Ø了解并关注一、二级重要故障的处理进程及结果
运维中心
(网管中心)
Ø负责公司所有已移交上线运营的各产品及应用系统的运行监控(7×24小时)
Ø负责对所有上线运营系统的故障统一受理,对故障进行测试、初步判断,对故障调度,跟踪故障处理情况,汇总处理结果,回复结果给故障投诉人,使故障处理形成闭环;
Ø通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况
7×24小时值班
运维中心
(其它二级部门)
Ø承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
Ø对本部门所负责运维保障的部分,与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7×24小时待命(指定专门接口人)
技术应用部
Ø承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
Ø对本部门所负责运维保障的部分,与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7×24小时待命(指定专门接口人)
应用支持部
Ø承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
Ø对本部门所负责运维保障的部分,与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7×24小时待命(指定专门接口人)
IT管理部
Ø承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
Ø对本部门所负责运维保障的部分,与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7×24小时待命(指定专门接口人)
产品开发部
Ø承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
Ø与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
5×8小时(工作日)支持(指定专门接口人),在测试期未移交运维的应提供7×24小时待命(指定专门接口人)
其它相关部门
Ø提供工作日5×8小时的工作支持(指定专门的接口人)
Ø配合技术部门解决相关故障
厂商
Ø对公司无法解决的故障应提供7×24小时的及时、到位的技术支持(包括工作日的所有故障及节假日期间的重大故障)
Ø对重要故障及长期未解决故障提供专项分析及解决方案并协助公司技术部门彻底解决
7×24小时待命(指定专门接口人)
2、部门间协作关系图
3.主动运维管理规范
3.1.主动运维的概念
“运维就是服务”,运维未来的发展趋势势必是由被动维护转变为主动服务。
与之相对应,运行维护工作的对象也从面向网络、系统、网元转变为面向用户,由面向设备维护转变为面向外部和内部客户服务。
本管理办法中所提出的“主动运维”的概念即是从此理念出发,通过在公司建立和完善相关的预先检查、预先发现及处理以及编制完善的各类应急预案等,来达到把故障和问题的萌芽消除在其发生之前,从而减少或避免故障的发生,这不仅使用户服务的质量更加精细化,而且能够有效地降低和节约建设维护成本,为公司业务的发展和稳定运营服务提供强有力的保障。
3.2.建立预检、巡检及预警机制
1、预检和巡检
各运行维护保障部门,尤其是运维中心、IT管理部、技术应用部等直接负责关键系统运维的部门,要建立完善的预检及巡检制度,明确预检和巡检的责任人、时间要求、检查内容要求、检查流程、检查记录及发现问题的汇报和通报机制等。
对预检及巡检中应该发现的问题由于检查人员的疏忽没有得到及时发现,后续发生相关故障并给公司造成损失的,应对相关责任人进行事后追究及处罚(具体体现在对责任部门及责任人的考核及奖惩中)。
2、预警机制
检查人员对预检和巡检中发现的问题,要进行及时的分析和预处理,并及时通报本部门相关人员、各相关部门,情况严重时要及时通报给公司分管领导及其他公司领导。
对检查中发现的问题,发起部门要及时跟进问题的处理结果和进度,确保问题得到有效的处理及反馈,并最终形成问题解决的闭环(具体参见故障管理和问题管理部分)。
3.3.建立和完善故障处理预案制度
为减少或避免同类或类似问题再次出现或多次发生,各运维部门应建立并逐步完善故障处理预案制度,对重要的故障及可能多次出现的故障根据前期的处理情况制定完整的处理预案,并对相关运维人员进行培训和传达,以确保在主动运维及故障发生后的第一时间根据处理预案进行及时、有效的故障分析和排除。
故障处理预案可根据故障等级、故障性质及故障类别等进行分类和保存,以方便故障处理人员的查阅和调用。
公司鼓励和支持各运维部门加强横向的沟通和交流,不断完善各自在故障处理预案上的积累与提高。
4.故障管理规范
4.1.故障定义
本管理办法中定义的故障,主要是指网络和系统在运行中设备、线路或应用服务出现各种异常问题导致服务中断,或者导致网络和系统运行质量降低、维护指标劣化超过门限值的现象;主要考虑对业务影响的程度和业务影响范围,对于有计划的割接和维护操作所造成的业务影响,不列为故障。
同时,为使故障的传递和描述规范化,按照网络和系统的业务组成及其网络层次,对故障进行如下结构分解定义:
1.故障的编号:
故障的数字编号。
2.故障的名称:
故障所在点,包括客户、网络设备或系统名称。
3.故障的业务分类:
故障所涉及的业务主体,包括:
●交互电视网络:
承载交互电视业务的网络
●IPTV服务系统:
承载IPTV业务的应用系统
●增值服务系统:
承载数字电视增值业务的系统,如游戏、财经、彩票等
●传输网络:
承载传输业务的网络
●动力系统:
机房电源系统
●综合业务:
包含上述多个业务
●应用服务系统:
包括如增值服务等提供应用业务的业务平台,如游戏平台等
●支撑系统:
OSS,BOSS等
●其他:
未包含在上述业务范围内的
4.故障的层次:
●骨干层(应用层):
骨干机房的网络设备、应用服务系统及互联链路
●接入层:
指骨干机房或小区机房的网络设备到客户前端接入设备之间,包括小区机房的网络设备
●客户层:
客户机房相关业务的接入设备
5.故障的类别:
●设备故障:
硬件设备本身引起的故障。
●配置故障:
业务配置数据存在错误,而导致故障。
●误申告:
故障处理后,判别为不存在的故障或其它不属于公司既定的业务。
●环境故障:
由于温度、湿度、动力机房环境及自然因素所引起的故障。
●线路故障:
设备之间的物理连接发生的故障,包括光缆、电缆等。
●系统故障:
应用系统软件引起的故障。
●其他:
未包含在上述故障类别范围内的。
●(需要各专业部门将各业务、各层次的故障类别作详细的定义)
6.故障的状态:
故障发生后,从开始到结束所经历的不同状态,用以标识故障处理进展状况。
●处理中:
故障发生后的第一个状态,表示该故障处于处理过程中;
●等待维护现场处理:
●等待第三方确认:
等待第三方配合,包括运营商或供应商等。
●已修复,等待客户确认:
●已解决:
4.2.故障的分级
故障的分级主要依据故障对网络、系统及其所承载的业务所带来的已发生的和潜在的影响程度进行区分,用以标识故障本身的重要和紧急程度,以及故障的事后分析统计作依据。
●第一级:
特大故障,指包括以下情况的故障:
Ø影响某一种及以上主要业务100%的用户,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 精选 运营 支撑 保障 管理 规程