第一篇：代維集團(tuán)專線故障處理流程優(yōu)化

集團(tuán)專線流程

整體流程：監(jiān)控派單>代維提單>聯(lián)系用戶>上門>故障定位>故障處理>代維回單>監(jiān)控回單 流程各環(huán)節(jié)關(guān)鍵時(shí)間點(diǎn)：

1、代維提單（催單：系統(tǒng)不支持，人工抽查）

代維公司10分鐘內(nèi)提單。如該線路未驗(yàn)收或發(fā)現(xiàn)為對(duì)方工單，需在20分鐘內(nèi)反饋未驗(yàn)收情況及將工單派對(duì)方。

2、聯(lián)系用戶（催單：系統(tǒng)支持，每單必跟）

代維公司30分鐘內(nèi)聯(lián)系用戶，若未聯(lián)系到用戶，需上報(bào)故障管理人員，同時(shí)在工單中階段回復(fù)（工單中回復(fù)聯(lián)系哪個(gè)客戶及聯(lián)系方式）。

3、代維上門（催單：系統(tǒng)支持，每單必跟）

金牌1小時(shí)內(nèi)；銀牌4小時(shí)內(nèi)；普通8小時(shí)內(nèi)，如遇客戶端距離較遠(yuǎn)等原因無(wú)法在規(guī)定時(shí)間內(nèi)到達(dá)，需在故障歷時(shí)1小時(shí)時(shí)向客戶說(shuō)明原因，并在工單上階段回復(fù)，每家代維當(dāng)上級(jí)故障少于兩件時(shí)，本級(jí)故障需按金牌故障標(biāo)準(zhǔn)1小時(shí)內(nèi)上門。

4、故障定位（催單及上報(bào)：系統(tǒng)支持，每單必跟）

金牌2小時(shí)內(nèi)；銀牌5小時(shí)內(nèi)；普通9小時(shí)內(nèi)未定位故障原因，需上升故障管理人員，內(nèi)容需包含詳細(xì)處理過(guò)程及相關(guān)數(shù)據(jù)（另有文件描述），故障管理人員走EOMS技術(shù)支援工單，由故障管理人員跟進(jìn)該故障定位情況。所有現(xiàn)場(chǎng)情況均需在規(guī)定時(shí)間內(nèi)階段性回復(fù)SUPPORT工單。

5、故障處理（催單及上報(bào)：系統(tǒng)支持，每單必跟）

金牌2.5小時(shí)內(nèi)；銀牌6小時(shí)內(nèi)；普通10小時(shí)內(nèi)未完成故障處理，需上升故障管理人員，由故障管理人員督促故障處理進(jìn)度；金牌3小時(shí)、銀牌7小時(shí)、普通11小時(shí)未完成故障處理，由故障管理人員上報(bào)相關(guān)部門三級(jí)經(jīng)理；金牌4小時(shí)、銀牌8小時(shí)、普通12小時(shí)未完成故障處理，由故障管理人員上報(bào)相關(guān)部門領(lǐng)導(dǎo)；故障處理過(guò)程中，現(xiàn)場(chǎng)維護(hù)人員應(yīng)每1小時(shí)給客戶反饋一次故障處理進(jìn)度，并在工單中階段回復(fù)。如因特殊原因，故障不能及時(shí)處理完的，應(yīng)給客戶進(jìn)行說(shuō)明，并上報(bào)故障管理人員備檔。

6、工單回復(fù)（催單：系統(tǒng)不支持，人工抽查）

工單回復(fù)必須符合前期制定的“集團(tuán)專線工單回復(fù)標(biāo)準(zhǔn)”。

7、故障分析會(huì)：當(dāng)故障導(dǎo)致用戶意見大且上升到集客部或領(lǐng)導(dǎo)的，第二個(gè)工作日內(nèi)，牽頭集客部、各相關(guān)專業(yè)及公司專家，召開專題故障分析會(huì)，其余有必要召開會(huì)議的（我中心認(rèn)為的），三個(gè)工作日牽頭召開專題故障分析會(huì)，所有專題會(huì)。

第二篇：代維故障處理規(guī)范

代維故障處理規(guī)范

為保證代維單位及時(shí)高效地處理故障，結(jié)合公司實(shí)際制定本規(guī)范。

一、故障分類

按照目前代維公司維護(hù)的界面分工，需要代維處理的故障主要分為基站設(shè)備故障（主要為動(dòng)力配套設(shè)備）、基站停電故障、光纜線路故障（按線路級(jí)別分干線、本地網(wǎng)、接入網(wǎng)）、室內(nèi)分布系統(tǒng)。

二、故障通知程序

1、基站設(shè)備故障

基站設(shè)備故障由網(wǎng)管中心值班人員通過(guò)監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時(shí)間內(nèi)修復(fù)障礙，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，基站代維管理員應(yīng)立即通知?jiǎng)恿ΥS中心主任和部門分管經(jīng)理。

2、基站停電故障

基站停電由網(wǎng)管中心值班人員通過(guò)動(dòng)力環(huán)境監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員，并做好故障派單記錄，基站代維管理員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時(shí)間內(nèi)修復(fù)障礙，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，基站代維管理員應(yīng)立即通知?jiǎng)恿ΥS中心主任和部門分管經(jīng)理。

3、光纜線路故障

干線光纜線路故障（含本地網(wǎng)骨干網(wǎng)線路）網(wǎng)管中心值班人員通知線路代維管理人員，同時(shí)通知傳輸中心值班工程師和傳輸中心主任，線路代維管理人員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并向部門分管領(lǐng)導(dǎo)匯報(bào)，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，網(wǎng)管中心值班人員應(yīng)立即部門經(jīng)理和公司分管領(lǐng)導(dǎo)。

本地網(wǎng)線路故障（本地網(wǎng)骨干網(wǎng)除外）網(wǎng)管中心值班人員通知線路代維管理人員，同時(shí)通知傳輸中心值班工程師和傳輸中心主任，線路代維管理人員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時(shí)間內(nèi)修復(fù)障礙，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，線路代維管理員應(yīng)立即通知?jiǎng)恿ΥS中心主任和部門分管經(jīng)理。

