［黃凱方 劉誠 吳文波］

1 引言

近年來，隨著通信行業(yè)競爭的加劇,三大運營商都把政企客戶的爭奪作為重要的競爭領(lǐng)地。而政企客戶對業(yè)務(wù)保障也提出了越來越高的要求，業(yè)務(wù)保障的及時性決定運營商競爭地位是否有利、是否持久。部分政企客戶尤其是銀行金融業(yè)務(wù)對話務(wù)保障提出了較高要求，業(yè)務(wù)出現(xiàn)問題后必須在2 小時甚至1 小時內(nèi)解決。

目前傳統(tǒng)故障的處理模式是，設(shè)備出現(xiàn)問題時網(wǎng)管產(chǎn)生告警，送至集中告警平臺，集中告警平臺送至電子運維系統(tǒng)，監(jiān)控工位值班人員看到告警工單后再派單給后端人員處理，中間涉及環(huán)節(jié)多，而且有些環(huán)節(jié)需要人工判斷處理，到系統(tǒng)維護人員接到工單時往往已經(jīng)過了30 分鐘甚至更長時間。而維護人員接收到工單后，還需要登錄設(shè)備，作各種判斷分析處理，處理效率低，如果遇到需要切換的號碼多還極容易出錯。而隨著公司去年數(shù)字化轉(zhuǎn)型的興起與發(fā)展，本文嘗試通過開源技術(shù)，以微眾平臺話務(wù)雙路由保障為例，提出一種新的解決話務(wù)雙路由實時切換的解決方案。

2 微眾平臺現(xiàn)網(wǎng)分析

2.1 話務(wù)路由

微眾平臺的話務(wù)采用注冊代理或非注冊對等方式，IPPBX 可通過SIP 中繼接入到IMS 核心網(wǎng)ABAC/IBAC，ABAC/IBAC 做為語音核心網(wǎng)網(wǎng)邊緣接入服務(wù)器，向客戶提供號碼注冊/呼叫代理功能，安全隔離用戶接入設(shè)備，隱藏核心網(wǎng)拓撲。

微眾平臺商呼中心非注冊對等方式接入到深圳IBAC，同時為了保障業(yè)務(wù)的可靠性，商呼平臺通過雙路由接入到深圳IBAC01/02,實現(xiàn)平臺呼出和呼入平臺的話務(wù)負荷分擔，確保在IBAC-平臺單路由或IBAC 單設(shè)備故障時，呼出和呼入話務(wù)可通過配對的另一臺IBAC 路由疏通話務(wù)，保障業(yè)務(wù)的連續(xù)服務(wù)。如圖1 所示，后面就這幾部分分別說明。

圖1 微眾平臺網(wǎng)絡(luò)拓撲圖

2.2 話務(wù)保障要求

2.2.1 平臺呼出業(yè)務(wù)保障

客戶平臺監(jiān)測到IBAC 路由狀態(tài)或呼叫接續(xù)情況，當監(jiān)測到路由“中斷”或在該路由上發(fā)出呼叫請求INVITE后收到5XX 響應(yīng)消息時，客戶平臺啟動重選路由功能，將呼叫申請發(fā)送到配對的另一個BAC。

如果平臺具備監(jiān)測路由狀態(tài)能力，可在路由狀態(tài)可用時自動取消重選功能；否則，采用人工方式取消重選路由功能。

2.2.2 呼入平臺業(yè)務(wù)保障

IBAC 監(jiān)測到平臺路由中斷或在到平臺發(fā)出呼叫請求INVITE 后收到5XX 響應(yīng)消息時，IBAC 啟動重選路由功能，在被叫號碼前插路由碼，呼叫返回到AGCF，通過配對AGCF 將呼叫路由到配對IBAC 到平臺落地。如：IBAC01到平臺路由中斷，IBAC 在被叫號碼前插路由碼，路由到AGCF63、AGCF64，AGCF64 刪除前插路由碼后，經(jīng)過IBAC02 送到平臺。

當IBAC 監(jiān)測到平臺路由可用，自動取消重選路由功能。

2.3 風險分析

