這是每個工程師的噩夢：云服務(wù)提供商突然中斷，導(dǎo)致系統(tǒng)故障、產(chǎn)品故障，憤怒的客戶抱怨服務(wù)停止。這可能會對企業(yè)信譽造成嚴(yán)重影響，并使產(chǎn)品的可靠性受到質(zhì)疑。
AWS首席技術(shù)官Werner Vogels談到了針對故障的設(shè)計架構(gòu)，他表示，無論你或你的云供應(yīng)商在數(shù)據(jù)中心運營方面有多出色，數(shù)據(jù)中心總有一天會中斷。
即使是規(guī)模最大、最成功的公司也會成為故障的受害者——Facebook、Slack和AWS最近就是例子。雖然并非所有的停機都是云造成的，但AWS最近的一個例子已經(jīng)證明，有可行的、主動的業(yè)務(wù)連續(xù)性（BCP）和災(zāi)難恢復(fù)（DR）計劃，以及每一個計劃的運行手冊，都能帶來不同。
雖然BCP和災(zāi)難恢復(fù)通常被歸為一類，但業(yè)務(wù)連續(xù)性往往比災(zāi)難恢復(fù)更常見，勞動強度也更低。BCP通常指的是典型的云中斷，而DR指的是由于惡意行為或其他破壞性事件導(dǎo)致所有數(shù)據(jù)完全銷毀的情況。對于BCP計劃，數(shù)據(jù)和服務(wù)器的多個副本通常就足夠了，而災(zāi)難恢復(fù)計劃要求有更多的備份和協(xié)議。
另一個需要確定的重要方面是恢復(fù)點目標(biāo)（RPO）和恢復(fù)時間目標(biāo)（RTO）。RTO是指在從災(zāi)難中恢復(fù)時，企業(yè)能夠承受的斷開連接的時間量，而RPO是指在不損害企業(yè)聲譽或違反服務(wù)級別協(xié)議（SLA）的情況下，你在災(zāi)難中可能丟失的數(shù)據(jù)量（例如，24小時）。
既然已經(jīng)確定了這些重要因素，那么在發(fā)生另一次云中斷或任何其他可能出現(xiàn)的問題時，如何保護你的組織？以下是在最壞情況發(fā)生后準(zhǔn)備和恢復(fù)服務(wù)的一些步驟。
創(chuàng)建多可用性區(qū)域部署
BCP最簡單、最常見的架構(gòu)是在同一區(qū)域內(nèi)至少使用兩個可用性區(qū)域（AZ）。例如，在AWS上，每個區(qū)域由三個AZ組成，它們彼此相對靠近，通過專用光纖和低延遲連接連接。這可以保持服務(wù)正常運行，以便在一個AZ出現(xiàn)故障時繼續(xù)為客戶提供服務(wù)。
云提供商傾向于將其服務(wù)分布在多個AZ（例如Amazon S3、Amazon DynamoDB、Google Cloud Spaner等）。因此，它們被設(shè)計用來處理AZ故障。
注意，需要考慮到此類架構(gòu)可能涉及設(shè)計階段需要考慮的內(nèi)部成本。
在多區(qū)域部署中使用單個AZ
在這個場景中，你將在兩個不同區(qū)域的一個AZ上實現(xiàn)應(yīng)用程序和數(shù)據(jù)庫。這使你能夠在一個地區(qū)出現(xiàn)停機時提供服務(wù)。
這兩個AZ可以通過以下幾種方式部署：
——每個地區(qū)將使用負(fù)載均衡器或DNS（域名系統(tǒng)）路由為50%的工作負(fù)載提供服務(wù)。
——主區(qū)域?qū)榇蟛糠只蛩辛髁刻峁┓?wù)，第二個區(qū)域?qū)⒃诔霈F(xiàn)故障時為用戶提供服務(wù)。如果選擇此路線，可能需要自動執(zhí)行此故障切換任務(wù)。
使用多AZ和多區(qū)域部署
最近一次AWS大故障發(fā)生在北弗吉尼亞州（US-East-1）地區(qū)，由于網(wǎng)絡(luò)影響，影響了整個地區(qū)。如果你所有的基本工作負(fù)載都在該地區(qū)運行，那么你的服務(wù)將不可避免地受到影響。這意味著在該地區(qū)的AWS服務(wù)恢復(fù)之前，你的所有服務(wù)都將暫停——你把所有的雞蛋放在一個籃子里！這是一種罕見的情況，網(wǎng)絡(luò)故障會影響多個AZ。
對于這種情況，最好的保護措施是在不同的位置運行不同的工作負(fù)載和備份，這樣，如果一個地區(qū)出現(xiàn)故障，你可以繼續(xù)為來自不同地區(qū)的客戶提供服務(wù)。
當(dāng)然，運行的區(qū)域越多，環(huán)境就越復(fù)雜，云賬單也就越昂貴。因此，考慮到你的產(chǎn)品實際上有多重要，在哪里和多少地區(qū)建立業(yè)務(wù)時要有策略。你將需要付出額外的努力，以確保你的產(chǎn)品在所有情況下都能發(fā)揮作用，從而保證盡可能實現(xiàn)地區(qū)多元化。
在多云或混合部署上運行
在多個云提供商上運行已經(jīng)變得越來越流行。但現(xiàn)實是，維護多個云環(huán)境非常困難，當(dāng)你使用托管服務(wù)時，這一挑戰(zhàn)變得更加困難。例如，如果你使用的是Amazon DynamoDB，則其他云提供商無法提供類似的解決方案。
因此，行業(yè)趨勢是在一個特定的云上（在一個多AZ或多地區(qū)架構(gòu)上）運行每個工作負(fù)載，但允許不同的工作負(fù)載在不同的其他云上運行——這意味著你可以在兩個不同的云提供商之間拆分部分服務(wù)。在這種情況下，發(fā)生停機時并非所有系統(tǒng)都停機。
或者，另一種常見做法是在內(nèi)部設(shè)置DR站點。當(dāng)客戶將其工作負(fù)載遷移到云端時，他們傾向于將本地作為災(zāi)難恢復(fù)站點使用，因此如果出現(xiàn)問題，他們將能夠在本地運行一些關(guān)鍵服務(wù)。當(dāng)公司的云成熟度處于初始階段，并且沒有使用托管服務(wù)時，這是一個很好的實踐。
創(chuàng)建備份
雖然上述所有解決方案都是BCP的理想解決方案，但在數(shù)據(jù)被加密或刪除的情況下，它們行不通，需要可靠的災(zāi)難恢復(fù)策略。因此，除了為你的服務(wù)提供多個實施之外，你可能還需要一個可靠的備份計劃，以滿足公司的RPO和RTO要求。
有許多第三方備份解決方案和云備份服務(wù)可用，例如AWS Backup，它們可以幫助你實現(xiàn)備份自動化，并將備份保存到單獨的賬戶和區(qū)域。你應(yīng)該像保護金庫一樣保護備份賬戶，這樣它就可以抵御攻擊，將數(shù)據(jù)加密。
如果發(fā)生此類攻擊，備份賬戶上的數(shù)據(jù)將用于恢復(fù)服務(wù)，以便繼續(xù)為客戶提供服務(wù)。
已經(jīng)介紹了為云環(huán)境構(gòu)建BCP和DR計劃的最常用方法，讓我們討論一下可用于實現(xiàn)這些方法的工具：
利用基礎(chǔ)設(shè)施即代碼
基礎(chǔ)設(shè)施即代碼（IaC）可以實現(xiàn)環(huán)境的自動配置。一旦配置了要使用的參數(shù)，它將被保存到主文件中，也就是清單。從那里，你的環(huán)境可以自動重新創(chuàng)建，用于測試、災(zāi)難恢復(fù)或各種其他情況。
對容器使用縮放規(guī)則
如果你使用的是容器，那么基于各種度量實現(xiàn)縮放規(guī)則會非常有幫助。可以向上縮放以增加同一塊中的簇，也可以向外縮放，這將復(fù)制實例。通過實施擴展規(guī)則，你可以輕松備份和恢復(fù)基于容器的應(yīng)用程序，以便在出現(xiàn)停機時檢索所有重要的工作負(fù)載。理想情況下，你需要在容器和實例級別上進行縮放，以使其最有效。
重新路由DNS請求
如果一個位置的服務(wù)器關(guān)閉，你可以將所有請求重新路由到運行服務(wù)的其他位置。可以將Cloudflare等DNS提供商配置為檢測系統(tǒng)何時關(guān)閉，并自動執(zhí)行基于地理位置的重新路由。
同樣，你還可以設(shè)置容器編排器來定義和自動化各種重新路由請求的規(guī)則。我們建議同時實現(xiàn)自動縮放以確保可用性，并使用Amazon ECS來實現(xiàn)重路由請求。
設(shè)置指示燈以在多個位置運行
另一個推薦的業(yè)務(wù)連續(xù)性策略是運行試點燈，它本質(zhì)上是在不同區(qū)域備用運行的工作負(fù)載的復(fù)制版本。如果發(fā)生災(zāi)難，所有數(shù)據(jù)都將保存在那里，隨時準(zhǔn)備進行設(shè)置。只需在事件發(fā)生后部署基礎(chǔ)設(shè)施并擴展資源，產(chǎn)品就應(yīng)該立即啟動并運行。
如果不能有任何停機時間，你可能需要考慮運行熱備用。根據(jù)AWS的說法，“熱備用方法包括確保在另一個地區(qū)有一個縮小的、但功能齊全的生產(chǎn)環(huán)境副本。這種方法擴展了指示燈概念，減少了恢復(fù)時間，因為工作負(fù)載總是在另一個地區(qū)。”
雖然成本要高得多，但熱備用的啟動和運行速度將比指示燈快，因為不需要基礎(chǔ)設(shè)施設(shè)置。
總結(jié)
在災(zāi)難恢復(fù)方面，抱最好的希望，做最壞的打算是最重要的規(guī)則之一。云中斷可能會發(fā)生在任何人身上，不會有任何事先通知。
通過遵循上述策略，你可以確保服務(wù)在多個位置可用，可以輕松地將流量轉(zhuǎn)移到未受影響的區(qū)域，并在災(zāi)難發(fā)生時做好備份和行動準(zhǔn)備。最好的是，你可以放輕松，企業(yè)的功能和信譽保持在最高標(biāo)準(zhǔn)。
