沈強

攜程旅行網 通信技術中心高級經理

擁有十幾年的呼叫中心系統建設和運維管理經驗，經歷了攜程呼叫中心系統架構的多次轉型設計，使之從單一系統逐步演進到異地冗災、異地雙活，從單品牌到多平臺的融合架構設計。目前負責攜程上萬座席呼叫中心的產品管理和架構設計工作。

序言

之前，我先拜讀了《Google SRE》 這本書的幾個章節，我對這些章節中的內容非常認同，特別是基于自動化運維以及故障響應時間的闡述，感同身受。

今天我講的這個技術實現就是一個非常接地氣的案例，很好了詮釋了 Google SRE 的理念，下面我會結合攜程實際的技術實現方案，進行詳細的講解。

今天演講分為三塊內容：

•首先，介紹一下攜程呼叫中心系統的整體架構，因為攜程主要是以呼叫中心起家，當時呼叫中心占整個業務訂單量70% 以上，因此呼叫中心在我們的業務里面，起到非常重要作用。

•其次，講解一下攜程呼叫中心異地雙活的架構，整個過程中會涉及到各個層面的雙活架構設計。

•最后，講解一下座席介入端的異地雙活的系統設計。

一、呼叫中心在攜程

就像剛才舉手的同學不是特別多，大家對呼叫中心這個系統還不是特別了解，因此我先簡單介紹一下呼叫中心的基本的架構，由于各個廠家或者說各個公司對于呼叫中心的設計不一樣，可能會有一些架構不一樣，因此此次基本上以攜程的基本架構作為一個模板進行的說明。

對于呼叫中心系統，主要一個系統就是 PBX 系統，這個 PBX ，類似于運營商的語音交換機，只是用于企業端，功能比較簡單一點，主要實現語音媒體的處理和呼叫排隊。

第二個系統就是 CTI 系統，就是電話和電腦的集成，等于是我們在電腦和電話之間建立的一個中間件，還包括 IVR ，錄音等系統，當然有些平臺這些系統會從 CTI 中獨立出來。

最后一點就是 CRM 系統，當然各個企業業務定義不同，攜程的 CRM 是一個訂單的業務系統，包括酒店、機票、度假等等。可能在運營商，他們更多是一個客服系統，這里面會有業務差別，但從整體架構上面來說其實都是相似的，以下是架構圖。

在這個架構圖中，描述了 PBX，CTI 和 CRM 的組網結構和關系圖，另外我們增加了遠程座席和在家辦公，上海的成本越來越高，很多的座席希望回家鄉上班，但是沒有一個好的工作或者是一個相對合適的平臺。對于在家辦公而言，大家花在交通上的成本很高，希望能在家辦公，這也是借鑒從美國引進的一些成熟理念，因此我們新增這兩種座席辦公的途徑。

前面介紹了一些呼叫中心的架構，下面講解一下攜程呼叫中心的一些高可用架構相關大紀事。

攜程呼叫中心成立以來，總共經歷了三次大的調整，第一次是2007年公司大樓搬遷，呼叫中心系統也要搬遷到新大樓，由于當時系統硬件的設計限制和成本考慮，無法做到無縫搬遷，所以搬遷過程中我們整個呼叫中心業務中斷了兩個小時。這兩個小時中斷從現在來說可能是不可想象的，說明當時我們的高可用架構還不夠完善。

第二次調整是2010年，我們在南通建了一個新的大樓，同時我們也按新架構重構了呼叫中心系統，從平臺上實現了異地雙活設計，并且將中繼路由以及其他業務進行模塊化的分拆，各模塊之間全部通過SIP協議進行連接，每個模塊之間再采用異地雙活的設計，因此各個模塊可以在異地靈活組合搭配，充分體現系統可靠性。

最后當系統正式啟用的后，兩地系統同時工作，對業務沒有任何影響，系統無縫銜接。

最后一次是今年，我們在上半年對座席客戶端進行了一個改造，因為原先我們在做設計的時候，平臺這邊我們都已經做到了全部的異地雙活，但是在客戶端由于歷史的原因，我們的一些分機全部是模擬的線路，模擬的線路如果想異地切換的話，技術上沒法實現。

