今天，最为本次分享的最后一期，作者将集中作答大家前期提出的问题。

　　问答环节

　　基于传统数据中心和物理服务器，我们能够计算出Genesys是可以保证您每一年是99.999%，也就是大概实际一年是五到六分钟这样的一个QS，这样的一个高可用度的。但是我们这样的一个系统，如果从传统的物理级的IDC机房迁移到云，会发现QS或者说HA的高可用度需要进行重新计算，也就是包括几个月前业界著名的公有云厂商在华北地区发生的大规模断网事件也直接影响到了我们的一些客户的平台。因为它的整体平台托管在这个云的华北区。那这个时候其实对于我们的应用系统而言，对于底层的IaaS层而言，发生这么一个剧变，是非常乏力的。

　　如果想做到高可用性的连续，这里面是有方案的，但是这些方案可能会相对来说代价会比较高。我简单介绍三种吧。第一种，就是说传统企业级那种HA我们依然不会在云上面使用，但是我们会怎样做？无论是基于SOA架构还是基于Microservice架构，我们在部署的时候，如果是公有云，我们会怎么做？我们会把一部分的服务放在不同的可用区，完全不同的可用区之间的这样的高可用性或者说Load Balance，这样能够保证什么？这样能够保证即便是某一个可用区发生问题时，我通过Load Balance或者HA的切换，我依然可以保证整体系统是可用的，这是第一种方案。第二种方案是在不同云厂商之间去做LoadBalance和HA，当然我相信这种成本会更高。如果是私有云化部署，实际上我们对于方案的选择而言，首先，对于私有云方案而言，我们一般来说会推荐客户尽量使用这种Cluster的方式，也就是说整体套件除了在私有云A上面部署之后，我会在本地的比如说一些在本地的IDC机房或者是另外一个私有云或者公有云上面我去做一个Disaster Recovery，Disaster Recovery的目的就是可以实现平滑的切换，但是它并不能保证实时的切换。我们知道如果是实时的切换，你的业务要求性越高，你的成本区就越高。基于我们大量的实践证明，如果是呼叫中心系统，我们可以做到一些紧急的应急方案，比如说当我的业务系统发生中断时，我是用电话系统进行托管，同时给我半小时到一小时的时间我能做紧急恢复。这种方案叫作disasterrecovery，如果你真想做到业务的平滑无损地切换，也是要做的是HA或者Load Balance。其实在不同成本角度考虑，是有不同的方案的。那当然了，还有一种比如说像基于传统的VMware VMotion或者说基于阿里云、华为云，无论是公有云还是专有云，都有这种时光镜像和快速恢复的方案，它是可以做到的。如果是基于微服务，其实相对来说会更加会困难一些。

　　首先对于数据库而言，我们可以天然地使用云端的数据库，而不是说在云端的ECS上去装一个数据库。这是呼叫中心上云的第一个前提，我不能因为上云的使用ECS，买了一台Windows或者是服务器，再去装一个商业版的数据库软件，这样上云的意义就不存在了。因为无论是BAT也好，华为也好，他们都会提供这种云端数据库。其实看企业的不同的喜好。目前我们能够看到的是有云端的MSSQL，也有云端的Postgre SQL，都是可以去进行支持的。如果客户说我宁愿自己去安装一套Postgre SQL或者安装一套Oracle，这个当然也是可以的。我们通过实际的脚本数据进行匹配表明，基于微软的MSSQL上云端的，比如说目前腾讯云、华为云和阿里云都提供这种云端MSC这种方式。它的业务适配度达到了99.95，也就是说只有部分非常少的功能会使用到MSC企业版中会使用到的ServiceBroker这样的一些东西。如果是Postgre SQL，它的适配度是100%，因为基本上来说是云原生的，这是第一个方面。

　　第二个是存储。对于存储而言，我们会存在一个问题就是，如果是呼叫中心的存储，会有一个在逻辑架构设计的不同，就是呼叫中心的存储大概会有NAS级的存储，也会有面向对象的存储，但是面向对象的存储通过我们的实践表明，它并不是为了像呼叫中心这种高容量、高并发的场景而去设计和存在的。简单来说就是，当我使用到录音的时候，会产生大量的录音和大量的报表数据。当我进行存储，我们会发现存储实际上是很乏力的。需要去做一些接口的适配，或者是采用云端非面向对象型的存储，而是采用高性能的存储方式能够去解决。这方面我们也是在持续地关注，在于后续而言，我们可能通过接口方式的变更和负载均衡的使用能够进一步对存储进行一些优化。目前我们实际上在两种云上面都已经做了这样的录音的云端的部署，也是没有什么问题的。一种方式是通过直接的对象存储，通过接口更改的方式，另一种方式是直接存入ECS的自带硬盘，然后紧接着去做转储这样的方式，会更加得便捷。Genesys录音也提供一个标准的功能，就是说我的录音可以提供标准的单声道、多声道、MP3或者WAV的方式，方便云端系统进行转译和相应的后续的一些处理，包括智能质检。

　　报表的定制化方案中是分成两块。首先，如果您这边指的是实时报表和历史报表，他讲的可能是历史报表吧。如果是历史报表，是天然地支持定制化开发的。当然，您完全可以使用基于我们的RawData，也就是元数据的方式来进行二次开发。在这里面做定制化开发是没有问题的，那具体的个性化解决方案中，我们本身系统是自带了很多套模板。当然我们可以根据您的系统去做二次开发。

　　包括这里面比如说，我的历史报表、历史商业报表可以与您的业务系统数据进行交互，甚至如果您的数据是云端的Salesforce数据，我可以直接通过Salesforce接口直接进行数据的获取。它可以做到完全的定制化的开发。

　　NPS净推荐值，一般来说通常的模式是，我们需要根据您的具体业务场景来进行深入的了解。可能简单来说，它并不是说是某一种技术方案，而是说结合您的场景去做一些数据的分析，一些量化的分析之后才能给出一些比较好的方案。那这个具体需求可能我们线下去了解会比较合适。

　　对于您说的大座席需求，我可能理解为是，海量座席如何去提高净推荐值？第一点是我们可以通过你的一手数据，您的IVR和路由数据，去做很多的买点。第二个，我是可以对你的座席进行画像。通过座席的画像来去对座席进行360度的打分。能够看出您座席的不足，然后去进一步帮助座席改善技能。当然我们还是需要考虑很多产品和业务方面的一些需求。这个不是一个简单可以一两句话就能解决的问题。