接入網(wǎng)線路故障由客響中心112故障專業(yè)人員和網(wǎng)管中心值班人員誰(shuí)先發(fā)現(xiàn)誰(shuí)通知客響中心值班工程師或縣分裝維人員，客響中心值班工程師（或縣分裝維人員）判斷為線路故障應(yīng)立即通知線路代維管理人員（網(wǎng)管中心值班人員若能直接判斷線路故障可直接通知線路代維管理人員，并告知客響中心值班工程師），線路代維管理人員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時(shí)間內(nèi)修復(fù)障礙，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，線路代維管理員應(yīng)立即通知?jiǎng)恿ΥS中心主任和部門分管經(jīng)理。

4、室內(nèi)分布系統(tǒng)

室內(nèi)分布系統(tǒng)故障由網(wǎng)管中心值班人員通過(guò)監(jiān)控系統(tǒng)發(fā)現(xiàn)通知基站代維管理員和無(wú)線中心主任，并做好故障派單記錄，基站代維管理員接到通知后應(yīng)立即通知代維公司專業(yè)接口人，并做好故障記錄督促代維公司在規(guī)定時(shí)間內(nèi)修復(fù)障礙，代維公司未能在規(guī)定時(shí)間內(nèi)修復(fù)障礙的，基站代維管理員應(yīng)立即通知?jiǎng)恿ΥS中心主任和部門分管經(jīng)理，網(wǎng)管中心值班人員應(yīng)通知部門無(wú)線分管經(jīng)理。

三、故障處理記錄

1、對(duì)于基站設(shè)備和停電故障，代維單位每周匯總一次提交基站代維管理人員，對(duì)涉及到的搶修材料應(yīng)做好臺(tái)賬登記。

2、對(duì)于線路故障，應(yīng)在處理故障結(jié)束后24小時(shí)內(nèi)提交故障處理記錄。

四、故障處理支撐

對(duì)于已經(jīng)交由代維單位處理的故障如不能及時(shí)搶通修復(fù)，運(yùn)行維護(hù)部相應(yīng)專業(yè)需派人到場(chǎng)進(jìn)行指導(dǎo)和督促。對(duì)于影響業(yè)務(wù)的故障如代維單位不能在規(guī)定的搶修時(shí)限內(nèi)完成，基站或線路代維管理人員應(yīng)與相關(guān)專業(yè)工程師到場(chǎng)協(xié)助搶修。

五、故障歸口及上報(bào)

所有涉及代維故障需第一時(shí)間通知到代維管理中心基站或線路代維管理人員，各專業(yè)工程師及縣分工維中心工程師不得擅自調(diào)動(dòng)代維人員，緊急情況下可先通知代維搶修人員后向代維管理中心報(bào)備。所有代維公司處理的故障由動(dòng)力代維中心督促代維公司提交故障處理記錄后向質(zhì)量管理中心進(jìn)行上報(bào)。

二○一二年一月十七日

第三篇：2010 東莞移動(dòng)公司集團(tuán)客戶專線代維考核辦法( 20100113)

集團(tuán)客戶專線代維質(zhì)量考核辦法

一、考核辦法

1.考核每月進(jìn)行一次，考核形式采取量化評(píng)分制。考核評(píng)分辦法見東莞移動(dòng)

公司《2009年集團(tuán)客戶專線代維量化考核表》。

2.對(duì)于存在問(wèn)題未按甲方要求完成處理或未作改進(jìn)措施，以致同類問(wèn)題仍有

發(fā)生的，按相關(guān)問(wèn)題的條款加倍扣分。

3.代維量化基本考核分為95分，采用扣分制，獎(jiǎng)勵(lì)分為5分，采用加分制，每月考核總得分不超過(guò)100分，考核得分為95分（含95分）以上為合格。

4.如果代維公司全年累計(jì)三次代維考核得分低于80分，或者連續(xù)兩次代維考

核得分低于80分，或者一次代維考核得分低于75分，東莞移動(dòng)公司有權(quán)調(diào)整代為公司的代維量或者單方面解除代維合同。

5.如果代維公司一個(gè)月的故障處理及時(shí)率低于60%(含60%)，移動(dòng)公司有權(quán)終

止代維合同。

6.如果代維公司連續(xù)兩個(gè)月的故障處理及時(shí)率低于70%（含70%），移動(dòng)公司

有權(quán)終止代維合同。

7.如果代維公司連續(xù)三個(gè)月的故障處理及時(shí)率低于80%（含80%），移動(dòng)公司

有權(quán)終止本協(xié)議。

8.每月量化考核的成績(jī)作為支付代維費(fèi)的依據(jù)，移動(dòng)公司應(yīng)將每月考核得分

情況及時(shí)通報(bào)代維公司，并根據(jù)當(dāng)月代維考核情況支付該月的代維費(fèi)用。

9.以每月代理維護(hù)費(fèi)用中的30%作為考核基數(shù)對(duì)代維公司服務(wù)質(zhì)量進(jìn)行量化

考核，根據(jù)量化考核得分付給相應(yīng)款項(xiàng)。

10.對(duì)代維公司連續(xù)三個(gè)月得分在75分以下，全年累計(jì)四個(gè)月得分在75分以

下，移動(dòng)公司可自行解除合同。

11.移動(dòng)公司將每月考核得分情況在每月的代維總結(jié)會(huì)議上通報(bào)。

12.詳細(xì)的扣分情況和扣分原因在每月的代維量化考核表列出。

13.對(duì)于代理維護(hù)質(zhì)量超過(guò)協(xié)議規(guī)定的，可適當(dāng)給予獎(jiǎng)勵(lì)；對(duì)損壞設(shè)備及儀表的，應(yīng)予懲罰及賠償。

