摘要：某些時候，企業當然需要調用一套相應的災難恢復計劃，但該災難恢復計劃是否真的涵蓋了現代數字化的企業所需要的一切呢？無論企業對于突發事件的準備有多么全面，也不可能會有一套災難恢復計劃是能夠完美的應付各種不測的。正如分析機構Gartner所指出的那樣：“想要完全避免所有一切的災難風險的威脅是不可能的。”

無論企業對于突發事件的準備有多么全面，也不可能會有一套災難恢復計劃是能夠完美的應付各種不測的。正如分析機構Gartner所指出的那樣：“想要完全避免所有一切的災難風險的威脅是不可能的。”

但是，如果企業有一套明確的行動計劃的話，那么某些停機中斷事故其實是可以避免的，或者至少可以說，可以盡量減輕其所帶來的影響。在Computer Weekly網站最新一次的CW500俱樂部活動上，與會的IT領導人們共同交流了關于他們及其同行在處理和應對災害事件時的真實經歷。

“我們為客戶提供了食物餐點的鏈接，但如果人們不能下訂單的話，對我們來說無疑是一大災難。”在線外賣服務供應商Just Eat公司的技術經理Amarpal Attwal表示說。

“我所經歷的第一次災難事件是：由于丹麥的一處數據中心的服務器出現超載，導致我們所有網站的出現癱瘓。”他說。這個問題是源于容量規劃所造成的。Attwal承認，該公司在其數據中心業務運營方面，還沒有足夠的靈活敏捷性。

對于Just Eat公司而言，另一種形式的災難是：企業工作人員無法連接到內部工具。他所經歷的第二次災難事件是發生在該公司英國總部的一次電力故障，此次故障的影響更大。“英國總部是所有其他國家辦事處的樞紐。”他補充說。彼時，該公司沒有準備應對災害的計劃。

Attwal說，該公司不得不仔細排查其基礎設施，并在企業業務層面創建了一套關于如何針對災難場景及其成本影響進行應對的框架概述。他說：“我們需要從一個災難恢復的視角來了解什么對我們來說是最為重要的，最終，我們建立起了一套涉及企業整個系統的架構。”

其所帶來的結果是，雖然該公司仍然在丹麥運營其數據中心，但Just Eat公司現在實施了cloud native。Atwall說：“我們已經把一切工作負載均遷移到了亞馬遜網絡服務(AWS)，不僅僅是我們的電子商務平臺，同時也包括我們的企業基礎設施。”

正是由于在亞馬遜網絡服務上部署了公司的網站和業務系統，Just Eat現在已經從企業的辦公室中移除了物理服務器。其結果是各個的辦事處都連接到同一個核心。“我們也是SaaS (軟件即服務)的忠實粉絲——我們要保護我們的數據，并盡量減少故障運行失敗。”Attwal補充道。

Just Eat采用了一個預期失敗的政策，并以該方式架構其云系統。IT團隊使用了一款開源的工具稱為Chaos Monkey，該工具最初是由Netflix開發的，目的旨在能夠在AWS系統組件中故意造成故障以測試反應，并學習如何防止他們擾亂整個操作。

在處理數據中心災難的最佳實踐方面，Attwal說：“實踐就是一切。我們在我們的備災方案中引入了這一概念，例如，所有人都無法登錄的話。我們該怎么辦?于是，我們選擇了處理場景模擬的理論，然后付諸實際的運行。”這樣的模擬情況應定期運行，而不是一年一次。

考慮人的因素

Attwal說，企業往往忽視了災難恢復(DR)規劃：“我們對于發生某些相關場景的應對規劃還沒有引起高度重視，例如，如果有20名員工同時離開公司，應如何處理。”為了解決這些模擬場景，Just Eat公司舉辦了一些圓桌討論會，以便讓員工們廣泛的探討和分享他們的專業知識。

為了避免所有的專業知識訣竅只被一個人了解，Just Eat組成了一個專門的項目團隊。Attwal說：“我們更注重目標，并組織了一個專門的團隊，這可以幫助降低風險。”

在投資管理公司Brewin Dolphin的業務連續性的負責人柯克·蘭利也認為，人的元素在災害管理中往往被忽視了。

“跨部門的協作是一項相當艱巨的任務。我曾經在許多企業工作過，負責業務連續性的人員與企業的IT人員往往在相互間形成了孤島。”他說。

蘭利認為，業務連續性專家需要了解關于IT的合理人數配額：“在任何類型的企業，你都會發現有人會掐你的團隊。如果你在關鍵團隊失去了一名理財規劃師;或者在金融服務團隊失去了一名投資經理，這固然是一個商業問題，但這同時也是一個IT問題，因為你必須使用IT向所有的客戶分配一個新的投資經理。”

