復原設計
 工作負載必須能夠預期和從所有規模的大多數失敗中復原，而且對用戶體驗和商務目標造成最少的中斷。 |
|---|
即使是高度復原的系統也需要在架構設計和工作負載作業中採用災害準備方法。 在數據層上，如果損毀，您應該有可修復工作負載狀態的策略。
範例案例
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 資料庫。 因此，小組會移轉至執行 SQL Server 2022 的 Azure VM。
- 小組決定對所有資料庫使用「自動備份」功能，包括重要的資料庫，例如 VM 所使用的資料庫。
- 對於重要資料庫，小組計劃使用「自動備份」函式以及 受控執行個體 連結函式，主動將資料庫複寫至 Azure SQL 受控執行個體。
在設計中實作自動化自我修復功能
自我修復功能是一種機制，可讓工作負載的元件藉由復原受影響的元件，並視需要故障轉移至備援基礎結構，自動解決問題。 使用設計模式，透過自我修復機制將復原功能新增至工作負載。
自我修復自動化有助於降低人為介入等外部因素的風險，並縮短中斷修復週期。
Contoso 的挑戰
- 擷取數據最初部署到多個 VM 以提升可用性時，從 Azure Data Factory 叫用的 Windows 程式。
- 在某些情況下，舊版 Windows 進程已當機，需要重新啟動 VM。 雖然整體處理時間已受到最小影響（因為備援層級），但小組想要實作可自動偵測失敗和復原的解決方案。
套用方法和結果
- 小組決定實作 Azure 虛擬機擴展集解決方案，此解決方案已設定為部署應用程式健康情況擴充功能，以持續監視 VM 程式的健康情況。
- 啟用自動實例修復后，擴展集現在可以藉由重新啟動 VM 或根據相同映像建立新的實例來修復元件。