14.對(duì)代維公司在一年代維工作中服務(wù)質(zhì)量好，工作積極主動(dòng)，能力較強(qiáng)的，使得網(wǎng)絡(luò)質(zhì)量大大超過(guò)代維前的，東莞移動(dòng)公司將向上級(jí)主管部門申報(bào)，經(jīng)審核屬實(shí)的，可給予一定的獎(jiǎng)勵(lì)。

二、代理維護(hù)工作量化考核表

集團(tuán)客戶專線代理維護(hù)工作量化考核表

代理維護(hù)公司：考核月份：年月

三、代維費(fèi)用結(jié)算方法

1.東莞移動(dòng)公司每月對(duì)代維公司的維護(hù)工作進(jìn)行考核，根據(jù)得分計(jì)算應(yīng)得維

護(hù)費(fèi)。得分在95分（含95分）以上，不扣維護(hù)費(fèi)；將每月代維總費(fèi)用（M）的70%作為固定費(fèi)用，另30%作為考核費(fèi)用，即每月實(shí)際結(jié)算費(fèi)用（L）= M×（70%+30％×月考核得分（Y）/100)，如月考核實(shí)際得分≥95分時(shí)，則Y按100分計(jì)算。

2.代理維護(hù)費(fèi)用按月度以現(xiàn)金或支票支付的方式由東莞移動(dòng)公司支付給代維

公司，具體費(fèi)用以當(dāng)月度考核情況核準(zhǔn)費(fèi)用支付。代維公司在每次請(qǐng)求付款前應(yīng)向東莞移動(dòng)公司開具正式發(fā)票。

第四篇：運(yùn)維故障處理思路

事件/故障處理應(yīng)該要有什么思路 導(dǎo)讀：

在講解事件、故障處理思路前，我先講一個(gè)故障場(chǎng)景（以呼叫中心系統(tǒng)作為一例子）：

業(yè)務(wù)人員反映呼叫中心系統(tǒng)運(yùn)行緩慢，部份電話在自助語(yǔ)言環(huán)節(jié)系統(tǒng)處理超時(shí)，話務(wù)轉(zhuǎn)人工座席，人工座席出現(xiàn)爆線情況。

運(yùn)維人員開始忙活了，查資源使用情況、查服務(wù)是否正常、查日志是否報(bào)錯(cuò)、查交易量還有沒(méi)有??時(shí)間不知不覺(jué)的在敲鍵盤、敲鍵盤、敲鍵盤中過(guò)去，但是原因還未定位。

經(jīng)理過(guò)來(lái)了解情況：“系統(tǒng)恢復(fù)了嗎？”、“故障影響是什么？”、“交易中斷了嗎？”??

運(yùn)維人員趕緊敲鍵盤，寫sql，看交易量；敲鍵盤，寫命令，看系統(tǒng)資源、情況??

最終，定位到問(wèn)題原因是其中一個(gè)功能沒(méi)有控制返回?cái)?shù)量，導(dǎo)致內(nèi)存泄露。針對(duì)這個(gè)故障，業(yè)務(wù)希望運(yùn)維能否更快的解決故障的恢復(fù)，經(jīng)理希望制定優(yōu)化呼叫中心故障處理流程，做了以下幾件事：

1.優(yōu)先故障處理過(guò)程的時(shí)間——”能通過(guò)鼠標(biāo)完成的工作，不要用鍵盤“ 2.提前發(fā)現(xiàn)故障，加強(qiáng)監(jiān)控——“技術(shù)早于業(yè)務(wù)發(fā)現(xiàn)問(wèn)題，監(jiān)控不僅是報(bào)警，還要協(xié)助故障定位”

3.完善故障應(yīng)急方案——“應(yīng)急方案是最新的、準(zhǔn)確的、簡(jiǎn)單明了的” 4.長(zhǎng)遠(yuǎn)目標(biāo)：故障自愈——”能固化的操作自動(dòng)化，能機(jī)器做的讓機(jī)器做“ 下面將從故障常見的處理方法開始介紹，再?gòu)墓收锨暗臏?zhǔn)備工作（完善監(jiān)控、制定應(yīng)急方案等方式）來(lái)解決經(jīng)理提出的問(wèn)題，并提出未來(lái)解決故障的想法。

1、常見的方法：

1）確定故障現(xiàn)象并初判問(wèn)題影響

在處理故障前，運(yùn)維人員首先要知道故障現(xiàn)象，故障現(xiàn)象直接決定故障應(yīng)急方案的制定，這依賴于運(yùn)維人員需要對(duì)應(yīng)用系統(tǒng)的整體功能有一定的熟悉程度。確認(rèn)了故障現(xiàn)象后，才能指導(dǎo)運(yùn)維人員初判斷故障影響。2）應(yīng)急恢復(fù)

運(yùn)維最基本的指標(biāo)就是系統(tǒng)可用性，應(yīng)急恢復(fù)的時(shí)效性是系統(tǒng)可用性的關(guān)鍵指標(biāo)。

有了上述故障現(xiàn)象與影響的判斷后，就可以制定故障應(yīng)急操作，故障應(yīng)急有很多，比如：

? ? ? ? ? ? ? 服務(wù)整體性能下降或異常，可以考慮重啟服務(wù)； 應(yīng)用做過(guò)變更，可以考慮是否需要回切變更； 資源不足，可以考慮應(yīng)急擴(kuò)容；

應(yīng)用性能問(wèn)題，可以考慮調(diào)整應(yīng)用參數(shù)、日志參數(shù)； 數(shù)據(jù)庫(kù)繁忙，可以考慮通過(guò)數(shù)據(jù)庫(kù)快照分析，優(yōu)化SQL； 應(yīng)用功能設(shè)計(jì)有誤，可以考慮緊急關(guān)閉功能菜單； 還有很多??

另外，需要補(bǔ)充的是，在故障應(yīng)急前，在有條件的情況需要保存當(dāng)前系統(tǒng)場(chǎng)景，比如在殺進(jìn)程前，可以先抓個(gè)CORE文件或數(shù)據(jù)庫(kù)快照文件。

