外呼不通？如何排查

2023-06-05 18:37:44|

來源：搜狐數碼

打印

呼叫風控服務的話，作為對外呼行為的風險控制關鍵組件，也是重點排查的

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

(資料圖片)

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

了解外呼系統的架構：

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

上圖是基于軟交換核心的外呼系統主要分層架構。

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

自下而上簡單介紹下：

資源層：各上游的通信資源服務商。接入層：對接通信資源的接入服務或者設備服務層：軟交換的核心，云端部署軟交換系統常常拆分為各種組件，集群化部署。支撐層：包括整個服務的計費支撐管理，服務的監控，接口服務及呼叫系統特有的呼叫風控服務。應用層：最上面是應用層，各種調用呼叫服務的產品和應用，比較常見的是人工外呼，自動外呼和AI外呼。

全局還是局部故障？

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

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

如果是小范圍內獨立事件，那么重點去觀察范圍內的獨特特征，比如業務的通信資源、產品功能配置、應用狀態等。

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

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

從哪里開始優先排查：

如果是局部性的外呼不通情況發生，我建議優先去資源層，問下資源供應商有無問題。

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

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

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

首先看監控：

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

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

這些都是問題的突破口。

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

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

所需要的證據，就來自于日志系統：

馬上去查看日志系統的詳細內容，和有經驗的運維工程師，研發工程師一起，根據日志，更根據歷史經驗去盡快排查問題。

各個服務的異常指征應該都詳細記錄并管理的，作為運營外呼系統的專業人員，這是一項基本的建設要求，如果沒有監控系統，出現問題如盲人摸象。

找到故障對應的服務后，啟動故障處理預案，該替換的替換，該啟動備份的啟動備份，然后觀察系統運行情況確認是否操作有效。當然做故障恢復動作時，要明確對業務的影響，給到業務和客戶方一個通知。

人為的原因？

當檢查所有接入層、服務層均正常，資源層運營商也反饋無異常，那么先恭喜，至少沒有系統問題和嚴重事件的發生。

接下來我們把目光要轉向支撐層和應用層。

支撐層的常見問題：

支撐層一般是賬戶，計費、管理、接口類產品，這里產品基本由內部人員操作。可以首先檢查有無最近的操作，本操作導致的結果。從而排查是否由人為誤操作導致問題發生。

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

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

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

如果不是的話，結合客戶的風控規則來檢查呼叫行為是否超過了默認的呼叫時段、頻次、內容風險的控制。根據這些來尋找問題。

操作的問題？

支撐層檢查也沒發現問題，那么我們的排查要點就只能是應用層了。

我們要有辦法還原用戶使用外呼動作的現場。

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

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

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

如果呼叫在座席側失敗，那么優先檢查座席配置、話機和軟電話設置、或者客戶側的網絡環境等

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

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

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