就算總部發生災難，靈活的工作團隊也可以使企業的業務繼續保持正常運行進行。但正如Just Eat的Attwal所指出的那樣：“沒有什么比面對面的互動是更好的溝通交流模式了。”不要讓同一間辦公室的人也會妨礙規劃，特別是在災難中的早期階段，關鍵負責人員需要一步一步的協調各個流程，這需要調用該公司的災難恢復策略。

隨著企業越來越多地使用專用的數據中心和云服務，因此，在正確的時間和正確的職位上安置關鍵人員就顯得是至關重要的。戴爾軟件系統顧問的高級經理阿德里安·莫爾說：“讓20個人在一個數據中心，圍著大約四臺機架并嘗試一起做一切工作是很難的。你企業的災難恢復中心實際上是一處辦公室，那里才應該是您企業專業天才人員和輔助硬件所在。”

莫爾認為，數據中心災難恢復計劃往往沒有顧及關鍵IT人員的因素：“很多人都忘了為業務部門提供服務，并確保業務部門積極和富有成效的工作的IT部門的同事。”

他說，雖然企業經常會主動的進行彈性數據中心運行，但IT部門往往忘了究竟是誰需要訪問數據中心：“想想看，有多少被訪問設備和應用程序需要執行災難恢復計劃。”

精心策劃

當系統開啟并運行時，沒有人會表示擔心，人們只會在系統出現故障時才注意到。然后，企業的業務部門就會不斷的詢問：“我們如何才能盡快恢復并再次運行?”這是一個關鍵性的問題，全國建設協會災難恢復部門負責人詹姆斯·洛奇說。

他說：“在任何特定的某些時刻，許多企業都很難確定一款關鍵系統將需要多長時間來恢復。”他說。當系統出現故障時，其再次啟動和運行的時間并不能總是可以準確估計的。

一家典型的銀行將需要運行三種類型的系統，洛奇說。保持與客戶互動的系統;業務系統等進行銷售處理;數據中心及其系統。顯然，有些系統在不同的時間內對業務會有更大的可視性。

“如果當所有其他的系統均正常運行時，銷售系統發生故障，那么，較之發生一次更廣泛的數據中心故障，其會具備較高的優先級。”洛奇說。業務連續性專家需要考慮的另一個因素是，關鍵系統將隨著時間的不同而改變。例如，電子郵件系統中白天的工作時間往往比在夜間下班時間更重要。

在他所使用的這個災難恢復模型中(見下圖表)，洛奇為任何給定的業務系統恢復正常運作規定了時限，指定其如果發生故障需要多長時間恢復。

從災難恢復的角度來看，數據中心的核心組件，如網絡或Active Directory軟件是一樣重要的，因為它們會影響業務正常運行的能力。不幸的是，其往往是難以準確估計整個數據中心需要多長時間才能重新聯機。

傳統上，當一處數據中心發生中斷后，讓一切業務重新恢復正常運營估計大約需要24到48小時。洛奇說，但通過將數據中心分割成各個組成成分，有可能對于企業的恢復時間做出更準確的評估。“這是對數據中心建立更精細的恢復的一種方法。”他說。

自上而下的策略

根據Gartner的分析師介紹，企業災難恢復策略問題的產生是因為災難恢復規劃并不是從企業整體戰略角度出發，并排序適當的優先事項和目標自上而下建立的。舉例來說，Just Eat公司就只是建立了一個框架，用于處理未來的事件。

這種策略需要明確規定：關鍵責任人必須在何處待崗——特別是如果數據中心系統需要重新啟動時。顯然，這些人員需要訪問業務連續性站點并必須在重啟系統時具備系統的訪問權限。這涉及到業務連續性管理者對于所需專業IT人員的充分理解。

雖然系統儀表板將就相關問題提醒IT團隊，但企業內部的其他部門可能也需要被迅速提醒，尤其是在當前客戶一旦在網站或移動App遇到問題是，他們會第一時間將問題發布到社交媒體。“通常情況下，客戶可能會意識到發生了一次中斷事故，并會在八分鐘內開始將這些消息發表到社交媒體。”洛奇說。

因此他建議企業要主動和積極的管理Twitter等社會媒體。根據企業類型的不同，社交媒體監測和團隊管理媒體是必不可少的手段，洛奇說。

沒有人能充分保護主要系統不會發生任何故障。但是，正如洛奇所指出的那樣：“由此所帶來的企業聲譽的損害可能會遠遠大于企業的實際經濟損失。”因此，現代企業災難恢復策略需要包括的不僅僅是讓IT系統迅速重新聯機。