运营支撑保障管理规程.docx

1、运营支撑保障管理规程J/ UJASU运营支撑保障管理规程(Versio n 1.0)基本信息文档名称文档编号起草时间姓名部门运营支撑保障管理规程当前版本 1.0定稿时间电话发布版本电子邮件1.0编制运营管理部运维中心技术应用部IT管理部产品管理部审核备注审阅人修订记录序号 修改时间 修改人1234567891112131.概述 52.运营支撑保障体系架构 62.1.体系架构图 622各部门职责 623 运营支撑各层面间的分工协作 83.主动运维管理规范 93.1.主动运维的概念 932建立预检、巡检及预警机制 1033建立和完善故障处理预案制度 104.故障管理规范 114.1.故障定义 11

2、4.2.故障的分级 134.3.故障的超时与升级 144.4.故障的受理与处理 144.5.故障的通知通报机制 175.割接管理规范 186.问题管理 266.1. 问题管理定义 2662问题的来源及分类 2663问题管理的流程及分工 2864问题管理的记录、报表及通报机制 296.5. 问题管理的考核 311.概述随着公司用户规模的不断扩大、公司合作区域的不断拓展和公司新产品、新应 用的不断推出，运营维护及服务保障的压力越来越大，对各后台支撑部门的保障能 力及部门间的协作提出了更高的要求，为规范公司的运营保障流程、加强运营支撑 部门的分工协作、提高运维保障水平、提高用户故障响应及服务质量，从

3、而确保为 用户提供及时、准确、到位的运营支撑服务，特制定本规程。本规程界定了运营支撑保障体系的架构及相关部门人员的职责分工、部门间的 协作流程、主动运维规范、故障受理及处理反馈流程、割接管理规范、问题管理规 范等涉及公司整体运营支撑保障的各环节流程及规范。本规程适用于对已投入运行维护的各种业务承载网络、业务应用系统、业务服 务系统以及各类支撑系统（包括已承载业务的在建网络系统和已有大量测试用户的 测试系统）所涉及的运营保障支撑工作。本规程主要分为如下几个部分：一、 运营支撑保障体系架构及分工协作二、 主动运维管理规范三、 故障管理（受理及处理）规范四、 割接管理规范五、 问题管理规范2.运营支

4、撑保障体系架构3.2.1.体系架构图最终用户（所有上线产时的:用户）采用四级技术支撑体系架构，分现场支持（合作城市运维部门）、一线支持（指 运维中心）、二线支持（指后台各相关专业部门）、三线支持（指设备、系统的厂商 及产品开发部门）。2.2.各部门职责1、合作城市运维部门负责受理当地客户的故障申告负责本地业务网络的运维负责本地业务系统的硬件维护负责配合运维中心完成故障的现场排查2、运维中心负责公司所有已移交上线运营的各产品及应用系统的运行监控（ 7X 24小时）负责割接调度、割接的对外通知和确认负责对所有上线运营系统的故障统一受理，对故障进行测试、初步判断，对故 障调度，跟踪故障处理情况，汇总

5、处理结果，回复结果给故障投诉人，使故障 处理形成闭环； 通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及 故障处理情况；3、二线支持二线支持部门主要包括：技术应用部、IT管理部、应用支持部、运维中心的各二级 部门及其它后台支撑部门或业务部门。运行管理：对系统和网络进行日常主动巡检、性能分析、优化改造故障管理：负责所有一级支持部门转交的网络故障投诉的处理，重大故障的分 析问题管理：以找到问题根源、提出解决方案，避免故障重复发生的机制，对问 题在各个二线、三线支持部门的处理进行跟踪管理技术支持：对公司各类业务相关网络和系统运行中出现的热点难点问题，为其 它部门进行技术支援；4、

6、三线支持三线支持部门主要包括：产品开发部、应用支持部（自主开发的部分）及厂商。此层面包括设备、系统的最终技术支持层面受理网络、系统运行过程的技术咨询及对一、二线支持提供培训为产品使用方提供远程和现场技术支持负责对网络、系统运行中的发现的，无法定位的问题进行原因查明，并提供解决方案23 运营支撑各层面间的分工协作1、各部门的主要职责及分工责任人、部门主要职责时间节点及要求公司分管领导（何 总、蔡总）对一级、二级重要故障的处理指导与监督 对一级重大故障的协调与督办其它公司领导了解并关注一、二级重要故障的处理进程及结果运维中心（网管中心）负责公司所有已移交上线运营的各产品及应用系统 的运行监控（7X

