本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 多区域基础知识 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)来了解起点。然后，在将要使用的所有服务中，使用 S [ervice 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/)帮助您构建持续 integration/continuous 交付 (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/bluegreen-deployments.html)等强大的[部署策略](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)，可以实现最少至零的停机时间部署。
但是，当应用程序或数据的状态未外部化到持久存储时，有状态功能的部署可能会变得更加复杂。在这些情况下，请仔细调整部署流程以满足您的需求。将部署管道和流程设计为一次部署到一个区域，而不是同时部署到多个区域。这减少了区域之间出现相关故障的机会。要了解 Amazon 用于自动部署软件的技术，请参阅 AWS Builders Library 文章[自动化安全、无需动手](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)的部署。
## 4.c: 可观察性
在设计多区域时，请考虑如何监控每个区域中所有组件的运行状况，以全面了解区域运行状况。这可能包括复制延迟的监控指标，这不是单区域工作负载的考虑因素。
在构建多区域架构时，也要考虑从备用区域观察工作负载的性能。这包括在备用区域运行运行状况检查和加那利群岛（综合测试），以提供主区域健康状况的外部视图。此外，您还可以使用 [Amazon CloudWatch Internet Monit](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-cloudwatch-internet-monitor/) or 从最终用户的角度了解外部网络的状态和工作负载的性能。主区域应具有相同的可观察性，以监控备用区域。
备用区域的加那利群岛应监控客户体验指标，以确定工作负载的整体运行状况。这是必需的，因为如果主区域出现问题，则主区域的可观察性可能会受到损害，从而影响您评估工作负载运行状况的能力。
在这种情况下，在该区域之外进行观察可以提供见解。这些指标应汇总到每个区域可用的仪表板和在每个区域创建的警报中。由于[CloudWatch](https://aws.amazon.com/cloudwatch/)是一项区域服务，因此需要在两个区域都设置警报。这些监控数据将用于调用从主区域故障转移到备用区域。
## 4.d：流程和程序
现在是回答 “我什么时候应该进行故障切换？” 这个问题的最佳时机 早在你需要之前。在问题出现之前，尽早制定包含人员、流程和技术的恢复计划，并定期对其进行测试。确定恢复决策框架。如果有经过良好实践的恢复过程并且对恢复时间了如指掌，则可以选择使用满足 RTO 目标的故障转移来启动恢复过程。该时间点可能是在发现主区域中的应用程序存在问题之后立即出现的，也可能是在该区域应用程序中的恢复选项已用尽之后。
故障转移操作本身应百分之百自动化，但激活故障切换的决定应由人来做出，通常是组织中少数预先确定的个人。这些人应考虑数据丢失和有关事件的信息。此外，还需要在组织内部明确定义和全面了解故障转移的标准。要定义和完成这些流程，您可以使用 [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：成本和复杂性
多区域架构的成本影响是由更高的基础设施使用率、运营开销和资源时间造成的。如前所述，预配置时，备用区域的基础设施成本与主区域的基础设施成本相似，因此总成本会翻一番。配置容量，使其足以满足日常运营需求，但仍保留足够的缓冲容量来容纳需求激增。然后在每个区域配置相同的限制。
此外，如果您采用主动-主动架构，则可能需要进行应用程序级别的更改才能在多区域架构中成功运行应用程序。这些变更的设计和操作可能既耗时又耗费资源。组织至少需要花时间了解每个地区的技术和业务依赖关系，并设计故障转移和故障恢复流程。
团队还应进行正常的故障转移和故障恢复练习，以便对活动期间使用的运行手册感到满意。尽管这些活动对于从多区域投资中获得预期结果至关重要，但它们代表着机会成本，会占用其他活动的时间和资源。
## 4.g：组织多区域故障转移策略
AWS 区域 提供故障隔离边界，防止相关故障，并控制 AWS 服务 损伤发生时对单个区域的影响。您可以使用这些故障边界来构建由每个区域中独立的故障隔离副本组成的多区域应用程序，以限制共享命运场景。这使您可以构建多区域应用程序，并使用一系列方法（从备份和恢复，到指示灯，再到主动-主动）来实现您的多区域架构。但是，应用程序通常不会孤立运行，因此请考虑将要使用的组件及其依赖关系作为故障转移策略的一部分。通常，多个应用程序协同工作以支持*用户故事*，这是为最终用户提供的一项特定功能，例如在社交媒体应用程序上发布图片和标题或在电子商务网站上结账。因此，您应该制定组织多区域故障转移策略，以提供必要的协调和一致性，使您的方法取得成功。
组织可以从四种高级策略中进行选择，以指导多区域方法。从最精细的方法到最广泛的方法列出了这些方法：
+ 组件级故障转移
+ 单个应用程序故障转移
+ 依赖关系图故障转移
+ 整个应用程序组合故障转移
每种策略都有权衡取舍，可以应对不同的挑战，包括故障转移决策的灵活性、测试故障转移组合的能力、模式行为的存在以及组织在规划和实施方面的投资。要更详细地了解每种策略，请参阅 AWS 博客文章《[创建组织多区域故障转移策略》](https://aws.amazon.com/blogs/architecture/creating-an-organizational-multi-region-failover-strategy/)。
## 关键指导
+ 审查所有 AWS 服务 配额，确保这些配额在工作负载将运行的所有区域中保持平衡。
+ 部署过程应一次针对一个区域，而不是同时涉及多个区域。
+ 诸如复制延迟之类的其他指标特定于多区域场景，应予以监控。
+ 将工作负载的监控范围扩展到主区域之外。监控每个区域的客户体验指标，并衡量每个运行工作负载的区域以外的这些数据。
+ 定期测试故障转移和故障恢复。为故障转移和故障恢复流程实施单一操作手册，并将其用于测试和实时活动。测试和直播活动的运行手册应该没有区别。
+ 了解故障转移策略的权衡取舍。实施依赖关系图或整个应用程序组合策略。