概觀
本系列提供一個說明範例，說明組織如何為 Azure 企業資料平臺設計災害復原 (DR) 策略。
Azure 提供廣泛的復原選項，可在發生災害時提供服務持續性。 但較高的服務等級可能會帶來複雜度和成本進階。 成本與復原與複雜性的取捨是大部分客戶對於 DR 的重要決策因素。
雖然偶爾會在 Azure 服務中發生點失敗，但應該注意 Microsoft 資料中心和 Azure 服務內建多層備援。 任何失敗通常會限制在範圍內，而且通常會在幾小時內復原。 在過去，身分識別管理等金鑰服務會經歷服務問題，而不是離線的整個 Azure 區域。
也應該確認網路攻擊，特別是勒索軟體，現在會對任何新式資料生態系統造成有形的威脅，並可能導致資料平臺中斷。 雖然這一系列的範圍不足，但建議客戶在任何資料平臺的安全性和復原設計中實作這類攻擊的控制措施。
- Azure 雲端基本概念中提供勒索軟體防護的 Microsoft 指導方針
範圍
本文系列的範圍包括：
- 從實體災害中復原 Azure 資料平臺的服務，適用于客戶的說明角色。 此說明客戶如下：
- 具有已定義作業支援功能的中型組織，遵循以 ITIL 為基礎的服務管理方法
- 不是雲端原生，其核心企業共用服務，例如存取和驗證管理和事件管理仍保留在內部部署
- 在雲端移轉至 Azure 的過程中，由自動化啟用
- Azure 資料平臺已在客戶的 Azure 租用內實作下列設計
- 企業登陸區域 – 提供平臺基礎，包括網路功能、監視、安全性等。
- Azure Analytics 平臺 - 提供支援服務所提供各種解決方案和資料產品的資料元件
- 此程式將由 Azure 技術資源執行，而不是專家 Azure SME。 因此，資源 () 應具備下列層級的知識/技能
- Azure 基本概念 – 瞭解 Azure、其核心服務和資料元件
- 瞭解 Azure DevOps。 能夠巡覽原始檔控制並執行管線部署
- 此程式描述從主要區域到次要區域的容錯移轉程式
超出範圍
本文系列將下列專案視為範圍不足：
- 後援程式，從次要區域回到主要區域
- 任何非 Azure 應用程式、元件或系統 – 這包括但不限於內部部署、其他雲端廠商、協力廠商 Web 服務等。
- 復原任何上游服務，例如內部部署網路、閘道、企業共用服務等，這些是此程式的必要條件
- 復原任何下游服務，例如內部部署作業系統、協力廠商報告系統、資料模型化或資料科學應用程式等，相依于此程式以復原自己的服務
- 資料遺失案例，包括從勒索軟體或類似的資料安全性事件中復原
- 資料備份策略和資料還原計劃
- 建立 DR 事件的根本原因
- 針對 Azure 服務/元件事件，Microsoft 會在狀態 – 歷程記錄網頁內發佈「根本原因分析」
重要假設
此 DR 運作範例的主要假設是
- 組織遵循 ITIL 型服務管理方法，以取得 Azure 資料平臺的操作支援
- 組織有現有的災害復原程式，作為 IT 資產服務還原架構的一部分
- 「基礎結構即程式碼」 (IaC) 已用來部署自動化服務所啟用的 Azure 資料平臺，例如 Azure DevOps 或類似專案
- Azure 資料平臺所裝載的每個解決方案都已完成商務影響評估或類似專案，為 RPO、RTO 和 MTO 提供清楚的服務需求
下一步
既然您已瞭解高階案例，您可以繼續瞭解專為使用案例設計的 架構 。