當你使用的外呼系統呼叫不通時，你知道該如何排查嗎？本文保姆式教程手把手教你如何排查，并且從排查過程管中窺豹，了解外呼系統的工作原理和産品設計思路。一起來看看吧。
外呼不通時，不要慌張，首先你要對你的外呼系統的構造了如指掌，才可以順藤摸瓜，找到問題所在。
了解外呼系統的架構：
不管外呼系統是什麼樣的：自己做的，外面買的。基本架構和原理都不會變，我給大家抽象出一個架構圖：
上圖是基于軟交換核心的外呼系統主要分層架構。
有類似産品的對号入座，如果是硬交換、本地化部署方式的服務層核心基本原理是一緻的。
自下而上簡單介紹下：
- 資源層：各上遊的通信資源服務商。
- 接入層：對接通信資源的接入服務或者裝置
- 服務層：軟交換的核心，雲端部署軟交換系統常常拆分為各種元件，叢集化部署。
- 支撐層：包括整個服務的計費支撐管理，服務的監控，接口服務及呼叫系統特有的呼叫風控服務。
- 應用層：最上面是應用層，各種調用呼叫服務的産品和應用，比較常見的是人工外呼，自動外呼和AI外呼。
全局還是局部故障？
接下來我們就講下外呼不通時，如何順藤摸瓜，找到問題所在。
我們首先要做一個範圍限定，外呼不通是個局部性事件，還是故障級别的全局情況？
如果是小範圍内獨立事件，那麼重點去觀察範圍内的獨特特征，比如業務的通信資源、産品功能配置、應用狀态等。
确認是局部問題後，至少心态不會那麼炸裂，接下來去認真分析具體日志，使用情況去定位分析測試。
如果是後者？那意味着出現了比較嚴重的情況，需要你争分奪秒，盡快定位問題并給出解決方案。
從哪裡開始優先排查：
如果是局部性的外呼不通情況發生，我建議優先去資源層，問下資源供應商有無問題。
有人說，為什麼？産品是我們自己的，我們自己去查豈不是最友善了？
說的沒錯，但恰恰因為資源層是不受你管理的“黑盒子”，才需要馬上去溝通對接，同時開始自己的排查，否則查來查去，找不到原因，最後一問才發現，營運商的問題，白忙活一場。是以第一個起手動作大家牢記，先去對接上遊資源服務商，确認資源問題情況，溝通時，記得帶上明确現象、話單資料：包括主被叫号碼，時間等。然後催促盡快給予回複。
如果發生的外呼不通是全局性故障，反而是資源層出現問題的可能性小，一般不太可能出現這麼大範圍的資源商全體撲街型事件，如果一旦發生，那麼對應的一定有什麼重要的不可抗力的事情發生了，好好安撫客戶，等待解決吧。
首先看監控：
現在是争分奪秒排查故障的時刻了，接下來我們還是按照自下而上的順序，去檢查。
如果是全局性的故障，那麼接入層、服務層、支撐層、應用層的任一和外呼有關的元件，都需要檢查對應的監控告警和日志資訊。
這些都是問題的突破口。
内部如果有完善的告警資訊，可以馬上去定位目前時刻的告警元件、問題時間點内的告警資訊，找到故障的“疑似”問題點。
注意我說的是“疑似”，這個時候還需要給出更多的證據來證明結論。
所需要的證據，就來自于日志系統：
馬上去檢視日志系統的詳細内容，和有經驗的運維工程師，研發工程師一起，根據日志，更根據曆史經驗去盡快排查問題。
各個服務的異常指征應該都詳細記錄并管理的，作為營運外呼系統的專業人員，這是一項基本的建設要求，如果沒有監控系統，出現問題如盲人摸象。
找到故障對應的服務後，啟動故障處理預案，該替換的替換，該啟動備份的啟動備份，然後觀察系統運作情況确認是否操作有效。當然做故障恢複動作時，要明确對業務的影響，給到業務和客戶方一個通知。
人為的原因？
當檢查所有接入層、服務層均正常，資源層營運商也回報無異常，那麼先恭喜，至少沒有系統問題和嚴重事件的發生。
接下來我們把目光要轉向支撐層和應用層。
支撐層的常見問題：
支撐層一般是賬戶，計費、管理、接口類産品，這裡産品基本由内部人員操作。可以首先檢查有無最近的操作，本操作導緻的結果。進而排查是否由人為誤操作導緻問題發生。
不開玩笑，随着系統的複雜度越來越高，一些内部人為操作，往往導緻無法外呼的故障發生。比如某人員将客戶的外顯号碼禁用，賬戶整體欠費，路由配置更改等操作。都有可能直接導緻外呼失敗故障。
接口服務的話，和使用者接口使用的場景有很大關系，一般接口服務都有日志，對于外呼失敗的情況，如果客戶的外呼接口情況沒有接收到。那麼馬上就去排查下客戶方網絡和服務商接入之間的連通性。如果接口服務已收到請求，并且被接口服務日志所記錄，可檢查其中的錯誤資訊，這些錯誤資訊，自帶了問題的特征，比如引用了錯誤的外顯号碼，接口頻次超過額定标準，這些證據都可以馬上收集到并定位到原因。
呼叫風控服務的話，作為對外呼行為的風險控制關鍵元件，也是重點排查的對象，如果客戶的外呼行為已經觸發了呼叫行為風控機制，則會直接傳回失敗的資訊給到使用者，這裡也會抛出具體的失敗原因，是以使用者告障時如果明确的告知是因為呼叫風控服務導緻，那麼可以一步到位找到問題。
如果不是的話，結合客戶的風控規則來檢查呼叫行為是否超過了預設的呼叫時段、頻次、内容風險的控制。根據這些來尋找問題。
操作的問題？
支撐層檢查也沒發現問題，那麼我們的排查要點就隻能是應用層了。
我們要有辦法還原使用者使用外呼動作的現場。
這裡面需要對自己的産品非常熟悉。知道客戶的哪些操作，産品的哪些配置、可能導緻外呼的失敗。
那麼針對具體客戶的呼叫使用場景，我們可以通過跳入客戶背景、和客戶溝通使用場景，澄清問題現象，借助遠端連線、檢查通話記錄，檢查功能配置項的方式來逐一檢查。如果一個正常使用的客戶，突發性的出現了外呼不同現象，優先的檢查近期的配置更新。是不是有什麼操作變動。
導緻外呼失敗的情況會有很多，學會從通話記錄中快速判斷，可以少走很多彎路：
如果呼叫在座席側失敗，那麼優先檢查座席配置、話機和軟電話設定、或者客戶側的網絡環境等
如果呼叫座席側正常接通，呼叫客戶側失敗，檢查外顯号碼配置，外呼任務配置等等。
出問題不用怕，不會查問題才拉胯。
出現問題、解決問題時需要有非常清晰的頭腦，對産品的熟悉，以及對客戶使用的深入了解。
不要亂，學會從整體到局部，從大到小的方式逐一摸排定位，并且快速的去調動資源協查。
相信經過多次問題的洗禮，你也可以成為系統營運管理的專家，也能發現産品中更多的改進項目，可以把産品打造的更加強壯。
本文由 @通信産品的那些事 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。