因此我們從2014年進行統一登錄平臺的建設，經歷一年多的一些優化和改進，我們在今年上半年就實現了一個座席端的異地雙活的設計。

二、呼叫中心異地雙活架構簡介

剛才對攜程的呼叫中心系統做了一個簡短的介紹，下面把呼叫中心異地雙活的架構設計做一下簡單的描述。

異地雙活衡量標準，我們從自己的業務的角度定了兩個級別的標準：

•區別異地災備

•故障恢復時間

當出現故障時，我們啟用備份，但經常出現備份無法正常工作，或者不能完全接替主應用。而雙活我們是兩個系統實時存活的，切換時，只是負載增加，其他的功能模塊都一樣。對于故障恢復時間，我們希望故障恢復快速，只有快速恢復，對用戶幾乎透明或無感知，才是真正的雙活。

我們根據這兩個概念定義了一個我們的架構分層或者說這個技術實現的一個標準。

針對這兩個標準我們將系統分成三個層面進行設計實現：

•公網接入層

•應用層

•座席接入層

公網接入層和運營商線路相關，雙活設計原理很簡單，基本上都是在運營商端配置，主要涉及以下內容：

•話務中繼兩地接入

•智能網平臺(可配置三個路由)

•按百分比/主叫號碼區域

•SIP 語音中繼

只是對運營商，如果不提出你的一些想法和設計要求的話，他也不一定幫你去做，因為這樣對他的成本會高很多。我們當時在上海和南通兩地分別找了電信和聯通，總共四家運營商。對于運營商我們要求上海和南通分別都有中繼接入的，然后通過運營商的智能網平臺將我們的話務進行分配。

運營商智能網平臺有多個話務分流的策略，可以根據你的需求進行話務的分配：按百分比進行分配，或按照主叫號碼歸屬的區域進行分配。這樣企業可以根據自己的業務需求，規劃自己的話務分配邏輯設計。

我們考慮到話務費用成本問題，采用了根據主機號碼所處的區域進行分布的策略。因為我們不希望上海的話務分配到南通，產生長途費用。

運營商還有一個先進的技術方案，就是SIP中繼接入。這個概念和方案其實很早就提出來了，只是運營商考慮技術風險，當時一直在運營商內部使用，沒有對外推廣。我們和運營商進行一些技術溝通，最終嘗試接入SIP中繼，在兩個機房分別接入了一個SIP 中繼群，負載均衡，光纖接入。

達到的效果就是線路快速擴容，無需重新施工，只需后臺參數配置即可。線路主備快速切換，無需事先部署備份額外線路資源。如傳統的中繼接進來，我的話務要切到另外一邊去，這個時候如果沒有足夠的線路資源的話，而話務量還是原先那么多，那就會存在電話呼損。

而如果事先預留資源的話，一直放著沒用的，成本比較高。采用光線接入，直接就是百兆接入，資源充足，先期投入也就是新增幾根網線，切換也非常方便，而且我們這邊部署簡單，無須中繼網關和中繼線路，只須網絡交換機進行數據接入即可。這個方案我們當初跟運營商談判時，估計當時也是第一家運營商正式開通SIP中繼的公司。

總體而言，公網接入層除了SIP中繼外，其他在我們企業端的設備部署也比較簡單，就是兩地部署，所有的線路均衡分配到不同的設備上，預防單設備故障。并且都上聯到我們南通上海核心交換，由核心系統進行異地調度。

第二層是應用層，其實原理和互聯網WEB應用都是相似的，細節就不再展開，唯一需要說明的就是我們的應用層跟我們的核心交換層，他是一個靜態配置，就是我們原先就制訂好了一個路由策略，本地訪問，優先訪問本地集群，如果出現故障，可以通過路由到異地的集群去，配置非常簡單。

我們的四個核心也是full mapping設計，這四套我們分別部署在兩地，兩地都是雙活的架構，任何一地出現問題，都不影響所有的業務。這個設計我們和Google SRE的介紹的理念一致，并且我們每年都會進行冗災演練，把核心關掉，或者把集群關掉，進行觀察驗證。

第三層就是客戶端接入層，也是我們項目的實施的重點，主要講一下三種客戶端注冊登錄方式：

•雙中心連接

•輪詢技術

•負載均衡