3）快速定位故障原因

? 是否為偶發(fā)性、是否可重現(xiàn)

故障現(xiàn)象是否可以重現(xiàn)，對(duì)于快速解決問(wèn)題很重要，能重現(xiàn)說(shuō)明總會(huì)有辦法或工具幫助我們定位到問(wèn)題原因，而且能重現(xiàn)的故障往往可能是服務(wù)異常、變更等工作導(dǎo)致的問(wèn)題。

但，如果故障是偶發(fā)性的，是有極小概率出現(xiàn)的，則比較難排查，這依賴于系統(tǒng)是否有足夠的故障期間的現(xiàn)場(chǎng)信息來(lái)決定是否可以定位到總是原因。

? 是否進(jìn)行過(guò)相關(guān)變更

大部份故障是由于變更導(dǎo)致，確定故障現(xiàn)象后，如果有應(yīng)的變更，有助于從變更角度出現(xiàn)分析是否是變更引起，進(jìn)而快速定位故障并準(zhǔn)備好回切等應(yīng)急方案。

? 是否可縮小范圍

一方面應(yīng)用系統(tǒng)提倡解耦，一支交易會(huì)流經(jīng)不同的應(yīng)用系統(tǒng)及模塊；另一方面，故障可能由于應(yīng)用、系統(tǒng)軟件、硬件、網(wǎng)絡(luò)等環(huán)節(jié)的問(wèn)題。在排查故障原因時(shí)應(yīng)該避免全面性的排查，建議先把問(wèn)題范圍縮小到一定程序后再開始協(xié)調(diào)關(guān)聯(lián)團(tuán)隊(duì)排查。

? 關(guān)聯(lián)方配合分析問(wèn)題 與第（3）點(diǎn)避免同時(shí)各關(guān)聯(lián)團(tuán)隊(duì)同時(shí)無(wú)頭緒的排查的同時(shí)，對(duì)于牽頭方在縮小范圍后需要開放的態(tài)度去請(qǐng)求關(guān)聯(lián)方配合定位，而對(duì)于關(guān)聯(lián)方則需要有積極配合的工作態(tài)度。

? 是否有足夠的日志

定位故障原因，最常用的方法就是分析應(yīng)用日志，對(duì)運(yùn)維人員不僅需要知道業(yè)務(wù)功能對(duì)應(yīng)哪個(gè)服務(wù)進(jìn)程，還要知道這個(gè)服務(wù)進(jìn)程對(duì)應(yīng)的哪些應(yīng)用日志，并具備一些簡(jiǎn)單的應(yīng)用日志異常錯(cuò)誤的判斷能力。

? 是否有core或dump等文件

故障期間的系統(tǒng)現(xiàn)場(chǎng)很重要，這個(gè)在故障應(yīng)急前建議在有條件的情況下留下系統(tǒng)現(xiàn)場(chǎng)的文件，比如COREDUMP，或TRACE采集信息等，備份好一些可能被覆蓋的日志等。

上述是一般性的故障常見的方法，在重大故障或多方處理的故障出現(xiàn)時(shí)，往往小范圍的排查不利于快速解決，需要啟動(dòng)緊急處理的流程，建議可以考慮以下溝通：

? ? ? ? ? ? 召集相關(guān)人員 描述故障現(xiàn)狀

說(shuō)明正常應(yīng)用邏輯流程 陳述變更

排查進(jìn)展，展示信息 領(lǐng)導(dǎo)決策

2、完善監(jiān)控

1）從監(jiān)控可視化上完善

完善的監(jiān)控策略需要有統(tǒng)一的可視化操作界面，在制定完善的監(jiān)控策略后，故障處理人員需要能夠快速的看到相應(yīng)的運(yùn)行數(shù)據(jù)，比如：能夠看到一段時(shí)間的趨勢(shì)、故障期間的數(shù)據(jù)表現(xiàn)、性能分析的情況等等數(shù)據(jù)，且這些數(shù)據(jù)可以提前制定好策略直接推出分析結(jié)果給故障處理人員，這樣就大大提高了故障的處理效率，以呼叫中心系統(tǒng)為例，需要提前配置好以下實(shí)時(shí)交易數(shù)據(jù)，以便故障定位：

-交易性能數(shù)據(jù)：平均交易耗時(shí)、系統(tǒng)內(nèi)部模塊交易耗時(shí)（IVR交易耗時(shí)、接口總線交易耗時(shí)）、關(guān)聯(lián)系統(tǒng)交易耗時(shí)（核心交易耗時(shí)、工單系統(tǒng)交易耗時(shí)等）-重要交易指標(biāo)數(shù)據(jù)：交易量、IVR交易量、話務(wù)量、座席通話率、核心交易筆數(shù)、工單等系統(tǒng)交易量

-交易異常情況數(shù)據(jù)：交易成功率、失敗率、錯(cuò)誤碼最多交易-按服務(wù)器分析交易數(shù)據(jù)：按server統(tǒng)計(jì)各服務(wù)交易處理筆數(shù)，交易總耗時(shí) 有了以上交易數(shù)據(jù)，并通過(guò)監(jiān)控按一定頻率統(tǒng)計(jì)，運(yùn)維人員在出現(xiàn)故障時(shí)，通過(guò)鼠標(biāo)即點(diǎn)擊即可看到故障什么時(shí)候開始，是系統(tǒng)內(nèi)部有問(wèn)題還是關(guān)聯(lián)系統(tǒng)有問(wèn)題，最突出的交易是哪一支，各服務(wù)器交易量是否均衡等情況。

2）從監(jiān)控面上完善

監(jiān)控最基本的工作就是實(shí)現(xiàn)對(duì)負(fù)載均衡設(shè)備、網(wǎng)絡(luò)設(shè)備、服務(wù)器、存儲(chǔ)設(shè)備、安全設(shè)備、數(shù)據(jù)庫(kù)、中間件及應(yīng)用軟件等IT資源的全面監(jiān)控管理。在應(yīng)用軟件類的監(jiān)控工作中，不僅需要有服務(wù)進(jìn)程、端口等監(jiān)控，還需要有業(yè)務(wù)、交易層的監(jiān)控。

