這是每個工程師的噩夢：云服務提供商突然中斷，導致系統故障、產品故障，憤怒的客戶抱怨服務停止。這可能會對企業信譽造成嚴重影響，并使產品的可靠性受到質疑。

AWS首席技術官Werner Vogels談到了針對故障的設計架構，他表示，無論你或你的云供應商在數據中心運營方面有多出色，數據中心總有一天會中斷。

即使是規模最大、最成功的公司也會成為故障的受害者——Facebook、Slack和AWS最近就是例子。雖然并非所有的停機都是云造成的，但AWS最近的一個例子已經證明，有可行的、主動的業務連續性(BCP)和災難恢復(DR)計劃，以及每一個計劃的運行手冊，都能帶來不同。

雖然BCP和災難恢復通常被歸為一類，但業務連續性往往比災難恢復更常見，勞動強度也更低。BCP通常指的是典型的云中斷，而DR指的是由于惡意行為或其他破壞性事件導致所有數據完全銷毀的情況。對于BCP計劃，數據和服務器的多個副本通常就足夠了，而災難恢復計劃要求有更多的備份和協議。

另一個需要確定的重要方面是恢復點目標(RPO)和恢復時間目標(RTO)。RTO是指在從災難中恢復時，企業能夠承受的斷開連接的時間量，而RPO是指在不損害企業聲譽或違反服務級別協議(SLA)的情況下，你在災難中可能丟失的數據量(例如，24小時)。

既然已經確定了這些重要因素，那么在發生另一次云中斷或任何其他可能出現的問題時，如何保護你的組織?以下是在最壞情況發生后準備和恢復服務的一些步驟。

創建多可用性區域部署

BCP最簡單、最常見的架構是在同一區域內至少使用兩個可用性區域(AZ)。例如，在AWS上，每個區域由三個AZ組成，它們彼此相對靠近，通過專用光纖和低延遲連接連接。這可以保持服務正常運行，以便在一個AZ出現故障時繼續為客戶提供服務。

云提供商傾向于將其服務分布在多個AZ(例如Amazon S3、Amazon DynamoDB、Google Cloud Spaner等)。因此，它們被設計用來處理AZ故障。

注意，需要考慮到此類架構可能涉及設計階段需要考慮的內部成本。

在多區域部署中使用單個AZ

在這個場景中，你將在兩個不同區域的一個AZ上實現應用程序和數據庫。這使你能夠在一個地區出現停機時提供服務。

這兩個AZ可以通過以下幾種方式部署：

• 每個地區將使用負載均衡器或DNS(域名系統)路由為50%的工作負載提供服務。
• 主區域將為大部分或所有流量提供服務，第二個區域將在出現故障時為用戶提供服務。如果選擇此路線，可能需要自動執行此故障切換任務。

使用多AZ和多區域部署

最近一次AWS大故障發生在北弗吉尼亞州(US-East-1)地區，由于網絡影響，影響了整個地區。如果你所有的基本工作負載都在該地區運行，那么你的服務將不可避免地受到影響。這意味著在該地區的AWS服務恢復之前，你的所有服務都將暫停——你把所有的雞蛋放在一個籃子里!這是一種罕見的情況，網絡故障會影響多個AZ。

對于這種情況，最好的保護措施是在不同的位置運行不同的工作負載和備份，這樣，如果一個地區出現故障，你可以繼續為來自不同地區的客戶提供服務。

當然，運行的區域越多，環境就越復雜，云賬單也就越昂貴。因此，考慮到你的產品實際上有多重要，在哪里和多少地區建立業務時要有策略。你將需要付出額外的努力，以確保你的產品在所有情況下都能發揮作用，從而保證盡可能實現地區多元化。

在多云或混合部署上運行

在多個云提供商上運行已經變得越來越流行。但現實是，維護多個云環境非常困難，當你使用托管服務時，這一挑戰變得更加困難。例如，如果你使用的是Amazon DynamoDB，則其他云提供商無法提供類似的解決方案。

因此，行業趨勢是在一個特定的云上(在一個多AZ或多地區架構上)運行每個工作負載，但允許不同的工作負載在不同的其他云上運行——這意味著你可以在兩個不同的云提供商之間拆分部分服務。在這種情況下，發生停機時并非所有系統都停機。

或者，另一種常見做法是在內部設置DR站點。當客戶將其工作負載遷移到云端時，他們傾向于將本地作為災難恢復站點使用，因此如果出現問題，他們將能夠在本地運行一些關鍵服務。當公司的云成熟度處于初始階段，并且沒有使用托管服務時，這是一個很好的實踐。

創建備份

雖然上述所有解決方案都是BCP的理想解決方案，但在數據被加密或刪除的情況下，它們行不通，需要可靠的災難恢復策略。因此，除了為你的服務提供多個實施之外，你可能還需要一個可靠的備份計劃，以滿足公司的RPO和RTO要求。

有許多第三方備份解決方案和云備份服務可用，例如AWS Backup，它們可以幫助你實現備份自動化，并將備份保存到單獨的賬戶和區域。你應該像保護金庫一樣保護備份賬戶，這樣它就可以抵御攻擊，將數據加密。

如果發生此類攻擊，備份賬戶上的數據將用于恢復服務，以便繼續為客戶提供服務。

已經介紹了為云環境構建BCP和DR計劃的最常用方法，讓我們討論一下可用于實現這些方法的工具：

利用基礎設施即代碼

基礎設施即代碼(IaC)可以實現環境的自動配置。一旦配置了要使用的參數，它將被保存到主文件中，也就是清單。從那里，你的環境可以自動重新創建，用于測試、災難恢復或各種其他情況。

對容器使用縮放規則

如果你使用的是容器，那么基于各種度量實現縮放規則會非常有幫助。可以向上縮放以增加同一塊中的簇，也可以向外縮放，這將復制實例。通過實施擴展規則，你可以輕松備份和恢復基于容器的應用程序，以便在出現停機時檢索所有重要的工作負載。理想情況下，你需要在容器和實例級別上進行縮放，以使其最有效。

重新路由DNS請求

如果一個位置的服務器關閉，你可以將所有請求重新路由到運行服務的其他位置。可以將Cloudflare等DNS提供商配置為檢測系統何時關閉，并自動執行基于地理位置的重新路由。

同樣，你還可以設置容器編排器來定義和自動化各種重新路由請求的規則。我們建議同時實現自動縮放以確保可用性，并使用Amazon ECS來實現重路由請求。

設置指示燈以在多個位置運行

另一個推薦的業務連續性策略是運行試點燈，它本質上是在不同區域備用運行的工作負載的復制版本。如果發生災難，所有數據都將保存在那里，隨時準備進行設置。只需在事件發生后部署基礎設施并擴展資源，產品就應該立即啟動并運行。

如果不能有任何停機時間，你可能需要考慮運行熱備用。根據AWS的說法，“熱備用方法包括確保在另一個地區有一個縮小的、但功能齊全的生產環境副本。這種方法擴展了指示燈概念，減少了恢復時間，因為工作負載總是在另一個地區。”

雖然成本要高得多，但熱備用的啟動和運行速度將比指示燈快，因為不需要基礎設施設置。

總結

在災難恢復方面，抱最好的希望，做最壞的打算才是最重要的規則之一。云中斷可能會發生在任何人身上，不會有任何事先通知。

通過遵循上述策略，你可以確保服務在多個位置可用，可以輕松地將流量轉移到未受影響的區域，并在災難發生時做好備份和行動準備。最好的是，你可以放輕松，企業的功能和信譽保持在最高標準。