Azure 中的業務持續性管理
Azure 維護的是業界裡其中一種最成熟且受尊重的業務持續性管理計畫。 Azure 中的業務持續性目標是針對所有可獨立復原的服務，無論該服務是客戶面向 (Azure 供應項目的一部分) 或內部支援平台服務的一部分，建置並提升恢復能力和復原能力。
若要了解業務持續性，請務必注意許多供應項目是由多個服務所組成。 在 Azure 中，每項服務都是透過工具靜態識別，而且是用於隱私權、安全性、詳細目錄、風險業務持續性管理和其他功能的測量單位。 為了正確測量服務的功能，每個服務都會包含人員、程序和技術的三個元素，不論服務類型為何。
例如：
- 如果有以人員為基礎的業務程序，例如技術支援中心或小組，服務傳遞就是他們所做的工作。 人員會使用流程和技術來執行服務。
- 如果有技術即服務，例如 Azure 虛擬機器，則服務傳遞是技術，以及支援其作業的人員和流程。
責任分擔模式
Azure 提供的許多供應項目都需要您在多個區域中設定災害復原，且不是 Microsoft 的責任。 並非所有 Azure 服務都會自動複寫資料，或從失敗的區域自動回復，以跨複寫至另一個已啟用的區域。 在這些情況下，您負責設定復原和複寫。
Microsoft 會確保基準基礎結構和平台服務可供使用。 但在某些情況下，使用方式會要求您在多重區域容量中複製您的部署和儲存體，如果您選擇要這樣做的話。 這些範例說明共同責任模型。 這是業務持續性和災害復原策略的基本要素。
責任劃分
在內部部署資料中心，您擁有整個堆疊。 但是當您將資產移至雲端時，部分責任就會轉移給 Microsoft。 下圖根據部署類型，說明您與 Microsoft 之間的責任區分。
共用責任模型的良好範例是部署虛擬機器。 如果您想要在發生區域失敗時設定跨區域複寫以進行復原，則必須在替代啟用的區域中部署一組重複的虛擬機器。 如果失敗，Azure 不會自動複寫這些服務。 部署必要的資產是您的責任。 您必須有手動變更主要區域的流程，或者必須使用流量管理員來偵測並自動進行容錯移轉。
客戶啟用的災害復原服務全都有公開的文件可引導您。 如需客戶所啟用災害復原的公開文件範例，請參閱 Azure Data Lake Analytics。
如需共用責任模型的詳細資訊，請參閱 Microsoft 信任中心。
業務持續性合規性：服務層級責任
每個服務都必須完成 Azure Business Continuity Manager 工具中的業務持續性災害復原記錄。 服務擁有者可以使用此工具在同盟模型中運作，以完成並納入包含下列項目的需求：
服務屬性：定義服務，以及達成災害復原和復原的方式，並識別災害復原的責任方 (技術)。 如需復原擁有權的詳細資訊，請參閱上一節和圖表中有關共同責任模型的討論。
業務影響分析：這項分析可協助服務擁有者根據影響資料表中服務的重要程度，定義復原時間目標 (RTO) 和復原點目標 (RPO)。 營運、法律、法規、品牌形象和財務影響會用作復原的目標。
注意
Microsoft 不會針對服務發佈 RTO 或 RPO，因為此資料僅適用於內部量值。 所有客戶承諾和量值都是 SLA 型，因為其涵蓋更廣泛的範圍與 RTO 或 RPO，這僅適用於重大損失。
相依性：每個服務都會對應相依性 (其他服務)，其運作無關重要性，且會對應至執行階段和/或僅復原所需。 如果有儲存體相依性，則系統會對應另一個資料來定義儲存的內容，以及是否需要時間點快照集等等。
員工：如服務定義中所述，請務必掌握員工能夠支援服務的位置和數量，確保沒有單一失敗點，以及重要員工是否分散，以避免單一位置共置而導致失敗。
外部供應商：Microsoft 會保留完整的外部供應商清單，而認為重要的供應商會測量其功能。 如果服務識別為相依性，則供應商功能會與服務的需求進行比較，以確保協力廠商中斷不會中斷 Azure 服務。
復原評等：此評等對 Azure 業務持續性管理計畫而言是唯一的。 此評等會測量數個重要元素，以建立復原分數：
- 願意容錯移轉：雖然可能有流程，但可能不是短期中斷的優先選項。
- 將容錯移轉自動化。
- 將容錯移轉決策自動化。
最可靠且最短的容錯移轉時間是自動化且不需要人為決策的服務。 自動化服務會使用活動訊號監視或綜合交易來判斷服務已關閉，並開始立即補救。
復原方案和測試：Azure 要求每個服務都有詳細的復原計畫，並假設服務因重大中斷而失敗的情況來測試該方案。 必須撰寫復原計畫，讓具有類似技能和存取權的人員可以完成工作。 撰寫的計畫可避免依賴可用的主題專家。
測試是以數種方式完成，包括在生產環境或近乎生產環境中進行自我測試，以及作為 Canary 區域集合中 Azure 完整區域向下切入的一部分。 這些啟用的區域與生產區域相同，但可以停用而不會影響您的服務。 測試會被視為整合，因為所有服務都會同時受到影響。
客戶啟用：當您負責設定災害復原時，必須有 Azure 公開的文件指導。 針對所有這類服務，系統會提供此流程的文件和詳細資料連結。
確認您的業務持續性合規性
當服務完成其業務持續性管理記錄時，您必須提交記錄以供核准。 記錄會指派給具有業務持續性管理經驗的從業人員，讓他們檢閱整個記錄以了解完整性和品質。 如果記錄符合所有需求，則會獲得核准。 如果不符合，則會遭到拒絕並要求重新作業。 此流程可確保雙方都同意已符合業務持續性合規性，且工作只會由服務擁有者證明。 Azure 內部稽核和合規性小組也會定期隨機取樣，以確保提交的是最佳資料。
服務測試
Microsoft 和 Azure 會針對災害復原和可用性區域整備進行廣泛的測試。 服務會在生產環境或生產前環境中自我測試，可針對不依賴主要平台容錯移轉的服務示範獨立的復原性。
為了確保服務可以在真正的區域停機案例中復原，「停止運作」類型測試是在完全部署符合生產環境的 Canary 環境中完成。 例如，真正關閉叢集、機架和電源供應器，以模擬全體區域失敗。
在這些測試期間，Azure 會使用相同的生產流程來進行偵測、通知、回應和復原。 沒有任何人員預期會有演練，而依賴復原的工程師是一般待命輪替資源。 此時間可避免依賴於實際事件期間可能無法提供協助的主題專家。
這些測試包含您負責遵循 Microsoft 公開文件設定災害復原的服務。 服務小組會建立類似客戶的執行個體，以顯示客戶啟用的災害復原如預期般運作，且提供的指示正確。
如需認證的詳細資訊，請參閱 Microsoft 信任中心和合規性一節。