呼叫中心怎樣充分利用云計(jì)算的優(yōu)勢(shì)？

采用哪種架構(gòu)才能應(yīng)對(duì)業(yè)務(wù)快速增長(zhǎng)的挑戰(zhàn)？

建立原生云架構(gòu)最重要的一步是什么？

　　不斷擴(kuò)大的業(yè)務(wù)規(guī)模與快速增長(zhǎng)的客戶(hù)數(shù)量，促使企業(yè)呼叫中心對(duì)大規(guī)模座席可用性要求日益提升，自建與外包職場(chǎng)的統(tǒng)一管理需求以及外呼、質(zhì)檢效率等問(wèn)題為呼叫中心帶來(lái)挑戰(zhàn)，傳統(tǒng)模式難以為繼。

　　云計(jì)算、人工智能等新技術(shù)的興起，推動(dòng)呼叫中心行業(yè)進(jìn)入新時(shí)代，以硬件集成為特點(diǎn)的傳統(tǒng)呼叫中心迎來(lái)變革機(jī)遇。曾經(jīng)多租戶(hù)技術(shù)有效降低一次性建設(shè)成本，賦予呼叫中心更好的座席彈性；軟交換和CTI部分云化解決了擴(kuò)展性等問(wèn)題，現(xiàn)在呼叫中心云服務(wù)逐漸受到企業(yè)客戶(hù)的認(rèn)可與信賴(lài)。

　　呼叫中心怎樣充分利用云計(jì)算的優(yōu)勢(shì)？采用哪種架構(gòu)才能應(yīng)對(duì)業(yè)務(wù)快速增長(zhǎng)的挑戰(zhàn)？建立原生云架構(gòu)最重要的一步是什么？

　　傳統(tǒng)呼叫中心軟件架構(gòu)有些設(shè)計(jì)理念與云計(jì)算價(jià)值相背。如果傳統(tǒng)呼叫中心軟件架構(gòu)繼續(xù)以CPU序列號(hào)方式來(lái)做license授權(quán)，那么在云端虛擬環(huán)境底層硬件變化時(shí)，呼叫中心將變得不可用。

　　原生云架構(gòu)就是打破了傳統(tǒng)呼叫中心軟件架構(gòu)的設(shè)計(jì)理念，與云計(jì)算價(jià)值與發(fā)展相一致，在基礎(chǔ)設(shè)施、平臺(tái)、軟件等方面全部采用云化資源的架構(gòu)模式。原生云架構(gòu)利用云端成熟、開(kāi)放、開(kāi)源技術(shù)，使得基于原生云架構(gòu)的呼叫中心成為了一個(gè)可生長(zhǎng)的系統(tǒng)。呼叫中心可與云服務(wù)組件的性能增長(zhǎng)、功能完善、可用性提升等共同成長(zhǎng)。

圖1呼叫中心演進(jìn)歷程

　　基于原生云架構(gòu)，呼叫中心將變得比以往能力更強(qiáng)、效率更高，可以有效滿(mǎn)足對(duì)平臺(tái)高可用性的需求，同時(shí)在大容量、高彈性、擴(kuò)展性、快速部署等方面具有優(yōu)勢(shì)。

　　呼叫中心的每一次進(jìn)步都與技術(shù)進(jìn)步緊密相關(guān)，云計(jì)算是呼叫中心云服務(wù)的核心技術(shù)，賦予呼叫中心隨時(shí)隨地、按需便捷地使用共享計(jì)算資源、存儲(chǔ)資源和應(yīng)用功能，有效解決平臺(tái)大容量下的高可用性、擴(kuò)展性等問(wèn)題，此外使得呼叫中心在部署速度、統(tǒng)一管理、成本管理等方面具有極大優(yōu)勢(shì)。當(dāng)前采用原生云架構(gòu)的天潤(rùn)融通CTI-Cloud，成功實(shí)現(xiàn)單平臺(tái)20000座席并發(fā)登錄，平臺(tái)可用性也達(dá)到99.99%。

　　天潤(rùn)融通一直致力于用新模式、新技術(shù)為企業(yè)提供高品質(zhì)的呼叫中心服務(wù)。作為全球最大的云服務(wù)商AWS中國(guó)區(qū)高級(jí)技術(shù)合作伙伴，天潤(rùn)融通充分利用與AWS的合作，基于云平臺(tái)更加地專(zhuān)注在呼叫中心云服務(wù)的演進(jìn)與應(yīng)用。

　　關(guān)注用戶(hù)需求，領(lǐng)先一步。“我們?cè)��?jīng)在團(tuán)隊(duì)中討論過(guò)如何用S3做對(duì)象數(shù)據(jù)庫(kù)，然而S3 Select、Glacier Select不久后便上線(xiàn)了”，天潤(rùn)融通總架構(gòu)師安靜波介紹說(shuō)，“當(dāng)我們想做跨區(qū)（Region）漂移時(shí)，AWS Aurora  Multi-Master則恰好發(fā)布；當(dāng)我們嘗試用Kaldi做語(yǔ)音識(shí)別時(shí)，AmazonT ranscribe則提供了托管服務(wù)。”AWS新產(chǎn)品的發(fā)布總是領(lǐng)先用戶(hù)一步，用戶(hù)可以方便地根據(jù)自身節(jié)奏演進(jìn)產(chǎn)品。

