代维集团专线故障处理流程优化[范文大全]

第一篇：代维集团专线故障处理流程优化

集团专线流程

整体流程：监控派单>代维提单>联系用户>上门>故障定位>故障处理>代维回单>监控回单 流程各环节关键时间点：

1、代维提单（催单：系统不支持，人工抽查）

代维公司10分钟内提单。如该线路未验收或发现为对方工单，需在20分钟内反馈未验收情况及将工单派对方。

2、联系用户（催单：系统支持，每单必跟）

代维公司30分钟内联系用户，若未联系到用户，需上报故障管理人员，同时在工单中阶段回复（工单中回复联系哪个客户及联系方式）。

3、代维上门（催单：系统支持，每单必跟）

金牌1小时内；银牌4小时内；普通8小时内，如遇客户端距离较远等原因无法在规定时间内到达，需在故障历时1小时时向客户说明原因，并在工单上阶段回复，每家代维当上级故障少于两件时，本级故障需按金牌故障标准1小时内上门。

4、故障定位（催单及上报：系统支持，每单必跟）

金牌2小时内；银牌5小时内；普通9小时内未定位故障原因，需上升故障管理人员，内容需包含详细处理过程及相关数据（另有文件描述），故障管理人员走EOMS技术支援工单，由故障管理人员跟进该故障定位情况。所有现场情况均需在规定时间内阶段性回复SUPPORT工单。

5、故障处理（催单及上报：系统支持，每单必跟）

金牌2.5小时内；银牌6小时内；普通10小时内未完成故障处理，需上升故障管理人员，由故障管理人员督促故障处理进度；金牌3小时、银牌7小时、普通11小时未完成故障处理，由故障管理人员上报相关部门三级经理；金牌4小时、银牌8小时、普通12小时未完成故障处理，由故障管理人员上报相关部门领导；故障处理过程中，现场维护人员应每1小时给客户反馈一次故障处理进度，并在工单中阶段回复。如因特殊原因，故障不能及时处理完的，应给客户进行说明，并上报故障管理人员备档。

6、工单回复（催单：系统不支持，人工抽查）

工单回复必须符合前期制定的“集团专线工单回复标准”。

7、故障分析会：当故障导致用户意见大且上升到集客部或领导的，第二个工作日内，牵头集客部、各相关专业及公司专家，召开专题故障分析会，其余有必要召开会议的（我中心认为的），三个工作日牵头召开专题故障分析会，所有专题会。

第二篇：代维故障处理规范

代维故障处理规范

为保证代维单位及时高效地处理故障，结合公司实际制定本规范。

一、故障分类

按照目前代维公司维护的界面分工，需要代维处理的故障主要分为基站设备故障（主要为动力配套设备）、基站停电故障、光缆线路故障（按线路级别分干线、本地网、接入网）、室内分布系统。

二、故障通知程序

1、基站设备故障

基站设备故障由网管中心值班人员通过监控系统发现通知基站代维管理员，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理。

2、基站停电故障

基站停电由网管中心值班人员通过动力环境监控系统发现通知基站代维管理员，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理。

3、光缆线路故障

干线光缆线路故障（含本地网骨干网线路）网管中心值班人员通知线路代维管理人员，同时通知传输中心值班工程师和传输中心主任，线路代维管理人员接到通知后应立即通知代维公司专业接口人，并向部门分管领导汇报，代维公司未能在规定时间内修复障碍的，网管中心值班人员应立即部门经理和公司分管领导。

本地网线路故障（本地网骨干网除外）网管中心值班人员通知线路代维管理人员，同时通知传输中心值班工程师和传输中心主任，线路代维管理人员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，线路代维管理员应立即通知动力代维中心主任和部门分管经理。

接入网线路故障由客响中心112故障专业人员和网管中心值班人员谁先发现谁通知客响中心值班工程师或县分装维人员，客响中心值班工程师（或县分装维人员）判断为线路故障应立即通知线路代维管理人员（网管中心值班人员若能直接判断线路故障可直接通知线路代维管理人员，并告知客响中心值班工程师），线路代维管理人员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，线路代维管理员应立即通知动力代维中心主任和部门分管经理。

4、室内分布系统

