當(dāng)你使用的外呼系統(tǒng)呼叫不通時，你知道該如何排查嗎？本文保姆式教程手把手教你如何排查，并且從排查過程管中窺豹，了解外呼系統(tǒng)的工作原理和產(chǎn)品設(shè)計思路。一起來看看吧。

外呼不通時，不要慌張，首先你要對你的外呼系統(tǒng)的構(gòu)造了如指掌，才可以順藤摸瓜，找到問題所在。

了解外呼系統(tǒng)的架構(gòu)：

不管外呼系統(tǒng)是什么樣的：自己做的，外面買的。基本架構(gòu)和原理都不會變，我給大家抽象出一個架構(gòu)圖：

上圖是基于軟交換核心的外呼系統(tǒng)主要分層架構(gòu)。

有類似產(chǎn)品的對號入座，如果是硬交換、本地化部署方式的服務(wù)層核心基本原理是一致的。

自下而上簡單介紹下：

• 資源層：各上游的通信資源服務(wù)商。
• 接入層：對接通信資源的接入服務(wù)或者設(shè)備
• 服務(wù)層：軟交換的核心，云端部署軟交換系統(tǒng)常常拆分為各種組件，集群化部署。
• 支撐層：包括整個服務(wù)的計費支撐管理，服務(wù)的監(jiān)控，接口服務(wù)及呼叫系統(tǒng)特有的呼叫風(fēng)控服務(wù)。
• 應(yīng)用層：最上面是應(yīng)用層，各種調(diào)用呼叫服務(wù)的產(chǎn)品和應(yīng)用，比較常見的是人工外呼，自動外呼和AI外呼。

全局還是局部故障？

接下來我們就講下外呼不通時，如何順藤摸瓜，找到問題所在。

我們首先要做一個范圍限定，外呼不通是個局部性事件，還是故障級別的全局情況？

如果是小范圍內(nèi)獨立事件，那么重點去觀察范圍內(nèi)的獨特特征，比如業(yè)務(wù)的通信資源、產(chǎn)品功能配置、應(yīng)用狀態(tài)等。

確認(rèn)是局部問題后，至少心態(tài)不會那么炸裂，接下來去認(rèn)真分析具體日志，使用情況去定位分析測試。

如果是后者？那意味著出現(xiàn)了比較嚴(yán)重的情況，需要你爭分奪秒，盡快定位問題并給出解決方案。

從哪里開始優(yōu)先排查：

如果是局部性的外呼不通情況發(fā)生，我建議優(yōu)先去資源層，問下資源供應(yīng)商有無問題。

有人說，為什么？產(chǎn)品是我們自己的，我們自己去查豈不是最方便了？

說的沒錯，但恰恰因為資源層是不受你管理的“黑盒子”，才需要馬上去溝通對接，同時開始自己的排查，否則查來查去，找不到原因，最后一問才發(fā)現(xiàn)，運營商的問題，白忙活一場。所以第一個起手動作大家牢記，先去對接上游資源服務(wù)商，確認(rèn)資源問題情況，溝通時，記得帶上明確現(xiàn)象、話單數(shù)據(jù)：包括主被叫號碼，時間等。然后催促盡快給予回復(fù)。

如果發(fā)生的外呼不通是全局性故障，反而是資源層出現(xiàn)問題的可能性小，一般不太可能出現(xiàn)這么大范圍的資源商全體撲街型事件，如果一旦發(fā)生，那么對應(yīng)的一定有什么重要的不可抗力的事情發(fā)生了，好好安撫客戶，等待解決吧。

首先看監(jiān)控：

現(xiàn)在是爭分奪秒排查故障的時刻了，接下來我們還是按照自下而上的順序，去檢查。

如果是全局性的故障，那么接入層、服務(wù)層、支撐層、應(yīng)用層的任一和外呼有關(guān)的組件，都需要檢查對應(yīng)的監(jiān)控告警和日志信息。

這些都是問題的突破口。

內(nèi)部如果有完善的告警信息，可以馬上去定位當(dāng)前時刻的告警組件、問題時間點內(nèi)的告警信息，找到故障的“疑似”問題點。

注意我說的是“疑似”，這個時候還需要給出更多的證據(jù)來證明結(jié)論。

所需要的證據(jù)，就來自于日志系統(tǒng)：

馬上去查看日志系統(tǒng)的詳細(xì)內(nèi)容，和有經(jīng)驗的運維工程師，研發(fā)工程師一起，根據(jù)日志，更根據(jù)歷史經(jīng)驗去盡快排查問題。

各個服務(wù)的異常指征應(yīng)該都詳細(xì)記錄并管理的，作為運營外呼系統(tǒng)的專業(yè)人員，這是一項基本的建設(shè)要求，如果沒有監(jiān)控系統(tǒng)，出現(xiàn)問題如盲人摸象。

