外呼不通?如何排查
呼叫風控服務(wù)的話,作為對外呼行為的風險控制關(guān)鍵組件,也是重點排查的
當你使用的外呼系統(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)特有的呼叫風控服務(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)等。
確認是局部問題后,至少心態(tài)不會那么炸裂,接下來去認真分析具體日志,使用情況去定位分析測試。
如果是后者?那意味著出現(xiàn)了比較嚴重的情況,需要你爭分奪秒,盡快定位問題并給出解決方案。
從哪里開始優(yōu)先排查:
如果是局部性的外呼不通情況發(fā)生,我建議優(yōu)先去資源層,問下資源供應(yīng)商有無問題。
有人說,為什么?產(chǎn)品是我們自己的,我們自己去查豈不是最方便了?
說的沒錯,但恰恰因為資源層是不受你管理的“黑盒子”,才需要馬上去溝通對接,同時開始自己的排查,否則查來查去,找不到原因,最后一問才發(fā)現(xiàn),運營商的問題,白忙活一場。所以第一個起手動作大家牢記,先去對接上游資源服務(wù)商,確認資源問題情況,溝通時,記得帶上明確現(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)部如果有完善的告警信息,可以馬上去定位當前時刻的告警組件、問題時間點內(nèi)的告警信息,找到故障的“疑似”問題點。
注意我說的是“疑似”,這個時候還需要給出更多的證據(jù)來證明結(jié)論。
所需要的證據(jù),就來自于日志系統(tǒng):
馬上去查看日志系統(tǒng)的詳細內(nèi)容,和有經(jīng)驗的運維工程師,研發(fā)工程師一起,根據(jù)日志,更根據(jù)歷史經(jīng)驗去盡快排查問題。
各個服務(wù)的異常指征應(yīng)該都詳細記錄并管理的,作為運營外呼系統(tǒng)的專業(yè)人員,這是一項基本的建設(shè)要求,如果沒有監(jiān)控系統(tǒng),出現(xiàn)問題如盲人摸象。
找到故障對應(yīng)的服務(wù)后,啟動故障處理預(yù)案,該替換的替換,該啟動備份的啟動備份,然后觀察系統(tǒng)運行情況確認是否操作有效。當然做故障恢復(fù)動作時,要明確對業(yè)務(wù)的影響,給到業(yè)務(wù)和客戶方一個通知。
人為的原因?
當檢查所有接入層、服務(wù)層均正常,資源層運營商也反饋無異常,那么先恭喜,至少沒有系統(tǒng)問題和嚴重事件的發(fā)生。
接下來我們把目光要轉(zhuǎn)向支撐層和應(yīng)用層。
支撐層的常見問題:
支撐層一般是賬戶,計費、管理、接口類產(chǎn)品,這里產(chǎn)品基本由內(nèi)部人員操作。可以首先檢查有無最近的操作,本操作導(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ù)日志所記錄,可檢查其中的錯誤信息,這些錯誤信息,自帶了問題的特征,比如引用了錯誤的外顯號碼,接口頻次超過額定標準,這些證據(jù)都可以馬上收集到并定位到原因。
呼叫風控服務(wù)的話,作為對外呼行為的風險控制關(guān)鍵組件,也是重點排查的對象,如果客戶的外呼行為已經(jīng)觸發(fā)了呼叫行為風控機制,則會直接返回失敗的信息給到用戶,這里也會拋出具體的失敗原因,所以用戶告障時如果明確的告知是因為呼叫風控服務(wù)導(dǎo)致,那么可以一步到位找到問題。
如果不是的話,結(jié)合客戶的風控規(guī)則來檢查呼叫行為是否超過了默認的呼叫時段、頻次、內(nèi)容風險的控制。根據(jù)這些來尋找問題。
操作的問題?
支撐層檢查也沒發(fā)現(xiàn)問題,那么我們的排查要點就只能是應(yīng)用層了。
我們要有辦法還原用戶使用外呼動作的現(xiàn)場。
這里面需要對自己的產(chǎn)品非常熟悉。知道客戶的哪些操作,產(chǎn)品的哪些配置、可能導(dǎo)致外呼的失敗。
那么針對具體客戶的呼叫使用場景,我們可以通過跳入客戶后臺、和客戶溝通使用場景,澄清問題現(xià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)品打造的更加強壯。
本文由 @通信產(chǎn)品的那些事 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
責任編輯: