針對復原進行設計
 工作負載必須能夠預測大部分的失敗並且復原，盡可能減少使用者體驗和營運目標的中斷。 |
|---|
即使是高度復原的系統也需要在架構設計和工作負載作業中採用災害準備方法。 在資料圖層上，您應該有策略可在損毀時修復工作負載狀態。
範例案例
Contoso 目前在內部部署 SQL Server 資料庫上裝載大量資料，最近已使用 Azure 服務將其分析解決方案現代化。
新的分析解決方案會利用 Azure Analysis Services、Azure Data Factory、Azure Synapse Analytics、Power BI 和 Azure 虛擬機器。 解決方案的所有使用者都是內部的。 考慮解決方案的可用性需求之後，小組會決定在單一區域中實作解決方案。
資料是使用 Azure Data Factory 進行擷取的，並在儲存至 Analysis Services 儲存體之前進行處理。 此程序的一部分需要部署至雲端中 VM 的舊版 Windows 程序。
針對災害做好準備
已結構化、測試和記載與交涉復原目標相符的復原計劃。 除了整個系統之外，計劃還必須涵蓋所有元件。
定義完善的程序可導致快速復原，防止對企業財務和信譽產生負面影響。 進行定期復原演練來測試復原系統元件、資料和容錯移轉與容錯回復步驟的程序，以避免在時間和資料完整性是成功的關鍵量值時發生混淆。
Contoso 的挑戰
- 解決方案只會在內部使用，而且不會被視為任務關鍵性。 因此，工作負載小組和商務專案關係人一致認為，在部署解決方案的 Azure 區域遺失或整個解決方案因其他原因而無法使用的情況下，在次要區域中重建解決方案是足夠的復原模式。
- 工作負載小組描述如何在 DR 計劃中的另一個區域中建置解決方案，但尚未有機會執行完整的 DR 演練。
套用方法和結果
- 發生區域性中斷之後，DR 回應小組能夠遵循 DR 計劃的指示，在另一個區域中重新部署分析解決方案。
- 小組會針對部署解決方案所需的部分作業探索 DR 計劃中的差距，並更新計劃，讓復原在未來更有效率。
- 工作負載小組和專案關係人同意加速規劃的 DR 測試，以確保更新的計劃能夠更有效率地復原。
處理具狀態資料
確定您可以修復復原目標內所有具狀態元件的資料。
備份是讓系統回到工作狀態的必要條件，方法是使用受信任的復原點，例如最後已知的良好狀態。
固定且交易一致的備份可確保無法改變資料，而且還原的資料不會損毀。
Contoso 的挑戰
- 工作負載小組決定將 SQL 資料庫移至 Azure，以減少分析處理時間。 VM 分析程序期間，其中一個資料庫會大量使用，因此小組必須確保資料庫狀態能夠以最低的可能 RPO 復原。
套用方法和結果
- 由於資料庫的大小都超過 4 TB，因此在短期內無法移轉至 Azure SQL Database。 因此，小組會移轉至執行 SQL Server 2022 的 Azure VM。
- 小組決定對所有資料庫使用「自動備份」功能，包括重要的資料庫，例如 VM 所使用的資料庫。
- 對於重要資料庫，小組計劃使用「自動備份」功能以及受控執行個體連結功能，主動將資料庫複寫至 Azure SQL 受控執行個體。
在設計中實作自動化自我修復功能
自我修復功能是一種機制，可讓工作負載的元件藉由復原受影響的元件，並視需要容錯移轉至備援基礎結構，自動解決問題。 使用設計模式，透過自我修復機制將復原功能新增至工作負載。
自我修復自動化可協助降低人為介入等外部因素的風險，並縮短協助修正週期。
Contoso 的挑戰
- 擷取資料最初部署到多個 VM 以提升可用性時，從 Azure Data Factory 叫用的 Windows 程序。
- 在某些情況下，舊版 Windows 程序當機，需要重新啟動 VM。 雖然整體處理時間受到的影響已是最小 (因為備援層級)，但小組想要實作可自動偵測失敗和復原的解決方案。
套用方法和結果
- 小組決定實作 Azure 虛擬機器擴展集解決方案，此解決方案已設定為部署應用程式健全狀況延伸模組，以持續監視 VM 程序的健康情況。
- 啟用自動執行個體修復後，擴展集現在可以藉由重新啟動 VM 或根據相同映像建立新的執行個體來修復元件。