
呼叫中心怎樣充分利用云計算的優(yōu)勢?
采用哪種架構才能應對業(yè)務(wù)快速增長(cháng)的挑戰?
建立原生云架構最重要的一步是什么?
不斷擴大的業(yè)務(wù)規模與快速增長(cháng)的客戶(hù)數量,促使企業(yè)呼叫中心對大規模座席可用性要求日益提升,自建與外包職場(chǎng)的統一管理需求以及外呼、質(zhì)檢效率等問(wèn)題為呼叫中心帶來(lái)挑戰,傳統模式難以為繼。
云計算、人工智能等新技術(shù)的興起,推動(dòng)呼叫中心行業(yè)進(jìn)入新時(shí)代,以硬件集成為特點(diǎn)的傳統呼叫中心迎來(lái)變革機遇。曾經(jīng)多租戶(hù)技術(shù)有效降低一次性建設成本,賦予呼叫中心更好的座席彈性;軟交換和CTI部分云化解決了擴展性等問(wèn)題,現在呼叫中心云服務(wù)逐漸受到企業(yè)客戶(hù)的認可與信賴(lài)。
呼叫中心怎樣充分利用云計算的優(yōu)勢?采用哪種架構才能應對業(yè)務(wù)快速增長(cháng)的挑戰?建立原生云架構最重要的一步是什么?
01 什么是原生云架構
傳統呼叫中心軟件架構有些設計理念與云計算價(jià)值相背。如果傳統呼叫中心軟件架構繼續以CPU序列號方式來(lái)做license授權,那么在云端虛擬環(huán)境底層硬件變化時(shí),呼叫中心將變得不可用。
原生云架構就是打破了傳統呼叫中心軟件架構的設計理念,與云計算價(jià)值與發(fā)展相一致,在基礎設施、平臺、軟件等方面全部采用云化資源的架構模式。原生云架構利用云端成熟、開(kāi)放、開(kāi)源技術(shù),使得基于原生云架構的呼叫中心成為了一個(gè)可生長(cháng)的系統。呼叫中心可與云服務(wù)組件的性能增長(cháng)、功能完善、可用性提升等共同成長(cháng)。

圖1呼叫中心演進(jìn)歷程
基于原生云架構,呼叫中心將變得比以往能力更強、效率更高,可以有效滿(mǎn)足對平臺高可用性的需求,同時(shí)在大容量、高彈性、擴展性、快速部署等方面具有優(yōu)勢。
呼叫中心的每一次進(jìn)步都與技術(shù)進(jìn)步緊密相關(guān),云計算是呼叫中心云服務(wù)的核心技術(shù),賦予呼叫中心隨時(shí)隨地、按需便捷地使用共享計算資源、存儲資源和應用功能,有效解決平臺大容量下的高可用性、擴展性等問(wèn)題,此外使得呼叫中心在部署速度、統一管理、成本管理等方面具有極大優(yōu)勢。當前采用原生云架構的天潤融通CTI-Cloud,成功實(shí)現單平臺20000座席并發(fā)登錄,平臺可用性也達到99.99%。
02 原生云架構的建立與探索
天潤融通一直致力于用新模式、新技術(shù)為企業(yè)提供高品質(zhì)的呼叫中心服務(wù)。作為全球最大的云服務(wù)商AWS中國區高級技術(shù)合作伙伴,天潤融通充分利用與AWS的合作,基于云平臺更加地專(zhuān)注在呼叫中心云服務(wù)的演進(jìn)與應用。
關(guān)注用戶(hù)需求,領(lǐng)先一步。“我們曾經(jīng)在團隊中討論過(guò)如何用S3做對象數據庫,然而S3 Select、Glacier Select不久后便上線(xiàn)了”,天潤融通總架構師安靜波介紹說(shuō),“當我們想做跨區(Region)漂移時(shí),AWS Aurora Multi-Master則恰好發(fā)布;當我們嘗試用Kaldi做語(yǔ)音識別時(shí),AmazonT ranscribe則提供了托管服務(wù)。”AWS新產(chǎn)品的發(fā)布總是領(lǐng)先用戶(hù)一步,用戶(hù)可以方便地根據自身節奏演進(jìn)產(chǎn)品。
無(wú)服務(wù)器架構創(chuàng )新讓開(kāi)發(fā)者更專(zhuān)注。Lambda是AWS在2014年推出的世界上第一個(gè)基于無(wú)服務(wù)器架構技術(shù)(Serverless)的商用產(chǎn)品,一經(jīng)推出便備受推崇。re:Invent 2017上大量實(shí)踐案例分享標志著(zhù)這項技術(shù)的成熟。除無(wú)服務(wù)器架構的核心Lambda、API Gateway之外,Aurora、Baremetal、GPU、FPGA、IoT等都可以在A(yíng)WS找到,開(kāi)發(fā)人員已不再需要關(guān)注和代碼不相關(guān)的任何事情,只需關(guān)注業(yè)務(wù)邏輯,連接服務(wù)即可。
天潤融通CTI-Cloud的原生云架構基于A(yíng)WS各種成熟的云服務(wù)組件來(lái)進(jìn)行快速迭代、快速演進(jìn),使用微服務(wù)架構技術(shù)將呼叫中心切成了26個(gè)子模塊,每個(gè)模塊均利用集群、雙活等技術(shù)實(shí)現大容量、高彈性、高可用性。