首先，雖然目前核心網(wǎng)綜合網(wǎng)管已實現(xiàn)對IMS 網(wǎng)絡(luò)的全面監(jiān)控，可以通過提升IBAC 到客戶路由告警的等級，實現(xiàn)當IBAC 出現(xiàn)附錄1 告警時，一方面立即上面集中告警系統(tǒng)，通過監(jiān)控人員派單，通知相關(guān)維護部門/人員處理；另一方面通過短信方式，通知指定客戶保障人員。但是告警經(jīng)過的環(huán)節(jié)過多，告警目前上報途徑為：IBAC →IMS U2000 網(wǎng)管→核心網(wǎng)綜合網(wǎng)管→集中告警系統(tǒng)→電子運維系統(tǒng)→監(jiān)控人員看到告警工單并派單→維護人員接單并聯(lián)系微眾平臺客戶經(jīng)理處理，中間經(jīng)過五六個環(huán)節(jié)才通知到系統(tǒng)維護人員，而且監(jiān)控人員判斷告警并派單、維護人員接單并聯(lián)系客戶經(jīng)理這兩個人工環(huán)節(jié)是不一定實時的，可能存在一定延遲。因此，這種方案并不是實時的監(jiān)控處理，只能說是準實時。

其次，當兩個IBAC 到客戶的中繼故障（承載中斷或客戶設(shè)備故障）時，重選路由的呼叫在兩個AGCF 之間乒乓振蕩，存在沖擊AGCF 的網(wǎng)絡(luò)風險，因此，需要在IBAC 取消重選路由功能。

3 改進后的告警監(jiān)測方案

為滿足客戶業(yè)務(wù)保障需求，通過開源組件Kakfa 來實現(xiàn)告警消息實現(xiàn)實時監(jiān)測，我們先介紹一下Kafka。

3.1 Kafka 介紹

Kafka是由Apache軟件基金會開發(fā)的一個開源流處理平臺，由Scala 和Java 編寫。該項目的目標是為處理實時數(shù)據(jù)提供一個統(tǒng)一、高吞吐、低延遲的平臺。其持久化層本質(zhì)上是一個“按照分布式事務(wù)日志架構(gòu)的大規(guī)模發(fā)布/訂閱消息隊列”，這使它作為企業(yè)級基礎(chǔ)設(shè)施來處理流式數(shù)據(jù)非常有價值。此外，Kafka 可以通過Kafka Connect 連接到外部系統(tǒng)（用于數(shù)據(jù)輸入/輸出），并提供了Kafka Streams——一個Java 流式處理庫。

可以看到Kafka 也就是一個發(fā)布/訂閱的消息隊列。只是它具有分布式以及大規(guī)模（支持大數(shù)據(jù)量）的特性。

3.2 Kafka 組件

Kafka 各組件之間的關(guān)系如圖2 所示，具體組件用途說明如下：

Producer：消息生產(chǎn)者，就是向Kafka 發(fā)送數(shù)據(jù)。

Consumer：消息消費者，從Kafka broker取消息的客戶端。

Consumer Group（CG）：消費者組，由多個consumer 組成。消費者組內(nèi)每個消費者負責消費不同分區(qū)的數(shù)據(jù)，一個分區(qū)只能由一個組內(nèi)消費者消費；消費者組之間互不影響。所有的消費者都屬于某個消費者組，即消費者組是邏輯上的一個訂閱者。

Broker：經(jīng)紀人一臺Kafka 服務(wù)器就是一個broker。一個集群由多個broker 組成。一個broker 可以容納多個 topic。

Topic：話題，可以理解為一個隊列，生產(chǎn)者和消費者面向的都是一個topic。

Partition：為了實現(xiàn)擴展性，一個非常大的topic 可以分布到多個broker（即服務(wù)器）上，一個topic 可以分為多個 partition，每個partition 是一個有序的隊列；如果一個topic 中的partition 有5 個，那么topic 的并發(fā)度為5。

Replica：副本（Replication），為保證集群中的某個節(jié)點發(fā)生故障時，該節(jié)點上的partition 數(shù)據(jù)不丟失，且Kafka 仍然能夠繼續(xù)工作，Kafka 提供了副本機制，一個topic 的每個分區(qū)都有若干個副本，一個leader 和若干個follower。

Leader：每個分區(qū)多個副本的“主”，生產(chǎn)者發(fā)送數(shù)據(jù)的對象，以及消費者消費數(shù)據(jù)的對象都是leader。

Follower：每個分區(qū)多個副本中的“從”，實時從leader 中同步數(shù)據(jù)，保持和leader 數(shù)據(jù)的同步。leader 發(fā)生故障時，某個Follower 會成為新的leader。

高吞吐量、低延遲：kafka 每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic 可以分多個partition，consumer group對partition進行consume操作。

可擴展性：kafka 集群支持熱擴展。

持久性、可靠性：消息被持久化到本地磁盤，并且支持數(shù)據(jù)備份防止數(shù)據(jù)丟失。

容錯性：允許集群中節(jié)點失敗（若副本數(shù)量為n，則允許n-1 個節(jié)點失?。?。