7、24小时）负责对所有上线运营系统的故障统一受理，对故障 进行测试、初步判断，对故障调度，跟踪故障处理情况， 汇总处理结果，回复结果给故障投诉人，使故障处理形 成闭环；通过运行日报、周报、月报等形式向各个相关部门 传递网络系统的运行状况及故障处理情况7X24小时值班运维中心（其它二级部门）承担本规程所规定的本部门所负责系统、网络及设 备的主动运维、故障处理及问题管理的职能对本部门所负责运维保障的部分，与厂家对接对相 关系统、网络及设备的故障及问题进行协调处理并全程 跟踪和反馈结果7X 24小时待命 （指定专门接口人）技术应用部承担本规程所规定的本部门所负责系统、网络及设 备的主动运维、故障处理及

8、问题管理的职能对本部门所负责运维保障的部分，与厂家对接对相 关系统、网络及设备的故障及问题进行协调处理并全程 跟踪和反馈结果7X 24小时待命 （指定专门接口人）应用支持部承担本规程所规定的本部门所负责系统、网络及设 备的主动运维、故障处理及问题管理的职能对本部门所负责运维保障的部分，与厂家对接对相 关系统、网络及设备的故障及问题进行协调处理并全程 跟踪和反馈结果7X 24小时待命 （指定专门接口人）IT管理部承担本规程所规定的本部门所负责系统、网络及设 备的主动运维、故障处理及问题管理的职能对本部门所负责运维保障的部分，与厂家对接对相 关系统、网络及设备的故障及问题进行协调处理并全程 跟踪和

9、反馈结果7X 24小时待命（指定专门接口 人）产品开发部承担本规程所规定的本部门所负责系统、网络及设 备的主动运维、故障处理及问题管理的职能与厂家对接对相关系统、网络及设备的故障及问题5X 8小时（工作 日）支持（指定 专门接口人），在责任人、部门主要职责时间节点及要求进行协调处理并全程跟踪和反馈结果测试期未移交运 维的应提供7X 24小时待命（指 定专门接口人）其它相关部门提供工作日5X8小时的工作支持（指定专门的接口 人）配合技术部门解决相关故障厂商对公司无法解决的故障应提供 7 X 24小时的及时、到位的技术支持（包括工作日的所有故障及节假日期间 的重大故障）对重要故障及长期未解决故障提

10、供专项分析及解决 方案并协助公司技术部门彻底解决7X 24小时待命（指定专门接口人）2、部门间协作关系图4.主动运维管理规范3.1.主动运维的概念“运维就是服务”，运维未来的发展趋势势必是由被动维护转变为主动服务。与之相对应，运行维护工作的对象也从面向网络、系统、网元转变为面向用户，由 面向设备维护转变为面向外部和内部客户服务。本管理办法中所提出的“主动运维”的概念即是从此理念出发，通过在公司建 立和完善相关的预先检查、预先发现及处理以及编制完善的各类应急预案等，来达 到把故障和问题的萌芽消除在其发生之前，从而减少或避免故障的发生，这不仅使 用户服务的质量更加精细化，而且能够有效地降低和节约建

11、设维护成本，为公司业 务的发展和稳定运营服务提供强有力的保障。32 建立预检、巡检及预警机制1、 预检和巡检各运行维护保障部门，尤其是运维中心、IT管理部、技术应用部等直接负责关 键系统运维的部门，要建立完善的预检及巡检制度，明确预检和巡检的责任人、时 间要求、检查内容要求、检查流程、检查记录及发现问题的汇报和通报机制等。对预检及巡检中应该发现的问题由于检查人员的疏忽没有得到及时发现，后续 发生相关故障并给公司造成损失的，应对相关责任人进行事后追究及处罚（具体体 现在对责任部门及责任人的考核及奖惩中）。2、 预警机制检查人员对预检和巡检中发现的问题，要进行及时的分析和预处理，并及时通 报本部门

12、相关人员、各相关部门，情况严重时要及时通报给公司分管领导及其他公 司领导。对检查中发现的问题，发起部门要及时跟进问题的处理结果和进度，确保问题 得到有效的处理及反馈，并最终形成问题解决的闭环（具体参见故障管理和问题管 理部分）。4.3.建立和完善故障处理预案制度为减少或避免同类或类似问题再次出现或多次发生，各运维部门应建立并逐步 完善故障处理预案制度，对重要的故障及可能多次出现的故障根据前期的处理情况 制定完整的处理预案，并对相关运维人员进行培训和传达，以确保在主动运维及故 障发生后的第一时间根据处理预案进行及时、有效的故障分析和排除。故障处理预案可根据故障等级、故障性质及故障类别等进行分类和