全面性的應(yīng)用監(jiān)控可以讓故障提前預(yù)警，并保存了影響應(yīng)用運(yùn)行環(huán)境的數(shù)據(jù)，以縮短故障處理時(shí)間。

3）從監(jiān)控告警上完善

完善的監(jiān)控策略需要有清晰的監(jiān)控告警提示，值班人員要以根據(jù)監(jiān)控告警即可作出簡(jiǎn)單的問(wèn)題定位與應(yīng)急處理方案。比如類似以下的監(jiān)控短信：

22時(shí)，【理財(cái)應(yīng)用系統(tǒng)】中【應(yīng)用服務(wù)器LC_APPsvrA 10.2.111.111】的【前置應(yīng)用模塊】出現(xiàn)【應(yīng)用端口：9080】不存在，該端口作用【提供理財(cái)應(yīng)用處理（負(fù)載均衡部署）】，原因可能為【SERVER1服務(wù)異常停止】，監(jiān)控系統(tǒng)己進(jìn)行以下應(yīng)急處理【自動(dòng)執(zhí)行端口進(jìn)程啟動(dòng)】，該事件緊急程度【高】。管理員可以通過(guò)短信內(nèi)容看到哪個(gè)系統(tǒng)、哪個(gè)應(yīng)用、哪個(gè)模塊出了什么問(wèn)題，可能是什么原因，對(duì)業(yè)務(wù)有什么影響，是否需要馬上處理（比如凌晨出現(xiàn)此預(yù)警是否可以延遲到次日處理）等信息。

4)從監(jiān)控分析上完善

完善的監(jiān)控策略不僅需要有實(shí)時(shí)的數(shù)據(jù)告警，也要有匯總數(shù)據(jù)的分析告警,實(shí)時(shí)數(shù)據(jù)分析的告警的重要性不用多說(shuō)，對(duì)于匯總分析的數(shù)據(jù)則能發(fā)現(xiàn)潛在風(fēng)險(xiǎn)，同時(shí)也為分析疑難雜癥提供幫忙。

5)從監(jiān)控主動(dòng)性上完善

監(jiān)控不僅僅是報(bào)警，它還可以做得更多，只要我們想辦法賦予它主動(dòng)解決事件的規(guī)則，它便有為管理員處理故障的能力。

3、應(yīng)急方案

提前制定好故障應(yīng)急方案是很有必要的，但在日常工作過(guò)程中我們的應(yīng)急方案遇到一些問(wèn)題： 1）應(yīng)急方案缺乏持續(xù)維護(hù)，缺乏演練，信息不及時(shí)、不準(zhǔn)確； 2）應(yīng)急方案過(guò)于追求大而全，導(dǎo)致不利于閱讀與使用； 3）應(yīng)急方案形式大于實(shí)際使用效果，方案針對(duì)性不強(qiáng)； 4）只關(guān)注應(yīng)急方案的內(nèi)容，但沒(méi)有關(guān)注運(yùn)維人員對(duì)方案的理解； 針對(duì)上述常見問(wèn)題，我認(rèn)為應(yīng)急方案需要做到以下幾點(diǎn)：

1）內(nèi)容精&簡(jiǎn)

很多人可能會(huì)認(rèn)為故障出現(xiàn)的形式各種各樣，所以應(yīng)急方案需要涉及到方方面面。但實(shí)際的故障處理過(guò)程中，我們可以發(fā)現(xiàn)其實(shí)我們的應(yīng)急措施往往重復(fù)使用幾個(gè)常用的步驟，所以我認(rèn)為應(yīng)急方案要有重點(diǎn)，如果一個(gè)應(yīng)急方案可以應(yīng)對(duì)平時(shí)故障處理80%的場(chǎng)景，那這個(gè)應(yīng)急手冊(cè)應(yīng)該是合格的。過(guò)于追求影響應(yīng)用系統(tǒng)方方面面的內(nèi)容，會(huì)導(dǎo)致這個(gè)方案可讀性變差，最終變更一個(gè)應(yīng)付檢查的文檔。以下是我覺(jué)得應(yīng)用系統(tǒng)應(yīng)急方案應(yīng)該有的內(nèi)容：（1）系統(tǒng)級(jí)：

能知道當(dāng)前應(yīng)用系統(tǒng)在整個(gè)交易中的角色，當(dāng)前系統(tǒng)出現(xiàn)問(wèn)題或上下游出現(xiàn)問(wèn)題時(shí)，可以知道如何配合上下游分析問(wèn)題，比如：上下游系統(tǒng)如何通訊，通訊是否有唯一的關(guān)鍵字等。

另外，系統(tǒng)級(jí)里還涉及一些基本應(yīng)急操作，比如擴(kuò)容、系統(tǒng)及網(wǎng)絡(luò)參數(shù)調(diào)整等。（2）服務(wù)級(jí)：

能知道這個(gè)服務(wù)影響什么業(yè)務(wù)，服務(wù)涉及的日志、程序、配置文件在哪里，如何檢查服務(wù)是否正常，如何重啟服務(wù)，如何調(diào)整應(yīng)用級(jí)參數(shù)等。（3）交易級(jí)：

能知道如何查到某支或某類交易出現(xiàn)了問(wèn)題，是大面積、局部，還是偶發(fā)性問(wèn)題，能用數(shù)據(jù)說(shuō)明交易影響的情況，能定位到交易報(bào)錯(cuò)的信息。這里最常用的方法就是數(shù)據(jù)庫(kù)查詢或工具的使用。

知道最重要的交易如何檢查是否正常，重要的定時(shí)任務(wù)的應(yīng)急處理方案，比如開業(yè)、換日、對(duì)賬的時(shí)間要求及應(yīng)急措施。（4）輔助工具的使用：

