一般来说，当一个企业的呼叫中心有了让云落地”这个想法时，就可以认为他们即将要走入几个大坑了...。。有时可能只是因为公司没有完全理解或采用新技术（或者被厂商忽悠）；有时是因为他们调过了必须的架构和设计调整步骤，直接奔向了部署模式；还有时是因为预期不太切实际，比如过于激进的交付日期、过于宏大的目标或错误的适用人群等。

　　出来混，迟早是要连本带上余额宝的利息一起还的。Be Nice~是我的工作信条。所以今天我本着耐撕”的名义，跟大家讨论几个常见的X事件，或者说是错误实践，或者是正确的错误。技术水平有限，读者笑出咖啡气出痘痘概不负责。

　　一个企业，自建呼叫中心的时候，往往被其实际的Capex+Opex给吓坏了。因为东西真的很多，Genesys的CTI套件真的只是其中很小的一块~~（当然，也是最重要的一块，没有之一！）。

　　一个呼叫中心至少应包括

　　传统的扩展通常只意味这垂直扩展，通过增加现有硬件来完成。而弹性则是云计算的关键特性之一，真正具有弹性意味这软件能够按需扩展或者缩减，而且必须不受运行所处物理环境的限制。

　　除了个别自身对IT理解很深而且养大牛的公司以外，很多公司对于呼叫中心上云的第一个入坑就是并非为了弹性，而仅仅是不想在管理和维护基础设施，其实他们此时此刻最喜欢的是托管解决方案。托管云理论上并不提供云计算的一些特性，比如弹性、可计量、按需服务以及资源池。托管只是在托管服务提供商出租用或购买基础设施和地面空间。

　　（敲黑板，其实确实有人是这么做的。）

　　当然，这比迁移至云中要简单啦，没有最好的方案，只有最适合的方案，开行就好。其实，刚才所说的是X事件中的第一事件：迁移至云端的结果实现。

　　对于已经开始讨论给既有呼叫中心上云的土豪客户们来说，他们要的是真云~嘿嘿，X事件中的第二事件来了：理想遭遇实际的期望管理。

　　我们需要搞清楚，上云的目的是什么，同时还要分析现有的东西还有哪些剩余价值和独有价值。并不是每一个问题都需要云计算来解决，实际上云在某些方面的实际效果往往不如客户的预料，或者至少目前不行。比如IaaS中的云端数据库，往往响应不能满足呼叫中心实时数据读写的要求，或者PaaS中去异构几个WebDAV+Storage，真是的效果还需要评估。

　　比如这里插播一个广告，即便您使用Genesys的企业网方案（没错，一般您在国内看见的都是Framework，那就是企业网方案）Genesys依然可以让您的呼叫中心部分上云，G厂新推出的G-hub方案就是方便企业级用户方便地接入社交媒体渠道，将各类Facebook/Twitter/Wechat等连入G-hub来统一加载。

　　上了云，我们的数据到底是更安全还是更不安全？这是X事件中的第三事件：对于云安全的错误认知。

　　在我看来，安全不是你买来的某种商铺，而是你必须在软件中计划和设计好的东西。根据Forrester的安全漏洞报告，真正的大头---75%的漏洞产生与企业内部，其中又有63%并非有意行为。对于此，实际上放在云是更安全了...

　　要想在呼叫中心上云后的安全竞争力，窍门就是知道安全风险在那里，然后通过技术、流程和监管的组合来应对这些风险，常见的技术有TLS加密，SIPs，Secure RTP等，常见的管理有分权分域（Role Based Access Control），常见的方式有自动化部署角色集，以及自动化补丁等。

　　现在的政府新闻在台风雷雨天经常会冒出一句：XXX已启动二级紧急预案...。”，同样的，在使用云服务时，企业应当做好这样的心里准备：一切皆有可能，故障是一定会发生的，不管企业选择的是哪种云服务模式，在某个时间点总会出问题。前不久北美Amazon的AWS-US-East数据中心被临时工”给搞挂了，结果全美都上千家大型公司都不能提供服务---其中包括部分部署在Genesys PureCloud云并没有买多点备份的客户们...。是的，X事件中的第四事件：服务中断及中断场景预案。

　　不要被SLA所迷惑，即便是AWS的99.95%的可用性也意味着每月20分钟或者一年4小时的宕机时间。

　　比如这里插播一个广告，在Genesys PureCloud云里，即便是云端出了问题（鬼知道那里的问题！也许是网站，也许是网络，也许是网线），我们的客户依然可以提前预防，通过在本地设置PureBridge网关，实现本地流量卸载的功能，真的，很神奇的，改天您可以找我们各地售前问问问。

　　源自《三体》中著名的黑暗森林理论：灭你，与你无关。呼叫中心上云，真正影响最大的可是这篇文章的读者们，X事件中的终极事件:低估给组织变革带来的影响。

　　在云中部署、监控和维护软件，可能会与组织当前处理这些任务的方式有着根本的不同。不管是开发人员、管理人员、服务人员或者其他任何角色，为了更好地完成工作，他们都需要对云计算有着深刻的认识，意味着他们需要对网络、安全等掌握丰富的知识。要知道，一个既熟悉旧有的遗留方案到全新云方案所有不同架构的人，真的很难找，也很难培养，也很贵啊！---不过你们可以来GU参加培训。

　　会不会有人说，别吹了，G厂自己也做云，那么对你们组织变革有影响呗？

　　这个时候，我一般会私信一个天窗，瞧瞧问一句：听说过DevOps没？

　　听G厂BJ研发中心大拿Fellow Wang说，G厂的研发已经改成DevOps模式了。仔细问了半天，用我通俗的语言说就是：研发和技术支持放一个部门了~开发的坑终于要被人怼了~可服务性已经变成了开发和支持一起设计的事情了。

　　其实很多时候DevOps并非是一个团队，也不是一个智能，而是一种文化转变，或者说是一种新的思考我们如何开发和发布软件的方式。