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

《运营支撑保障管理规程.doc》由会员分享，可在线阅读，更多相关《运营支撑保障管理规程.doc（32页珍藏版）》请在三一办公上搜索。

1、运营支撑保障管理规程(Version 1.0)2009年7月基本信息文档名称运营支撑保障管理规程文档编号当前版本1.0发布版本1.0起草时间2009年6月定稿时间2009年6月编制姓名部门电话电子邮件郭海涛运营管理部曾宪龙运维中心林 杰技术应用部丁继承IT管理部王秀双产品管理部审核蔡高伟备注审阅人修订记录序号修改时间修改人主要修改存档版本123456789111213目录1.概述52.运营支撑保障体系架构62.1.体系架构图62.2.各部门职责62.3.运营支撑各层面间的分工协作83.主动运维管理规范93.1.主动运维的概念93.2.建立预检、巡检及预警机制103.3.建立和完善故障处理预案制

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

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

4、管理规范2. 运营支撑保障体系架构2.1. 体系架构图(所有上线产品的用户)应用支持部呼叫中心其它故障受理渠道采用四级技术支撑体系架构，分现场支持（合作城市运维部门）、一线支持（指运维中心）、二线支持（指后台各相关专业部门）、三线支持（指设备、系统的厂商及产品开发部门）。2.2. 各部门职责1、合作城市运维部门l 负责受理当地客户的故障申告l 负责本地业务网络的运维l 负责本地业务系统的硬件维护l 负责配合运维中心完成故障的现场排查2、运维中心l 负责公司所有已移交上线运营的各产品及应用系统的运行监控（724小时）l 负责割接调度、割接的对外通知和确认l 负责对所有上线运营系统的故障统一受理，

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

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

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

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

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

10、分析及解决方案并协助公司技术部门彻底解决724小时待命（指定专门接口人）2、部门间协作关系图呼叫中心其它故障受理渠道应用支持部所有产品(所有上线产品的用户)3. 主动运维管理规范3.1. 主动运维的概念“运维就是服务”，运维未来的发展趋势势必是由被动维护转变为主动服务。与之相对应，运行维护工作的对象也从面向网络、系统、网元转变为面向用户，由面向设备维护转变为面向外部和内部客户服务。本管理办法中所提出的“主动运维”的概念即是从此理念出发，通过在公司建立和完善相关的预先检查、预先发现及处理以及编制完善的各类应急预案等，来达到把故障和问题的萌芽消除在其发生之前，从而减少或避免故障的发生，这不仅使用户

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

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

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

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

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

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

17、二级：重大故障，指包括以下情况的故障： 影响某一主要业务100的用户，中断时间1小时的故障； 影响某两种及以上主要业务10以上的用户，中断时间1小时的故障； 自第三级故障升级后的故障。l 第三级：主要故障，指包括以下情况的故障： 除一级、二级以外的同时影响多个用户的故障； 支撑系统、业务应用系统、骨干网络系统本身发生的但不影响业务的故障，如冗余故障等； 单个VIP客户故障； 来自第四级故障升级后的故障；l 第四级：次要故障，指包括以下情况的故障： 影响单个普通用户业务的一般故障； 客户接入链路发生故障，但不影响业务的故障，如客户的冗余接入发生故障等； 来自第五级故障升级后的故障。l 第五级：指

18、不影响业务的投诉，不属于故障统计范围，只作为故障的区分和记录用。4.3. 故障的超时与升级1、故障的超时故障的超时是为了明确和规定故障的处理时限，有效控制故障影响时长，其计时以故障记录时刻为起始点，结束为终止点。是否超时由故障管理系统实行自动判断。五级四级三级二级一级超时时限（小时）4822222、故障的升级故障的升级是为了获取更多的资源和关注。l 升级规则：不连续性，即同一故障每次只能升一级，不进行跳跃性升级。l 升级时限：不同级别的故障对应不同的升级时限，其实现途径由故障管理系统根据故障记录的实际发生时间作自动升级判断。五级四级三级二级一级升级时限（小时）7224814.4. 故障的受理与

