一個呼叫中心至少應包括

　　傳統的擴展通常只意味這垂直擴展，通過增加現有硬件來完成。而彈性則是云計算的關鍵特性之一，真正具有彈性意味這軟件能夠按需擴展或者縮減，而且必須不受運行所處物理環境的限制。

　　除了個別自身對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并非是一個團隊，也不是一個智能，而是一種文化轉變，或者說是一種新的思考我們如何開發和發布軟件的方式。