因為呼叫中心他有一個語音線路，一個話機，我們設計的雙中心連接的方法，就是我的話機同時接入到兩個中心里面去，同時有效，按需切換。另外一個就是輪詢技術，訪問應用服務器，主系統有問題可以自動訪問第二個。最后一個就是負載均衡，這個就不多說了，WEB應用訪問。這三個技術其實我們在整個客戶端都采用了。

座席端接入異地雙活的必要性

下面講一下座席接入端異地雙活的必要性，攜程總共有一萬多的座席，如果一地系統出現重大故障，業務影響非常大。我們在這方面有很多的經驗教訓。在2014年，我們運維同事去機房進行巡檢，結果由于工作機電源線路短路，又正好觸發了電源的設計中一個bug，導致二級開關跳閘，當時我們整個呼叫中心一個大的部門業務全部垮掉了。

雖然我們快速把電源恢復起來，但是有些系統恢復不了，經過排查，發現是一些設備由于異常斷電而損壞，導致我們花了很長時間處理這個問題。故障時，系統所在地我們有大量的座席，他們沒法進行工作，而在另外一地系統即使我們把當地所有的人員加進去都沒法解決人員不足這個問題。

后續把故障的硬件設備排除后，系統恢復，但我們花了將近兩個小時，這個業務影響很大，對我們的觸動也特別大，如果那個時候座席異地雙活能實現，直接登錄到異地系統，這個業務影響就會避免掉。

第二個就是業務需求，其實所有的業務需求類似于我們的計劃內的系統的一個調整，這方面我們也有一個真實的故事，也是在去年夏天的時候，臺風當時特別大，全市學校都停課。

我們大樓的物業說，這個臺風可能會造成我們機房這邊的漏水，所以決定在臺風來的時候，把這個機房全部停電。我們當時所有的設備都在這個機房，我們這邊也很頭疼，經過協商以后，物業說還是不行，風險太大。

我們這邊不得不安排了技術人員去通宵加班，在異地系統新增配置全部的數據，計劃讓我們的上海的座席登到異地系統上，花了一個通宵才把數據配好。

第二天，由于臺風沒有預期到來，因此沒有實施這個方案，我們配置數據效果也沒有驗證過是否可靠，而我們花了大量的時間做這些應急處理，如果說當時系統能夠登錄到異地的話，這些工作我們都可以省下來，而且系統的可靠性也更高。

經歷的這幾個點，是我們深有感觸的一些痛點，因此我們花了很多的精力整改這一套系統，做到客戶端的異地雙活接入。

三、呼叫中心座席介入異地雙活

座席端異地接入前提條件：

•話務多地接入，可全局分配

•座席一地簽入，可接全局話務

•話機IP化

話務多地接入，可全局分配，如果不能全局分配的話，座席異地登錄后，就不能接聽全局的電話。另外座席一地簽入以后，可以接全局的話務，這里有一個話務分配的策略，這樣才能保證我們座席在任意地方簽入，都能接聽我們所有的話務。

當然最重要的一點就是IP話機，我們原先沒這么做就是因為模擬話機無法實現兩地注冊，而IP話機可以預先注冊登錄，并且可以實現自動化。這是我們三個前提條件。

客戶端異地雙活難點：

•話機注冊問題

•客戶端登錄問題

•資源配置問題

話機注冊問題，以前的話機是模擬線路，只能對應一個分機，并注冊到一個后臺系統，物理線路和系統一一對應，而雙活則必須同時能注冊到至少兩個平臺上，且能自動切換，以前的系統不支持。

座席登錄問題，座席是一個點對點，一個長連接的狀態，座席通過一個操作員號登錄CTI， 就和PBX中的一個話機進行綁定，因此登錄后就是一個常態的固定綁定關系。

如果切換系統，必須要重新更換一個新系統的操作員號進行登錄，分機也要重新注冊到新系統，這個必須人為去進行操作，業務、報表等等都要受到影響。且以前出現問題是人工去操作，一萬多座席進行調整，難度還是很大，而且會出現很多的偏差。

因此如果沒有一個自動化的措施，而是座席人工操作，根本不知道配置什么數據，會一片混亂，這是一個痛點。所以座席登錄我們也是希望做到自動識別，自動完成，不需要人工干預。這也是我們的難點之一。

