今天，最為本次分享的最后一期，作者將集中作答大家前期提出的問題。

　　問答環(huán)節(jié)

　　Q1如何保證云呼叫中心的網(wǎng)絡安全和業(yè)務不斷？

　　基于傳統(tǒng)數(shù)據(jù)中心和物理服務器，我們能夠計算出Genesys是可以保證您每一年是99.999%，也就是大概實際一年是五到六分鐘這樣的一個QS，這樣的一個高可用度的。但是我們這樣的一個系統(tǒng)，如果從傳統(tǒng)的物理級的IDC機房遷移到云，會發(fā)現(xiàn)QS或者說HA的高可用度需要進行重新計算，也就是包括幾個月前業(yè)界著名的公有云廠商在華北地區(qū)發(fā)生的大規(guī)模斷網(wǎng)事件也直接影響到了我們的一些客戶的平臺。因為它的整體平臺托管在這個云的華北區(qū)。那這個時候其實對于我們的應用系統(tǒng)而言，對于底層的IaaS層而言，發(fā)生這么一個劇變，是非常乏力的。

　　如果想做到高可用性的連續(xù)，這里面是有方案的，但是這些方案可能會相對來說代價會比較高。我簡單介紹三種吧。第一種，就是說傳統(tǒng)企業(yè)級那種HA我們依然不會在云上面使用，但是我們會怎樣做？無論是基于SOA架構還是基于Microservice架構，我們在部署的時候，如果是公有云，我們會怎么做？我們會把一部分的服務放在不同的可用區(qū)，完全不同的可用區(qū)之間的這樣的高可用性或者說Load Balance，這樣能夠保證什么？這樣能夠保證即便是某一個可用區(qū)發(fā)生問題時，我通過Load Balance或者HA的切換，我依然可以保證整體系統(tǒng)是可用的，這是第一種方案。第二種方案是在不同云廠商之間去做LoadBalance和HA，當然我相信這種成本會更高。如果是私有云化部署，實際上我們對于方案的選擇而言，首先，對于私有云方案而言，我們一般來說會推薦客戶盡量使用這種Cluster的方式，也就是說整體套件除了在私有云A上面部署之后，我會在本地的比如說一些在本地的IDC機房或者是另外一個私有云或者公有云上面我去做一個Disaster Recovery，Disaster Recovery的目的就是可以實現(xiàn)平滑的切換，但是它并不能保證實時的切換。我們知道如果是實時的切換，你的業(yè)務要求性越高，你的成本區(qū)就越高?；谖覀兇罅康膶嵺`證明，如果是呼叫中心系統(tǒng)，我們可以做到一些緊急的應急方案，比如說當我的業(yè)務系統(tǒng)發(fā)生中斷時，我是用電話系統(tǒng)進行托管，同時給我半小時到一小時的時間我能做緊急恢復。這種方案叫作disasterrecovery，如果你真想做到業(yè)務的平滑無損地切換，也是要做的是HA或者Load Balance。其實在不同成本角度考慮，是有不同的方案的。那當然了，還有一種比如說像基于傳統(tǒng)的VMware VMotion或者說基于阿里云、華為云，無論是公有云還是專有云，都有這種時光鏡像和快速恢復的方案，它是可以做到的。如果是基于微服務，其實相對來說會更加會困難一些。

　　Q2呼叫中心上云已經(jīng)支持到何種程度了？目前的實體機部署的方式對應的數(shù)據(jù)庫存儲如何遷移到云上？是否已經(jīng)支持Docker方式進行部署了？

　　首先對于數(shù)據(jù)庫而言，我們可以天然地使用云端的數(shù)據(jù)庫，而不是說在云端的ECS上去裝一個數(shù)據(jù)庫。這是呼叫中心上云的第一個前提，我不能因為上云的使用ECS，買了一臺Windows或者是服務器，再去裝一個商業(yè)版的數(shù)據(jù)庫軟件，這樣上云的意義就不存在了。因為無論是BAT也好，華為也好，他們都會提供這種云端數(shù)據(jù)庫。其實看企業(yè)的不同的喜好。目前我們能夠看到的是有云端的MSSQL，也有云端的Postgre SQL，都是可以去進行支持的。如果客戶說我寧愿自己去安裝一套Postgre SQL或者安裝一套Oracle，這個當然也是可以的。我們通過實際的腳本數(shù)據(jù)進行匹配表明，基于微軟的MSSQL上云端的，比如說目前騰訊云、華為云和阿里云都提供這種云端MSC這種方式。它的業(yè)務適配度達到了99.95，也就是說只有部分非常少的功能會使用到MSC企業(yè)版中會使用到的ServiceBroker這樣的一些東西。如果是Postgre SQL，它的適配度是100%，因為基本上來說是云原生的，這是第一個方面。

　　第二個是存儲。對于存儲而言，我們會存在一個問題就是，如果是呼叫中心的存儲，會有一個在邏輯架構設計的不同，就是呼叫中心的存儲大概會有NAS級的存儲，也會有面向?qū)ο蟮拇鎯?，但是面向?qū)ο蟮拇鎯νㄟ^我們的實踐表明，它并不是為了像呼叫中心這種高容量、高并發(fā)的場景而去設計和存在的。簡單來說就是，當我使用到錄音的時候，會產(chǎn)生大量的錄音和大量的報表數(shù)據(jù)。當我進行存儲，我們會發(fā)現(xiàn)存儲實際上是很乏力的。需要去做一些接口的適配，或者是采用云端非面向?qū)ο笮偷拇鎯Γ遣捎酶咝阅艿拇鎯Ψ绞侥軌蛉ソ鉀Q。這方面我們也是在持續(xù)地關注，在于后續(xù)而言，我們可能通過接口方式的變更和負載均衡的使用能夠進一步對存儲進行一些優(yōu)化。目前我們實際上在兩種云上面都已經(jīng)做了這樣的錄音的云端的部署，也是沒有什么問題的。一種方式是通過直接的對象存儲，通過接口更改的方式，另一種方式是直接存入ECS的自帶硬盤，然后緊接著去做轉儲這樣的方式，會更加得便捷。Genesys錄音也提供一個標準的功能，就是說我的錄音可以提供標準的單聲道、多聲道、MP3或者WAV的方式，方便云端系統(tǒng)進行轉譯和相應的后續(xù)的一些處理，包括智能質(zhì)檢。 　　Q3報表的個性化解決方案中，Genesys會有定制化開發(fā)的可能嗎？

　　報表的定制化方案中是分成兩塊。首先，如果您這邊指的是實時報表和歷史報表，他講的可能是歷史報表吧。如果是歷史報表，是天然地支持定制化開發(fā)的。當然，您完全可以使用基于我們的RawData，也就是元數(shù)據(jù)的方式來進行二次開發(fā)。在這里面做定制化開發(fā)是沒有問題的，那具體的個性化解決方案中，我們本身系統(tǒng)是自帶了很多套模板。當然我們可以根據(jù)您的系統(tǒng)去做二次開發(fā)。

　　包括這里面比如說，我的歷史報表、歷史商業(yè)報表可以與您的業(yè)務系統(tǒng)數(shù)據(jù)進行交互，甚至如果您的數(shù)據(jù)是云端的Salesforce數(shù)據(jù)，我可以直接通過Salesforce接口直接進行數(shù)據(jù)的獲取。它可以做到完全的定制化的開發(fā)。

　　Q4是在大座席需求中，NPS凈推薦值，Genesys是如何提供給客戶解決方案的？

　　NPS凈推薦值，一般來說通常的模式是，我們需要根據(jù)您的具體業(yè)務場景來進行深入的了解?？赡芎唵蝸碚f，它并不是說是某一種技術方案，而是說結合您的場景去做一些數(shù)據(jù)的分析，一些量化的分析之后才能給出一些比較好的方案。那這個具體需求可能我們線下去了解會比較合適。

　　對于您說的大座席需求，我可能理解為是，海量座席如何去提高凈推薦值？第一點是我們可以通過你的一手數(shù)據(jù)，您的IVR和路由數(shù)據(jù)，去做很多的買點。第二個，我是可以對你的座席進行畫像。通過座席的畫像來去對座席進行360度的打分。能夠看出您座席的不足，然后去進一步幫助座席改善技能。當然我們還是需要考慮很多產(chǎn)品和業(yè)務方面的一些需求。這個不是一個簡單可以一兩句話就能解決的問題。