室内分布系统故障由网管中心值班人员通过监控系统发现通知基站代维管理员和无线中心主任，并做好故障派单记录，基站代维管理员接到通知后应立即通知代维公司专业接口人，并做好故障记录督促代维公司在规定时间内修复障碍，代维公司未能在规定时间内修复障碍的，基站代维管理员应立即通知动力代维中心主任和部门分管经理，网管中心值班人员应通知部门无线分管经理。

三、故障处理记录

1、对于基站设备和停电故障，代维单位每周汇总一次提交基站代维管理人员，对涉及到的抢修材料应做好台账登记。

2、对于线路故障，应在处理故障结束后24小时内提交故障处理记录。

四、故障处理支撑

对于已经交由代维单位处理的故障如不能及时抢通修复，运行维护部相应专业需派人到场进行指导和督促。对于影响业务的故障如代维单位不能在规定的抢修时限内完成，基站或线路代维管理人员应与相关专业工程师到场协助抢修。

五、故障归口及上报

所有涉及代维故障需第一时间通知到代维管理中心基站或线路代维管理人员，各专业工程师及县分工维中心工程师不得擅自调动代维人员，紧急情况下可先通知代维抢修人员后向代维管理中心报备。所有代维公司处理的故障由动力代维中心督促代维公司提交故障处理记录后向质量管理中心进行上报。

二○一二年一月十七日

第三篇：2010 东莞移动公司集团客户专线代维考核办法( 20100113)

集团客户专线代维质量考核办法

一、考核办法

1.考核每月进行一次，考核形式采取量化评分制。考核评分办法见东莞移动

公司《2009年集团客户专线代维量化考核表》。

2.对于存在问题未按甲方要求完成处理或未作改进措施，以致同类问题仍有

发生的，按相关问题的条款加倍扣分。

3.代维量化基本考核分为95分，采用扣分制，奖励分为5分，采用加分制，每月考核总得分不超过100分，考核得分为95分（含95分）以上为合格。

4.如果代维公司全年累计三次代维考核得分低于80分，或者连续两次代维考

核得分低于80分，或者一次代维考核得分低于75分，东莞移动公司有权调整代为公司的代维量或者单方面解除代维合同。

5.如果代维公司一个月的故障处理及时率低于60%(含60%)，移动公司有权终

止代维合同。

6.如果代维公司连续两个月的故障处理及时率低于70%（含70%），移动公司

有权终止代维合同。

7.如果代维公司连续三个月的故障处理及时率低于80%（含80%），移动公司

有权终止本协议。

8.每月量化考核的成绩作为支付代维费的依据，移动公司应将每月考核得分

情况及时通报代维公司，并根据当月代维考核情况支付该月的代维费用。

9.以每月代理维护费用中的30%作为考核基数对代维公司服务质量进行量化

考核，根据量化考核得分付给相应款项。

10.对代维公司连续三个月得分在75分以下，全年累计四个月得分在75分以

下，移动公司可自行解除合同。

11.移动公司将每月考核得分情况在每月的代维总结会议上通报。

12.详细的扣分情况和扣分原因在每月的代维量化考核表列出。

13.对于代理维护质量超过协议规定的，可适当给予奖励；对损坏设备及仪表的，应予惩罚及赔偿。

14.对代维公司在一年代维工作中服务质量好，工作积极主动，能力较强的，使得网络质量大大超过代维前的，东莞移动公司将向上级主管部门申报，经审核属实的，可给予一定的奖励。

二、代理维护工作量化考核表

集团客户专线代理维护工作量化考核表

代理维护公司：考核月份：年月

三、代维费用结算方法

1.东莞移动公司每月对代维公司的维护工作进行考核，根据得分计算应得维

护费。得分在95分（含95分）以上，不扣维护费；将每月代维总费用（M）的70%作为固定费用，另30%作为考核费用，即每月实际结算费用（L）= M×（70%+30％×月考核得分（Y）/100)，如月考核实际得分≥95分时，则Y按100分计算。

2.代理维护费用按月度以现金或支票支付的方式由东莞移动公司支付给代维

公司，具体费用以当月度考核情况核准费用支付。代维公司在每次请求付款前应向东莞移动公司开具正式发票。

第四篇：运维故障处理思路

