機房托管數(shù)據(jù)中心遭遇停電、宕機和非計劃性業(yè)務中斷的后果是十分嚴重的，一般托管數(shù)據(jù)中心的停機運行會影響該托管數(shù)據(jù)中心的流量下降50%以上，我們盡管在設計和運行托管數(shù)據(jù)中心時會努力避免各種事故的發(fā)生，但現(xiàn)有托管IDC機房設施并不能完全避免出現(xiàn)事故問題，其短期和長期的意外中斷都將是代價高昂的，另一方面如果我們因為事故風險選擇中斷放棄服務，企業(yè)可能會因為違反服務協(xié)議(SLA)而受到經(jīng)濟處罰，也將對企業(yè)的關鍵業(yè)務造成長期傷害，并使企業(yè)品牌形象蒙受極大損失。

從托管數(shù)據(jù)中心的角度來看，應該做什么或不應該做什么都無法完全避免潛在事故風險的發(fā)生，但這并不妨礙數(shù)據(jù)承接業(yè)務的日常運營，那么如果客戶已經(jīng)將主要數(shù)據(jù)運營放在托管中心，并和托管方進行了基本的事故模擬和風險預案，這樣就真的能夠面對所有最壞結果了嗎？答案是否定的。如果客戶發(fā)現(xiàn)自己已經(jīng)處在這種未知的情況下該怎么辦?如果發(fā)生未預料到的情況怎么辦？如果故障恢復失敗或耗時太長影響到了事故處理步驟和業(yè)務計劃性的安排如何處理？這一切都將取決于管理者對托管數(shù)據(jù)事故風險分析和戰(zhàn)略性的應對策略。

分散關鍵業(yè)務的集中度

以筆者單位為例，在制定關鍵業(yè)務應用戰(zhàn)略時，應避免將所有數(shù)據(jù)放在一處。同樣的道理，也避免將所有關鍵應用的服務程序放在同一區(qū)域，甚至同一托管方。同時要考慮在主要數(shù)據(jù)存放位置后，備份數(shù)據(jù)存放的位置以及和主要數(shù)據(jù)的物理關聯(lián)，然后逐步擴大到每個場景，并確定任何級別的故障將產(chǎn)生怎么樣的影響。當然在正常情況下，機房的數(shù)據(jù)動態(tài)是要記錄按天按周按月的日志并進行內控處理或者外部審計的，然而有時候，這種審查可能是由不完全了解自身托管數(shù)據(jù)中心和自身業(yè)務流如何運營的人員來完成。

因此，企業(yè)需要安排了解托管數(shù)據(jù)中心如何可靠運營的第三方專業(yè)人士進行審核，這些第三方審核通常會比托管人員自己識別的風險要容易得多，并且可以提供的信息更加豐富，在大多數(shù)情況下，與發(fā)生中斷事故的成本和運營成本相比，通過審查和驗證措施減輕風險的成本通常是最小的。

制定完善的多方備份戰(zhàn)略

企業(yè)一定要了解自己關鍵數(shù)據(jù)面臨的風險，并為最壞的情況做好策略上的準備。大多數(shù)IDC機房都配備替代的鏡像，可以處理最基本的災難恢復，以確保他們的客戶對運營幾乎沒有影響。同時大多數(shù)公司仍在追求在托管數(shù)據(jù)中心(托管數(shù)據(jù)中心，云計算或者內部部署)中部署雙活數(shù)據(jù)庫。雖然有些雙活部署接近成功，但在嘗試使用災難恢復備份時，其長時間的關鍵業(yè)務應用中斷卻讓人痛苦，最后的結果是數(shù)據(jù)庫沒有企業(yè)期望的那樣完整，數(shù)據(jù)丟失或應用程序在故障轉換期間受到不一致性的影響。

另一方面，如果是IDC托管提供商的計劃內停電或者中斷，在與IDC托管方簽訂合同時，必須提前承認雙方同意在什么情況將造成中斷。這一點至關重要，通常時候真正數(shù)據(jù)擁有者到時就會發(fā)現(xiàn)預想的協(xié)議往往并沒有涵蓋他們真實的想法。