13、保存，以方便故障处理人员的查阅和调用公司鼓励和支持各运维部门加强横向的沟通和交流，不断完善各自在故障处理 预案上的积累与提高。5.故障管理规范4.1.故障定义本管理办法中定义的故障，主要是指网络和系统在运行中设备、线路或应用服 务出现各种异常问题导致服务中断，或者导致网络和系统运行质量降低、维护指标 劣化超过门限值的现象；主要考虑对业务影响的程度和业务影响范围，对于有计划 的割接和维护操作所造成的业务影响，不列为故障。同时，为使故障的传递和描述 规范化，按照网络和系统的业务组成及其网络层次， 对故障进行如下结构分解定义:1.故障的编号：故障的数字编号。2.故障的名称：故障所在点，包括客户、网络

14、设备或系统名称3.故障的业务分类：故障所涉及的业务主体，包括：交互电视网络：承载交互电视业务的网络IPTV服务系统：承载IPTV业务的应用系统增值服务系统：承载数字电视增值业务的系统，如游戏、财经、彩票等 传输网络：承载传输业务的网络动力系统：机房电源系统综合业务：包含上述多个业务应用服务系统：包括如增值服务等提供应用业务的业务平台，如游戏平台 等支撑系统：OSS, BOSS等其他：未包含在上述业务范围内的4.故障的层次：骨干层（应用层）：骨干机房的网络设备、应用服务系统及互联链路接入层：指骨干机房或小区机房的网络设备到客户前端接入设备之间， 包括小区机房的网络设备客户层：客户机房相关业务的接

15、入设备5.故障的类别：设备故障：硬件设备本身引起的故障。配置故障：业务配置数据存在错误，而导致故障。误申告：故障处理后，判别为不存在的故障或其它不属于公司既定的业务。 环境故障：由于温度、湿度、动力机房环境及自然因素所引起的故障。线路故障：设备之间的物理连接发生的故障，包括光缆、电缆等。系统故障：应用系统软件引起的故障。其他：未包含在上述故障类别范围内的。（需要各专业部门将各业务、各层次的故障类别作详细的定义）6.故障的状态：故障发生后，从开始到结束所经历的不同状态，用以标识故 障处理进展状况。处理中：故障发生后的第一个状态，表示该故障处于处理过程中；等待维护现场处理：等待第三方确认：等待第三

16、方配合，包括运营商或供应商等。已修复，等待客户确认：已解决：42故障的分级故障的分级主要依据故障对网络、系统及其所承载的业务所带来的已发生的和 潜在的影响程度进行区分，用以标识故障本身的重要和紧急程度，以及故障的事后 分析统计作依据。第一级：特大故障，指包括以下情况的故障：影响某一种及以上主要业务100%的用户，中断时间1小时的故障；影响某两种及以上主要业务 10%以上的用户，并且中断时间1小时的 故障；对公司业务运营影响巨大的故障。自第二级故障升级后的故障。第二级：重大故障，指包括以下情况的故障：影响某一主要业务100%的用户，中断时间W 1小时的故障；影响某两种及以上主要业务10%以上的用

17、户，中断时间W 1小时的故障； 自第三级故障升级后的故障。第三级：主要故障，指包括以下情况的故障：除一级、二级以外的同时影响多个用户的故障；支撑系统、业务应用系统、骨干网络系统本身发生的但不影响业务的故障，如冗余故障等；单个VIP客户故障；来自第四级故障升级后的故障；第四级：次要故障，指包括以下情况的故障：影响单个普通用户业务的一般故障；客户接入链路发生故障，但不影响业务的故障，如客户的冗余接入发生故障等；来自第五级故障升级后的故障。第五级：指不影响业务的投诉，不属于故障统计范围，只作为故障的区分 和记录用。43故障的超时与升级1、故障的超时故障的超时是为了明确和规定故障的处理时限，有效控制故

18、障影响时长，其计 时以故障记录时刻为起始点，结束为终止点。是否超时由故障管理系统实行自动判 断。五级四级三级二级一级超时时限（小时）4822222、故障的升级故障的升级是为了获取更多的资源和关注。升级规则：不连续性，即同一故障每次只能升一级，不进行跳跃性升级。升级时限：不同级别的故障对应不同的升级时限， 其实现途径由故障管理 系统根据故障记录的实际发生时间作自动升级判断。五级四级三级二级一级升级时限（小时）7224814.4.故障的受理与处理1、管理原则以故障拥有人为故障主要责任人，故障发起人为次要责任人。即故障拥有人对 故障负有主要责任，包括处理、跟踪、调配、协调、监督、通知、报告等等。故障

