企業(yè)通常希望公共云為許多應用程序類型提供靈活性、快速可擴展性和可靠性，但公共云并不完美。每個主要云計算提供商都經(jīng)歷過內(nèi)部系統(tǒng)或存儲以及外部資源（如網(wǎng)絡連接）的中斷。業(yè)務中斷對任何企業(yè)來說都是毀滅性的打擊，而云計算中斷也可能會影響數(shù)百個用戶的業(yè)務。

所有這些都凸顯了公共云計算的普遍現(xiàn)實：用戶需要采用災難恢復計劃，就像使用內(nèi)部部署數(shù)據(jù)中心一樣。制定計劃以及在出現(xiàn)云計算中斷時采取的措施可以減輕或加劇對企業(yè)的影響。人們需要考慮以下六個重要步驟，以平穩(wěn)度過公共云中斷。

步驟1：制定災難復原策略

應對云計算中斷的第一步是創(chuàng)建和實施災難恢復（DR）計劃，并在災難發(fā)生之前很長時間就將其部署到位。盡管云計算提供商提供了大量的服務和資源，但是用戶需要為每個工作負載創(chuàng)建、部署、配置和監(jiān)視這些服務和資源。

實際的災難恢復策略可能會根據(jù)工作負載的需求及其對企業(yè)的重要性而發(fā)生根本性的變化。日常應用程序可能非常適合常規(guī)數(shù)據(jù)備份和虛擬機快照到輔助位置，例如其他提供程序區(qū)域、另一個云計算提供程序甚至本地存儲資源。

高級災難恢復計劃可以使用已部署但在另一個區(qū)域處于空閑狀態(tài)的備用實例，并準備在主要實例中斷時接管。甚至更全面的災難恢復策略也可以包括分布式集群，該集群可以在多個云區(qū)域或可用性區(qū)域中運行重復的工作負載實例。例如，這種策略可以包括使用負載平衡器在多個實例之間分配流量，并在該區(qū)域發(fā)生云中斷時重定向流量。

這些復制工作的極端變化是多云災難恢復策略，其中工作負載跨兩個或多個云平臺（例如AWS和Microsoft Azure或Azure和谷歌云）進行冗余操作，以防止云計算中斷的可能性。

步驟2：溝通并實現(xiàn)云計算透明

當事情發(fā)生變化時，需要了解云中發(fā)生了什么。傳統(tǒng)上，云計算提供商對服務中斷一直不透明，但隨著企業(yè)將更有價值的工作負載委托給公共云，這種情況正在改變。企業(yè)需要更多的云計算透明性，提供商也在改善與用戶的通信，提供有關中斷性質(zhì)及其當前狀態(tài)的更及時的見解。

例如，AWS公共云提供的服務運行狀況儀表板顯示了所有服務的當前狀態(tài)，而微軟Azure公共云提供了類似的“Azure狀態(tài)”頁面。災難恢復決策可以取決于企業(yè)對災難及其嚴重性的理解，提供商對災難持續(xù)時間的估計——所有這些都可以隨著云計算透明度的提高而改善。

但是不要停留在那里。業(yè)務和用戶群取決于受影響的工作負載，因此，將中斷的詳細信息傳達給內(nèi)部用戶或客戶也同樣重要。通知他們停機、停機對工作負載的影響以及為解決停機而采取的步驟。

步驟3：確定災難恢復計劃的業(yè)務價值

確定需要執(zhí)行什么來實施災難恢復計劃。有些計劃是自動的。例如，重要的工作負載通常通過某種類型的集群來保護，即使節(jié)點（或?qū)嵗┌l(fā)生故障，集群也應繼續(xù)運行。但是，針對次要工作負載的災難恢復策略可能需要人為干預或分散步驟，例如恢復和重新啟動快照或切換到備份實例。

如果需要人為干預，需要考慮恢復過程中涉及的工作和費用，并確定啟動恢復的業(yè)務價值。詢問恢復工作負載是否會比只是等待云計算提供商解決中斷所需的時間更長且成本更高。來自云計算提供商的通信將會顯著影響這一決定。

步驟4：實施災難恢復計劃

在許多情況下，關鍵任務災難恢復計劃可能是完全自動化的，并且管理人員可能無需采取任何有意的操作。例如，即使一個節(jié)點在云計算中斷期間變得不可用，跨越AWS云計算可用性區(qū)域或Azure云區(qū)域的集群也可能繼續(xù)起作用。

但是，不太重要的工作負載可能需要采取有計劃的行動。采用準備好的腳本、模板或其他資源，以協(xié)調(diào)適當?shù)臑碾y恢復響應。當企業(yè)決定啟動需要人為干預的災難恢復計劃時，管理員必須立即采取行動。這可能包括在云計算中斷期間從快照重新啟動或?qū)⒘髁恐囟ㄏ虻絺溆脤嵗?/p>

災難恢復計劃需要定期測試。執(zhí)行測試演練，以確保適當?shù)倪^程和資源來推動工作負載恢復。測試還驗證相關資源的配置，例如IP地址以及相關的驅(qū)動程序和相關性。如果恢復在常規(guī)測試中正常運行，則很可能在實際災難恢復情況下正常運行。

步驟5：監(jiān)控災難復原策略

無論實施災難恢復策略所涉及的工作量或自動化程度如何，驗證已恢復的工作負載是否正常運行仍然很重要。管理人員應將以災難恢復狀態(tài)運行的工作負載的性能與在正常條件下運行的相同工作負載的性能進行比較。

應用程序監(jiān)視工具（例如Amazon CloudWatch和Google Stackdriver）著眼于工作負載運行狀況。這些工具還收集日志、指標和事件，以中繼有關已恢復工作負載的操作數(shù)據(jù)。此外，他們將在整個云計算中斷期間繼續(xù)監(jiān)視工作負載的性能和可用性。

步驟6：云計算中斷的事后評估

云計算中斷對企業(yè)來說可能會很痛苦，但不會一直持續(xù)下去。當云計算提供商解決其中斷并恢復正常的工作負載操作時，組織需要對事件進行事后評估，并評估其災難恢復響應。

企業(yè)還要考慮災難恢復計劃的效果如何，并根據(jù)需要調(diào)整計劃。這可能包括更改分配給應用程序的災難恢復保護級別，微調(diào)用于實施災難恢復程序的過程或其他可能減輕未來云計算中斷影響的更改。

來源：Stephen J. Bigelow