运营支撑保障管理规程教材Word格式文档下载.docx

1、234567891112131. 概述随着公司用户规模的不断扩大、公司合作区域的不断拓展和公司新产品、新应用的不断推出，运营维护及服务保障的压力越来越大，对各后台支撑部门的保障能力及部门间的协作提出了更高的要求，为规范公司的运营保障流程、加强运营支撑部门的分工协作、提高运维保障水平、提高用户故障响应及服务质量，从而确保为用户提供及时、准确、到位的运营支撑服务，特制定本规程。本规程界定了运营支撑保障体系的架构及相关部门人员的职责分工、部门间的协作流程、主动运维规范、故障受理及处理反馈流程、割接管理规范、问题管理规范等涉及公司整体运营支撑保障的各环节流程及规范。本规程适用于对已投入运行维护的各种业

2、务承载网络、业务应用系统、业务服务系统以及各类支撑系统（包括已承载业务的在建网络系统和已有大量测试用户的测试系统）所涉及的运营保障支撑工作。本规程主要分为如下几个部分：一、 运营支撑保障体系架构及分工协作二、 主动运维管理规范三、 故障管理（受理及处理）规范四、 割接管理规范五、 问题管理规范2. 运营支撑保障体系架构2.1. 体系架构图采用四级技术支撑体系架构，分现场支持（合作城市运维部门）、一线支持（指运维中心）、二线支持（指后台各相关专业部门）、三线支持（指设备、系统的厂商及产品开发部门）。2.2. 各部门职责1、合作城市运维部门 负责受理当地客户的故障申告 负责本地业务网络的运维 负责

3、本地业务系统的硬件维护 负责配合运维中心完成故障的现场排查2、运维中心 负责公司所有已移交上线运营的各产品及应用系统的运行监控（724小时） 负责割接调度、割接的对外通知和确认 负责对所有上线运营系统的故障统一受理，对故障进行测试、初步判断，对故障调度，跟踪故障处理情况，汇总处理结果，回复结果给故障投诉人，使故障处理形成闭环； 通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况；3、二线支持二线支持部门主要包括：技术应用部、IT管理部、应用支持部、运维中心的各二级部门及其它后台支撑部门或业务部门。 运行管理：对系统和网络进行日常主动巡检、性能分析、优化改造 故障管

4、理：负责所有一级支持部门转交的网络故障投诉的处理，重大故障的分析 问题管理：以找到问题根源、提出解决方案，避免故障重复发生的机制，对问题在各个二线、三线支持部门的处理进行跟踪管理 技术支持：对公司各类业务相关网络和系统运行中出现的热点难点问题，为其它部门进行技术支援；4、三线支持三线支持部门主要包括：产品开发部、应用支持部（自主开发的部分）及厂商。 此层面包括设备、系统的最终技术支持层面 受理网络、系统运行过程的技术咨询及对一、二线支持提供培训 为产品使用方提供远程和现场技术支持 负责对网络、系统运行中的发现的，无法定位的问题进行原因查明，并提供解决方案2.3. 运营支撑各层面间的分工协作1、

5、各部门的主要职责及分工责任人、部门主要职责时间节点及要求公司分管领导（何总、蔡总） 对一级、二级重要故障的处理指导与监督 对一级重大故障的协调与督办其它公司领导 了解并关注一、二级重要故障的处理进程及结果（网管中心） 负责公司所有已移交上线运营的各产品及应用系统的运行监控（7 负责对所有上线运营系统的故障统一受理，对故障进行测试、初步判断，对故障调度，跟踪故障处理情况，汇总处理结果，回复结果给故障投诉人，使故障处理形成闭环； 通过运行日报、周报、月报等形式向各个相关部门传递网络系统的运行状况及故障处理情况724小时值班（其它二级部门） 承担本规程所规定的本部门所负责系统、网络及设备的主动运维、

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

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

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

9、部门要及时跟进问题的处理结果和进度，确保问题得到有效的处理及反馈，并最终形成问题解决的闭环（具体参见故障管理和问题管理部分）。3.3. 建立和完善故障处理预案制度为减少或避免同类或类似问题再次出现或多次发生，各运维部门应建立并逐步完善故障处理预案制度，对重要的故障及可能多次出现的故障根据前期的处理情况制定完整的处理预案，并对相关运维人员进行培训和传达，以确保在主动运维及故障发生后的第一时间根据处理预案进行及时、有效的故障分析和排除。故障处理预案可根据故障等级、故障性质及故障类别等进行分类和保存，以方便故障处理人员的查阅和调用。公司鼓励和支持各运维部门加强横向的沟通和交流，不断完善各自在故障处理