第三點是資源配置的問題，我在A城市訪問B城市，原先的資源都是各自配置各自，各自登錄，相互獨立，現在我們需要座席異地登錄時能無縫，則需實現兩地配置自動互通，而不是再去人工干預。

統一登錄

如果能解決以上這幾個問題，則我們的就能實現座席接入異地雙活了。以下我們來講一下我們針對這三個問題的解決過程。

話機注冊問題，以前是模擬線路，無法實現，此次改造我們首先更換成IP話機。而且現在話機廠商很多，只要選定廠商，能配置雙線路（A線、B線），你配置好以后，只要A線和B線雙活，配合客戶端軟件的聯動機制和心跳檢測機制，由客戶端自由選擇，就可實現話機綁定關系。現在有很多廠家支持這類配置，通過招標選型基本上不是問題。

座席登錄的問題，座席怎么去自動識別和登錄，這也是我們花了很多的時間和精力去處理的一個業務邏輯。統一登錄，顧名思義，座席不管在哪里，用唯一的帳號就可以登錄。

•ITDB

•IP話機MAC與分機號映射

•座席虛擬ID（內部資源）

•座席工號與域帳號關系表

•座席工號動態使用（資源池）

ITDB，我們的實現過程，首先我們自己IT部門建立的一個ITDB資源庫，就是對我們管理IT設備進行自動關聯，包括我們的話機、PC機信息、座位號等，都是通過我們的系統可自動實時識別，自動更新。

如一個話機接入網絡以后，可以通過網絡接口識別到話機MAC地址，同時可以識別PC的MAC地址（話機和PC共用一個網口），并進行綁定關聯，再根據ITDB中配置的話機MAC地址對應的分機號碼，PC的MAC地址對應的機器名，就可以把PC的機器名和話機號碼進行關聯，座席客戶端登錄時通過獲取PC機器名的同時獲取到話機分機號碼。

座席虛擬ID，前面講過我們的座席要用操作員號要登錄到CTI中去，要正常登錄的話首先要配置好相關的數據，包括PBX中的數據。如果你想換一套呼叫中心的系統，這個數據要重配，包括CTI 和PBX中的數據。

因此如果要實現在兩套呼叫中心都能登錄，則必須兩套都要事先配置好數據，這樣會造成很多的冗余數據，人員信息也不統一，容易造成數據的偏差。因此我們建立的一個虛擬ID，這個ID跟CTI和PBX系統沒有直接關系，只是中間過渡銜接的模式，但和座席人員是唯一綁定。

這樣把整個CTI的操作員號資源變成一個動態的資源池，不再和座席人員固定，根據座席登錄的實時需要再去動態獲取。獲取后可以保留一定時間，類似DHCP獲取IP地址，到了設定時間，自動的釋放這個資源。這樣我們用虛擬ID把座席人員和呼叫中心系統資源解綁，使座席人員和呼叫中心系統無強耦合關系。

后續我們將虛擬ID和域帳號進行綁定，讓后根據HR系統中域帳號對應員工信息確定員工業務屬性，確定他歸屬哪個技能組，自此虛擬ID獲取了座席業務屬性，并建立了域帳號和操作員工號（技能組）的邏輯關系。

座席通過域帳號登錄時，將業務屬性告知給CTI，CTI 根據定義好的邏輯分配一個對應技能組的動態操作員工號給域帳號進行關聯，并用分配的操作員工號登錄CTI ，同時結合ITDB獲取的信息關聯到話機，完成了自動登錄。

通過統一登錄將座席員工和CTI/PBX資源進行了分離和動態分配。當系統出現故障時，可按照業務邏輯到另外的系統并重新獲取一個動態操作員號并重新登錄，實現了容災處理。

資源配置的問題：

•在雙中心的統一登錄平臺中配置全部座席虛擬ID

•雙中心IP話機的MAC信息共享

•分機號碼各自獨立

對異地雙活整個邏輯了解以后，我們講一下心跳監控聯動策略：

•Client-CTI-PBX-IP話機聯動

•二次確認，預防誤判

•故障確認，異地登錄

•全程自動，用戶透明

這個機制其實就是我們這邊設置的座席客戶端，CTI，PBX以及IP話機實時的聯動，當任何一個設備出現問題，通過心跳機制，互相之間檢測到這個故障，并發出一個消息確認，以便進行整個呼叫的調整。

