設計災害復原策略的建議

  • 發行項

適用于此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：09 實作與復原目標一致的結構化、測試和記載商務持續性和災害復原 (BCDR) 計畫。 方案必須涵蓋所有元件和整個系統。

本指南描述針對工作負載設計可靠災害復原策略的建議。 若要符合內部服務等級目標， (SLO) ，或甚至是服務等級協定 (SLA) ，您必須具備健全且可靠的災害復原策略。 預期會發生失敗和其他重大問題。 您處理這些事件的準備會決定客戶可以信任您的企業以可靠地提供這些事件的準備。 災害復原策略是準備重大事件的骨幹。

定義

詞彙 定義
容錯移轉 自動化和/或手動將生產工作負載流量從無法使用的區域轉移到不受影響的地理區域。
容錯回復 將生產工作負載流量從容錯移轉區域移回主要區域的自動化和/或手動移轉。

主要設計策略

本指南假設您已經在可靠性規劃中執行下列工作：

可靠的災害復原 (DR) 策略是以可靠的工作負載架構為基礎來建置。 解決建置工作負載的每個階段的可靠性，以確保在開始設計 DR 策略之前，已備妥優化復原的必要部分。 此基礎可確保工作負載的可靠性目標，例如復原時間目標 (RTO) ，以及 RPO) (復原點目標都是實際且可行的。

維護災害復原計畫

工作負載可靠 DR 策略的基礎是 DR 計畫。 您的計畫應該是在環境演進時定期檢閱和更新的即時檔。 將計畫呈現給適當的小組， (營運、技術領導及商務專案關係人，) 每六個月定期 (一次，例如) 。 將它儲存在高可用性的安全資料存放區中，例如商務用 OneDrive。

請遵循這些建議來開發 DR 方案：

  • 清楚定義構成災害的內容，因此需要啟用 DR 方案。

    • 災害是大規模的問題。 這可能是區域性中斷、Microsoft Entra識別碼或 Azure DNS 等服務的中斷，或勒索軟體攻擊或 DDoS 攻擊等嚴重惡意攻擊。

    • 識別未被視為災害的失敗模式，例如單一資源的失敗，因此操作員不會誤叫用其 DR 呈報。

  • 在您的 FMA 檔上建置 DR 方案。 請確定您的 DR 計畫會針對定義為災害的中斷，擷取失敗模式和風險降低策略。 以平行方式更新 DR 方案和 FMA 檔，以便在環境變更或測試發現非預期的行為時正確。

    • 您是否針對非生產環境開發 DR 方案，取決於您的商務需求和成本影響。 例如，如果您提供品質保證 (QA) 環境給特定客戶進行發行前版本測試，您可能會想要在 DR 規劃中包含這些環境。

  • 清楚定義工作負載小組內的角色和責任，並瞭解組織內的任何相關外部角色。 角色應包括：

    • 負責宣告災害的合作物件。

    • 負責宣告事件關閉的合作物件。

    • 作業角色。

    • 測試和驗證角色。

    • 內部和外部通訊角色。

    • (RCA) 潛在客戶角色進行回顧和根本原因分析。

  • 定義工作負載小組必須遵循的呈報路徑，以確保復原狀態會傳達給專案關係人。

  • 擷取元件層級復原程式、資料資產層級復原，以及整個工作負載的復原程式。 包含指定的作業順序，以確保元件以最不具影響力的方式復原。 例如，在復原應用程式之前，請先復原和檢查資料庫。

    • 詳細說明每個元件層級的復原程式，作為逐步指南。 可能的話，請包含螢幕擷取畫面。

    • 定義小組的責任與雲端主機提供者的責任。 例如，Microsoft 負責還原 PaaS (平臺即服務) ，但您必須負責重新凍結資料，並將設定套用至服務。

    • 包含執行程式的必要條件。 例如，列出需要收集的必要腳本或認證。

    • 在您開始復原之前，先擷取事件的根本原因並執行風險降低。 例如，如果事件的原因是安全性問題，請在復原容錯移轉環境中的受影響系統之前，先減輕該問題。

  • 視工作負載的 備援設計 而定，您可能需要在容錯移轉後執行重大工作，才能讓工作負載再次提供給您的客戶使用。 容錯移轉後的工作可能包括 DNS 更新、資料庫連接字串更新，以及流量路由變更。 擷取復原程式中的所有容錯移轉後工作。

    注意

    備援設計可讓您完全或部分地自動從主要事件復原，因此請確定您的計畫包含這些案例的流程和程式。 例如，如果您有跨越 可用性區域或區域的完全主動式設計，您可能能夠在可用性區域或區域性中斷之後以透明方式自動容錯移轉，並將需要執行的 DR 方案中的步驟降到最低。 同樣地，如果您使用 部署戳記來設計工作負載，則如果戳記是區域性部署，則只會發生部分中斷。 在此情況下，您的 DR 方案應該涵蓋如何在未受影響的區域或區域中復原戳記。

  • 如果您需要在容錯移轉環境中重新部署應用程式，請使用工具來盡可能自動化部署程式。 請確定已在容錯移轉環境中預先部署並設定 DevOps 管線，以便立即開始應用程式部署。 必要時使用自動化端對端部署，並視需要手動核准閘道，以確保一致且有效率的部署程式。 完整部署持續時間必須與復原目標一致。

    • 當部署程式的階段需要手動介入時，請記載手動步驟。 清楚定義角色和責任。

  • 盡可能自動化大部分的程式。 在您的腳本中，使用宣告式程式設計，因為它允許等冪。 當您無法使用宣告式程式設計時，請留意開發及執行自訂程式碼。 使用重試邏輯和斷路器邏輯，以避免在停滯于中斷工作的腳本上浪費時間。 由於您只以異常方式執行這些腳本，因此您不想不正確地開發腳本，而導致復原程式更損毀或變慢。

    注意

    自動化會造成風險。 訓練的操作員必須仔細監視自動化程式，並在任何程式遇到問題時介入。 若要將自動化對誤判做出回應的風險降到最低，請在 DR 演練中徹底完成。 測試計劃的所有階段。 模擬偵測以產生警示，然後在整個復原程式中移動。

    請記住，您的 DR 演練應該驗證或通知復原目標計量的更新。 如果您發現自動化容易受到誤判，您可能需要增加容錯移轉閾值。

  • 將容錯回復計畫與 DR 方案分開，以避免與 DR 程式產生潛在混淆。 容錯回復計畫應遵循所有 DR 計畫的開發和維護建議，且應以相同方式進行結構化。 容錯移轉所需的任何手動步驟都應該在容錯回復計畫中進行鏡像處理。 容錯回復可能會在容錯移轉之後快速發生，或可能需要數天或數周的時間。 請考慮將容錯回復視為與容錯移轉分開。

    • 容錯回復的需求是情況。 如果您要基於效能考慮在區域之間路由傳送流量，則原本在容錯移轉區域中容錯回復負載很重要。 在其他情況下，您可能已將工作負載設計為完全運作，而不論其在任何時間所在的生產環境為何。

進行災害復原演練

DR 測試實務與開發完善的 DR 計畫一樣重要。 許多產業都有合規性架構，需要定期執行指定數目的 DR 演練。 無論您的產業為何，一般 DR 演練對您的成功至關重要。

請遵循下列建議，以成功進行 DR 演練：

  • 每年至少執行一個生產 DR 演練。 資料表 (幹執行) 鑽研或非生產演練，有助於確保相關物件熟悉其角色和責任。 這些演練也可協助操作員遵循復原程式，以 (「記憶」) 建立熟悉度。 但只有生產演練會真正測試 DR 方案和 RTO 和 RPO 計量的有效性。 使用生產演練來計時元件和流程的復原程式，以確保已針對工作負載定義的 RTO 和 RPO 目標可達成。 對於超出您控制權的函式，例如 DNS 傳播，請確定涉及這些函式之流程的 RTO 和 RPO 目標會考慮超出您控制項的可能延遲。

  • 使用資料表頂端鑽研不僅能為經驗豐富的操作員建置熟悉度，還能教育新的操作員有關 DR 程式和程式。 資深操作員應該花一點時間讓新操作員執行其角色，並watch改善機會。 如果新運算子在程式中的某個步驟感到困惑或混淆，請檢閱該程式以確保其已清楚撰寫。

考量事項

  • 在生產環境中執行 DR 演練可能會導致非預期的重大失敗。 請務必在初始部署期間，在非生產環境中測試復原程式。

  • 在鑽研期間，為您的小組提供盡可能多的維護時間。 規劃維護時間時，請使用您在 測試 期間擷取的復原計量，作為 必要的最低時間 配置。

  • 當您的 DR 演練實務成熟時，您將瞭解哪些程式可以平行執行，以及必須依序執行的程式。 在演練實務初期，假設每個程式都必須依序執行，而且您需要在每個步驟中額外時間來處理非預期的問題。

Azure 設施

許多 Azure 產品都有內建的容錯移轉功能。 熟悉這些功能，並將其包含在復原程式中。

針對 IaaS (基礎結構即服務) 系統，請使用Azure Site Recovery將容錯移轉和復原自動化。 如需常見的 PaaS 產品，請參閱下列文章：

範例

如需準備適用于 DR 的企業資料資產的指引，請參閱 適用于 Azure 資料平臺的 DR 系列 。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單