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

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

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

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

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

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

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

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

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

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