找到故障對應(yīng)的服務(wù)后，啟動故障處理預(yù)案，該替換的替換，該啟動備份的啟動備份，然后觀察系統(tǒng)運行情況確認(rèn)是否操作有效。當(dāng)然做故障恢復(fù)動作時，要明確對業(yè)務(wù)的影響，給到業(yè)務(wù)和客戶方一個通知。

人為的原因？

當(dāng)檢查所有接入層、服務(wù)層均正常，資源層運營商也反饋無異常，那么先恭喜，至少沒有系統(tǒng)問題和嚴(yán)重事件的發(fā)生。

接下來我們把目光要轉(zhuǎn)向支撐層和應(yīng)用層。

支撐層的常見問題：

支撐層一般是賬戶，計費、管理、接口類產(chǎn)品，這里產(chǎn)品基本由內(nèi)部人員操作?？梢允紫葯z查有無最近的操作，本操作導(dǎo)致的結(jié)果。從而排查是否由人為誤操作導(dǎo)致問題發(fā)生。

不開玩笑，隨著系統(tǒng)的復(fù)雜度越來越高，一些內(nèi)部人為操作，往往導(dǎo)致無法外呼的故障發(fā)生。比如某人員將客戶的外顯號碼禁用，賬戶整體欠費，路由配置更改等操作。都有可能直接導(dǎo)致外呼失敗故障。

接口服務(wù)的話，和用戶接口使用的場景有很大關(guān)系，一般接口服務(wù)都有日志，對于外呼失敗的情況，如果客戶的外呼接口情況沒有接收到。那么馬上就去排查下客戶方網(wǎng)絡(luò)和服務(wù)商接入之間的連通性。如果接口服務(wù)已收到請求，并且被接口服務(wù)日志所記錄，可檢查其中的錯誤信息，這些錯誤信息，自帶了問題的特征，比如引用了錯誤的外顯號碼，接口頻次超過額定標(biāo)準(zhǔn)，這些證據(jù)都可以馬上收集到并定位到原因。

呼叫風(fēng)控服務(wù)的話，作為對外呼行為的風(fēng)險控制關(guān)鍵組件，也是重點排查的對象，如果客戶的外呼行為已經(jīng)觸發(fā)了呼叫行為風(fēng)控機制，則會直接返回失敗的信息給到用戶，這里也會拋出具體的失敗原因，所以用戶告障時如果明確的告知是因為呼叫風(fēng)控服務(wù)導(dǎo)致，那么可以一步到位找到問題。

如果不是的話，結(jié)合客戶的風(fēng)控規(guī)則來檢查呼叫行為是否超過了默認(rèn)的呼叫時段、頻次、內(nèi)容風(fēng)險的控制。根據(jù)這些來尋找問題。

操作的問題？

支撐層檢查也沒發(fā)現(xiàn)問題，那么我們的排查要點就只能是應(yīng)用層了。

我們要有辦法還原用戶使用外呼動作的現(xiàn)場。

這里面需要對自己的產(chǎn)品非常熟悉。知道客戶的哪些操作，產(chǎn)品的哪些配置、可能導(dǎo)致外呼的失敗。

那么針對具體客戶的呼叫使用場景，我們可以通過跳入客戶后臺、和客戶溝通使用場景，澄清問題現(xiàn)象，借助遠(yuǎn)程連線、檢查通話記錄，檢查功能配置項的方式來逐一檢查。如果一個正常使用的客戶，突發(fā)性的出現(xiàn)了外呼不同現(xiàn)象，優(yōu)先的檢查近期的配置更新。是不是有什么操作變動。

導(dǎo)致外呼失敗的情況會有很多，學(xué)會從通話記錄中快速判斷，可以少走很多彎路：

如果呼叫在座席側(cè)失敗，那么優(yōu)先檢查座席配置、話機和軟電話設(shè)置、或者客戶側(cè)的網(wǎng)絡(luò)環(huán)境等

如果呼叫座席側(cè)正常接通，呼叫客戶側(cè)失敗，檢查外顯號碼配置，外呼任務(wù)配置等等。

出問題不用怕，不會查問題才拉胯。

出現(xiàn)問題、解決問題時需要有非常清晰的頭腦，對產(chǎn)品的熟悉，以及對客戶使用的深入了解。

不要亂，學(xué)會從整體到局部，從大到小的方式逐一摸排定位，并且快速的去調(diào)動資源協(xié)查。

相信經(jīng)過多次問題的洗禮，你也可以成為系統(tǒng)運營管理的專家，也能發(fā)現(xiàn)產(chǎn)品中更多的改進項目，可以把產(chǎn)品打造的更加強壯。