制定危機模式下管理計劃

在事故真正發(fā)生的時候，托管數(shù)據(jù)中心的各方都進入危機模式，危機模式要有分不同等級的便于操作的應急預案，比如在不同程度的損壞下，允許什么級別的人，采取什么樣的步驟和順序以及應對的策略。

比如，企業(yè)要關心的一個重要問題就是，在危機模式期間誰可以訪問?誰來操作執(zhí)行關鍵業(yè)務的恢復和一致性處理，企業(yè)需要準確了解其在此期間那些數(shù)據(jù)可以訪問，可以更改，以及訪問權限，以及在訪問時允許執(zhí)行的操作。此外，還要知道在修復期間將采取什么額外的安全措施來保護其數(shù)據(jù)，數(shù)據(jù)有沒有外流，關鍵業(yè)務數(shù)據(jù)在危機模式之后和之前能不能保持一致性。

記錄文檔并進行評估和學習

記錄文檔不僅適用于發(fā)生事故的托管數(shù)據(jù)中心，而且適用于所有與數(shù)據(jù)業(yè)務有關聯(lián)的公司。

筆者在調查中發(fā)現(xiàn)，許多客戶沒有記錄他們的日常運營流程和程序。就算有記錄，也沒有規(guī)律性的進行更新。文檔對于在發(fā)生災難時做好準備至關重要，這其中包括：了解應用程序運行的位置，知道中斷哪些受到影響最大，誰需要了解更改等。因為在事故的評估過程中，大多數(shù)托管數(shù)據(jù)中心商都會告訴企業(yè)，系統(tǒng)是如何安裝的，以防止服務中斷。他們還給為企業(yè)提供滿意的客戶的推薦和參考。但他們通常不會告訴他們失敗的案例。要記錄文檔并了解過往的故障處理的失敗案例，要了解事故的細節(jié)，從中學習如何糾正以及采取了哪些步驟來防止再次發(fā)生事故。

慎重對待托管數(shù)據(jù)中心簽署的免責條款

如果企業(yè)對托管數(shù)據(jù)中心的故障恢復工作失去信心，請務必了解合約中的免責條款，這有助于企業(yè)順利地中止合作。確保合同沒有采用模糊的語言描述，避免被不合理的條款所限制。大多數(shù)托管數(shù)據(jù)中心的合同期限一般都為長期合同，托管數(shù)據(jù)中心市場的規(guī)模將擴大，新的廠商進入市場，雖然企業(yè)可能目前不會尋求采用新的托管數(shù)據(jù)中心，但應該不斷評估其他提供商。如果發(fā)生失敗，企業(yè)必須知道移動到新的解決方案的選擇，如果托管數(shù)據(jù)中心的故障處理和恢復工作花費的時間太長，那么后果可能會迫使相關業(yè)務停止線上運營，讓您所在的組織業(yè)務遭受巨大的損失，而又無法得到相關托管方對這部分關鍵業(yè)務的賠償。

規(guī)?；亟M建風險處理團隊

如今規(guī)?；亟M織運營托管數(shù)據(jù)業(yè)務，就必須規(guī)?；亟㈩A備團隊，團隊組織不但要熟知托管數(shù)據(jù)中心的知識，而且還要了解市場趨勢。通過詢問問題和閱讀報告，可以了解托管數(shù)據(jù)中心解決方案的各個方面情況。最重要的是，知道潛在的失敗點，了解什么情況可能導致中斷，人們都希望中斷或失敗永遠不會出現(xiàn)。

但是如果這樣做，企業(yè)必須為此規(guī)模化地組建風險處理團隊，最好的建議是在這些故障情況下制定計劃，并組建工作組團隊按部就班遵循這個計劃，團隊內部溝通對步驟實施準確和成功至關重要，因為人們在發(fā)生失敗可能會不耐煩，但團隊必須遵守嚴格執(zhí)行，并通過定期檢查這些重要領域，按團隊計劃性完成風險的分析和事故的預判，為管理者在中斷事故中的資源戰(zhàn)略調度提供有效性的建議。