另外在檢測的時候，擔心可能網絡抖動或者是意外情況，做二次確認，故障確認以后，我們便可以異地登錄，而整個過程對座席來說基本無感知的，整個是過程全程自動，用戶透明。

我這里整理了一張內部統一登錄邏輯圖

這個邏輯圖，圖中表述了座席登錄的三種狀態，第一種狀態就是在已登錄狀態（綠色這一部分），在已登錄的時候，檢測到話機出現故障，會發起一個請求，如果說第二次請求是OK，保持狀態不變，如果發現有問題，直接觸發統一登錄請求登錄，如果說異地請求登錄OK的話，會向異地發消息登錄成功的。

如果異地登錄的時候發現還是失敗，兩地同時失敗，那基本上你話機本身的問題。如果是話機本身的問題，基本上會認為是一個單點故障，問題不是很大。

另外兩種狀態就是在登錄過程中發現問題，如果是CTI出現問題，則會直接向異地進行登錄請求，如果是統一登錄平臺出現了問題，我們會進行二次確認，如果二次確認登錄不成功的話，則會向異地再發起一個請求，進行異地登錄。

技術特點：

•支持故障情況下在線座席自動雙活切換

•支持按系統、按地域、按座席技能組等不同維護進行計劃內的手工切換

•支持1000+ 并發在線座席異地雙活自動切換

演練效果：

我們當時做了一個演練，這個演練也比較符合Google的一個理念，定期演練并根據演練結果進行修正。在做演練過程中，你會發現計劃內目標是否完成的，是否有一些計劃外的事情。而在實際演練中也確實發現跟我們計劃稍微有點出入，具體數據如下：

后期我們針對演練發現的問題，進行了修復和調整，并在測試環境進行壓測驗證，最終實現1000+座席自動切換在2分鐘內全部完成。

未來

未來的方向，這也是我們公司目前正在做的兩個方向

•客戶端全軟件化，取消硬件電話限制

•客戶端移動化，任意地點可接入

客戶端全軟件化，其實現在的很多的都已經全軟化的，全部在軟件上實現，這個從技術上我們在嘗試，而且也做demo，之所以我們這邊并沒有全部推推廣，也是跟我們的公司的戰略有關。

現在我們客戶端幾乎是全部是虛擬云桌面，運行在后臺的虛機上面，如果我們的語音功能在虛機上運行的話，我的后臺配置要求高，成本也會比較高。當然如果運行在普通PC機上，我們是可以采用全軟化的方式，這個就不會存在我們前面所說的一些瓶頸限定。

還有就是客戶端移動化，我們現在也做了一些嘗試，我們自己開發了一個APP，座席可在任意地點接入，就可以登錄到系統里面去。只是因業務發展的需求做了一些業務的分類，目前只用于外呼。對于呼入，我們現在還沒有去應用，呼入會涉及到一些話務分配的問題，分配到哪個座席，我們要解決他的狀態，這些是一個難點，所以我們現在還沒去規劃。

但對于外呼業務的話，由于主動權在我們手里，也無嚴格的分配話務要求，任何一地點都可以接入，這個可以嘗試，也是在未來的發展方向，當然可能其他廠商或者其他的公司也有一些不同的接入方式，大家可以討論一下。

我今天主要是講一些針對我們攜程自身接地氣的一些技術實現，也是跟業務需求做的一些開發和嘗試。我今天就講這么多，有什么問題大家可以現場問一下。

四、提問環節

Q1：

我問一下像呼叫中心這個全軟化方向，現在你們有沒有實際的案例或者實際的可用的解決方案是全軟件化的？

沈強：這個是有的，我剛才只是講了一個平臺，其實我們公司從14年開始就是多平臺進行接入的。現在我們至少有三個平臺，有兩個平臺基于的硬件，基于語音設備的，第三個平臺全是我們自研的，現在也是基于開源的軟件做了一些開發，連語音交換機沒有了，基本上實現了全軟的概念。

