其實，雲服務也會出現中斷故障。雲服務中斷故障意味著一個雲數據中心或整個地區的基本服務（如存儲、計算能力或中間件）中斷。隨著後端和業務應用程序在雲中應用的普及，如今這種故障影響的不僅僅是面向客戶的網頁和在線商店，所有應用程序都會受到影響，整個企業將陷入停頓，所有員工，無論是財務、人力資源、銷售、生產、客戶服務還是物流的員工都無法工作。
此外，中斷可能不僅僅是暫時的。如果一個數據中心燒壞了，伺服器和裡面的所有數據也就永遠消失了。因此，首席資訊官（CIO）、首席資訊安全官（CISO）和董事會必須決定在災難恢復和業務連續性規劃中接受哪些風險以及需要解決哪些風險。
傳統的業務連續性管理（BCM）涵蓋了物理領域的挑戰：大量員工的缺席（例如，由於大流行病）或洪水和火災摧毀了辦公大樓和數據中心。雲服務中斷則是一種新的情況——解決這些問題需要深入理解各種技術和設計模式並將其納入組織的企業架構。
公共雲服務故障
故障發生時，雲中斷BCM設計必須確保以下資源的可用性。
· 存儲和計算等資源
· 數據和應用。
· 雲服務應用（除了SaaS應用）的一個特別之處在於，這些應用是以下列業務邏輯和數據的形式組成：
· 基礎設施即服務（IaaS）工作負載與虛擬機
· 平台即服務（Platform-as-a-Service）工作負載，包括（不僅僅包括）對象存儲或資料庫即服務
公共雲提供了在更廣泛故障出現時的生存功能。儘管如此，IT部門和風險管理人員仍然必須了解這些機制，並為潛在的公共雲中斷做好準備。我們在下文裡就來看看所選定的微軟Azure概念，儘管其他雲（如GCP或AWS）都非常相似。
Azure劃分了分區服務、區域服務和全球永久在線服務（下圖）。分區服務在一個數據中心運行——最具代表性的分區服務是Azure虛擬機。如果你訂購了這樣的虛擬機，Azure就會啟動一個虛擬機分配給你。因此，如果這個數據中心發生故障，你的虛擬機就會掛掉。沒有任何冗餘。
區域服務是第一類有一定冗餘的服務。許多Azure中用於存儲數據或資料庫即服務產品的Azure服務屬於這一類。這些區域服務在一個區域內的多個分區運行（因此提供了冗餘）。例如，Azure蘇黎世區域由蘇黎世市附近的三個分區組成。某個本地事件（例如飛機墜毀在一個數據中心）不會導致區域服務的癱瘓。所以，區域服務可以提供有限的韌性。然而，區域服務並不能提供對大規模事件的保護，例如瑞士各地都停電幾天。
全球永久在線服務（如DNS或Azure活動目錄）則屬於另一個檔次。Azure保證全球永久在線服務的可用性，無論世界上發生什麼事情。客戶不需要在全球雲中斷的情況下計劃和準備災難恢復。不過問題是屬於這一類的服務非常少。大多數服務都只是區域性的，甚至只是分區性的，特別是與運行應用程序代碼和處理數據有關的服務。
為雲中斷做準備意味著要在提高韌性的成本與中斷的概率和影響之間取得平衡。你是否真的需要區域性或全球性服務？或是分區性服務（加上其他地方的一些備份）就足夠了（下圖）？所有需要的和使用的服務都能滿足這些需求嗎？如果一個應用在發生區域性災難時也必須繼續運行，那麼很容易知道單個虛擬機顯然不可行。在這樣的場景里服務SLA和服務描述都不符合業務需求。
增強韌性
在面臨雲中斷的情況下，韌性是至關重要的。當一項服務不能滿足韌性需求時，韌性模式其實很簡單：就是在不同的分區或區域複製服務。如果一個虛擬機上的應用程序在數據中心掛掉仍然必須繼續運行，那麼你就需要在一個隔得稍遠的第二個數據中心運行另一個虛擬機。如果你要求蘇黎世周圍的區域停電不影響你的應用程序，那麼就必須在日內瓦、芬蘭或澳大利亞增加一個虛擬機。只需考慮兩個細節：成本和改路由。
在蘇黎世數據中心以外的地方運行額外的虛擬機只是為了應付緊急情況，但如果不能針對發來的請求改路由就幫不上忙。解決方案：負載平衡器。負載平衡器是一種區域性服務，即便蘇黎世周圍的一個數據中心完全崩潰，負載平衡器還是可以繼續運行。負載平衡服務在運行初始虛擬機的數據中心崩潰時將流量重新分配到仍在運行的數據中心的虛擬機上。如果你必須在整個區域發生故障時重定向流量，那麼諸如DNS或Azure前門（Azure Front Door）等始終在線的服務就是正確的選擇。
有些選定的區域服務具有地理冗餘功能，可以緩解問題或令問題複雜化。例如，Azure Cosmos資料庫服務可以備份到不同區域並從這些備份恢復（下圖A），甚至允許工程師將該服務配置為地理冗餘（下圖B）。
我們看看從兩個維度（數據和資源容量）的角度設計故障轉移系統（下圖）會有所受益的。最昂貴的設計是在兩個數據中心建立起運行日常操作的全部容量。一半的虛擬機（和其他容量）運行日常操作，另一半則是閒置的，希望不出故障永遠不用這一半閒置的服務和容量。閒置的容量只是為了在故障轉移的情況下存在。由於成本問題，一眾公司只會對最關鍵的任務系統實施這種架構。
另一個極端是完全沒有留出故障轉移的能力。換句話說，IT部門是賭一賭，想靠雲供應商有足夠的容量來應對災難情況，從而接受供應商可能並沒有應對災難情況容量的風險，或者只在遙遠的數據中心有高延時的容量。當採用這種方法時，你永遠不應該忘記一個事實：典型的雲中斷會影響成千上萬的客戶。雲供應商不可能在同一區域的其他數據中心有這麼多沒人日常使用（和支付）的閒置虛擬機或服務能力。而且，在這兩個極端（所有的東西都有重複的資源或對任何東西都沒有容量保留）之間有很多選擇。
設計故障轉移系統時的第二個維度是數據備份和複製的可用性和及時性。兩個主要的複製模式是 「異步複製」和「同步複製」。後一種模式是在確認寫操作成功之前更新各個數據中心的所有數據副本。同步複製的好處是，所有的數據副本總是最新的，應用程序可以在第二個數據中心待命並處於活動狀態（活動/活動）。
數據中心崩潰不會造成任何數據損失或服務中斷。缺點是：由於延遲，可能造成吞吐量損失。最慢的數據中心決定了吞吐量。因此，典型的同步複製是一個區域內的複製，例如，蘇黎世周圍的各個數據中心，但不是從蘇黎世到弗吉尼亞的美東1區域。對於區域之間的複製，異步複製是一個典型的選擇。
異步複製意味著雲服務（或你的應用程序）在本地區域提交更新；當異步複製服務將更新推送到同一個或另一個大陸的不同區域時，應用程序繼續運行。更新傳播時的延遲不會損害你的應用程序的性能。然而，發生故障時尚未轉發的變化會丟失。第三種，最傳統和最便宜的選擇是配置定期備份而不是設置複製。在這最後一種情況下，雲服務執行備份，例如，每4小時或每天一次。
所以，複製和冗餘的選擇會影響到一個公司在雲計算數據中心中斷甚至是區域性雲計算中斷時的生存能力。事實上，業界公司必須明確他們能接受哪些風險以及要為哪些風險做準備。這裡的挑戰在於，在後一種情況下如何設計一個一致的災難恢復架構。雲服務有不同的冗餘選項。雲架構師必須為建立在五個或十個雲服務上的應用挖掘各種細節，即使所有的雲服務都來自同一個雲供應商，也要為雲中斷做好準備。董事會最終是希望IT部門能夠交付雲計算的主要營銷承諾之一：在雲中無服務中斷，由於雲計算可以提供冗餘、複製和備份等神話般的功能。