高并發(fā)：支持數(shù)千個客戶端同時讀寫。

圖2 kafka 結(jié)構(gòu)

3.3 Kafka 消息獲取模式

3.3.1 producer 采用push（推）模式向broker 中寫入數(shù)據(jù)

pull（拉）模式需要kafka 集群事先知曉producer 的信息，即producer 需要先注冊后才能使用。當有生產(chǎn)者實例宕機了，可能會存在空等。若需要擴展新的producer，則需要先注冊，在后續(xù)的kafka版本中逐步地和zookeeper進行了解耦。

push（推）模式的優(yōu)點是生產(chǎn)者有數(shù)據(jù)就塞給消息隊列，不用管其他的事情，只用專注于生產(chǎn)數(shù)據(jù)。

3.3.2 consumer 采用pull（拉）模式從broker 中讀取數(shù)據(jù)

push（推）模式很難適應(yīng)消費速率不同的消費者，因為消息發(fā)送速率是由broker 決定的（如圖3 所示）。它的目標是盡可能以最快速度傳遞消息，但是這樣很容易造成consumer來不及處理消息，典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞。而pull 模式則可以根據(jù)consumer 的消費能力以適當?shù)乃俾氏M消息。

pull 模式不足之處是，如果Kafka 沒有數(shù)據(jù)，消費者可能會陷入循環(huán)中，一直返回空數(shù)據(jù)。針對這一點，Kafka 的消費者在消費數(shù)據(jù)時會傳入一個時長參數(shù)timeout，如果當前沒有數(shù)據(jù)可供消費，consumer會等待一段時間之后再返回，這段時長即為timeout。

圖3 kafka 獲取消息圖

3.4 Kafka 實時監(jiān)測路由方案

在IBAC 服務(wù)器上，部署腳本，將IBAC 每分鐘產(chǎn)生的日志實時傳送到部署Kafka 的機器上，這樣Kafka 里面就有了IBAC 的實時日志。

然后配置Kafka 系統(tǒng)，訂閱日志中路由變化的日志，一旦產(chǎn)生這類日志，通過預(yù)先編寫好的java 程序，Kafka會自動通過短信業(yè)務(wù)網(wǎng)關(guān)、語音ivr 通知到客戶經(jīng)理以及維護人員，以Kafka 的特性，從告警日志產(chǎn)生到客戶經(jīng)理以及維護人員接到通知，正常情況只需要5 s 的時長（如圖4 所示）。

圖4 kafka 監(jiān)測流程

4 改進后的故障處理方案

傳統(tǒng)的政企客戶故障處理流程是，維護人員接到報障后，首先登錄網(wǎng)元查看告警，確認告警仍然存在后，立即聯(lián)系客戶經(jīng)理處理。

客戶經(jīng)理則需要上報主管確定是否組織路由切換，得到主管同意以后再通知維護人員組織路由切換，然后維護人員編寫腳本進行切換，整個過程都是人工進行，時間長效率低不說，還極容易出現(xiàn)差錯，批復(fù)下來后中間網(wǎng)絡(luò)狀態(tài)也有可能發(fā)生了變更。

為解決這個問題，我們通過編寫java 程序，改造成全自動的故障處理方式：

4.1 預(yù)制應(yīng)急腳本，一鍵調(diào)用

按照客戶保障要求，通過核心網(wǎng)綜合網(wǎng)管預(yù)設(shè)定AGCF 側(cè)路由切換應(yīng)急腳本，包括檢查從AGCF-IBAC-客戶平臺路由狀態(tài)、當配對AGCF-IBAC-客戶平臺路由狀態(tài)正常時，AGCF 調(diào)整落地號碼路由指向配對AGCF 等。當客戶保障人員收到短信通知后，或通知客戶確認受影響情況、檢查IBAC 與平臺路由狀態(tài)，或直接通過遠程方式觸發(fā)路由切換等等，需要時由核心網(wǎng)綜合網(wǎng)管發(fā)送應(yīng)急腳本到AGCF，并反饋執(zhí)行結(jié)果給客戶保障人員。

4.2 程序內(nèi)置審批流程

通過編寫java 程序內(nèi)置流程，首先減少維護人員通知客戶經(jīng)理這個環(huán)節(jié)，直接由客戶經(jīng)理發(fā)起故障處理流程，也符合現(xiàn)在倒三角賦能前端，讓一線呼喚炮火的實時要求。

重新改進過的流程如下。

（1）在上一環(huán)節(jié)中，客戶經(jīng)理接到語音IVR 后同時也會接收到短信，提示是否按照應(yīng)急腳本進行操作，如果同意則按Y，否則則按N。

