运营支撑保障管理规程.docx
《运营支撑保障管理规程.docx》由会员分享，可在线阅读，更多相关《运营支撑保障管理规程.docx（33页珍藏版）》请在冰豆网上搜索。
运营支撑保障管理规程
J/UJASU
运营支撑保障管理规程
（Version1.0）
基本信息
文档名称
文档编号
起草时间
姓名
部门
运营支撑保障管理规程
当前版本1.0
定稿时间
电话
发布版本
电子邮件
1.0
编制
运营管理部
运维中心
技术应用部
IT管理部
产品管理部
审核
备注
审阅人
修订记录
序号修改时间修改人
1
2
3
4
5
6
7
8
9
11
12
13
1.概述5
2.运营支撑保障体系架构6
2.1.体系架构图6
22各部门职责6
23运营支撑各层面间的分工协作8
3.主动运维管理规范9
3.1.主动运维的概念9
32建立预检、巡检及预警机制10
33建立和完善故障处理预案制度10
4.故障管理规范11
4.1.故障定义11
4.2.故障的分级13
4.3.故障的超时与升级14
4.4.故障的受理与处理14
4.5.故障的通知通报机制17
5.割接管理规范18
6.问题管理26
6.1.问题管理定义26
62问题的来源及分类26
63问题管理的流程及分工28
64问题管理的记录、报表及通报机制29
6.5.问题管理的考核31
1.概述
随着公司用户规模的不断扩大、公司合作区域的不断拓展和公司新产品、新应用的不断推出，运营维护及服务保障的压力越来越大，对各后台支撑部门的保障能力及部门间的协作提出了更高的要求，为规范公司的运营保障流程、加强运营支撑部门的分工协作、提高运维保障水平、提高用户故障响应及服务质量，从而确保为用户提供及时、准确、到位的运营支撑服务，特制定本规程。
本规程界定了运营支撑保障体系的架构及相关部门人员的职责分工、部门间的协作流程、主动运维规范、故障受理及处理反馈流程、割接管理规范、问题管理规范等涉及公司整体运营支撑保障的各环节流程及规范。
本规程适用于对已投入运行维护的各种业务承载网络、业务应用系统、业务服务系统以及各类支撑系统（包括已承载业务的在建网络系统和已有大量测试用户的测试系统）所涉及的运营保障支撑工作。
本规程主要分为如下几个部分：
一、运营支撑保障体系架构及分工协作
二、主动运维管理规范
三、故障管理（受理及处理）规范
四、割接管理规范
五、问题管理规范
2.运营支撑保障体系架构
3.
2.1.体系架构图
最终用户（（所有上线产时的:
用户）
采用四级技术支撑体系架构，分现场支持（合作城市运维部门）、一线支持（指运维中心）、二线支持（指后台各相关专业部门）、三线支持（指设备、系统的厂商及产品开发部门）。
2.2.各部门职责
1、合作城市运维部门
负责受理当地客户的故障申告
负责本地业务网络的运维
负责本地业务系统的硬件维护
负责配合运维中心完成故障的现场排查
2、运维中心
负责公司所有已移交上线运营的各产品及应用系统的运行监控（7X24小时）
负责割接调度、割接的对外通知和确认
负责对所有上线运营系统的故障统一受理，对故障进行测试、初步判断，对故障调度，跟踪故障处理情况，汇总处理结果，回复结果给故障投诉人，使故障处理形成闭环；通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况；
3、二线支持
二线支持部门主要包括：
技术应用部、IT管理部、应用支持部、运维中心的各二级部门及其它后台支撑部门或业务部门。
运行管理：
对系统和网络进行日常主动巡检、性能分析、优化改造
故障管理：
负责所有一级支持部门转交的网络故障投诉的处理，重大故障的分析
问题管理：
以找到问题根源、提出解决方案，避免故障重复发生的机制，对问题在各个二线、三线支持部门的处理进行跟踪管理
技术支持：
对公司各类业务相关网络和系统运行中出现的热点难点问题，为其它部门进行技术支援；
4、三线支持
三线支持部门主要包括：
产品开发部、应用支持部（自主开发的部分）及厂商。
此层面包括设备、系统的最终技术支持层面
受理网络、系统运行过程的技术咨询及对一、二线支持提供培训
为产品使用方提供远程和现场技术支持
负责对网络、系统运行中的发现的，无法定位的问题进行原因查明，并提供解
决方案
23运营支撑各层面间的分工协作
1、各部门的主要职责及分工
责任人、部门
主要职责
时间节点及要求
公司分管领导（何总、蔡总）
对一级、二级重要故障的处理指导与监督对一级重大故障的协调与督办
其它公司领导
了解并关注一、二级重要故障的处理进程及结果
运维中心
（网管中心）
负责公司所有已移交上线运营的各产品及应用系统的运行监控（7X24小时）
负责对所有上线运营系统的故障统一受理，对故障进行测试、初步判断，对故障调度，跟踪故障处理情况，汇总处理结果，回复结果给故障投诉人，使故障处理形成闭环；
通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况
7X24小时值班
运维中心
（其它二级部门）
承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
对本部门所负责运维保障的部分，与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7X24小时待命（指定专门接口
人）
技术应用部
承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
对本部门所负责运维保障的部分，与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7X24小时待命（指定专门接口
人）
应用支持部
承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
对本部门所负责运维保障的部分，与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7X24小时待命（指定专门接口
人）
IT管理部
承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
对本部门所负责运维保障的部分，与厂家对接对相关系统、网络及设备的故障及问题进行协调处理并全程跟踪和反馈结果
7X24小时待命
（指定专门接口人）
产品开发部
承担本规程所规定的本部门所负责系统、网络及设备的主动运维、故障处理及问题管理的职能
与厂家对接对相关系统、网络及设备的故障及问题
5X8小时（工作日）支持（指定专门接口人），在
责任人、部门
主要职责
时间节点及要求
进行协调处理并全程跟踪和反馈结果
测试期未移交运维的应提供7X24小时待命（指定专门接口人）
其它相关部门
提供工作日5X8小时的工作支持（指定专门的接口人）
配合技术部门解决相关故障
厂商
对公司无法解决的故障应提供7X24小时的及时、
到位的技术支持（包括工作日的所有故障及节假日期间的重大故障）
对重要故障及长期未解决故障提供专项分析及解决方案并协助公司技术部门彻底解决
7X24小时待命
（指定专门接口
人）
2、部门间协作关系图
4.主动运维管理规范
3.1.主动运维的概念
“运维就是服务”，运维未来的发展趋势势必是由被动维护转变为主动服务。
与之相对应，运行维护工作的对象也从面向网络、系统、网元转变为面向用户，由面向设备维护转变为面向外部和内部客户服务。
本管理办法中所提出的“主动运维”的概念即是从此理念出发，通过在公司建立和完善相关的预先检查、预先发现及处理以及编制完善的各类应急预案等，来达到把故障和问题的萌芽消除在其发生之前，从而减少或避免故障的发生，这不仅使用户服务的质量更加精细化，而且能够有效地降低和节约建设维护成本，为公司业务的发展和稳定运营服务提供强有力的保障。
32建立预检、巡检及预警机制
1、预检和巡检
各运行维护保障部门，尤其是运维中心、IT管理部、技术应用部等直接负责关键系统运维的部门，要建立完善的预检及巡检制度，明确预检和巡检的责任人、时间要求、检查内容要求、检查流程、检查记录及发现问题的汇报和通报机制等。
对预检及巡检中应该发现的问题由于检查人员的疏忽没有得到及时发现，后续发生相关故障并给公司造成损失的，应对相关责任人进行事后追究及处罚（具体体现在对责任部门及责任人的考核及奖惩中）。
2、预警机制
检查人员对预检和巡检中发现的问题，要进行及时的分析和预处理，并及时通报本部门相关人员、各相关部门，情况严重时要及时通报给公司分管领导及其他公司领导。
对检查中发现的问题，发起部门要及时跟进问题的处理结果和进度，确保问题得到有效的处理及反馈，并最终形成问题解决的闭环（具体参见故障管理和问题管理部分）。
4.3.建立和完善故障处理预案制度
为减少或避免同类或类似问题再次出现或多次发生，各运维部门应建立并逐步完善故障处理预案制度，对重要的故障及可能多次出现的故障根据前期的处理情况制定完整的处理预案，并对相关运维人员进行培训和传达，以确保在主动运维及故障发生后的第一时间根据处理预案进行及时、有效的故障分析和排除。
故障处理预案可根据故障等级、故障性质及故障类别等进行分类和保存，以方
便故障处理人员的查阅和调用
公司鼓励和支持各运维部门加强横向的沟通和交流，不断完善各自在故障处理预案上的积累与提高。
5.故障管理规范
4.1.故障定义
本管理办法中定义的故障，主要是指网络和系统在运行中设备、线路或应用服务出现各种异常问题导致服务中断，或者导致网络和系统运行质量降低、维护指标劣化超过门限值的现象；主要考虑对业务影响的程度和业务影响范围，对于有计划的割接和维护操作所造成的业务影响，不列为故障。
同时，为使故障的传递和描述规范化，按照网络和系统的业务组成及其网络层次，对故障进行如下结构分解定义:
1.故障的编号：
故障的数字编号。
2.故障的名称：
故障所在点，包括客户、网络设备或系统名称
3.故障的业务分类：
故障所涉及的业务主体，包括：
交互电视网络：
承载交互电视业务的网络
IPTV服务系统：
承载IPTV业务的应用系统
增值服务系统：
承载数字电视增值业务的系统，如游戏、财经、彩票等传输网络：
承载传输业务的网络
动力系统：
机房电源系统
综合业务：
包含上述多个业务
应用服务系统：
包括如增值服务等提供应用业务的业务平台，如游戏平台等
支撑系统：
OSS,BOSS等
其他：
未包含在上述业务范围内的
4.故障的层次：
骨干层（应用层）：
骨干机房的网络设备、应用服务系统及互联链路
接入层：
指骨干机房或小区机房的网络设备到客户前端接入设备之间，包
括小区机房的网络设备
客户层：
客户机房相关业务的接入设备
5.故障的类别：
设备故障：
硬件设备本身引起的故障。
配置故障：
业务配置数据存在错误，而导致故障。
误申告：
故障处理后，判别为不存在的故障或其它不属于公司既定的业务。
环境故障：
由于温度、湿度、动力机房环境及自然因素所引起的故障。
线路故障：
设备之间的物理连接发生的故障，包括光缆、电缆等。
系统故障：
应用系统软件引起的故障。
其他：
未包含在上述故障类别范围内的。
（需要各专业部门将各业务、各层次的故障类别作详细的定义）
6.故障的状态：
故障发生后，从开始到结束所经历的不同状态，用以标识故障处理进展状况。
处理中：
故障发生后的第一个状态，表示该故障处于处理过程中；
等待维护现场处理：
等待第三方确认：
等待第三方配合，包括运营商或供应商等。
已修复，等待客户确认：
已解决：
42故障的分级
故障的分级主要依据故障对网络、系统及其所承载的业务所带来的已发生的和潜在的影响程度进行区分，用以标识故障本身的重要和紧急程度，以及故障的事后分析统计作依据。
第一级：
特大故障，指包括以下情况的故障：
影响某一种及以上主要业务100%的用户，中断时间＞1小时的故障；
影响某两种及以上主要业务10%以上的用户，并且中断时间＞1小时的故障；
对公司业务运营影响巨大的故障。
自第二级故障升级后的故障。
第二级：
重大故障，指包括以下情况的故障：
影响某一主要业务100%的用户，中断时间W1小时的故障；
影响某两种及以上主要业务10%以上的用户，中断时间W1小时的故障；自第三级故障升级后的故障。
第三级：
主要故障，指包括以下情况的故障：
除一级、二级以外的同时影响多个用户的故障；
支撑系统、业务应用系统、骨干网络系统本身发生的但不影响业务的故
障，如冗余故障等；
单个VIP客户故障；
来自第四级故障升级后的故障；
第四级：
次要故障，指包括以下情况的故障：
影响单个普通用户业务的一般故障；
客户接入链路发生故障，但不影响业务的故障，如客户的冗余接入发生
故障等；
来自第五级故障升级后的故障。
第五级：
指不影响业务的投诉，不属于故障统计范围，只作为故障的区分和记录用。
43故障的超时与升级
1、故障的超时
故障的超时是为了明确和规定故障的处理时限，有效控制故障影响时长，其计时以故障记录时刻为起始点，结束为终止点。
是否超时由故障管理系统实行自动判断。
五级
四级
三级
二级
一级
超时时限（小时）
48
2
2
2
2
2、故障的升级
故障的升级是为了获取更多的资源和关注。
升级规则：
不连续性，即同一故障每次只能升一级，不进行跳跃性升级。
升级时限：
不同级别的故障对应不同的升级时限，其实现途径由故障管理系统根据故障记录的实际发生时间作自动升级判断。
五级
四级
三级
二级
一级
升级时限（小时）
72
24
8
1
4.4.故障的受理与处理
1、管理原则
以故障拥有人为故障主要责任人，故障发起人为次要责任人。
即故障拥有人对故障负有主要责任，包括处理、跟踪、调配、协调、监督、通知、报告等等。
故障受理
原则上公司对外统一的故障受理入口为运维中心，其他专业部门不直接受理故障。
故障受理人和故障申报人在故障传递时，必须主动互报姓名。
故障受理人员必须在故障记录系统中对故障的基本信息进行记录，包括故障
时间、故障现象、客户联系人、联系方式等，并对故障的后续处理做出判断，处理或移交给相关人员，如果移交必须记录相应的移交人。
各个环节的故障处理人员必须在故障记录系统中对故障原因、故障处理过
程、故障处理结果进行详细的记录。
必须在故障解决之后才能结束故障，特殊的需要非正常结束的故障必须由专业部门指定人员或主管及以上人员方可结束。
一、二级故障在故障结束时必须对故障的起止时间，故障的影响范围和影响程度进行记录和评估，同时故障拥有人必须出具重大故障报告。
重大故障的故障记录至少一小时更新一次。
各专业处理故障的工程师对故障记录中故障类别、故障名称的准确性负
责。
2、故障处理
故障的处理采用“首问责任制”，即：
故障受理的责任部门及责任人一旦接到故障受理的指令，需对整个故障处理过程全程负责，并及时跟进故障的处理进程，直至故障处理结束形成闭环后为止。
故障处理期间出现的任何问题或结果，首问责任人及部门应承担主要责任！
诊断故障时，应对故障现象、告警信息等进行认真分析处理，并本着先局内后局外；先本端后对端；先基础网络后业务网络，先重点后一般，先调通后修理，故障消除后立即复原的原则。
查找分析故障时，一般不应影响正在通信的用户或者任意扩大影响范围，
并严格按照专业维护规程进行处理。
各个专业部门要制定本专业的故障处理流程，制定紧急情况下的应急措
施，维护人员应熟悉操作处理办法并严格按照流程图操作。
各个环节的故障处理人应依据故障处理升级原则，对于在规定时限内未能处理的故障及时升级。
工作时间内故障处理完毕后由故障处理人员根据故障记录里的客户联系
信息通知故障申告人，并记录反馈信息。
非工作时间由网管中心运行工程师跟客户联系通知。
3、故障的转交
故障的转交是指故障拥有人的更换，也同时表明了故障责任的转移，转交原则
遵循如下规定：
以故障管理平台中记录为主，禁止一切无记录的转交；口头转交必须清楚表达“转交”两字，同时由转交的任一方在故障平台中详细记录。
禁止故障在转交时，向下游回传。
专业部门之间的故障转交可通过互相协商进行故障转移，但故障转移时，必须出具转移的理由和原因。
故障转交需在完成书面手续并经双方签字确认后，首问责任才可转移给相关部门，否则故障移交部门仍承担该故障的“首问责任”！
4、故障的处理升级
故障等级
故障处理升级时限
故障拥有人
部门主管
部门经理
分管领导
公司所有领导
L1
<1min
<5min
<10min
<10min
<20min
L2
<5min
<10min
<15min
<20min
<30min
L3
<60min
<90min
<24hours
<48hours
<72hours
L4
<90min
<120min
<72hours
<7days
<7days
L5
<48hours
<72hours
<120hours
<15days
<15days
对于未能在规定时限内解决的故障必须及时升级到相应的技术岗位。
对于一级二级故障必须由项目负责人和部门主管或经理负责指挥调度。
5、故障属性的更改
为使故障的等级、层次、类别的划分保持严格的准确性和统一性，其变更遵循如下规则：
等级的变更：
一级、二级的故障变更权限仅为各专业或故障类别中的特定人拥有，其他等级的变更以故障拥有人为主。
（需各专业指定）类别、层次等的变更：
以故障拥有人作最终变更授权人。
6、故障报告
对于一级二级故障需填写故障报告（参见故障报告模板），并在故障解决后三天内上报相关部门及公司所有领导；故障报告必须详细说明故障现
象、故障原因、故障处理过程、故障影响范围、已经采取的措施和即将采取的措施。
其他级别的故障报告根据需要，由故障拥有人制定；需要提交给客户的故障报告，由客服公司制定，并经各专业部门或故障所涉及部门确认后，提交市场部门，由市场部门作最后的确定。
由网管中心负责故障统计日报、周报、月报的整理。
各专业部门负责每月的故障分析报告。
7、故障监督
网管中心所有记录的未解决的故障有监督职责，需定期浏览故障处理情况，对于未能在规定时限内解决的故障需询问故障拥有人，并做相应的记录。
&对故障处理结果的考核:
按照《公司考核》中相关规定，对各执行单位进行考核，对不按规定执行的单位将予以通报处理，对造成重大事故的，将追究相关部门领导和责任人的责任。
4.5.故障的通知通报机制
根据故障等级对故障通报范围明确如下：
故障等级
故障通报范围及通报方式
故障可能涉及的相关部门接口人
分管领导及所有
涉及部门的部门
经理
公司所有领导及接口
部门相关人员
L1
<5min（电话）
<10min（电话）
<20min（短信）
L2
<10min（电话）
<20min（电话）
<30min（短信）
L3
<90min（电话）
<48hours（邮件）
<72hours（邮件）
L4
<120min（电话）
<7days（邮件）
<7days（邮件）
L5
<72hours（邮件）
<15days（邮件）
<15days（邮件）
日常故障通报：
日常故障均有运维中心故障负责人对当地故障申告人通报处理
~~进展和结果
重大故障对内通报：
凡重大故障发生，需在确认故障现象后5分钟内通知部门
主管，由专业部门主管确认后10分钟内通知所在部门经理、拓展技术支持负责人及拓展经理同时告知公司分管领导，故障在30分钟内仍未恢复的，部门经理应及时告知公司分管领导处理进展并寻求相关支持。
故障排除后需通报处理结果。
重大故障对外通报：
凡重大故障发生，需在确认故障现象后5分钟内通知部门
主管，由运维中心主管确认后15分钟内安排对外通报工作，对外的通报范围包括受影响合作城市技术管理负责人。
故障排除后需通报处理结果。
书面通报：
故障排除后的72小时内完成故障报告，经审核后发送到相关部门负
责人，并备案
故障由故障拥有部门负责按以上要求进行故障通报，故障已移交的由移交后的
故障拥有部门负责通报
故障通知范围包括运维部、呼叫中心以及故障涉及到的技术部门、业务部门、合作区域接口部门及市场销售部门相关联系人。
6.割接管理规范
第一条目的
为规范网络和系统的割接管理程序，确保割接过程对各种业务和用户的影响最小,保证网络和系统的安全、稳定运行，特制定本管理办法。
第二条适用范围
由华夏视联运维支持部门负责的日常运行维护的相关业务服务系统、业务支撑系统、业务应用系统、业务承载网络以及光缆网络的割接操作，均须遵守本管理制度。
第三条割接定义
割接是指包括更改、更换、搬迁、调整、升级和维修等将造成（或有可能造成）业务中断或对正常网络和系统的运行造成影响的有计划的变更操作。
割接所涉及的对象和范围，各部门可根据各自部门业务的特点，结合割接的含义，自行定义和划
分，并制定部门割接制度以供参考。
第四条割接单位定义
•割接项目单位：
为各级运维生产部门或负责已承载业务的在建网络系统的建设部门以及各类支撑系统的维护部门，如网络运维部、工程部、IT管理部、
技术应用部、应用支持部等。
害接项目单位负责提出网络割接申请、制定割接方案、提交割接确认表、实施割接、进行割接确认、反馈割接结果（割接总结）。
•割接调度：
负责分配割接编号，发布割接通知、割接结果通知，收集整个割接过程中的相关文档，统计割接数据等。
•割接审批单位：
指对割接进行可行性审核的部门或公司领导。
*割接配合单位：
指配合割接项目单位进行割接相关操作的相关部门。
第五条割接的分类和等级定义：
根据割接类型不同，可将割接划分为三大类：
・第一类割接：
主要指面向用户的直接影响用户业务的服务系统、应用系统和业务承载网络的割接。
•第二类割接：
主要指光缆割接，包括网络互联部分以及客户接入部分的光缆所作的割接。
-第三类割接：
主要指业务支撑系统、办公系统等系统类的割接，包括各类OSSOA等系统。
根据割接受影响用户程度的不同，将割接分为四个等级，等级之间以影响范围和中断时长两个参数作为主要判断依据：
-第一级割接：
指对业务承载网络、业务应用系统、业务服务系统进行割接时，影响100%的用户，中断时间＞4小时；或两种以上主要业务50%以上用户，中断时间＞2小时的割接。
*第二级割接：
指对业务承载网络、业务应用系统、业务服务系统进行割接时，影响某一主要业务20%以上的用户，中断时间＞2小时，或两种以上主要业务10%以上用户，中断时间＞1小时的割接。
*第三级割接：
除第一、第二级以外的所有网络或系统的割接，割接影响一个以上的用户，主要包括光缆割接、小区机房级别的小范围网络割接。
•第四级割接：
指不影响用户业务但需要用户或公司关注的割接，或针对单个客户所进行的割接。
第六条紧急割接的定义：
因意外事件或紧急事件引起，或网络、系统性能大幅度下降，影响到业务正常运行的情况下，在自发起割接申请起24小时
升级会员 