19、处理1、管理原则以故障拥有人为故障主要责任人，故障发起人为次要责任人。即故障拥有人对故障负有主要责任，包括处理、跟踪、调配、协调、监督、通知、报告等等。故障受理l 原则上公司对外统一的故障受理入口为运维中心，其他专业部门不直接受理故障。故障受理人和故障申报人在故障传递时，必须主动互报姓名。故障受理人员必须在故障记录系统中对故障的基本信息进行记录，包括故障时间、故障现象、客户联系人、联系方式等，并对故障的后续处理做出判断，处理或移交给相关人员，如果移交必须记录相应的移交人。l 各个环节的故障处理人员必须在故障记录系统中对故障原因、故障处理过程、故障处理结果进行详细的记录。l 必须在故障解决之后才

20、能结束故障，特殊的需要非正常结束的故障必须由专业部门指定人员或主管及以上人员方可结束。l 一、二级故障在故障结束时必须对故障的起止时间，故障的影响范围和影响程度进行记录和评估，同时故障拥有人必须出具重大故障报告。l 重大故障的故障记录至少一小时更新一次。l 各专业处理故障的工程师对故障记录中故障类别、故障名称的准确性负责。2、故障处理l 故障的处理采用“首问责任制”，即：故障受理的责任部门及责任人一旦接到故障受理的指令，需对整个故障处理过程全程负责，并及时跟进故障的处理进程，直至故障处理结束形成闭环后为止。故障处理期间出现的任何问题或结果，首问责任人及部门应承担主要责任！l 诊断故障时，应对故

21、障现象、告警信息等进行认真分析处理，并本着先局内后局外；先本端后对端；先基础网络后业务网络，先重点后一般，先调通后修理，故障消除后立即复原的原则。l 查找分析故障时，一般不应影响正在通信的用户或者任意扩大影响范围，并严格按照专业维护规程进行处理。l 各个专业部门要制定本专业的故障处理流程，制定紧急情况下的应急措施，维护人员应熟悉操作处理办法并严格按照流程图操作。l 各个环节的故障处理人应依据故障处理升级原则，对于在规定时限内未能处理的故障及时升级。l 工作时间内故障处理完毕后由故障处理人员根据故障记录里的客户联系信息通知故障申告人，并记录反馈信息。非工作时间由网管中心运行工程师跟客户联系通知。

22、3、故障的转交故障的转交是指故障拥有人的更换，也同时表明了故障责任的转移，转交原则遵循如下规定： l 以故障管理平台中记录为主，禁止一切无记录的转交；口头转交必须清楚表达“转交”两字，同时由转交的任一方在故障平台中详细记录。l 禁止故障在转交时，向下游回传。专业部门之间的故障转交可通过互相协商进行故障转移，但故障转移时，必须出具转移的理由和原因。l 故障转交需在完成书面手续并经双方签字确认后，首问责任才可转移给相关部门，否则故障移交部门仍承担该故障的“首问责任”！4、故障的处理升级故障等级故障处理升级时限故障拥有人部门主管部门经理分管领导公司所有领导L11min5min10min10min20

23、minL25min10min15min20min30minL360min90min24hours48hours72hoursL490min120min72hours7days7daysL548hours72hours120hours15days15days对于未能在规定时限内解决的故障必须及时升级到相应的技术岗位。对于一级二级故障必须由项目负责人和部门主管或经理负责指挥调度。5、故障属性的更改为使故障的等级、层次、类别的划分保持严格的准确性和统一性，其变更遵循如下规则：l 等级的变更：一级、二级的故障变更权限仅为各专业或故障类别中的特定人拥有，其他等级的变更以故障拥有人为主。(需各专业指定)l

24、 类别、层次等的变更：以故障拥有人作最终变更授权人。6、故障报告l 对于一级二级故障需填写故障报告（参见故障报告模板），并在故障解决后三天内上报相关部门及公司所有领导；故障报告必须详细说明故障现象、故障原因、故障处理过程、故障影响范围、已经采取的措施和即将采取的措施。l 其他级别的故障报告根据需要，由故障拥有人制定；需要提交给客户的故障报告，由客服公司制定，并经各专业部门或故障所涉及部门确认后，提交市场部门，由市场部门作最后的确定。l 由网管中心负责故障统计日报、周报、月报的整理。各专业部门负责每月的故障分析报告。7、故障监督网管中心所有记录的未解决的故障有监督职责，需定期浏览故障处理情况，对