事件/故障处理应该要有什么思路 导读：

在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子）：

业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。

运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有„„时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。

经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？”„„

运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况„„

最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事：

1.优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“ 2.提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”

3.完善故障应急方案——“应急方案是最新的、准确的、简单明了的” 4.长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做“ 下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。

1、常见的方法：

1）确定故障现象并初判问题影响

在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。确认了故障现象后，才能指导运维人员初判断故障影响。2）应急恢复

运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。

有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：

       服务整体性能下降或异常，可以考虑重启服务； 应用做过变更，可以考虑是否需要回切变更； 资源不足，可以考虑应急扩容；

应用性能问题，可以考虑调整应用参数、日志参数； 数据库繁忙，可以考虑通过数据库快照分析，优化SQL； 应用功能设计有误，可以考虑紧急关闭功能菜单； 还有很多„„

另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景，比如在杀进程前，可以先抓个CORE文件或数据库快照文件。

3）快速定位故障原因

 是否为偶发性、是否可重现

故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。

但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。

 是否进行过相关变更

大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。

 是否可缩小范围

一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。

 关联方配合分析问题 与第（3）点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。

 是否有足够的日志

定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。

 是否有core或dump等文件

故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如COREDUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。

上述是一般性的故障常见的方法，在重大故障或多方处理的故障出现时，往往小范围的排查不利于快速解决，需要启动紧急处理的流程，建议可以考虑以下沟通：

      召集相关人员 描述故障现状

说明正常应用逻辑流程 陈述变更

排查进展，展示信息 领导决策

2、完善监控

1）从监控可视化上完善

完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率，以呼叫中心系统为例，需要提前配置好以下实时交易数据，以便故障定位：

-交易性能数据：平均交易耗时、系统内部模块交易耗时（IVR交易耗时、接口总线交易耗时）、关联系统交易耗时（核心交易耗时、工单系统交易耗时等）-重要交易指标数据：交易量、IVR交易量、话务量、座席通话率、核心交易笔数、工单等系统交易量

-交易异常情况数据：交易成功率、失败率、错误码最多交易-按服务器分析交易数据：按server统计各服务交易处理笔数，交易总耗时 有了以上交易数据，并通过监控按一定频率统计，运维人员在出现故障时，通过鼠标即点击即可看到故障什么时候开始，是系统内部有问题还是关联系统有问题，最突出的交易是哪一支，各服务器交易量是否均衡等情况。

2）从监控面上完善

监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。

全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。

3）从监控告警上完善

完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。比如类似以下的监控短信：

22时，【理财应用系统】中【应用服务器LC_APPsvrA 10.2.111.111】的【前置应用模块】出现【应用端口：9080】不存在，该端口作用【提供理财应用处理（负载均衡部署）】，原因可能为【SERVER1服务异常停止】，监控系统己进行以下应急处理【自动执行端口进程启动】，该事件紧急程度【高】。管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题，可能是什么原因，对业务有什么影响，是否需要马上处理（比如凌晨出现此预警是否可以延迟到次日处理）等信息。

4)从监控分析上完善

完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警,实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙。

5)从监控主动性上完善

监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。

3、应急方案

提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题： 1）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确； 2）应急方案过于追求大而全，导致不利于阅读与使用； 3）应急方案形式大于实际使用效果，方案针对性不强； 4）只关注应急方案的内容，但没有关注运维人员对方案的理解； 针对上述常见问题，我认为应急方案需要做到以下几点：

1）内容精&简

很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以我认为应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。以下是我觉得应用系统应急方案应该有的内容：（1）系统级：

能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。

另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。（2）服务级：

能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。（3）交易级：

能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。这里最常用的方法就是数据库查询或工具的使用。

知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。（4）辅助工具的使用：

有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。（5）沟通方案：

沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。（6）其它：

上述5点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作。

2）应急方案是一项持续的工作

有了应急方案，如何让运维人员持续去更新是难点。我认为要解决这个难点，需要先让运维人员经常使用这个手册。如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。

3）关注运维人员对应用关键信息的认识

前两点关注了手册，最后一点我觉得有必要关注使用这个手册的人。有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻，所以应用运维人员在故障处理过程中的地位很尴尬，运维人员掌握操作权，但却不知道应该操作什么。