圖2天潤融通CTI-Cloud的原生云架構


圖3原生云架構正在使用和即將使用的AWS服務(wù)
在天潤融通目前正在使用的AWS服務(wù)(見(jiàn)圖3)中,黃色虛線(xiàn)框內的是去年才開(kāi)始使用,如Lambda是可以讓開(kāi)發(fā)者無(wú)需配置或管理服務(wù)器即可運行代碼的服務(wù),用來(lái)實(shí)時(shí)處理流數據,不運行不收費,可以用來(lái)降低成本;Amazon Dynamo DB是一項快速靈活的NoSQL數據庫服務(wù),在數據庫管理、性能、可擴展性和可靠性等方面具有非常大的優(yōu)勢,適合任何容量情況下低延遲存儲、讀取數據的應用程序等。
近年來(lái)人工智能技術(shù)在呼叫中心行業(yè)的應用變得廣泛,如機器學(xué)習、語(yǔ)音識別、NLP等。Lex、Polly、Machine Learning等人工智能相關(guān)的服務(wù)(見(jiàn)圖3)也已經(jīng)在我們后續的使用計劃中了。這些人工智能技術(shù)的應用將為呼叫中心帶來(lái)更優(yōu)秀的體驗和效率提升,比如Polly是一種文本轉換為逼真語(yǔ)音的服務(wù),可用來(lái)替換傳統TTS冰冷生硬的機器人聲音。
03 錄音處理架構的演進(jìn)與價(jià)值
原生云架構變革最重要的一步和價(jià)值是什么?我們可以從錄音處理架構的演進(jìn)過(guò)程看出端倪。錄音處理架構最重要的一步就是應用AutoScaling和Lambda,使錄音處理獲得了高可用性、大容量、高彈性,并且解決掉錄音會(huì )丟失情況,同時(shí)極大地降低了錄音生成時(shí)間以及成本。

圖4第一代錄音處理架構
在第一代錄音處理架構中,錄音是從CTI-Cloud平臺的sip-media模塊產(chǎn)生,經(jīng)過(guò)彈性負載均衡器(ELB)轉到media-zip錄音壓縮處理模塊進(jìn)行處理,最后將所有wav文件和處理后的mp3文件上傳到S3.
該架構最大的缺點(diǎn)是無(wú)彈性,需要預置media-zip的個(gè)數,當出現業(yè)務(wù)高峰時(shí),錄音處理延時(shí)會(huì )加大,如果預置太多實(shí)例,就會(huì )在業(yè)務(wù)低谷時(shí)造成極大的浪費。

圖5第二代錄音處理架構
在第二代錄音架構中使用AutoScaling將sip-media和media-zip兩個(gè)模塊放在了彈性伸縮組,能夠隨業(yè)務(wù)量變化彈性伸縮。但是該架構也有兩個(gè)缺點(diǎn):因為所有錄音wav文件都是通過(guò)彈性負載均衡器到后端的media-zip,所以彈性負載均衡器的流量壓力會(huì )比較大;media-zip的彈性伸縮要負責處理實(shí)例銷(xiāo)毀,如果實(shí)例在處理完wav文件之前銷(xiāo)毀,會(huì )造成錄音丟失。

圖6無(wú)服務(wù)化-錄音處理架構
在最新一代無(wú)服務(wù)化-錄音處理架構中,使用Lambda函數替換了EC2實(shí)例彈性組。wav文件通過(guò)sip-media直接上傳到S3bucket上,省去中間彈性負載均衡的環(huán)節。在S3上通過(guò)配置事件驅動(dòng)啟動(dòng)Lambda,Lambda會(huì )獲取wav文件并轉換成mp3,然后上傳到S3bucket上,整個(gè)中間的處理全部實(shí)現無(wú)服務(wù)化。
該架構有三個(gè)優(yōu)勢:更快的彈性、更可靠、更便宜,彈性響應從5分鐘縮短到了1秒,錄音生成時(shí)間縮短到5秒之內;實(shí)現自動(dòng)異常處理、先上傳后處理;從按照實(shí)例計費變成按毫秒計費。