（2）客戶經(jīng)理按Y 進行操作后，對應(yīng)主管會接收到語音IVR 以及短信通知，是否授權(quán)進行應(yīng)急腳本操作，同意則按Y，否則則按N。輸入Y 以后，同時為了保證網(wǎng)絡(luò)安全，需要輸入短信驗證碼，短信驗證碼由核心網(wǎng)控制系統(tǒng)下發(fā)，只有正確輸入了驗證碼才能進行下一步操作（短信驗證碼有3 次機會）。

（3）客戶經(jīng)理得到主管授權(quán)后，同樣需要核心網(wǎng)綜合網(wǎng)管下發(fā)的正確的短信驗證碼進行驗證后才能授權(quán)設(shè)備進行操作（短信驗證碼有3 次機會），驗證通過后進入下一步。

（4）核心網(wǎng)綜合網(wǎng)管首先檢查告警是否仍然存在路由是否正常，如果告警已經(jīng)消失，則不作任何操作，發(fā)短信和語音IVR 提醒客戶經(jīng)理、維護人員告警已經(jīng)消失，路由正常，無需操作。

（5）如果告警依然存在，路由不正常，程序會檢查另一側(cè)IBAC 至AGCF 的路由是否正常，如果另一側(cè)正常，則執(zhí)行應(yīng)急腳本倒換路由，倒換后自動測試路由情況，并將結(jié)果通知客戶經(jīng)理和維護人員。

整個環(huán)節(jié)下來溝通時間大大縮短，由原來的半個小時左右，壓縮到幾分鐘就能完成，如圖5 所示。

圖5 改進后故障處理流程

4.3 如何測試方案是否可行

整個實時監(jiān)測方案已經(jīng)出爐，但問題所之而來，如何測試這個方案是否可行呢？整個方案是采用java 程序+Kafka 組件+短信通知模塊+語音IVR 模塊等編寫，肯定會存在多個bug，需要反復(fù)測試多次才能保證毫無問題，但現(xiàn)網(wǎng)平臺不可能這樣操作，必須建立測試環(huán)境進行測試，只有在測試環(huán)境反復(fù)測試沒有問題了，才能在現(xiàn)網(wǎng)進行真實演練。

為模仿客戶的商呼平臺，我們申請了E8-C 終端以及測試IPPBX 各一臺，并對測試IPPBX 分配固定1994VPN IP 地址。

然后配置測試IPPBX 雙上聯(lián)IBAC，在IBAC 實施主叫鑒權(quán)，號碼為辦公號碼，如圖6 所示。

測試時在IBAC01/02 上同時打開信令跟蹤工具，首先正常時撥打電話，觀察話務(wù)走哪個IBAC，然后運行程序，手工去激活測試ippbx 至IBAC01 的鏈路，看是否產(chǎn)生告警短信和語音IVR 推送。

圖6 測試網(wǎng)絡(luò)

接著測試審批流程是否順暢，程序自動執(zhí)行倒換腳本后，話務(wù)是否正常從另外一邊的IBAC 出去，信令流程是否正常，為了保證客戶業(yè)務(wù)萬無一失，需要同時測試到話務(wù)走IBAC01 切換到IBAC02，以及話務(wù)走IBAC02 切換到IBAC01 這兩種情況，實際測試中發(fā)現(xiàn)需要多次電話撥打才能保證測試到這兩種情況（某一時間段可能話務(wù)都走IBAC01 或者IBAC02）。

其次就是驗證程序的高可用性、高可靠性和健壯性，設(shè)想多種可能出現(xiàn)的極端情況，比如客戶經(jīng)理驗證碼輸錯或者沒有輸，執(zhí)行腳本時發(fā)現(xiàn)另外一邊路由不可用，或者要執(zhí)行倒換時發(fā)現(xiàn)告警異常等10 多種情況，每種情況都要考慮到話務(wù)走IBAC01 還是走IBAC02 兩種情況，每種情況都測試數(shù)十次以上，解決發(fā)現(xiàn)的bug 幾十個，保證了應(yīng)急方案在任何情況下都能正確無誤地執(zhí)行。

5 小結(jié)

本文提出的并部署的政企客戶話務(wù)路由保障方案，經(jīng)過實驗環(huán)境多次測試，并通過現(xiàn)網(wǎng)檢驗，能夠?qū)崟r發(fā)現(xiàn)政企客戶的業(yè)務(wù)問題并快速準確地處理，值得在政企客戶話務(wù)路由保障中實行推廣，能夠有力保障公司在政企客戶競爭中的有利地位。