有時(shí)候，需要借助一些工具或自動(dòng)化工具輔助分析并應(yīng)急，這時(shí)需要有輔助工具如何使用的方法。（5）溝通方案：

溝通方案涉及通訊錄，包括上下游系統(tǒng)、第三方單位、業(yè)務(wù)部門等渠道。（6）其它：

上述5點(diǎn)內(nèi)容如何都完備，相信這個(gè)應(yīng)急手冊(cè)己可以解決80%的故障恢復(fù)工作。

2）應(yīng)急方案是一項(xiàng)持續(xù)的工作

有了應(yīng)急方案，如何讓運(yùn)維人員持續(xù)去更新是難點(diǎn)。我認(rèn)為要解決這個(gè)難點(diǎn)，需要先讓運(yùn)維人員經(jīng)常使用這個(gè)手冊(cè)。如果一個(gè)手冊(cè)沒(méi)有場(chǎng)景可以用，那就需要管理者為運(yùn)維人員創(chuàng)造機(jī)會(huì)去使用這個(gè)手冊(cè)，比如應(yīng)急演練。

3）關(guān)注運(yùn)維人員對(duì)應(yīng)用關(guān)鍵信息的認(rèn)識(shí)

前兩點(diǎn)關(guān)注了手冊(cè)，最后一點(diǎn)我覺(jué)得有必要關(guān)注使用這個(gè)手冊(cè)的人。有些運(yùn)維人員認(rèn)為應(yīng)用運(yùn)維人員沒(méi)有能力去把應(yīng)用系統(tǒng)本身的內(nèi)容了解得很透徹，所以應(yīng)用運(yùn)維人員在故障處理過(guò)程中的地位很尷尬，運(yùn)維人員掌握操作權(quán)，但卻不知道應(yīng)該操作什么。

對(duì)此，我認(rèn)同應(yīng)用運(yùn)維人員不需要掌握應(yīng)用系統(tǒng)的業(yè)務(wù)功能，但我覺(jué)得就對(duì)應(yīng)用系統(tǒng)本身來(lái)講應(yīng)用運(yùn)維人員需要具備以下最基本的能力：（1）知道應(yīng)用系統(tǒng)這個(gè)是干什么的，基本的業(yè)務(wù)是什么；（2）知道應(yīng)用架構(gòu)部署、上下游系統(tǒng)邏輯關(guān)系；

（3）知道應(yīng)用下的服務(wù)的作用、端口、服務(wù)級(jí)的應(yīng)急處理，日志等數(shù)據(jù)信息如何找到并簡(jiǎn)單定位。

（4）知道應(yīng)用系統(tǒng)重要的時(shí)間點(diǎn)及任務(wù)，比如開業(yè)、停業(yè)、換日、定時(shí)任務(wù)的時(shí)間點(diǎn)以及如何判斷這些任務(wù)是否正確（5）知道最重要的幾支交易的流程；（6）知道常見數(shù)據(jù)庫(kù)表結(jié)構(gòu)，并能使用。

4、智能化事件處理

處理方法如下圖（詳細(xì)的智能化涉及監(jiān)控、規(guī)則引擎、配置工具、CMDB、應(yīng)用配置庫(kù)等模塊協(xié)同工作，具體介紹后續(xù)分析）

第五篇：常見電路故障處理流程

本次主要針對(duì)電路方面的一些基礎(chǔ)知識(shí)和故障處理進(jìn)行培訓(xùn)，培訓(xùn)內(nèi)容主要有理論和實(shí)操兩部分。其中理論培訓(xùn)主要包括：愛(ài)立信電路故障處理流程，電路單通測(cè)試（指令測(cè)試），光口故障處理流程，光口保護(hù)倒換原理，三種非愛(ài)設(shè)備簡(jiǎn)單故障處理。實(shí)操部分包括：LIFE3000使用，電路單通測(cè)試（掛表測(cè)試），傳輸有誤碼或中斷時(shí)如何掛表測(cè)試，傳輸頭制作，DDF ODF認(rèn)識(shí)，基站應(yīng)急割接模擬等方面。

愛(ài)立信常規(guī)故障處理流程

故障的類型主要有兩大類：傳輸故障和交換設(shè)備故障。下面講一些常見故障的處理。

傳輸故障又主要分為物理傳輸故障和鏈路故障。物理傳輸故障，主要是傳輸ABL或者是傳輸質(zhì)量差而引起的話務(wù)設(shè)備ABL，影響通信業(yè)務(wù)，鏈路故障則是指信令鏈狀態(tài)不正常，會(huì)影響信令的接續(xù)。

第一章、傳輸故障 第一節(jié)：2M口的介紹

一、傳輸?shù)拿Q類型和出現(xiàn)的誤碼類型

愛(ài)立信的DIP名稱類型：RTG（GPRS的GB接口）、RBLT、RALT、RAL2、RBL2、MALT、MAL1、C7B4、C7B5、UPET、UPE、UPD、UPD1，起名稱長(zhǎng)度不能超過(guò)7個(gè)字母。

首先看傳輸狀態(tài)，用指令DTSTP：DIP=xxxx，傳輸狀態(tài)主要有WO、ABL和MBL。傳輸ABL，其誤碼類型常見的有5種告警，F(xiàn)C 1＝AIS、FC 2＝LOF、FC 3＝ERATE、FC 4＝RDI、FC 9＝LOS。

二、傳輸常見誤碼的處理

傳輸出現(xiàn)的誤碼常見組成為：FC 1&

2、FC 2&

9、FC 4，下面根據(jù)誤碼來(lái)判斷傳輸出現(xiàn)的情況：

FC 1&2：屬于遠(yuǎn)端告警，對(duì)于此類故障，應(yīng)該先在傳輸架上向本端自環(huán)，確定我們本端沒(méi)有問(wèn)題后，再和對(duì)端聯(lián)系，要對(duì)端也在傳輸架上自環(huán)，如果兩邊自環(huán)都沒(méi)有問(wèn)題，那就需要傳輸室在中間一段檢查、處理。FC 2&9：屬于近端告警或者是收發(fā)接反。先在交換機(jī)上確認(rèn)SNT和傳輸線是好的，然后在傳輸架上自環(huán)本端。如果正常，則和對(duì)端聯(lián)系，將收發(fā)反一下，看是否能恢復(fù)。

