攜程上萬坐席呼叫中心異地雙活架構及系統設計
編者：本文為攜程通信技術中心高級經理沈強，在GOPS 2016全球運維大會上的分享。
之前，我先拜讀了《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中繼外，其他在我們企業端的設備部署也比較簡單，就是兩地部署，所有的線路均衡分配到不同的設備上，預防單設備故障。並且都上聯到我們南通上海核心交換，由核心系統進行異地調度。
我們的四個核心也是full mapping設計，這四套我們分別部署在兩地，兩地都是雙活的架構，任何一地出現問題，都不影響所有的業務。這個設計我們和Google SRE的介紹的理念一致，並且我們每年都會進行冗災演練，把核心關掉，或者把集群關掉，進行觀察驗證。
第三層就是客戶端接入層，也是我們項目的實施的重點，主要講一下三種客戶端註冊登錄方式：
雙中心連接
輪詢技術
負載均衡
座席端接入異地雙活的必要性
下面講一下座席接入端異地雙活的必要性，攜程總共有一萬多的座席，如果一地系統出現重大故障，業務影響非常大。我們在這方面有很多的經驗教訓。在2014年，我們運維同事去機房進行巡檢，結果由於工作機電源線路短路，又正好觸發了電源的設計中一個bug，導致二級開關跳閘，當時我們整個呼叫中心一個大的部門業務全部垮掉了。
雖然我們快速把電源恢復起來，但是有些系統恢復不了，經過排查，發現是一些設備由於異常斷電而損壞，導致我們花了很長時間處理這個問題。故障時，系統所在地我們有大量的座席，他們沒法進行工作，而在另外一地系統即使我們把當地所有的人員加進去都沒法解決人員不足這個問題。
後續把故障的硬體設備排除後，系統恢復，但我們花了將近兩個小時，這個業務影響很大，對我們的觸動也特別大，如果那個時候座席異地雙活能實現，直接登錄到異地系統，這個業務影響就會避免掉。
第二個就是業務需求，其實所有的業務需求類似於我們的計劃內的系統的一個調整，這方面我們也有一個真實的故事，也是在去年夏天的時候，颱風當時特別大，全市學校都停課。
我們大樓的物業說，這個颱風可能會造成我們機房這邊的漏水，所以決定在颱風來的時候，把這個機房全部停電。我們當時所有的設備都在這個機房，我們這邊也很頭疼，經過協商以後，物業說還是不行，風險太大。
我們這邊不得不安排了技術人員去通宵加班，在異地系統新增配置全部的數據，計劃讓我們的上海的座席登到異地系統上，花了一個通宵才把數據配好。
第二天，由於颱風沒有預期到來，因此沒有實施這個方案，我們配置數據效果也沒有驗證過是否可靠，而我們花了大量的時間做這些應急處理，如果說當時系統能夠登錄到異地的話，這些工作我們都可以省下來，而且系統的可靠性也更高。
經歷的這幾個點，是我們深有感觸的一些痛點，因此我們花了很多的精力整改這一套系統，做到客戶端的異地雙活接入。
三、呼叫中心座席介入異地雙活
座席端異地接入前提條件：
話務多地接入，可全局分配
座席一地簽入，可接全局話務
話機IP化
話務多地接入，可全局分配，如果不能全局分配的話，座席異地登錄後，就不能接聽全局的電話。另外座席一地簽入以後，可以接全局的話務，這裡有一個話務分配的策略，這樣才能保證我們座席在任意地方簽入，都能接聽我們所有的話務。
當然最重要的一點就是IP話機，我們原先沒這麼做就是因為模擬話機無法實現兩地註冊，而IP話機可以預先註冊登錄，並且可以實現自動化。這是我們三個前提條件。
客戶端異地雙活難點：
話機註冊問題
客戶端登錄問題
資源配置問題
話機註冊問題，以前的話機是模擬線路，只能對應一個分機，並註冊到一個後台系統，物理線路和系統一一對應，而雙活則必須同時能註冊到至少兩個平台上，且能自動切換，以前的系統不支持。
座席登錄問題，座席是一個點對點，一個長連接的狀態，座席通過一個操作員號登錄CTI， 就和PBX中的一個話機進行綁定，因此登錄後就是一個常態的固定綁定關係。
如果切換系統，必須要重新更換一個新系統的操作員號進行登錄，分機也要重新註冊到新系統，這個必須人為去進行操作，業務、報表等等都要受到影響。且以前出現問題是人工去操作，一萬多座席進行調整，難度還是很大，而且會出現很多的偏差。
因此如果沒有一個自動化的措施，而是座席人工操作，根本不知道配置什麼數據，會一片混亂，這是一個痛點。所以座席登錄我們也是希望做到自動識別，自動完成，不需要人工干預。這也是我們的難點之一。
第三點是資源配置的問題，我在A城市訪問B城市，原先的資源都是各自配置各自，各自登錄，相互獨立，現在我們需要座席異地登錄時能無縫，則需實現兩地配置自動互通，而不是再去人工干預。
統一登錄
如果能解決以上這幾個問題，則我們的就能實現座席接入異地雙活了。以下我們來講一下我們針對這三個問題的解決過程。
話機註冊問題，以前是模擬線路，無法實現，此次改造我們首先更換成IP話機。而且現在話機廠商很多，只要選定廠商，能配置雙線路（A線、B線），你配置好以後，只要A線和B線雙活，配合客戶端軟體的聯動機制和心跳檢測機制，由客戶端自由選擇，就可實現話機綁定關係。現在有很多廠家支持這類配置，通過招標選型基本上不是問題。
ITDB
IP話機MAC與分機號映射
座席虛擬ID（內部資源）
座席工號與域帳號關係表
座席工號動態使用（資源池）
如一個話機接入網路以後，可以通過網路介面識別到話機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話機實時的聯動，當任何一個設備出現問題，通過心跳機制，互相之間檢測到這個故障，並發出一個消息確認，以便進行整個呼叫的調整。
另外在檢測的時候，擔心可能網路抖動或者是意外情況，做二次確認，故障確認以後，我們便可以異地登錄，而整個過程對座席來說基本無感知的，整個是過程全程自動，用戶透明。
如果異地登錄的時候發現還是失敗，兩地同時失敗，那基本上你話機本身的問題。如果是話機本身的問題，基本上會認為是一個單點故障，問題不是很大。
另外兩種狀態就是在登錄過程中發現問題，如果是CTI出現問題，則會直接向異地進行登錄請求，如果是統一登錄平台出現了問題，我們會進行二次確認，如果二次確認登錄不成功的話，則會向異地再發起一個請求，進行異地登錄。
技術特點：
支持故障情況下在線座席自動雙活切換
支持按系統、按地域、按座席技能組等不同維護進行計劃內的手工切換
支持1000+ 並發在線座席異地雙活自動切換
演練效果：
我們當時做了一個演練，這個演練也比較符合Google的一個理念，定期演練並根據演練結果進行修正。在做演練過程中，你會發現計劃內目標是否完成的，是否有一些計劃外的事情。而在實際演練中也確實發現跟我們計劃稍微有點出入，具體數據如下：
未來
未來的方向，這也是我們公司目前正在做的兩個方向
客戶端全軟體化，取消硬體電話限制
客戶端移動化，任意地點可接入
客戶端全軟體化，其實現在的很多的都已經全軟化的，全部在軟體上實現，這個從技術上我們在嘗試，而且也做demo，之所以我們這邊並沒有全部推推廣，也是跟我們的公司的戰略有關。
現在我們客戶端幾乎是全部是虛擬雲桌面，運行在後台的虛機上面，如果我們的語音功能在虛機上運行的話，我的後台配置要求高，成本也會比較高。當然如果運行在普通PC機上，我們是可以採用全軟化的方式，這個就不會存在我們前面所說的一些瓶頸限定。
還有就是客戶端移動化，我們現在也做了一些嘗試，我們自己開發了一個APP，座席可在任意地點接入，就可以登錄到系統裡面去。只是因業務發展的需求做了一些業務的分類，目前只用於外呼。對於呼入，我們現在還沒有去應用，呼入會涉及到一些話務分配的問題，分配到哪個座席，我們要解決他的狀態，這些是一個難點，所以我們現在還沒去規劃。
但對於外呼業務的話，由於主動權在我們手裡，也無嚴格的分配話務要求，任何一地點都可以接入，這個可以嘗試，也是在未來的發展方向，當然可能其他廠商或者其他的公司也有一些不同的接入方式，大家可以討論一下。
我今天主要是講一些針對我們攜程自身接地氣的一些技術實現，也是跟業務需求做的一些開發和嘗試。
【作者簡介】沈強，攜程通信技術中心高級經理。擁有十幾年的呼叫中心系統建設和運維管理經驗，經歷了攜程呼叫中心系統架構的多次轉型設計，使之從單一系統逐步演進到異地冗災、異地雙活，從單品牌到多平台的融合架構設計。目前負責攜程上萬座席呼叫中心的產品管理和架構設計工作。
文章沒看夠？更多來自攜程技術人的一手乾貨，歡迎關注攜程技術中心微信公號（ID：ctriptech）哦~
想和攜程技術小夥伴一起工作？砸簡歷tech@ctrip.com。
推薦閱讀：
※在呼叫中心工作是一種什麼樣的體驗？
※撥打 114 或 12580 查詢信息的體驗如何？這樣的信息查詢模式在移動互聯網時代將會收到什麼衝擊？
※國內有哪些呼叫中心外包服務公司值得推薦？
※400代理商、運營商、平台提供方、雲呼叫中心、雲總機之類的市場現狀是什麼樣？
※呼叫中心外包的意義是什麼？