宕機事件對公司的業務、信譽、客戶體驗以及信任等方面所造成的代價從未如此高昂。由于考慮到軟件驅動業務的持續性和關聯性,客戶和用戶們越來越不能容忍災難和故障的發生。而某種服務的故障可能影響到其所有的用戶。同時多用戶平臺發生故障的破壞力越來越大,因為它影響到在平臺上運行其服務的所有服務供應商。
隨著對設計災難恢復方案的重視,企業容易關注如何防止大的災難和故障。這種難以預測的不尋常事件往往對服務的可用性帶來極其巨大的幾乎是災難性的影響。這種影響的范圍很廣,換言之,這種影響可能延長服務發生災難的持續時間,也可能增加數據丟失的數量。這種影響規模巨大,而那些較輕的不太常發生的宕機事件就可能被忽略。
企業需要注意判定、發現和防止那些發生頻率越來越高的小故障。這些小的宕機事件可能會隨著時間的推移而累積,并且會完全破壞服務可用性的目標。對于災難恢復而言,可用的選擇包括本地的災難恢復解決方案,也可以是基于云的災難恢復方案,后者利用的是一些大型的云運營商的基礎架構和平臺的功能。
小宕機事件的代價容易累積。頻繁的宕機可能會增加大量用戶受影響的可能性。此外,同樣一個用戶被故障或宕機時間重復影響的可能性也會增加。這種頻繁的宕機會破壞對服務的信任。反復的宕機時間會令人經常感覺到不快。客戶可能會不再增加業務的規模,甚至決定不再續約。依賴每月帶來收入或每年帶來收入的SaaS業務極易受到頻繁的小型宕機事件的影響。
如果企業謀求針對重大和小型的宕機事件形成彈性,不妨重視形成和維護如下方面的能力。
提供通信服務的所有關鍵系統都應持續不斷地備份。除了以一種REST的方式設計外,這些服務所生成、更新和維護的數據都應連續地備份到本地集中化的或是基于云的災難恢復系統中。在不影響服務質量和系統的前提下,應盡可能地頻繁備份。同時,備份應是遞增的,基于快照的,以提供靈活性和在任何時間和任何宕機事件中恢復的能力。此外,備份應是多層級的,以確保備份系統不會受到影響主要系統的相同故障的影響。
企業應當持續地監視提供通信服務的所有關鍵系統。這對于確保盡快地檢測故障或災難并立即實施災難恢復至關重要。與備份類似,在實施監視時,如果同樣的故障已影響了主要的服務,就不能在這種系統上實施。同樣,客戶的反饋系統也需要監視,以獲得故障報告。在報告開始到達或在監視系統發出故障警告時,應確認故障并實施災難恢復。
在檢測到災難、生成報告并確認時,就應啟動失效轉移過程,啟用新服務器從而繼續提供通信服務。這種失效轉移的完成是經由確保新服務器承擔受宕機影響的服務器的角色而實現的。
管理員應當對失效轉移服務器進行配置,使其能夠訪問通信服務狀態和信息的備份。
在宕機時間結束并且主要服務環境中的底層問題被診斷、修復、確認修復后,自動恢復過程應當將所有的服務恢復到主要環境中。在確認自動恢復過程成功后,自動恢復服務器即可被回收再利用。
很多管理員認為并未實現服務的可用性,并承認在過去的一年中經歷過不少宕機事件。宕機的頻發要求認真規劃和設計,只有這樣才能減輕其威脅,并且確保快速的恢復。企業面臨很多選擇,應當認真評估和選擇最適合自己需要的方案,并確保檢測不可預料的宕機事件的敏捷性和快捷恢復。