我們今天要討論的是故障恢復，它是確保基于云或托管型呼叫中心的高可靠性服務的重要支柱之一。需要注意的是，應該如何防止故障和災難演變成服務的損失呢？用戶/服務供應商應向廠商提出哪些要求呢？

在如今高度發達的社會中，我們有穩定的公共資源供應：干凈的水、電、互聯網。當這些系統中斷時，我們會感到驚訝和憤怒：不能喝茶、沒有照明、網絡連接也中斷了。這樣的局面令人無法忍受。

對呼叫中心來說，核心的云/托管服務如IP帶寬、電話、呼叫控制等的中斷帶來的危害無法用不便”二字概括。它會導致糟糕的客戶服務、收入下降和名譽損失。

雖然100％的正常運行時間是最理想的，但是呼叫中心工作的實時處理性質使這個目標幾乎不可能實現。為什么呢？

此外，現實情況是，如果沒有整體全面的預算的話，大多數用戶是可以期待超高的正常運行時間的。配件的定期更換，硬件、網絡、電源、語音載體等故障都可以帶來較低的正常運行時間。

從軟件角度來看，故障通常是由某種形式的中斷造成的：

計劃性的——如果一個軟件平臺并沒有根據高速寫入升級而設計，那么升級就可能耗費數十分鐘，甚至數小時。不利于高可用性”系統。

非計劃性的——在系統某處出現故障；這些是可以預見的，如資源缺乏（內存、磁盤空間等）。通過精心規劃和相應的系統監測，這些故障是可以消除的。還有一些其他的故障無法預知、但卻不可避免。它們波及面很廣，從個別組件（例如硬盤、網絡交換機、媒體網關）到重大自然災害（如地震、海嘯）。

對于任何提供高可用性系統的供應商/服務供應商來說，核心問題是：如何預防故障和災難演化為服務的損失？

關鍵是通過服務的復制，消除單點故障”，也就是軟件冗余。但是，這也存在一定的問題。

理想狀況是，每個服務都有熱備份”——這是一個備用服務，它不間斷運行，監控主要服務的狀態。如果失敗，所有備用部分和資源都能實現無縫切換。這是全球網絡和其他運營商網絡的基礎。不過，雖然它適用于呼叫中心的許多流程，但是它卻無法應用于實時的處理工作（如會議/語音流量的記錄或者撥號器/ ACD測量）。實時化意味著一切都處于快速變化之中，無法完全遵照磁盤內容。因此，如果處理服務失敗，資源的簡單切換和正常業務的恢復也就無法進行了。當前會話結束或者備份撥號服務速度加快時，服務質量會暫時降低，備份系統會重新建立服務。

另一種是冷備份”。在這個模式中，每個服務的副本都被保存在一個單獨的系統中（可能是虛擬存儲器，一個完全不同的服務器，甚至位于不同的大陸），能在必要時立刻投入使用。

但是我們如何判斷何時是必要的”？為了實現高可用性，被動的等待故障的出現是不夠的。必須立即采取行動。這就需要持續的監控，不斷監測周圍服務的狀態。如果無法正常工作，控制功能就需要啟動備用服務。（順便說一句，每個服務都必須有一個備份。正如Juvenal所問：誰來監督監督者？”）

另一個挑戰是，當主服務器故障時，它會有一個特定的狀態。備用服務器必須被初始化，使用相同的設置，包括安全性和許可證。這可以通過備用服務器或云端的配置文件副本實現。它必須時刻就緒，也許可以從最新的當前狀態”文件中獲取。最后，所有激活資源和路徑都會被轉換到備用服務器中。

平滑切換后，主服務器會發生什么？如果故障的原因是暫時的，自動重啟是最好的選擇，重置和重新連接資源以重新投入服務。如果不是這樣，則需要IT部門介入。

托管/基于云的呼叫中心服務的高可用性不是理所當然存在的。支持故障恢復的功能必須涉及到軟件的深度設計。它必須進行規劃，并以此為發展方向，以便真正做到服務的無縫對接。