所有這些都凸顯了公共云計算的普遍現實：用戶需要采用災難恢復計劃，就像使用內部部署數據中心一樣。制定計劃以及在出現云計算中斷時采取的措施可以減輕或加劇對企業的影響。人們需要考慮以下六個重要步驟，以平穩度過公共云中斷。
步驟1：制定災難復原策略
應對云計算中斷的第一步是創建和實施災難恢復(DR)計劃，并在災難發生之前很長時間就將其部署到位。盡管云計算提供商提供了大量的服務和資源，但是用戶需要為每個工作負載創建、部署、配置和監視這些服務和資源。
實際的災難恢復策略可能會根據工作負載的需求及其對企業的重要性而發生根本性的變化。日常應用程序可能非常適合常規數據備份和虛擬機快照到輔助位置，例如其他提供程序區域、另一個云計算提供程序甚至本地存儲資源。
高級災難恢復計劃可以使用已部署但在另一個區域處于空閑狀態的備用實例，并準備在主要實例中斷時接管。甚至更全面的災難恢復策略也可以包括分布式集群，該集群可以在多個云區域或可用性區域中運行重復的工作負載實例。例如，這種策略可以包括使用負載平衡器在多個實例之間分配流量，并在該區域發生云中斷時重定向流量。
這些復制工作的極端變化是多云災難恢復策略，其中工作負載跨兩個或多個云平臺(例如AWS和Microsoft Azure或Azure和谷歌云)進行冗余操作，以防止云計算中斷的可能性。
步驟2：溝通并實現云計算透明
當事情發生變化時，需要了解云中發生了什么。傳統上，云計算提供商對服務中斷一直不透明，但隨著企業將更有價值的工作負載委托給公共云，這種情況正在改變。企業需要更多的云計算透明性，提供商也在改善與用戶的通信，提供有關中斷性質及其當前狀態的更及時的見解。
例如，AWS公共云提供的服務運行狀況儀表板顯示了所有服務的當前狀態，而微軟Azure公共云提供了類似的“Azure狀態”頁面。災難恢復決策可以取決于企業對災難及其嚴重性的理解，提供商對災難持續時間的估計——所有這些都可以隨著云計算透明度的提高而改善。
但是不要停留在那里。業務和用戶群取決于受影響的工作負載，因此，將中斷的詳細信息傳達給內部用戶或客戶也同樣重要。通知他們停機、停機對工作負載的影響以及為解決停機而采取的步驟。
步驟3：確定災難恢復計劃的業務價值
確定需要執行什么來實施災難恢復計劃。有些計劃是自動的。例如，重要的工作負載通常通過某種類型的集群來保護，即使節點(或實例)發生故障，集群也應繼續運行。但是，針對次要工作負載的災難恢復策略可能需要人為干預或分散步驟，例如恢復和重新啟動快照或切換到備份實例。
如果需要人為干預，需要考慮恢復過程中涉及的工作和費用，并確定啟動恢復的業務價值。詢問恢復工作負載是否會比只是等待云計算提供商解決中斷所需的時間更長且成本更高。來自云計算提供商的通信將會顯著影響這一決定。
步驟4：實施災難恢復計劃
在許多情況下，關鍵任務災難恢復計劃可能是完全自動化的，并且管理人員可能無需采取任何有意的操作。例如，即使一個節點在云計算中斷期間變得不可用，跨越AWS云計算可用性區域或Azure云區域的集群也可能繼續起作用。
但是，不太重要的工作負載可能需要采取有計劃的行動。采用準備好的腳本、模板或其他資源，以協調適當的災難恢復響應。當企業決定啟動需要人為干預的災難恢復計劃時，管理員必須立即采取行動。這可能包括在云計算中斷期間從快照重新啟動或將流量重定向到備用實例。
災難恢復計劃需要定期測試。執行測試演練，以確保適當的過程和資源來推動工作負載恢復。測試還驗證相關資源的配置，例如IP地址以及相關的驅動程序和相關性。如果恢復在常規測試中正常運行，則很可能在實際災難恢復情況下正常運行。
步驟5：監控災難復原策略
無論實施災難恢復策略所涉及的工作量或自動化程度如何，驗證已恢復的工作負載是否正常運行仍然很重要。管理人員應將以災難恢復狀態運行的工作負載的性能與在正常條件下運行的相同工作負載的性能進行比較。
應用程序監視工具(例如Amazon CloudWatch和Google Stackdriver)著眼于工作負載運行狀況。這些工具還收集日志、指標和事件，以中繼有關已恢復工作負載的操作數據。此外，他們將在整個云計算中斷期間繼續監視工作負載的性能和可用性。
步驟6：云計算中斷的事后評估
云計算中斷對企業來說可能會很痛苦，但不會一直持續下去。當云計算提供商解決其中斷并恢復正常的工作負載操作時，組織需要對事件進行事后評估，并評估其災難恢復響應。
企業還要考慮災難恢復計劃的效果如何，并根據需要調整計劃。這可能包括更改分配給應用程序的災難恢復保護級別，微調用于實施災難恢復程序的過程或其他可能減輕未來云計算中斷影響的更改。
京公網安備 11010502049343號