我們今天要討論的是故障恢復，它是確?；谠苹蛲泄苄秃艚兄行牡母呖煽啃苑盏闹匾е?。需要注意的是，應該如何防止故障和災難演變成服務的損失呢？用戶/服務供應商應向廠商提出哪些要求呢？

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

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

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

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

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

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

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

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

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

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

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

但是我們?nèi)绾闻袛嗪螘r是必要的”？為了實現(xiàn)高可用性，被動的等待故障的出現(xiàn)是不夠的。必須立即采取行動。這就需要持續(xù)的監(jiān)控，不斷監(jiān)測周圍服務的狀態(tài)。如果無法正常工作，控制功能就需要啟動備用服務。（順便說一句，每個服務都必須有一個備份。正如Juvenal所問：誰來監(jiān)督監(jiān)督者？”）

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

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

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