对此，我认同应用运维人员不需要掌握应用系统的业务功能，但我觉得就对应用系统本身来讲应用运维人员需要具备以下最基本的能力：（1）知道应用系统这个是干什么的，基本的业务是什么；（2）知道应用架构部署、上下游系统逻辑关系；

（3）知道应用下的服务的作用、端口、服务级的应急处理，日志等数据信息如何找到并简单定位。

（4）知道应用系统重要的时间点及任务，比如开业、停业、换日、定时任务的时间点以及如何判断这些任务是否正确（5）知道最重要的几支交易的流程；（6）知道常见数据库表结构，并能使用。

4、智能化事件处理

处理方法如下图（详细的智能化涉及监控、规则引擎、配置工具、CMDB、应用配置库等模块协同工作，具体介绍后续分析）

第五篇：常见电路故障处理流程

本次主要针对电路方面的一些基础知识和故障处理进行培训，培训内容主要有理论和实操两部分。其中理论培训主要包括：爱立信电路故障处理流程，电路单通测试（指令测试），光口故障处理流程，光口保护倒换原理，三种非爱设备简单故障处理。实操部分包括：LIFE3000使用，电路单通测试（挂表测试），传输有误码或中断时如何挂表测试，传输头制作，DDF ODF认识，基站应急割接模拟等方面。

爱立信常规故障处理流程

故障的类型主要有两大类：传输故障和交换设备故障。下面讲一些常见故障的处理。

传输故障又主要分为物理传输故障和链路故障。物理传输故障，主要是传输ABL或者是传输质量差而引起的话务设备ABL，影响通信业务，链路故障则是指信令链状态不正常，会影响信令的接续。

第一章、传输故障 第一节：2M口的介绍

一、传输的名称类型和出现的误码类型

爱立信的DIP名称类型：RTG（GPRS的GB接口）、RBLT、RALT、RAL2、RBL2、MALT、MAL1、C7B4、C7B5、UPET、UPE、UPD、UPD1，起名称长度不能超过7个字母。

首先看传输状态，用指令DTSTP：DIP=xxxx，传输状态主要有WO、ABL和MBL。传输ABL，其误码类型常见的有5种告警，FC 1＝AIS、FC 2＝LOF、FC 3＝ERATE、FC 4＝RDI、FC 9＝LOS。

二、传输常见误码的处理

传输出现的误码常见组成为：FC 1&

2、FC 2&

9、FC 4，下面根据误码来判断传输出现的情况：

FC 1&2：属于远端告警，对于此类故障，应该先在传输架上向本端自环，确定我们本端没有问题后，再和对端联系，要对端也在传输架上自环，如果两边自环都没有问题，那就需要传输室在中间一段检查、处理。FC 2&9：属于近端告警或者是收发接反。先在交换机上确认SNT和传输线是好的，然后在传输架上自环本端。如果正常，则和对端联系，将收发反一下，看是否能恢复。

FC 4：属于能够收到信号，而不能发送信号。这种误码可能是由于传输头松动，只有一边做好了，主要是排除本端传输的头是否有问题。

三、传输质量

下面讲一下传输质量。有时候传输状态查看是好的，但质量有问题，会使得误码逐渐增加，误码增加到一定程度就使得传输断掉。当传输是好的时候，有一定的误码，可以用以下指令清除，清误码也许只能治标而不能治本，最关键是要保证传输是通的。

DTQUP: DIP=XXXX;

DTQSR：DIP=ALL，DEGR，UNACC；

DTQSR：DIP=ALL，ES，SES，SF；

DTQSR：DIP=ALL，ES2，SES2；

第二节：光口ET155的介绍

ET155可以用来开电路和链路，在交换机没有升R9的时候，基于ET155的稳定性和安全考虑，一套ET155就开56个2M口，一般不用来开链。升为R9/R10后，就可以全部开电路，而且也用来开链路。其开电路和链路的方法和普通的2M电口没有任何区别。

ET155也存在传输质量问题，其误码的增加也会引起ET155的部分设备不能工作，在必要的时候就得清除传输质量误码，方法如下：

TPQSR：SDIP=XX，DEGR，UNACC；

TPQSR：SDIP=XX，ES，SES；