FC 4：屬于能夠收到信號(hào)，而不能發(fā)送信號(hào)。這種誤碼可能是由于傳輸頭松動(dòng)，只有一邊做好了，主要是排除本端傳輸?shù)念^是否有問(wèn)題。

三、傳輸質(zhì)量

下面講一下傳輸質(zhì)量。有時(shí)候傳輸狀態(tài)查看是好的，但質(zhì)量有問(wèn)題，會(huì)使得誤碼逐漸增加，誤碼增加到一定程度就使得傳輸斷掉。當(dāng)傳輸是好的時(shí)候，有一定的誤碼，可以用以下指令清除，清誤碼也許只能治標(biāo)而不能治本，最關(guān)鍵是要保證傳輸是通的。

DTQUP: DIP=XXXX;

DTQSR：DIP=ALL，DEGR，UNACC；

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

DTQSR：DIP=ALL，ES2，SES2；

第二節(jié)：光口ET155的介紹

ET155可以用來(lái)開電路和鏈路，在交換機(jī)沒(méi)有升R9的時(shí)候，基于ET155的穩(wěn)定性和安全考慮，一套ET155就開56個(gè)2M口，一般不用來(lái)開鏈。升為R9/R10后，就可以全部開電路，而且也用來(lái)開鏈路。其開電路和鏈路的方法和普通的2M電口沒(méi)有任何區(qū)別。

ET155也存在傳輸質(zhì)量問(wèn)題，其誤碼的增加也會(huì)引起ET155的部分設(shè)備不能工作，在必要的時(shí)候就得清除傳輸質(zhì)量誤碼，方法如下：

TPQSR：SDIP=XX，DEGR，UNACC；

TPQSR：SDIP=XX，ES，SES；

TPQSR：SDIP=XX，ES2，SES2；

光口ET155故障

A.維護(hù)人員從終端查看故障光纖中繼的狀態(tài)：指令TPSTP:SDIP=；見到MS及VC狀態(tài)為

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

B.根據(jù)電路資料，在傳輸ODF架前一個(gè)位置，樓層纖ODF，作硬件自環(huán)。同時(shí)其他配合人員在終端指令檢查光口狀態(tài)(應(yīng)不正常，否則需報(bào)其它科室處理)。而后，維護(hù)人員用光功率計(jì)在樓層ODF架測(cè)量光功率：-8~-20dbm之間的才合格。光功率計(jì)質(zhì)量越小越好，C.維護(hù)人員在樓層ODF對(duì)其備用纖(原本不放通)向交換機(jī)作自環(huán)，并用光功計(jì)確定其通光正常。原則上是盡快確定出可正常通光到樓層ODF的通道。

D.將備用纖與傳輸端光纖接通。其后，先在終端解除話務(wù)在主用邊的鎖定：指令PWFSE:SDIP=;，再把話務(wù)鎖定到光纖備用側(cè)：指令PWFSI:SDIP=,MS=MS-1;，恢復(fù)通話。

第三節(jié)、電路設(shè)備、鏈路故障的處理

一、電路設(shè)備故障

當(dāng)傳輸保證是正常狀態(tài)的情況下，電路設(shè)備也會(huì)出現(xiàn)不能工作的現(xiàn)象。其設(shè)備狀態(tài)不正常有三種情況：BLOC、LIBL、SEAL。