25、于未能在规定时限内解决的故障需询问故障拥有人，并做相应的记录。8、对故障处理结果的考核：按照公司考核中相关规定，对各执行单位进行考核，对不按规定执行的单位将予以通报处理，对造成重大事故的，将追究相关部门领导和责任人的责任。4.5. 故障的通知通报机制l 根据故障等级对故障通报范围明确如下：故障等级故障通报范围及通报方式故障可能涉及的相关部门接口人分管领导及所有涉及部门的部门经理公司所有领导及接口部门相关人员L15min （电话） 10min （电话）20min （短信）L210min （电话）20min （电话）30min （短信）L390min （电话）48hours（邮件）72hours（

26、邮件）L4120min（电话）7days （邮件）7days （邮件）L572hours（邮件）15days （邮件）4小时；或两种以上主要业务50以上用户，中断时间2小时的割接。 第二级割接：指对业务承载网络、业务应用系统、业务服务系统进行割接时，影响某一主要业务20以上的用户，中断时间2小时，或两种以上主要业务10以上用户，中断时间1小时的割接。 第三级割接：除第一、第二级以外的所有网络或系统的割接，割接影响一个以上的用户，主要包括光缆割接、小区机房级别的小范围网络割接。 第四级割接：指不影响用户业务但需要用户或公司关注的割接，或针对单个客户所进行的割接。第六条 紧急割接的定义：因意外事件

27、或紧急事件引起，或网络、系统性能大幅度下降，影响到业务正常运行的情况下，在自发起割接申请起24小时之内必须进行的割接定义为紧急割接，紧接割接也同时包含第五条中三种类别和四个等级的划分。第七条 “割接”与“故障处理”和“在线网络操作”的区分：1. 割接与故障处理的区分：若因不可抗拒的自然灾害或突发性事件，或网络、系统性能突然急剧下降，造成网络和系统服务质量已无法保证的情况下，工程、运维、维护、IT管理等人员应作为故障处理对待，在第一时间做出反应，并进行相应操作以尽快排除故障。此时不须执行割接（或紧急割接）申请流程。2. 割接与在线网络操作的区分：割接属于特殊的在线网络操作。按照以上第二条中割接之

28、定义，割接项目对操作的计划性、步骤性、实时性有更高的要求。若网络操作属运维、维护、IT管理等单位日常的数据修改、软件版本升级、端口调整、新产品测试等，不影响业务运行和用户正常使用，且不需多部门同时协作进行的一般性网络操作，不须执行割接申请流程。第八条 割接申请及审批流程 ：割接的审批根据割接等级和类别以及紧急程度不同而不同：1. 第一至三类的第一级割接：割接项目单位须制定详细的割接方案、割接通知，并填写割接申请单，于系统割接前提前7个工作日上报运营管理部门，运营管理部门在接到申请后2个工作日内组织相关部门对割接方案进行审核。若属全网性重大割接，在审核、确认通过后，须报公司主管副总进行审批，审批

29、通过后由运营管理部向割接项目单位下达割接调度令。2. 第一至三类的第二级割接：由割接项目单位制定详细的割接方案、割接通知，并填写割接申请单，于系统割接前提前3个工作日上报网络运维部，网络运维部门在接到申请后1个工作日内组织相关专业部门对割接方案进行审核。审核通过后向割接项目单位下达割接调度令。3. 第一至三类的第三至四级割接：由割接项目单位部门内部审批，走部门内部割接审批流程。4. 紧急割接：割接项目单位必须在将割接事由、割接方案告知网络运维部后方可执行，网络运维部在接到割接项目单位执行的紧急割接通知时，必须于第一时间内安排专人配合，协助割接项目单位完成割接任务。第九条 割接类别与等级的确定：

30、割接类别由割接项目单位确定，割接等级由网络运维部确定。第十条 割接的编号方法编号格式为： YW-N-M-X-YYMMDD-NNN段位置业务信息说明112部门简称YW或者GC或者IT23割接类型1-第一类割接，2-第二类割接，3-第三类割接 34割接等级1-第一级割接，2-第二级割接，3-第三级割接 4-第四级割接4 5专业代码I-IP网络 S-系统 O-光缆 C-传输 P动力5611割接日期如040101，割接时间为2004年1月1日61214割接顺序号如002表示年内该专业的第2个割接割接编号由割接调度人员统一提供第十一条 割接的通知1. 割接项目单位在制定割接方案后，将割接通知、割接申请单