TPQSR：SDIP=XX，ES2，SES2；

光口ET155故障

A.维护人员从终端查看故障光纤中继的状态：指令TPSTP:SDIP=；见到MS及VC状态为

ABL(DEGR)；指令DTSTP:DIP=；查看DIP为ABL。

B.根据电路资料，在传输ODF架前一个位置，楼层纤ODF，作硬件自环。同时其他配合人员在终端指令检查光口状态(应不正常，否则需报其它科室处理)。而后，维护人员用光功率计在楼层ODF架测量光功率：-8~-20dbm之间的才合格。光功率计质量越小越好，C.维护人员在楼层ODF对其备用纤(原本不放通)向交换机作自环，并用光功计确定其通光正常。原则上是尽快确定出可正常通光到楼层ODF的通道。

D.将备用纤与传输端光纤接通。其后，先在终端解除话务在主用边的锁定：指令PWFSE:SDIP=;，再把话务锁定到光纤备用侧：指令PWFSI:SDIP=,MS=MS-1;，恢复通话。

第三节、电路设备、链路故障的处理

一、电路设备故障

当传输保证是正常状态的情况下，电路设备也会出现不能工作的现象。其设备状态不正常有三种情况：BLOC、LIBL、SEAL。

BLOC：指设备断掉，主要是因为传输不通或误码过大而引起的。

LIBL： 主要是对端未解开对应设备引起

SEAL： 可能是两端设备的CIC不对应，按要求正确定义即可；也可能是信令拥塞导致，可尝试重新定义一遍数据

二、链路故障

当七号信令链路状态不正常时，若为FC 3，则可以由人工闭解恢复(C7LAI:LS=?,SLC=?；C7LAE:LS=?,SLC=?)，若为FC 108 可能是由于本端传输自环而引起，查看传输状态

若为FC 206 可能是对端数据没有做，或本端的半永久连接数据有问题。

首先检查该信令链所属中继的状态是否正常 可以由指令

C7LTP：LS=

；打印状态

C7LDP：LS= ； 打印所占用的设备以及信令终端 EXSCP：NAME=SGG01-0；/DEV=UPD-1/C7ST2C-0；查看半永久连接状态，看是否为ACT

三、信令链全阻：

A.ALLIP;

B.C7LTP:LS=2-19－255－13；

打印信令链状态，看是否为全阻。

C.C7LDP:LS=2-19－255－13；

打印信令链所用的设备(DEVICE)D.EXSCP：NAME=GZG01-0；/DEV=UPD-1/C7ST2C-0；查看半永久连接，看是否为ACT

EXDEP:DEV=C7BTC4-XX;

可以查到设备所属的传输号（DIP号）

E.DTSTP:DIP=xxC7B4;

打印传输状态（FC=1&2多为远端告警），如果交换维护人员在本端传输架自环正常，则需要请传输室处理，传输室电话：86321169。

F.DTQUP:DIP=xxC7B4;如果传输状态正常，则查看传输误码 ；如果传输误码增加很快，交换维护人员在传输架自环，观察5－10分钟，在此期间，误码没有增加则请传输室处理。如果在自环过程中误码仍然不断增加，则为本端问题，需要重新做传输头。

四、单通测试

以每个季度为周期，完成番禺所有代维网元电路的单通测试。电口电路使用LITE 3000进行监听测试，光口电路可以使用指令测试，每套电路正常监听测试原则上不能超过3秒钟，特殊情况可适当延长至10秒以内。对于监听发现通话不正常的电路，要及时准确记录下来，确认为单通后，并及时上报交换室数据组闭掉电路，但还要继续跟进处理。

二、单通测试-指令测试

EXTPP;EXTPI:BNB=86***;NTCOP:SNT=UPET-1;STDEP:DEV=UPD-1&&-31;或者STRDP:R=GZB2O,STATE=BUSY/INCO;MOCOI:DEV=UPD-X;CMB;END;

西门子交换机日常重大、紧急故障处理流程

一、日常重大故障: A、中继故障 1）、查哪些中继传输断

STATPORT:EQN=1-6-2;STATTRUNK:TGNO=X STATTRUNK：TGNO=x，STATUS=NCAR； STATTRUNK：TGNO=x，CIC=x-y；

