本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 多區域基礎 4：營運準備度
操作多區域工作負載是一項複雜的任務，伴隨多區域架構特有的操作挑戰。其中包括 AWS 帳戶 管理、重組部署程序、建立多區域可觀測性策略、建立和測試復原程序，以及管理成本。[營運準備度審查 (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/the-orr-mechanism.html) 可協助團隊準備用於生產的工作負載，無論是在單一區域還是跨多個區域執行。
## 4.a： AWS 帳戶 管理
若要跨 部署工作負載 AWS 區域，請確定帳戶內跨區域的所有[AWS 服務 配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)相同。首先，識別屬於架構的所有 AWS 服務 ，查看待命區域中的計劃用量，然後將計劃用量與目前的用量進行比較。在某些情況下，如果之前未使用待命區域，您可以參考[預設的服務配額](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)來了解起點。然後，在所有將使用的服務中，使用 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas/home) （需要登入） 或 [APIs](https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_Operations.html) 請求提高配額。
在每個區域中設定 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 角色，以授予操作員、自動化工具和待命區域內資源 AWS 服務 的適當許可。若要實現多區域架構的區域隔離，請依區域隔離角色。在使用待命區域上線之前，請確定有適當的許可。
## 4.b：部署實務
多區域功能可能會使將工作負載部署到多個區域變得複雜。您需要確保一次部署到一個區域。例如，如果您使用主動-被動方法，您應該先部署到主要區域，然後再部署到待命區域。 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)可協助您將基礎設施部署到單一或多個區域，並可根據您的需求量身打造。 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)可協助您建置持續整合/持續交付 (CI/CD) 管道，其具有[跨區域動作](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-create-cross-region.html)，允許部署到與管道所在區域不同的區域。這結合了強大的[部署策略](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)，例如[藍/綠](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html)，允許最低到零的停機時間部署。
不過，當應用程式或資料的狀態未外部化至持久性存放區時，狀態功能的部署可能會變得更加複雜。在這些情況下，請仔細量身打造部署程序以符合您的需求。設計部署管道和程序以一次部署到一個區域，而不是同時部署到多個區域。這可減少區域之間相互關聯失敗的機率。若要了解 Amazon 用來自動化軟體部署的技巧，請參閱 AWS 建置器程式庫文章[自動化安全的實作部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。
## 4.c：可觀測性
當您設計多區域時，請考慮如何監控每個區域中所有元件的運作狀態，以取得區域運作狀態的整體檢視。這可能包括監控複寫延遲的指標，這不是單一區域工作負載的考量。
當您建置多區域架構時，請考慮也從待命區域觀察工作負載的效能。這包括從待命區域執行運作狀態檢查和 Canary （合成測試），以提供主要區域運作狀態的外部檢視。此外，您可以使用 [Amazon CloudWatch 網路監視器](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-cloudwatch-internet-monitor/)，從最終使用者的角度了解外部網路的狀態和工作負載的效能。主要區域應具有相同的可觀測性，以監控待命區域。
來自待命區域的 Canary 應監控客戶體驗指標，以判斷工作負載的整體運作狀態。這是必要的，因為如果主要區域中發生問題，主要區域中的可觀測性可能會受損，並會影響您評估工作負載運作狀態的能力。
在這種情況下，觀察該區域以外的 可以提供洞見。這些指標應彙總到每個區域中可用的儀表板，以及每個區域中建立的警示。由於 [CloudWatch](https://aws.amazon.com/cloudwatch/) 是區域服務，因此在兩個區域中都具有警示是必要的。此監控資料將用於讓呼叫從主要區域容錯移轉到待命區域。
## 4.d：程序和程序
回答問題的最佳時機：「我應該何時容錯移轉？」 在您需要之前很長。在問題發生之前預先定義包含人員、程序和技術的復原計畫，並定期進行測試。決定復原決策架構。如果有執行良好的復原程序，且充分了解復原的時間，您可以選擇使用符合 RTO 目標的容錯移轉來啟動復原程序。識別主要區域中的應用程式問題後，可能會立即發生此時間點，或者當區域中應用程式內的復原選項已用盡時，可能會進一步進入事件。
容錯移轉動作本身應該 100% 自動化，但啟動容錯移轉的決定應由人類做出，通常是組織中少數的預定人員。這些人員應考慮資料遺失和事件的相關資訊。此外，需要明確定義容錯移轉的條件，並在組織內全面了解。若要定義和完成這些程序，您可以使用 [Amazon Application Recovery Controller (ARC) 區域切換](https://docs.aws.amazon.com/r53recovery/latest/dg/region-switch.html)，以允許完整的end-to-end自動化，並確保在測試和容錯移轉期間執行的程序一致性。
當您建立區域切換計劃時，它會自動在主要和待命區域中複寫您的計劃，以確保對單一區域沒有相依性。當此自動化準備就緒時，請定義並遵循定期測試節奏。這可確保發生實際事件時，回應會遵循組織可信的明確定義、實務程序。也請務必考慮資料調校程序的既定公差。確認提議的程序符合已建立的 RPO/RTO 要求。
## 4.e：測試
擁有未經測試的復原方法等於沒有復原方法。基本的測試層級是執行復原程序，以切換應用程式的操作區域。有時這稱為*應用程式輪換*方法。我們建議您建置將區域切換為正常操作狀態的功能；不過，僅此測試還不夠。
彈性測試對於驗證應用程式的復原方法也很重要。這包括注入特定失敗案例、了解您的應用程式和復原程序如何反應，然後在測試未按計劃進行時實作所需的任何緩解措施。在沒有錯誤的情況下測試復原程序，並不會告知您應用程式在發生錯誤時的整體行為。您必須制定計劃，根據預期的失敗案例來測試復原。 [AWS Fault Injection Service](https://docs.aws.amazon.com/fis/)提供越來越多的[案例](https://docs.aws.amazon.com/fis/latest/userguide/scenario-library.html)清單，讓您開始使用。
這對於高可用性應用程式特別重要，因為需要嚴格測試以確保符合業務連續性目標。主動測試復原功能可降低生產失敗的風險，進而建立應用程式可達到所需限制復原時間的信心。定期測試也會建立營運專業知識，這可讓團隊在中斷發生時快速且可靠地從中斷中復原。行使復原方法的人工元素或程序與技術層面同樣重要。
## 4.f：成本和複雜性
多區域架構的成本影響取決於更高的基礎設施使用量、營運開銷和資源時間。如前所述，待命區域中的基礎設施成本與預先佈建時主要區域中的基礎設施成本類似，因此會加倍您的總成本。佈建容量，使其足以進行日常操作，但仍保留足夠的緩衝容量來容忍需求激增。然後，在每個區域中設定相同的限制。
此外，如果您採用主動-主動架構，您可能需要進行應用程式層級的變更，才能在多區域架構中成功執行應用程式。這些變更可能需要耗費大量時間和資源，才能設計和操作。組織至少需要花時間了解每個區域的技術和業務相依性，以及設計容錯移轉和容錯回復程序。
團隊也應進行正常的容錯移轉和容錯回復練習，以熟悉將在事件期間使用的 Runbook。雖然這些練習對於從多區域投資取得預期成果至關重要，但它們代表了機會成本，並從其他活動取得時間和資源。
## 4.g：組織多區域容錯移轉策略
AWS 區域 提供故障隔離界限，以防止相關故障，並在 AWS 服務 故障發生時包含對單一區域的影響。您可以使用這些錯誤界限來建置多區域應用程式，這些應用程式由每個區域中獨立的錯誤隔離複本組成，以限制共用命運案例。這可讓您建置多區域應用程式，並使用各種方法，從備份和還原到指示燈，再到主動-主動，以實作多區域架構。不過，應用程式通常不會單獨運作，因此請將您將使用的元件及其相依性視為容錯移轉策略的一部分。一般而言，多個應用程式會共同支援*使用者案例*，這是提供給最終使用者的特定功能，例如在社交媒體應用程式上張貼圖片和字幕，或在電子商務網站上查看。因此，您應該制定組織多區域容錯移轉策略，以提供必要的協調和一致性，讓您的方法成功。
組織可以從中挑選四種高階策略，以引導多區域方法。這些是從最精細到最廣泛的方法列出：
+ 元件層級容錯移轉
+ 個別應用程式容錯移轉
+ 相依性圖表容錯移轉
+ 整個應用程式產品組合容錯移轉
每個策略都有權衡並解決不同的挑戰，包括容錯移轉決策的彈性、測試容錯移轉組合的能力、模態行為的存在，以及組織在規劃和實作方面的投資。若要深入了解每個策略，請參閱 AWS 部落格文章[建立組織多區域容錯移轉策略](https://aws.amazon.com/blogs/architecture/creating-an-organizational-multi-region-failover-strategy/)。
## 金鑰指引
+ 檢閱所有 AWS 服務 配額，以確保它們在工作負載將操作的所有區域中是相同的。
+ 部署程序應該一次以一個區域為目標，而不是同時涉及多個區域。
+ 複寫延遲等其他指標專屬於多區域案例，應予以監控。
+ 將工作負載的監控延伸到主要區域之外。監控每個區域的客戶體驗指標，並從執行工作負載的每個區域外部測量此資料。
+ 定期測試容錯移轉和容錯回復。針對容錯移轉和容錯回復程序實作單一 Runbook，並將其用於測試和即時事件。用於測試和即時事件的 Runbook 不應不同。
+ 了解容錯移轉策略的權衡。實作相依性圖表或整個應用程式產品組合策略。