31、和割接确认表提交到割接调度邮箱组：，同时双方以电话和邮件回执的机制来进行保障邮件是否到达。2. 割接调度在接到割接项目单位提交的割接通知、割接确认表和割接申请单后，根据割接通知范围列表，发出割接通知，内容包括割接原因、割接时间、割接类型、割接等级、割接编号、受影响用户清单等。3. 割接内部通知范围：受影响范围通知对象通知内容通知方式合作城市市场、技术支持、传媒等与拓展业务相关部门定制割接通知， 针对合作城市制定相应的割接受影响内容（含market，market-sup，back-sup，china-ceo，noc邮件组）4. 割接受影响合作城市的通知 运维中心根据割接受影响城市的范围，采用邮件

32、或电话的方式，逐个通知到合作城市指定的联系人。5. 割接的通知内容：主题必须包含割接时间、割接名称、发起部门（例如：运维部或IT管理部）、割接编号。6. 重大割接的通告：一级割接除了正常的通知方式之外，根据具体的割接情况选择其他的通告方式，主要包括网站、数字电视、平面媒体，通告方式的选择由运营管理部决定。第十二条 割接的实施：割接项目单位必须在接到割接调度令（以割接通知邮件为准）后才能实施割接，割接实施时必须统一指挥，统一调度，参加割接的所有部门应密切配合，割接现场必须设置割接联络电话，割接开始、完成及出现异常情况时，均应向割接现场总指挥报告，再逐级上报。第十三条 割接出现异常不能按计划完成情

33、况的处理：在割接过程中出现异常情况而不能按计划完成时，应按照应急方案及时恢复网络系统，并立即将情况向相关部门报告。割接项目部门应在36小时内写出原因报告，格式见附件，上报割接审批单位。二次割接须重新报批。第十四条 割接的确认和回访n 割接状态的确认：割接实施时，运维部网管中心根据割接确认表中需要确认的条目进行割接确认，并向割接负责单位反馈确认结果，同时根据确认结果，向客服部门提交割接回访通知单。n 割接状态的回访：客服部门于割接后09：00前，根据割接回访通知单对用户进行割接回访，并向割接负责单位和割接调度反馈回访结果。n 割接结果的确认：割接项目单位在割接实施结束后，以邮件方式将割接结果告知

34、割接调度，包括割接的起止时间和大致完成情况。割接调度在割接项目单位的割接完成情况简述后，于割接后的第一时间内将割接结果以割接结果通知单的形式通知相关部门，割接结果的通知范围同割接通知的范围。第十五条 割接的终止及变更：对于第一级割接，割接申请一经审批同意后不得随意终止或变更，如遇特殊情况必须取消割接作业，或变更割接时间，须由割接项目部门填报割接变更申请单，经审核审批单位批准后方可终止或变更，由割接调度发布割接变更申通知。终止变更时限要求相对批准割接时间至少提前1个工作日。其他类割接的终止和变更流程根据各割接项目单位内部流程执行。但均需将变更通知提交割接调度，由割接调度发布割接变更通知。第十六条

35、 割接报告：割接项目单位须详细地记录割接过程，割接完成后应尽快通知相关部门，在割接完成后36小时内写出割接总结报告，上报割接审批单位。割接报告中应根据具体实施情况，对割接方案等资料进行补充说明，并与测试、资源回收等数据一起转交相应的运维、维护、工程、受理等部门存档，各部门应根据割接后的变更对相应资料及时进行更新。第十七条 割接流程及各部门职责割接流程：各部门主要职责：部门主要职责割接项目单位l 根据各种情况，提出割接事由l 制定割接方案l 确定割接类型l 提交割接申请、割接通知、割接方案、割接过程文档（割接确认表、割接变更申请单等）l 按计划实施割接任务l 割接实施后，向割接调度反馈割接完成情