可查到哪一方向的哪一传输断。2）、先在本端自环，用STATDIU：LTG=x-y，DIU=z；检查PCM状态。如为ACT，则本端OK，报传输，让传输环给我们，再检查PCM状态，如为ACT，则为传输问题。

如为DIS-MA或DIS-SA，则多为传输问题。

如为MAL，则传输收发反。3）、对于DIU的UNA，可闭解一下

CONFDIU：LTG=x-y，DIU=z，OST=CBL； CONFDIU：LTG=x-y，DIU=z，OST=MBL； CONFDIU：LTG=x-y，DIU=z，OST=ACT； 4）、STATTRUNK查看时，参数STATUS意义为 IDLE 空闲 INC/OUT 打出/打入 NCAR 传输断

BADM 本端闭塞（CANTRDAT）HOBB 环路 MOBB 对方阻塞

NSYP 对方CIC没做，不同步 CCS7F NO7信令出错 MDIU DIU阻塞（人工）CDIU DIU阻塞（系统）MPRT PORT阻塞（人工）CPRT PORT阻塞（系统）

华为常见电路故障

一 假如监控报电路故障：GZB4到QYG06有传输断掉。

1>首先根据路由名查出对端中继号,命令：LST TG 2>检查故障状态是否正常,命令:DSP N7TKC 3>查询指定局向的电路信息，命令：LST OFTKC 4>通过MGW和查询电路信息，命令：LST TKCBYTID 5>查出TID,命令:LST TKC 6>查出本端端口之后，在传输架做环路测试，如果本端正常，联系对端处理,对端也是正常，转传输室处理。

二 假如监控报链路故障: GZB4到QYG06有套链路断掉。

1>首先根据路由名查出对端中继号,命令：LST TG 显示属于指定局向集的链路状态，命令：DSP N7LSLNK 2>根据模块查询链路状态，命令：LST N7LNK

3、贝尔日常维护

信令链路告警：

处理流程如下：

接到告警后用241看链路状态，再用241看链路配置，然后用MARCO或挂表测试传输是否正常，如果传输不正常本端原因检查传输，其他原因转传输室处理，如果传输正常，可尝试将链打死激活或者将信令终端重启，如果还是不行可以联系对端一起做重启信令终端的操作，一般可以恢复。以下是处理过程中涉及的详细指令：

链路有以下几种状态：

ACTIVE ……….表示链路正常

ACTING ……….表示链路中断

OOS

.…….表示链路退出服务

ORJ－DIS ……..表示链路人工闭塞

然后先:MM 7599:ALMTYPE=ALL,OPTION=LINK.（看链路告警）。

先:MM 241：DEST=”GZA1”&NAT,SLC=ALL,29=6;（按局向查看链路状态）先:MM 241：DEST=”GZA1”&NAT,SLC=ALL,29=1;（按局向查看链路数据）

可以查看到某个局向的链路配置:链路是2M还是64K,链路所占用的信令模块和中继模块。其中DTMEN的PCE是中继模块的NA,CCMEN的PCE是信令模块的NA。

看到配置后可以看中继状态是否正常，可用MARCO来检查，也可直接挂表测试。

用MACRO ALMPCE >ALMPCE:NA ALARM＝OFF 表示当前传输状态是好的

ALARM＝ON 表示当前传输状态是断的

如果链路所在传输没有问题，可尝试将链打死激活，指令如下：

先:MM 220：DEST= “GZA1”&NAT，SLC=0，FUNCTION=6；（链路打死）先:MM

220：DEST= “GZA1”&NAT，SLC=0，FUNCTION=5；（链路激活）

A> DI:SLTC,NA,1(查看电路状态)B> D:SLTC,NA,1(打死 SLTC)C> I:SLTC,NA,1(激活 SLTC)A> DI:CTLE,NA,1(查看中继板状态)B> D:CTLE,NA,1(闭塞中继板)C> I:CTLE,NA,1(激活中继板).查看中继板位置 的DTUA板

IDS:N,NA

对于CE RES(重启不会影响其他链路)AC NA CE RES

也可以CE BOO 或者对模块：RB(会影响同模块的其他链路)AC NA : RB

谢谢！