我們提出了客戶端也是全軟件，這個剛才也講過，我們已經實現了，只是我們沒有大規模推廣，畢竟我們對于客戶端全軟化還是有一些疑惑。如果用上去以后PC機出了問題，語音也會受到影響，語音在PC機上處理會不會對PC性能出現影響，導致業務處理受影響？我們是結合這兩點考慮，現在還是做一些線上測試，但是產品的話我們都已經全部開發完了。

Q2：

第一個我想問一下就是關于貴公司現在SIP中繼的使用量？

沈強：比例還是比少，因為這也是受制于運營商的一些限定，舉個例子，其實剛開始我們找上海運營商，但是他們不開放。我們也是找其他的地市的運營商，他們也愿意跟我們合作，因此我們當時嘗試應該是10%左右。

Q3：

我們之前的了解，就是SIP應用可能，第三方的安全性的話可能有差異，我不知道實際應用當中會不會有這影響？

沈強：是跟運營商協商過，開始也非常擔心這個問題，我們當時采購語音的安全網關設備進行保護。而且我們和運營商是專線連接，用的是內網地址，另外當時我們討論下，我們安全部認為運營商是可信任的一個點，因此繼續推行這么一個策略。

Q4：

我想問一下，就是 說攜程這么大規模的話，就是電話外呼有沒有被運營商封的可能性，如果被封的話怎么處理，針對外呼這塊？

沈強：確實，有這個可能性，雖然我們外呼的時候對所有的號碼進行了備案，但有些用戶在APP中標記為騷擾，針對這個問題，一方面我們跟運營商積極協商，讓他不要封，把號碼加入到白名單里面去。

另外一個如果檢測到這個號碼的呼叫成功率突然降低，或者有問題的話，我們馬上進行外呼號碼的切換，這個也是在運營商的號段里面的。如果出現一個號碼被攔截，我們可能換一個運營商進行一個切換，采用一個人工和自動相結合的方法。

Q5：

這樣的話，切換會不會影響用戶的接通率？

沈強：要看具體的情況，有些用戶只認這個號碼，因此可以設定呼叫不成功時，可以嘗試2-3次。其他的用戶的話，用戶可能這個號碼并不是特別關注的，因為可能只是一個臨時通知，同時也有短信通知。

還有部分外呼電話是跟酒店一些定單的確認，他們對這部分都不是很敏感，如果敏感的話我們設定了至少三個號碼事先通知他們。

Q6：

除了電信跟聯通之外移動線路的話你們也有在用？

沈強：也有。

Q7：

關于剛剛您講了對于雙活，話機也有雙連接的機制，就是說話機和客戶端的話都是有這種雙連接的機制？

沈強：只是話機是雙連接，話機我們這邊有一個客戶端自己識別關聯，我這邊能配置到IP話機和PBX對應的分機號碼的綁定關系，這些不可能讓話機自動識別，它非智能的，我們先要設定好。

Q8：

話盒和電腦的是用同一網絡嗎？

沈強：同一網絡。一個網線，我們交換機會實現，我們知道這兩個MAC地址是綁定一個上面，我們的網絡團隊也做了一些自動化的一些運維工具，識別他的對管理關系。

Q9：

對應的這兩個MAC地址是被劃到兩不同的VLAN？

沈強：語音和數據的話我們是從流量上我們劃了不同的VlAN里面，只是端口識別上我們可以統一識別。

Q10:

我們這邊也做異地雙活的時候，關于座席的分機，簽入的時候，比如說我們上海的呼叫中心，假如說注冊了什么9527這個分機號，在蘇州的呼叫中心，這個分機號已經用了，在蘇州不能注冊這個分機號，只能用另外一個號碼，我們會讓用戶，記住兩個分機號，出現 問題是用另一個，但是我們的業務不太接受，你讓一個人記兩個號。

沈強：我們是系統自動識別的。剛才有一頁可能講到了，我分機號號碼各自獨立的，我在登錄的時候如果說識別到這個MAC地址的話，我就能獲取對應的分機號碼，我在客戶端的時候跟這個分機號碼進行綁定。

我們的話盒是固定的，事先把這個數據兩邊全部備好就可以了，我們以前對模擬話機也是每個客戶端都需要座席去選擇我這個話機的號碼，后面全部通過網絡自動化識別，通過一些事現備注好的數據，系統自動識別，對于業務人員，只需記住自己的域帳號就行，無需關注分機號碼。