　　無(wú)服務(wù)器架構(gòu)創(chuàng)新讓開(kāi)發(fā)者更專(zhuān)注。Lambda是AWS在2014年推出的世界上第一個(gè)基于無(wú)服務(wù)器架構(gòu)技術(shù)（Serverless）的商用產(chǎn)品，一經(jīng)推出便備受推崇。re:Invent 2017上大量實(shí)踐案例分享標(biāo)志著這項(xiàng)技術(shù)的成熟。除無(wú)服務(wù)器架構(gòu)的核心Lambda、API Gateway之外，Aurora、Baremetal、GPU、FPGA、IoT等都可以在AWS找到，開(kāi)發(fā)人員已不再需要關(guān)注和代碼不相關(guān)的任何事情，只需關(guān)注業(yè)務(wù)邏輯，連接服務(wù)即可。

　　天潤(rùn)融通CTI-Cloud的原生云架構(gòu)基于AWS各種成熟的云服務(wù)組件來(lái)進(jìn)行快速迭代、快速演進(jìn)，使用微服務(wù)架構(gòu)技術(shù)將呼叫中心切成了26個(gè)子模塊，每個(gè)模塊均利用集群、雙活等技術(shù)實(shí)現(xiàn)大容量、高彈性、高可用性。

圖2天潤(rùn)融通CTI-Cloud的原生云架構(gòu)

圖3原生云架構(gòu)正在使用和即將使用的AWS服務(wù)

　　在天潤(rùn)融通目前正在使用的AWS服務(wù)（見(jiàn)圖3）中，黃色虛線(xiàn)框內(nèi)的是去年才開(kāi)始使用，如Lambda是可以讓開(kāi)發(fā)者無(wú)需配置或管理服務(wù)器即可運(yùn)行代碼的服務(wù)，用來(lái)實(shí)時(shí)處理流數(shù)據(jù)，不運(yùn)行不收費(fèi)，可以用來(lái)降低成本；Amazon Dynamo DB是一項(xiàng)快速靈活的NoSQL數(shù)據(jù)庫(kù)服務(wù)，在數(shù)據(jù)庫(kù)管理、性能、可擴(kuò)展性和可靠性等方面具有非常大的優(yōu)勢(shì)，適合任何容量情況下低延遲存儲(chǔ)、讀取數(shù)據(jù)的應(yīng)用程序等。

　　近年來(lái)人工智能技術(shù)在呼叫中心行業(yè)的應(yīng)用變得廣泛，如機(jī)器學(xué)習(xí)、語(yǔ)音識(shí)別、NLP等。Lex、Polly、Machine Learning等人工智能相關(guān)的服務(wù)（見(jiàn)圖3）也已經(jīng)在我們后續(xù)的使用計(jì)劃中了。這些人工智能技術(shù)的應(yīng)用將為呼叫中心帶來(lái)更優(yōu)秀的體驗(yàn)和效率提升，比如Polly是一種文本轉(zhuǎn)換為逼真語(yǔ)音的服務(wù)，可用來(lái)替換傳統(tǒng)TTS冰冷生硬的機(jī)器人聲音。

　　原生云架構(gòu)變革最重要的一步和價(jià)值是什么？我們可以從錄音處理架構(gòu)的演進(jìn)過(guò)程看出端倪。錄音處理架構(gòu)最重要的一步就是應(yīng)用AutoScaling和Lambda，使錄音處理獲得了高可用性、大容量、高彈性，并且解決掉錄音會(huì)丟失情況，同時(shí)極大地降低了錄音生成時(shí)間以及成本。

圖4第一代錄音處理架構(gòu)

　　在第一代錄音處理架構(gòu)中，錄音是從CTI-Cloud平臺(tái)的sip-media模塊產(chǎn)生，經(jīng)過(guò)彈性負(fù)載均衡器（ELB）轉(zhuǎn)到media-zip錄音壓縮處理模塊進(jìn)行處理，最后將所有wav文件和處理后的mp3文件上傳到S3.

　　該架構(gòu)最大的缺點(diǎn)是無(wú)彈性，需要預(yù)置media-zip的個(gè)數(shù)，當(dāng)出現(xiàn)業(yè)務(wù)高峰時(shí)，錄音處理延時(shí)會(huì)加大，如果預(yù)置太多實(shí)例，就會(huì)在業(yè)務(wù)低谷時(shí)造成極大的浪費(fèi)。

 

圖5第二代錄音處理架構(gòu)

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

圖6無(wú)服務(wù)化-錄音處理架構(gòu)

　　在最新一代無(wú)服務(wù)化-錄音處理架構(gòu)中，使用Lambda函數(shù)替換了EC2實(shí)例彈性組。wav文件通過(guò)sip-media直接上傳到S3bucket上，省去中間彈性負(fù)載均衡的環(huán)節(jié)。在S3上通過(guò)配置事件驅(qū)動(dòng)啟動(dòng)Lambda，Lambda會(huì)獲取wav文件并轉(zhuǎn)換成mp3，然后上傳到S3bucket上，整個(gè)中間的處理全部實(shí)現(xiàn)無(wú)服務(wù)化。

　　該架構(gòu)有三個(gè)優(yōu)勢(shì)：更快的彈性、更可靠、更便宜，彈性響應(yīng)從5分鐘縮短到了1秒，錄音生成時(shí)間縮短到5秒之內(nèi)；實(shí)現(xiàn)自動(dòng)異常處理、先上傳后處理；從按照實(shí)例計(jì)費(fèi)變成按毫秒計(jì)費(fèi)。