BLOC：指設(shè)備斷掉，主要是因?yàn)閭鬏敳煌ɑ蛘`碼過(guò)大而引起的。

LIBL： 主要是對(duì)端未解開對(duì)應(yīng)設(shè)備引起

SEAL： 可能是兩端設(shè)備的CIC不對(duì)應(yīng)，按要求正確定義即可；也可能是信令擁塞導(dǎo)致，可嘗試重新定義一遍數(shù)據(jù)

二、鏈路故障

當(dāng)七號(hào)信令鏈路狀態(tài)不正常時(shí)，若為FC 3，則可以由人工閉解恢復(fù)(C7LAI:LS=?,SLC=?；C7LAE:LS=?,SLC=?)，若為FC 108 可能是由于本端傳輸自環(huán)而引起，查看傳輸狀態(tài)

若為FC 206 可能是對(duì)端數(shù)據(jù)沒(méi)有做，或本端的半永久連接數(shù)據(jù)有問(wèn)題。

首先檢查該信令鏈所屬中繼的狀態(tài)是否正常 可以由指令

C7LTP：LS=

；打印狀態(tài)

C7LDP：LS= ； 打印所占用的設(shè)備以及信令終端 EXSCP：NAME=SGG01-0；/DEV=UPD-1/C7ST2C-0；查看半永久連接狀態(tài)，看是否為ACT

三、信令鏈全阻：

A.ALLIP;

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

打印信令鏈狀態(tài)，看是否為全阻。

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

打印信令鏈所用的設(shè)備(DEVICE)D.EXSCP：NAME=GZG01-0；/DEV=UPD-1/C7ST2C-0；查看半永久連接，看是否為ACT

EXDEP:DEV=C7BTC4-XX;

可以查到設(shè)備所屬的傳輸號(hào)（DIP號(hào)）

E.DTSTP:DIP=xxC7B4;

打印傳輸狀態(tài)（FC=1&2多為遠(yuǎn)端告警），如果交換維護(hù)人員在本端傳輸架自環(huán)正常，則需要請(qǐng)傳輸室處理，傳輸室電話：86321169。

F.DTQUP:DIP=xxC7B4;如果傳輸狀態(tài)正常，則查看傳輸誤碼 ；如果傳輸誤碼增加很快，交換維護(hù)人員在傳輸架自環(huán)，觀察5－10分鐘，在此期間，誤碼沒(méi)有增加則請(qǐng)傳輸室處理。如果在自環(huán)過(guò)程中誤碼仍然不斷增加，則為本端問(wèn)題，需要重新做傳輸頭。

四、單通測(cè)試

以每個(gè)季度為周期，完成番禺所有代維網(wǎng)元電路的單通測(cè)試。電口電路使用LITE 3000進(jìn)行監(jiān)聽測(cè)試，光口電路可以使用指令測(cè)試，每套電路正常監(jiān)聽測(cè)試原則上不能超過(guò)3秒鐘，特殊情況可適當(dāng)延長(zhǎng)至10秒以內(nèi)。對(duì)于監(jiān)聽發(fā)現(xiàn)通話不正常的電路，要及時(shí)準(zhǔn)確記錄下來(lái)，確認(rèn)為單通后，并及時(shí)上報(bào)交換室數(shù)據(jù)組閉掉電路，但還要繼續(xù)跟進(jìn)處理。

二、單通測(cè)試-指令測(cè)試

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;

西門子交換機(jī)日常重大、緊急故障處理流程

一、日常重大故障: A、中繼故障 1）、查哪些中繼傳輸斷

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

可查到哪一方向的哪一傳輸斷。2）、先在本端自環(huán)，用STATDIU：LTG=x-y，DIU=z；檢查PCM狀態(tài)。如為ACT，則本端OK，報(bào)傳輸，讓傳輸環(huán)給我們，再檢查PCM狀態(tài)，如為ACT，則為傳輸問(wèn)題。

如為DIS-MA或DIS-SA，則多為傳輸問(wèn)題。

如為MAL，則傳輸收發(fā)反。3）、對(duì)于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查看時(shí)，參數(shù)STATUS意義為 IDLE 空閑 INC/OUT 打出/打入 NCAR 傳輸斷

BADM 本端閉塞（CANTRDAT）HOBB 環(huán)路 MOBB 對(duì)方阻塞

NSYP 對(duì)方CIC沒(méi)做，不同步 CCS7F NO7信令出錯(cuò) MDIU DIU阻塞（人工）CDIU DIU阻塞（系統(tǒng)）MPRT PORT阻塞（人工）CPRT PORT阻塞（系統(tǒng)）

華為常見電路故障

一 假如監(jiān)控報(bào)電路故障：GZB4到QYG06有傳輸斷掉。

1>首先根據(jù)路由名查出對(duì)端中繼號(hào),命令：LST TG 2>檢查故障狀態(tài)是否正常,命令:DSP N7TKC 3>查詢指定局向的電路信息，命令：LST OFTKC 4>通過(guò)MGW和查詢電路信息，命令：LST TKCBYTID 5>查出TID,命令:LST TKC 6>查出本端端口之后，在傳輸架做環(huán)路測(cè)試，如果本端正常，聯(lián)系對(duì)端處理,對(duì)端也是正常，轉(zhuǎn)傳輸室處理。

二 假如監(jiān)控報(bào)鏈路故障: GZB4到QYG06有套鏈路斷掉。

1>首先根據(jù)路由名查出對(duì)端中繼號(hào),命令：LST TG 顯示屬于指定局向集的鏈路狀態(tài)，命令：DSP N7LSLNK 2>根據(jù)模塊查詢鏈路狀態(tài)，命令：LST N7LNK

3、貝爾日常維護(hù)

信令鏈路告警：

處理流程如下：

接到告警后用241看鏈路狀態(tài)，再用241看鏈路配置，然后用MARCO或掛表測(cè)試傳輸是否正常，如果傳輸不正常本端原因檢查傳輸，其他原因轉(zhuǎn)傳輸室處理，如果傳輸正常，可嘗試將鏈打死激活或者將信令終端重啟，如果還是不行可以聯(lián)系對(duì)端一起做重啟信令終端的操作，一般可以恢復(fù)。以下是處理過(guò)程中涉及的詳細(xì)指令：

鏈路有以下幾種狀態(tài)：

ACTIVE ……….表示鏈路正常

ACTING ……….表示鏈路中斷

OOS

.…….表示鏈路退出服務(wù)

ORJ－DIS ……..表示鏈路人工閉塞

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

先:MM 241：DEST=”GZA1”&NAT,SLC=ALL,29=6;（按局向查看鏈路狀態(tài)）先:MM 241：DEST=”GZA1”&NAT,SLC=ALL,29=1;（按局向查看鏈路數(shù)據(jù)）

可以查看到某個(gè)局向的鏈路配置:鏈路是2M還是64K,鏈路所占用的信令模塊和中繼模塊。其中DTMEN的PCE是中繼模塊的NA,CCMEN的PCE是信令模塊的NA。

看到配置后可以看中繼狀態(tài)是否正常，可用MARCO來(lái)檢查，也可直接掛表測(cè)試。

用MACRO ALMPCE >ALMPCE:NA ALARM＝OFF 表示當(dāng)前傳輸狀態(tài)是好的

ALARM＝ON 表示當(dāng)前傳輸狀態(tài)是斷的

如果鏈路所在傳輸沒(méi)有問(wèn)題，可嘗試將鏈打死激活，指令如下：

先:MM 220：DEST= “GZA1”&NAT，SLC=0，F(xiàn)UNCTION=6；（鏈路打死）先:MM

220：DEST= “GZA1”&NAT，SLC=0，F(xiàn)UNCTION=5；（鏈路激活）

A> DI:SLTC,NA,1(查看電路狀態(tài))B> D:SLTC,NA,1(打死 SLTC)C> I:SLTC,NA,1(激活 SLTC)A> DI:CTLE,NA,1(查看中繼板狀態(tài))B> D:CTLE,NA,1(閉塞中繼板)C> I:CTLE,NA,1(激活中繼板).查看中繼板位置 的DTUA板

IDS:N,NA

對(duì)于CE RES(重啟不會(huì)影響其他鏈路)AC NA CE RES

也可以CE BOO 或者對(duì)模塊：RB(會(huì)影響同模塊的其他鏈路)AC NA : RB

謝謝！