19、受理原则上公司对外统一的故障受理入口为运维中心， 其他专业部门不直接受 理故障。故障受理人和故障申报人在故障传递时，必须主动互报姓名。故 障受理人员必须在故障记录系统中对故障的基本信息进行记录， 包括故障时间、故障现象、客户联系人、联系方式等，并对故障的后续处理做出判 断，处理或移交给相关人员，如果移交必须记录相应的移交人。各个环节的故障处理人员必须在故障记录系统中对故障原因、 故障处理过程、故障处理结果进行详细的记录。必须在故障解决之后才能结束故障，特殊的需要非正常结束的故障必须由 专业部门指定人员或主管及以上人员方可结束。一、二级故障在故障结束时必须对故障的起止时间， 故障的影响范围和影

20、响程度进行记录和评估，同时故障拥有人必须出具重大故障报告。重大故障的故障记录至少一小时更新一次。各专业处理故障的工程师对故障记录中故障类别、故障名称的准确性负责。2、 故障处理故障的处理采用“首问责任制”，即：故障受理的责任部门及责任人一 旦接到故障受理的指令，需对整个故障处理过程全程负责， 并及时跟进故 障的处理进程，直至故障处理结束形成闭环后为止。 故障处理期间出现的 任何问题或结果，首问责任人及部门应承担主要责任！诊断故障时，应对故障现象、告警信息等进行认真分析处理，并本着先局 内后局外；先本端后对端；先基础网络后业务网络，先重点后一般，先调 通后修理，故障消除后立即复原的原则。查找分析

21、故障时，一般不应影响正在通信的用户或者任意扩大影响范围，并严格按照专业维护规程进行处理。各个专业部门要制定本专业的故障处理流程，制定紧急情况下的应急措施，维护人员应熟悉操作处理办法并严格按照流程图操作。各个环节的故障处理人应依据故障处理升级原则， 对于在规定时限内未能 处理的故障及时升级。工作时间内故障处理完毕后由故障处理人员根据故障记录里的客户联系信息通知故障申告人，并记录反馈信息。非工作时间由网管中心运行工程 师跟客户联系通知。3、 故障的转交故障的转交是指故障拥有人的更换，也同时表明了故障责任的转移，转交原则遵循如下规定：以故障管理平台中记录为主，禁止一切无记录的转交；口头转交必须清楚

22、表达“转交”两字，同时由转交的任一方在故障平台中详细记录。禁止故障在转交时，向下游回传。专业部门之间的故障转交可通过互相协 商进行故障转移，但故障转移时，必须出具转移的理由和原因。故障转交需在完成书面手续并经双方签字确认后，首问责任才可转移给相 关部门，否则故障移交部门仍承担该故障的“首问责任” ！4、故障的处理升级故障等级故障处理升级时限故障拥有人部门主管部门经理分管领导公司所有领导L11min5min10mi n10mi n20mi nL25min10mi n15mi n20mi n30mi nL360mi n90mi n24hours48hours72hoursL490mi n120mi

23、 n72hours7days7daysL548hours72hours120hours15days15days对于未能在规定时限内解决的故障必须及时升级到相应的技术岗位。对于一级 二级故障必须由项目负责人和部门主管或经理负责指挥调度。5、故障属性的更改为使故障的等级、层次、类别的划分保持严格的准确性和统一性，其变更遵循 如下规则：等级的变更：一级、二级的故障变更权限仅为各专业或故障类别中的特定 人拥有，其他等级的变更以故障拥有人为主。（需各专业指定） 类别、层次等的变更：以故障拥有人作最终变更授权人。6、故障报告对于一级二级故障需填写故障报告（参见故障报告模板），并在故障解决 后三天内上报相关

24、部门及公司所有领导；故障报告必须详细说明故障现象、故障原因、故障处理过程、故障影响范围、已经采取的措施和即将采 取的措施。其他级别的故障报告根据需要，由故障拥有人制定；需要提交给客户的故 障报告，由客服公司制定，并经各专业部门或故障所涉及部门确认后，提 交市场部门，由市场部门作最后的确定。由网管中心负责故障统计日报、周报、月报的整理。各专业部门负责每月 的故障分析报告。7、故障监督网管中心所有记录的未解决的故障有监督职责，需定期浏览故障处理情况，对 于未能在规定时限内解决的故障需询问故障拥有人，并做相应的记录。&对故障处理结果的考核:按照公司考核中相关规定，对各执行单位进行考核，对不按规定执行