36、况l 提交割接总结割接调度l 发布割接通知、割接结果通知l 归档割接文档：割接申请、割接方案、割接通知、割接结果通知、割接总结以及割接过程文档（割接变更申请、割接确认表、割接回访表等）l 割接统计：每月对割接进行统计，包括割接次数、割接结果情况、割接文档收集情况等，将割接统计结果上报运营管理部。l 割接调度单位暂由运维部承担运营管理部l 组织相关部门和割接项目单位对第一级割接进行方案审核，确定割接与否运维部l 协助割接项目单位制定受影响用户清单l 确定割接等级l 对二级割接进行审批l 割接实施时，进行状态监控，根据割接确认表进行割接配合确认，并将结果反馈给割接项目单位和客户服务部市场部门l 对

37、客服无法通知到位的用户进行单独通知其他部门l 关注各类割接第十八条 割接文档的存档割接全过程的文档在割接调度处统一存档，主要包括割接申请、割接方案、割接通知、割接结果通知、割接总结、割接变更申请、割接确认表、割接回访表等。第十九条 关于考核按照公司绩效考核中的相关规定，对各执行单位进行考核，对不按规定执行的单位将予以通报处理，对造成重大通信事故的，将追究相关部门领导和责任人的责任。6. 问题管理6.1. 问题管理定义1、问题的定义及与故障的关系问题管理是指通过对待解决问题的采集、跟踪、处理，查明问题产生的潜在原因，并制定解决问题的方案和防止问题再次出现及故障、事故等再次发生的措施。待解决的问题

38、是指在系统运行中，发生的故障原因无法定位或原因定位后暂时无法彻底的解决，这些问题均应纳入问题管理范围。问题管理与故障（事件）管理的区别在于目的不一样：问题管理的目的是分析事件存在的问题和原因，再从根本上解决问题。而故障（事件）管理的目的是使用各种可能的办法迅速解决故障，快速恢复正常业务服务。2、问题管理的意义结构化、系统化的问题管理方法能够迅速查明故障发生的潜在原因并找到解决此故障的方法或防止其再次发生的措施。因此，健全的问题管理关注预防性措施和引发故障的潜在因素的识别，其目的是寻找发生问题的根本原因，根据优先级定义解决关键性问题，并防止与这些故障相关的故障再次发生，增加支持人员解决问题的能力

39、，以维持一个稳定、健康的服务环境。6.2. 问题的来源及分类1、问题的来源问题的来源主要通过以下方面：l 日常运行分析报告（日报、周报、月报及不定期报告等）l 重大故障报告（专项报告）l 日常巡检发现（巡检报告及记录）l 日常故障评估l 管理改进要求l 新的业务需求l 2、问题的分类问题管理根据以下方面进行分类：l 系统分类问题关联的领域，如哪个子系统l 影响度描述问题对业务的影响程度，需量化评估，包括影响用户小时数和频度等l 紧迫性问题需要得到解决的紧急程度，以周为单位表示计划解决的时间l 优先级综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序l 状态描述问题所处的状态，包括

40、疑似问题、问题、已知错误、错误观察、已解决等n 疑似问题：指发生一次故障，怀疑存在隐患，需进行观察后转为问题n 错误观察：指已知错误以实施了解决方案，在确认解决问题前的观察期的状态6.3. 问题管理的流程及分工1、问题管理流程具体流程如下图所示： 问题跟踪与通报问题关闭问题处理问题采集（1）问题采集根据上一部分中所列的问题来源进行问题的采集。（2）问题处理问题管理部门负责对问题进行分析，查找其最终原因，并安排进行处理，必须明确每个问题的解决时间/计划。（3）问题关闭问题解决并经相关运维部门验证后，问题管理部门及负责人进行问题处理过程的总结并通报相关部门后可关闭该问题。（4）问题跟踪及通报问题管理部门应及时跟踪本部门负责的所有问题处理的进展及结果，并每周通报重要问题的处理情况及进展、每月通报所有问题的处理情况及进展。2、问题管理的职责分工各运营支撑部门的具体分工如下：（1）运维中心：负责所有初验移交的系统的所有问题采集、处理（包括移交后台处理的跟踪、协调等）、关闭及跟踪通报等。（2）技术应