10、预案上的积累与提高。4. 故障管理规范4.1. 故障定义本管理办法中定义的故障，主要是指网络和系统在运行中设备、线路或应用服务出现各种异常问题导致服务中断，或者导致网络和系统运行质量降低、维护指标劣化超过门限值的现象；主要考虑对业务影响的程度和业务影响范围，对于有计划的割接和维护操作所造成的业务影响，不列为故障。同时，为使故障的传递和描述规范化，按照网络和系统的业务组成及其网络层次，对故障进行如下结构分解定义：1. 故障的编号：故障的数字编号。2. 故障的名称：故障所在点，包括客户、网络设备或系统名称。3. 故障的业务分类：故障所涉及的业务主体，包括： 交互电视网络：承载交互电视业务的网络 I

11、PTV服务系统：承载IPTV业务的应用系统 增值服务系统：承载数字电视增值业务的系统，如游戏、财经、彩票等 传输网络：承载传输业务的网络 动力系统：机房电源系统 综合业务：包含上述多个业务 应用服务系统：包括如增值服务等提供应用业务的业务平台，如游戏平台等 支撑系统：OSS，BOSS等 其他：未包含在上述业务范围内的4. 故障的层次： 骨干层（应用层）：骨干机房的网络设备、应用服务系统及互联链路 接入层：指骨干机房或小区机房的网络设备到客户前端接入设备之间，包括小区机房的网络设备 客户层：客户机房相关业务的接入设备5. 故障的类别： 设备故障：硬件设备本身引起的故障。 配置故障：业务配置数据存

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

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

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

15、超时由故障管理系统实行自动判断。五级四级三级二级一级超时时限（小时）482、故障的升级故障的升级是为了获取更多的资源和关注。 升级规则：不连续性，即同一故障每次只能升一级，不进行跳跃性升级。 升级时限：不同级别的故障对应不同的升级时限，其实现途径由故障管理系统根据故障记录的实际发生时间作自动升级判断。升级时限（小时）72244.4. 故障的受理与处理1、管理原则以故障拥有人为故障主要责任人，故障发起人为次要责任人。即故障拥有人对故障负有主要责任，包括处理、跟踪、调配、协调、监督、通知、报告等等。故障受理 原则上公司对外统一的故障受理入口为运维中心，其他专业部门不直接受理故障。故障受理人和故障申

16、报人在故障传递时，必须主动互报姓名。故障受理人员必须在故障记录系统中对故障的基本信息进行记录，包括故障时间、故障现象、客户联系人、联系方式等，并对故障的后续处理做出判断，处理或移交给相关人员，如果移交必须记录相应的移交人。 各个环节的故障处理人员必须在故障记录系统中对故障原因、故障处理过程、故障处理结果进行详细的记录。 必须在故障解决之后才能结束故障，特殊的需要非正常结束的故障必须由专业部门指定人员或主管及以上人员方可结束。 一、二级故障在故障结束时必须对故障的起止时间，故障的影响范围和影响程度进行记录和评估，同时故障拥有人必须出具重大故障报告。 重大故障的故障记录至少一小时更新一次。 各专业

17、处理故障的工程师对故障记录中故障类别、故障名称的准确性负责。2、故障处理 故障的处理采用“首问责任制”，即：故障受理的责任部门及责任人一旦接到故障受理的指令，需对整个故障处理过程全程负责，并及时跟进故障的处理进程，直至故障处理结束形成闭环后为止。故障处理期间出现的任何问题或结果，首问责任人及部门应承担主要责任！ 诊断故障时，应对故障现象、告警信息等进行认真分析处理，并本着先局内后局外；先本端后对端；先基础网络后业务网络，先重点后一般，先调通后修理，故障消除后立即复原的原则。 查找分析故障时，一般不应影响正在通信的用户或者任意扩大影响范围，并严格按照专业维护规程进行处理。 各个专业部门要制定本专

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

19、通过互相协商进行故障转移，但故障转移时，必须出具转移的理由和原因。 故障转交需在完成书面手续并经双方签字确认后，首问责任才可转移给相关部门，否则故障移交部门仍承担该故障的“首问责任”！4、故障的处理升级故障等级故障处理升级时限故障拥有人部门主管部门经理分管领导公司所有领导L14小时；或两种以上主要业务50以上用户，中断时间2小时的割接。 第二级割接：指对业务承载网络、业务应用系统、业务服务系统进行割接时，影响某一主要业务20以上的用户，中断时间2小时，或两种以上主要业务10以上用户，中断时间1小时的割接。 第三级割接：除第一、第二级以外的所有网络或系统的割接，割接影响一个以上的用户，主要包括光缆割接、小区机房级别的小范围网络割接。 第四级割接：指不影响用户业务但需要用户或公司关注的割接，或针对单个客户所进行的割接。第六条 紧急割接的定义：因意外事件或紧急事件引起，或网络、系统性能大幅度下降，影响到业务正常运行的情况下，在自发起割接申请起24小时之内必须进行的割接定义为紧急割接，紧接割接也同时包含第五条中三种类别和四个等级的划分。第七条 “割接”与“故障处理”和“在线网络操作”的区分：1. 割接与故障处理的区分：若因不可抗拒的自然灾害或突发性事件，或网络、系统性能突然急剧下降，造成网络和系统服务质量已无法保证的情况下，工