25、的单 位将予以通报处理，对造成重大事故的，将追究相关部门领导和责任人的责任。4.5.故障的通知通报机制根据故障等级对故障通报范围明确如下：故障等级故障通报范围及通报方式故障可能涉及的 相关部门接口人分管领导及所有涉及部门的部门经理公司所有领导及接口部门相关人员L15min （电话）10mi n （电话）20mi n （短信）L210mi n （电话）20mi n （电话）30mi n （短信）L390mi n （电话）48hours （邮件）72hours （邮件）L4120min （电话）7days （邮件）7days （邮件）L572hours （邮件）15days （邮件）15days

26、（邮件）日常故障通报：日常故障均有运维中心故障负责人对当地故障申告人通报处理进展和结果重大故障对内通报：凡重大故障发生，需在确认故障现象后 5分钟内通知部门主管，由专业部门主管确认后10分钟内通知所在部门经理、拓展技术支持负责 人及拓展经理同时告知公司分管领导，故障在 30分钟内仍未恢复的，部门经理 应及时告知公司分管领导处理进展并寻求相关支持。故障排除后需通报处理结 果。重大故障对外通报：凡重大故障发生，需在确认故障现象后 5分钟内通知部门主管，由运维中心主管确认后15分钟内安排对外通报工作，对外的通报范围包 括受影响合作城市技术管理负责人。故障排除后需通报处理结果。书面通报：故障排除后的7

27、2小时内完成故障报告，经审核后发送到相关部门负责人，并备案故障由故障拥有部门负责按以上要求进行故障通报，故障已移交的由移交后的故障拥有部门负责通报故障通知范围包括运维部、呼叫中心以及故障涉及到的技术部门、业务部门、 合作区域接口部门及市场销售部门相关联系人。6.割接管理规范第一条 目的为规范网络和系统的割接管理程序，确保割接过程对各种业务和用户的影响最 小,保证网络和系统的安全、稳定运行，特制定本管理办法。第二条适用范围由华夏视联运维支持部门负责的日常运行维护的相关业务服务系统、业务支撑 系统、业务应用系统、业务承载网络以及光缆网络的割接操作，均须遵守本管理制 度。第三条割接定义割接是指包括更

28、改、更换、搬迁、调整、升级和维修等将造成（或有可能造成） 业务中断或对正常网络和系统的运行造成影响的有计划的变更操作。割接所涉及的 对象和范围，各部门可根据各自部门业务的特点，结合割接的含义，自行定义和划分，并制定部门割接制度以供参考。第四条割接单位定义割接项目单位：为各级运维生产部门或负责已承载业务的在建网络系统的建 设部门以及各类支撑系统的维护部门，如网络运维部、工程部、 IT管理部、技术应用部、应用支持部等。害接项目单位负责提出网络割接申请、制定割 接方案、提交割接确认表、实施割接、进行割接确认、反馈割接结果（割接 总结）。割接调度：负责分配割接编号，发布割接通知、割接结果通知，收集整个

29、割 接过程中的相关文档，统计割接数据等。割接审批单位：指对割接进行可行性审核的部门或公司领导。*割接配合单位：指配合割接项目单位进行割接相关操作的相关部门。第五条割接的分类和等级定义：根据割接类型不同，可将割接划分为三大类：第一类割接：主要指面向用户的直接影响用户业务的服务系统、应用系统和 业务承载网络的割接。第二类割接：主要指光缆割接，包括网络互联部分以及客户接入部分的光缆 所作的割接。-第三类割接：主要指业务支撑系统、办公系统等系统类的割接，包括各类OSS OA等系统。根据割接受影响用户程度的不同，将割接分为四个等级，等级之间以影响范围 和中断时长两个参数作为主要判断依据：-第一级割接：指

30、对业务承载网络、业务应用系统、业务服务系统进行割接时， 影响100%的用户，中断时间4小时；或两种以上主要业务 50%以上用户， 中断时间2小时的割接。*第二级割接：指对业务承载网络、业务应用系统、业务服务系统进行割接时， 影响某一主要业务20%以上的用户，中断时间2小时，或两种以上主要业务 10%以上用户，中断时间1小时的割接。*第三级割接：除第一、第二级以外的所有网络或系统的割接，割接影响一个 以上的用户，主要包括光缆割接、小区机房级别的小范围网络割接。第四级割接：指不影响用户业务但需要用户或公司关注的割接，或针对单个 客户所进行的割接。第六条紧急割接的定义：因意外事件或紧急事件引起，或网络、系统性能大幅度下降，影响到业务正常 运行的情况下，在自发起割接申请起 24小时