# 可靠性 **Topics** + [ # 基础 ](a-foundations.md) + [ # 工作负载架构 ](a-workload-architecture.md) + [ # 变更管理 ](a-change-management.md) + [ # 故障管理 ](a-failure-management.md) # 基础 **Topics** + [ # REL 1  如何管理服务配额和限制？ ](w2aac19b9b5b5.md) + [ # REL 2  如何规划网络拓扑？ ](w2aac19b9b5b7.md) # REL 1  如何管理服务配额和限制？ 基于云的工作负载架构存在服务配额（也被称作服务限制）。存在这些配额是为了防止意外预置超过您所需的资源，并对 API 操作的请求速率进行限制，以保护服务不会遭到滥用。还存在资源限制，例如，将比特推入光缆的速率，或物理磁盘上的存储量。 **Topics** + [ # REL01-BP01 了解服务限额和限制 ](rel_manage_service_limits_aware_quotas_and_constraints.md) + [ # REL01-BP02 跨多个账户和区域管理服务限额 ](rel_manage_service_limits_limits_considered.md) + [ # REL01-BP03 通过架构适应固定服务限额和限制 ](rel_manage_service_limits_aware_fixed_limits.md) + [ # REL01-BP04 监控和管理限额 ](rel_manage_service_limits_monitor_manage_limits.md) + [ # REL01-BP05 自动管理限额 ](rel_manage_service_limits_automated_monitor_limits.md) + [ # REL01-BP06 确保在当前限额与最大使用量之间存在足够的差距，以便应对失效转移 ](rel_manage_service_limits_suff_buffer_limits.md) # REL01-BP01 了解服务限额和限制 您要知道您的工作负载架构的默认配额和配额提高请求。您还要了解哪些资源限制（如磁盘或网络）可能会对您产生影响。 Service Quotas 是一项 AWS 服务，可帮助您在一个地方管理 100 多项 AWS 服务的限额。除了查找限额值，您还可以在 Service Quotas 控制台或通过 AWS 开发工具包请求增加限额并跟踪。AWS Trusted Advisor 提供服务限额检查，显示您的服务使用情况，以及某些服务在某些方面的限额。不同服务的默认服务限额也可在对应服务的 AWS 文档中找到，例如，请参阅 [Amazon VPC 配额](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html).通过配置使用计划，可在 API Gateway 内设置限流 API 的速率限制。可通过配置对应的服务进行设置的其他限制包括预置 IOPS、已分配的 RDS 存储，以及 EBS 卷分配等。Amazon Elastic Compute Cloud (Amazon EC2) 有自己的服务限制控制面板，可帮助您管理您的实例、Amazon Elastic Block Store (Amazon EBS) 和弹性 IP 地址限制。如果在某用例中，服务配额会对您的应用程序的性能造成影响，而且您无法根据自身需求对其进行调整，请联系 AWS 支持 了解是否有解决的办法。 **常见反模式：** + 部署工作负载，但未考虑所使用的 AWS 服务上的服务限额。 + 设计工作负载，但未不调查和考虑 AWS 服务的设计限制。 + 部署大量使用的工作负载来替换已知的现有工作负载，但没有配置必要的限额或预先联系 AWS 支持。 + 通过计划事件来将流量引导至您的工作负载，但没有配置必要的限额或预先联系 AWS 支持。 **建立此最佳实践的好处：** 了解服务配额，API 限流限制和设计限制，使您能够在设计、实施和运营工作负载时考虑到这些限制因素。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 在发布的文档和 Service Quotas 中查看 AWS 服务限额 + [AWS Service Quotas（以前称为限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + 通过查看部署代码确定工作负载所需的所有服务。 + 使用 AWS Config 查找 AWS 账户中使用的所有 AWS 资源。 + [AWS Config 支持的 AWS 资源类型和资源关系](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) + 您也可以使用 AWS CloudFormation 确定使用的 AWS 资源。查看 AWS 管理控制台中创建的资源或通过 list-stack-resources CLI 命令创建的资源。您还可以查看配置为要在模板自身部署的资源。 + [查看 AWS 管理控制台上的 AWS CloudFormation 堆栈数据和资源](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) + [适用于 CloudFormation 的 AWS CLI：list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) + 确定适用的服务配额。通过 Trusted Advisor 和 Service Quotas 使用能够以编程方式访问的信息。 ## 资源 **相关文档：** + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [AWS Trusted Advisor 最佳实践检查（见“服务限制”部分）](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) + [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL01-BP02 跨多个账户和区域管理服务限额 如果您目前使用多个 AWS 账户或 AWS 区域，请确保在运行生产工作负载的所有环境中都请求适当的限额。 每个账户的服务配额都可被跟踪。除非另有说明，否则每个限额都针对的是特定的 AWS 区域。除生产环境以外，还要管理所有适用的非生产环境中的配额，以避免妨碍测试与开发。 **常见反模式：** + 允许一个隔离区内的资源利用率增加，但没有相关机制保持其他隔离区中的容量。 + 手动单独设置隔离区中的所有限额。 + 无法确定区域级别隔离的部署是否具有足够的大小，在某个部署丢失时容纳来自其他区域的流量增长。 **建立此最佳实践的好处：** 在隔离区不可用时，确保您能够处理当前负载，这有助于减少在失效转移期间发生的错误数，并且不会导致您的客户遭遇服务拒绝访问的情况。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 根据您的服务要求、延迟、法规和灾难恢复（DR，Disaster Recovery）要求选择相关账户和区域。 + 确定跨所有相关账户、区域和可用区的服务限额。限制的范围具体到账户和区域。 + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) ## 资源 **相关文档：** + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [AWS Trusted Advisor 最佳实践检查（见“服务限制”部分）](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) + [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL01-BP03 通过架构适应固定服务限额和限制 请注意不可更改的服务配额和物理资源，并且在设计架构时要防止这些因素影响可靠性。 其中的示例包括网络带宽、AWS Lambda 有效负载大小、限制 API Gateway 的突发速率，以及并发用户连接至 Amazon Redshift 集群。 **常见反模式：** + 执行基准测试时间过短，利用突发限制，但随后希望服务在该容量下持续执行。 + 选择每个用户或客户使用一项服务资源的设计时，没有意识到设计存在限制，这些限制将导致扩展时设计失败。 **建立此最佳实践的好处：** 跟踪您工作负载其他部分中的 AWS 服务的固定限额和限制，例如连接限制、IP 地址限制和第三方服务限制，以便能够检测到何时接近限额，并使您能够在超出限额之前解决限额问题。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 了解固定服务限额：了解固定服务限额和限制，并围绕这些因素设计架构。 + [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) ## 资源 **相关文档：** + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [AWS Trusted Advisor 最佳实践检查（见“服务限制”部分）](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) + [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL01-BP04 监控和管理限额 评估您的可能使用情况，并适当提高您的限额，支持使用量按计划增长。 对于支持的服务，您可以通过配置 CloudWatch 警报来监控使用情况，并在接近配额时发出提醒，从而管理您的配额。这些警报可以从 Service Quotas 或 Trusted Advisor 触发。您还可以使用 CloudWatch Logs 上的指标筛选条件来搜索与提取日志中的模式，确定使用量是否快达到配额阈值。 **常见反模式：** + 配置警报，以在快达到 Service Quotas 时发出提醒，但没有关于如何响应提醒的流程。 + 只为 Service Quotas 支持的服务配置警报，不监控其他服务。 **建立此最佳实践的好处：** 自动跟踪 AWS 服务限额，并根据这些限额监控您的使用情况，使您可以了解何时达到限额。您也可以使用这些监控数据来评估何时可以降低限额，从而节省成本。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 监控和管理限额：评估您在 AWS 上的可能使用情况，适当提高您的区域服务限额，并支持使用量按计划增长。 + 获取当前资源使用量（例如存储桶、实例）。使用 Amazon EC2 DescribeInstances API 等服务 API 操作来收集当前资源使用情况信息。 + 捕获当前限额：使用 AWS Service Quotas、AWS Trusted Advisor 和 AWS 文档。 + AWS Service Quotas 是一项 AWS 服务，使用该服务可帮助您在一个地方管理 100 多项 AWS 服务的限额。 + 根据 Trusted Advisor 服务限制来确定您当前的服务限制。 + 使用服务 API 操作来确定当前服务限额（如果支持）。 + 记录已发出的限额提高请求及其状态。限额提高请求获得批准后，请确保更新您的记录以反映限额更改。 ## 资源 **相关文档：** + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [服务限制的 AWS Trusted Advisor 最佳实践检查](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html) + [AWS Answers 上的 AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) + [使用 Amazon CloudWatch 警报监控 Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL01-BP05 自动管理限额 实施工具以便在接近阈值时向您发送提醒。您可以自动发出限额提高请求：通过使用 AWS Service Quotas API，您可以自动发出限额提高请求。 如果将您的配置管理数据库 (CMDB) 或票证系统与 Service Quotas 集成，您可以自动跟踪配额提高请求和当前配额。除了 AWS 开发工具包之外，Service Quotas 还使用 AWS Command Line Interface（AWS CLI）提供自动化。 **常见反模式：** + 以电子表格的形式跟踪配额和使用情况。 + 每天、每周或每月运行使用情况报告，然后将使用情况与配额进行比较。 **建立此最佳实践的好处：** 自动跟踪 AWS 服务限额，并根据这些限额监控您的使用情况，从而让您了解何时接近限额。您可以设置自动流程，帮助您在需要时提出配额提高请求。当使用情况趋向于相反的方向时，您可能需要考虑降低一些限额，以实现降低风险（如果凭据被盗）和节省成本的效果。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 设置自动监控：通过开发工具包实施各种工具，以便在接近阈值时向您发出提醒。 + 利用 Service Quotas，通过自动限额监控解决方案（例如 AWS Limit Monitor 或从 AWS Marketplace 获得的产品）来增强服务。 + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) + [AWS 上的限额监控 – AWS 解决方案](https://aws.amazon.com/answers/account-management/limit-monitor/) + 使用 Amazon SNS 和 AWS Service Quotas API 来根据限额阈值来设置触发响应。 + 测试自动化。 + 配置限制阈值。 + 与来自 AWS Config、部署管道、Amazon EventBridge 或第三方的更改事件集成。 + 人工设置低限额阈值来测试响应。 + 设置触发器以根据通知采取适当措施，并在必要时联系 AWS 支持。 + 人工触发更改事件。 + 运行实际测试以测试限额提高更改流程。 ## 资源 **相关文档：** + [APN 合作伙伴：可帮助进行配置管理的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management) + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [AWS Trusted Advisor 最佳实践检查（见“服务限制”部分）](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) + [AWS 上的限额监控 – AWS 解决方案](https://aws.amazon.com/answers/account-management/limit-monitor/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL01-BP06 确保在当前限额与最大使用量之间存在足够的差距，以便应对失效转移 当资源出现故障时，它可能仍会被计入限额，直到被成功终止。在出现故障的资源被终止之前，请确保您的配额涵盖所有出现故障的资源与其替换资源的叠加。在计算此差距时，应将可用区故障考虑在内。 **常见反模式：** + 根据当前需求设置服务限额，而不考虑失效转移场景。 **建立此最佳实践的好处：** 当事件可能影响可用性时，云可让您实施策略来减小这些事件造成的影响或从这些事件中恢复。此类策略通常包括创建额外资源来替换出现故障的资源。您的限额策略必须适应这些额外资源。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 确保您的服务限额与最高使用量之间有足够的差距，以便应对失效转移。 + 根据您的部署模式、可用性要求和使用量增长情况确定服务限额。 + 根据需要请求增加限额。预计完成限额提高请求所需的时间。 + 确定可靠性要求（也称为“X 个 9”）。 + 构建故障场景（例如组件、可用区或区域缺失）。 + 确定部署方法（例如金丝雀部署、蓝/绿部署、红/黑部署或滚动部署）。 + 在当前限制中包含适当的缓冲区（例如 15%）。 + 预计使用量增长（例如监控使用量趋势）。 ## 资源 **相关文档：** + [AWS Marketplace：可以帮助跟踪限制的 CMDB 产品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) + [AWS Service Quotas（以前称为服务限制）](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) + [AWS Trusted Advisor 最佳实践检查（见“服务限制”部分）](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) + [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) + [什么是 Service Quotas？](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) **相关视频：** + [AWS Live re:Inforce 2019 – Service Quotas](https://youtu.be/O9R5dWgtrVo) # REL 2  如何规划网络拓扑？ 工作负载通常存在于多个环境中。其中包括多个云环境（可公开访问云和私有云），可能还包括现有数据中心基础设施。相关计划必须涵盖网络注意事项，如系统内部和系统间连接、公有 IP 地址管理、私有 IP 地址管理，以及域名解析。 **Topics** + [ # REL02-BP01 为工作负载公有端点使用高度可用的网络连接 ](rel_planning_network_topology_ha_conn_users.md) + [ # REL02-BP02 为云环境和本地部署环境之间的私有网络预置冗余连接 ](rel_planning_network_topology_ha_conn_private_networks.md) + [ # REL02-BP03 确保 IP 子网分配考虑扩展和可用性 ](rel_planning_network_topology_ip_subnet_allocation.md) + [ # REL02-BP04 轴辐式拓扑优先于多对多网格 ](rel_planning_network_topology_prefer_hub_and_spoke.md) + [ # REL02-BP05 在互相连接的所有私有地址空间中强制实施非重叠的私有 IP 地址范围 ](rel_planning_network_topology_non_overlap_ip.md) # REL02-BP01 为工作负载公有端点使用高度可用的网络连接 这些端点及其路由必须高度可用。为此，需使用高度可用的 DNS、内容分发网络 (CDN)、API Gateway、负载均衡或反向代理。 Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway 和 Elastic Load Balancing（ELB）都提供了高度可用的公共端点。您还可以选择评估 AWS Marketplace 软件设备是否适用于负载均衡和代理。 您的工作负载所提供的服务的用户，无论其是最终用户或其他服务，都要在这些服务终端节点上发起请求。您可以使用多个 AWS 资源以提供高度可用的端点。 Elastic Load Balancing 提供跨可用区的负载均衡，执行第 4 层（TCP）或第 7 层（http/https）路由，与 AWS WAF 集成，并与 AWS Auto Scaling 集成以帮助构建自我修复基础设施，吸收流量增长，并同时在流量减少时释放资源。 Amazon Route 53 是一项可扩展且高度可用的域名系统（DNS，Domain Name System）服务，可将用户请求连接至在 AWS 中运行的基础设施，如 Amazon EC2 实例、Elastic Load Balancing 负载均衡器或 Amazon S3 存储桶，此外还可用于将用户路由至 AWS 以外的基础设施。 AWS Global Accelerator 是一项网络层服务，您可以用它将流量引导至 AWS 全球网络中的最佳端点。 分布式拒绝服务（DDoS，Distributed Denial of Service）攻击会引发使您的用户的合法流量无法进入并降低可用性的风险。AWS Shield 提供自动防护，无需额外成本即可避免您的工作负载上的 AWS 服务端点遭受此类攻击。您可以使用 APN 合作伙伴和 AWS Marketplace 提供的虚拟设备来增强这些功能，以满足您的需求。 **常见反模式：** + 在实例或容器中使用公有互联网地址并通过 DNS 管理与它们的连接。 + 使用互联网协议地址而非域名查找服务。 + 为较大地理区域提供内容（网页、静态资产、媒体文件），而不使用内容分发网络。 **建立此最佳实践的好处：** 通过在工作负载中实施高度可用的服务，您将清楚自己的工作负载可供用户使用。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 确保为工作负载用户提供高度可用的连接：Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway 和 Elastic Load Balancing（ELB）都提供高度可用的面向公众的端点。您还可以选择评估 AWS Marketplace 软件设备是否适用于负载均衡和代理。 + 确保您与用户之间具有高度可用的连接。 + 确保使用高度可用的 DNS 来管理应用程序端点域名。 + 如果您的用户通过互联网访问应用程序，请使用服务 API 操作以确保正确使用互联网网关。另外，请确认托管应用程序端点的子网的路由表条目正确无误。 + [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html) + [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) + 确保在应用程序前使用高度可用的反向代理或负载均衡器。 + 如果用户通过本地部署环境访问您的应用程序，请确保 AWS 与本地部署环境之间的连接高度可用。 + 使用 Route 53 管理您的域名。 + [什么是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + 使用符合您要求的第三方 DNS 提供商。 + 使用 Elastic Load Balancing。 + [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + 使用符合您要求的 AWS Marketplace 设备。 ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助您规划联网的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=network) + [AWS Direct Connect 弹性建议](https://aws.amazon.com/directconnect/resiliency-recommendation/) + [适用于网络基础设施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) + [Amazon Virtual Private Cloud 连接选项白皮书](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) + [多数据中心 HA 网络连接](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) + [使用 Direct Connect 弹性工具包开始操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) + [VPC 终端节点和 VPC 终端节点服务 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) + [什么是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) + [什么是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) + [什么是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) + [什么是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + [使用 Direct Connect 网关](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) **相关视频：** + [AWS re:Invent 2018：Amazon VPC 的高级 VPC 设计和新功能（NET303）](https://youtu.be/fnxXNZdf6ew) + [AWS re:Invent 2019：适用于众多 VPC 的 AWS Transit Gateway 参考架构（NET406-R1）](https://youtu.be/9Nikqn_02Oc) # REL02-BP02 为云环境和本地部署环境之间的私有网络预置冗余连接 在单独部署的私有网络之间使用多个 AWS Direct Connect 连接或 VPN 隧道。使用多个 Direct Connect 位置实现高可用性。如果使用多个 AWS 区域，请确保其中至少有两个区域存在冗余。您可能想要评估终止 VPN 的 AWS Marketplace 设备。如果您使用 AWS Marketplace 设备，请在不同的可用区中部署冗余实例以实现高可用性。 AWS Direct Connect 是一项云服务，可以在本地环境和 AWS 之间轻松建立专用网络连接。使用 Direct Connect Gateway，您的本地数据中心可以连接至跨多个 AWS 区域的多个 AWS VPC。 此类冗余可解决会对连接弹性造成影响的潜在故障： + 您将如何灵活应对拓扑中的故障？ + 如果您配置错了某些内容并删除了连接，会发生什么情况？ + 您是否能应对服务流量或使用量的意外增加？ + 您是否能够吸收未遂的分布式拒绝服务 (DDoS) 攻击？ 若通过 VPN 将您的 VPC 连接至本地数据中心，您应该考虑在选择运行该设备所需的供应商和实例大小时所需要的弹性和带宽要求。如果您使用的 VPN 设备在其实施中没有弹性，则您应该通过第二个设备获取冗余连接。对于所有这些场景，您需要定义可接受的恢复时间并进行测试，以确保您可以满足这些要求。 如果选择通过 Direct Connect 连接将您的 VPC 连接至数据中心，而且您要求连接具有高可用性，请从每个数据中心获得冗余 Direct Connect 连接。冗余连接应使用来自与第一个不同位置的其他 Direct Connect 连接。如果您有多个数据中心，则确保连接在不同的位置终止。使用 [Direct Connect 弹性工具包](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) 以帮助您完成设置。 如果您选择使用 Site-to-Site VPN 并通过互联网失效转移到 VPN，一定要了解，它支持每个 VPN 隧道高达 1.25-Gbps 的吞吐量，但在多个 AWS 托管 VPN 隧道终止于同一 VGW 的情况下，不支持将等价多路径（ECMP，Equal Cost Multi Path）用于出站流量。我们不建议您使用 AWS 托管 VPN 作为 Direct Connect 连接的备份，除非您可以接受失效转移期间的速度低于 1 Gbps。 您还可以使用 VPC 端点将您的 VPC 私下连接至受支持的 AWS 服务和 VPC 端点服务，它们得到 AWS PrivateLink 的支持而无需通过公有互联网传输。终端节点为虚拟设备。它们是水平扩展、冗余，而且高度可用的 VPC 组件。它们支持在您的 VPC 和服务实例之间进行通信，而不会对您的网络流量施加可用性风险或带宽限制。 **常见反模式：** + 在本地网络和 AWS 之间只有一个连接供应方。 + 使用 AWS Direct Connect 连接的连接功能，但只有一个连接。 + 您的 VPN 连接只有一条路径。 **建立此最佳实践的好处：** 通过在云环境和公司或本地部署环境之间实施冗余连接，您可以确保两个环境之间的依赖服务能够可靠通信。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 确保您在 AWS 和本地部署环境之间具有高度可用的连接。在单独部署的私有网络之间使用多个 AWS Direct Connect 连接或 VPN 隧道。使用多个 Direct Connect 位置实现高可用性。如果使用多个 AWS 区域，请确保其中至少有两个区域存在冗余。您可能想要评估终止 VPN 的 AWS Marketplace 设备。如果您使用 AWS Marketplace 设备，请在不同的可用区中部署冗余实例以实现高可用性。 + 确保您拥有面向本地部署环境的冗余连接。您可能需要面向多个 AWS 区域的冗余连接，以满足可用性需求。 + [AWS Direct Connect 弹性建议](https://aws.amazon.com/directconnect/resiliency-recommendation/) + [使用冗余 Site-to-Site VPN 连接以提供故障转移](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) + 使用服务 API 操作确定正确使用了 Direct Connect 线路。 + [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) + [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) + [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) + [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) + [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) + [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) + [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) + 如果您仅有一个 Direct Connect 连接或没有此连接，请设置连接虚拟私有网关的冗余 VPN 隧道。 + [什么是 AWS Site-to-Site VPN？](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) + 捕获您的当前连接（例如，Direct Connect、虚拟私有网关、AWS Marketplace 设备）。 + 使用服务 API 操作查询 Direct Connect 连接的配置。 + [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) + [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) + [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) + [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) + [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) + [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) + [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) + 使用服务 API 操作收集路由表使用的虚拟私有网关。 + [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html) + [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) + 使用服务 API 操作收集路由表使用的 AWS Marketplace 应用程序。 + [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助您规划联网的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=network) + [AWS Direct Connect 弹性建议](https://aws.amazon.com/directconnect/resiliency-recommendation/) + [适用于网络基础设施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) + [Amazon Virtual Private Cloud 连接选项白皮书](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) + [多数据中心 HA 网络连接](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) + [使用冗余 Site-to-Site VPN 连接以提供故障转移](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) + [使用 Direct Connect 弹性工具包开始操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) + [VPC 终端节点和 VPC 终端节点服务 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) + [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) + [什么是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) + [什么是 AWS Site-to-Site VPN？](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) + [使用 Direct Connect 网关](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) **相关视频：** + [AWS re:Invent 2018：Amazon VPC 的高级 VPC 设计和新功能（NET303）](https://youtu.be/fnxXNZdf6ew) + [AWS re:Invent 2019：适用于众多 VPC 的 AWS Transit Gateway 参考架构（NET406-R1）](https://youtu.be/9Nikqn_02Oc) # REL02-BP03 确保 IP 子网分配考虑扩展和可用性 Amazon VPC IP 地址范围必须足够大，以满足工作负载的要求，包括考虑未来的扩展以及跨可用区为子网分配 IP 地址。这包括负载均衡器、EC2 实例和基于容器的应用程序。 当您规划网络拓扑时，第一步是定义 IP 地址空间本身。应（按照 RFC 1918 准则）为每个 VPC 分配私有 IP 地址范围。作为此流程的一部分，要满足以下要求： + 在每个区域中为多个 VPC 留出 IP 地址空间。 + 在 VPC 内，为跨多个可用区的多个子网留出空间。 + 始终在 VPC 内保留未使用的 CIDR 块空间以用于未来扩展。 + 确保有 IP 地址空间以满足您可能使用的任何 EC2 实例临时性队列的需求，如适用于机器学习的 Spot 队列、Amazon EMR 集群或 Amazon Redshift 集群。 + 注意，每个子网 CIDR 块中的前四个 IP 地址和最后一个 IP 地址将被预留而无法供您使用。 + 您应计划部署大型 VPC CIDR 块。注意，最初被分配到您的 VPC 的 VPC CIDR 块无法被更改或删除，但您可以向 VPC 添加额外的非重叠的 CIDR 块。虽然无法更改 IPv4 CIDR，但可以对 IPv6 CIDR 进行更改。请记住，部署最大的 VPC (/16) 会产生超过 65000 个 IP 地址。单单在基础 10.x.x.x IP 地址空间内，您可以预置 255 个这样的 VPC。因此，您可以趋向于过大数量而不是过小数量，这样更容易管理 VPC。 **常见反模式：** + 创建小型 VPC。 + 创建小型子网，然后在业务增长过程中向配置添加子网。 + 错误估计 Elastic Load Balancer 可以使用的 IP 地址数量。 + 在相同子网中部署多个高流量负载均衡器。 **建立此最佳实践的好处：** 这可确保您能适应工作负载增长要求，并在扩展过程中继续提供可用性。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 规划您的网络以适应增长、符合监管合规性以及实现与其他服务的集成。如果没有合理的规划，则增长可能会被低估、监管合规性可能会发生变化并且收购或私有网络连接可能难以实施。 + 根据您的服务要求、延迟、法规和灾难恢复（DR，Disaster Recovery）要求选择相关 AWS 账户和区域。 + 确定您的区域 VPC 部署需求。 + 确定 VPC 的大小。 + 确定您是否要部署多 VPC 连接。 + [什么是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) + [单区域多 VPC 连接](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) + 确定您是否需要隔离网络以满足法规要求。 + 使 VPC 尽可能大。最初为 VPC 分配的 VPC CIDR 块无法更改或删除，但您可以向 VPC 添加额外的非重叠 CIDR 块。但是，这样可能会分割您的地址范围。 + 使 VPC 尽可能大。最初为 VPC 分配的 VPC CIDR 块无法更改或删除，但您可以向 VPC 添加额外的非重叠 CIDR 块。但是，这样可能会分割您的地址范围。 ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助您规划联网的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=network) + [适用于网络基础设施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) + [Amazon Virtual Private Cloud 连接选项白皮书](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) + [多数据中心 HA 网络连接](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) + [单区域多 VPC 连接](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) + [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) **相关视频：** + [AWS re:Invent 2018：Amazon VPC 的高级 VPC 设计和新功能（NET303）](https://youtu.be/fnxXNZdf6ew) + [AWS re:Invent 2019：适用于众多 VPC 的 AWS Transit Gateway 参考架构（NET406-R1）](https://youtu.be/9Nikqn_02Oc) # REL02-BP04 轴辐式拓扑优先于多对多网格 如果通过 VPC 对等连接、AWS Direct Connect 或 VPN 连接的网络地址空间超过两个（例如，VPC 和本地网络），则使用与 AWS Transit Gateway 所提供的模型类似的轴辐式模型。 如果只有两个此类网络，您可以简单地使其相互连接，但随着网络数量的增加，这种网格连接的复杂性将变得无法接受。AWS Transit Gateway 提供易于维护的轴辐式模型，允许在您的多个网络中对流量进行路由。 ![\[显示未使用 AWS Transit Gateway 的情况的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png) ![\[显示使用 AWS Transit Gateway 的情况的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png) **常见反模式：** + 使用 VPC 对等连接来连接两个以上的 VPC。 + 为每个 VPC 建立多个 BGP 会话，从而建立跨多个 AWS 区域的虚拟私有云（VPC，Virtual Private Cloud）连接。 **建立此最佳实践的好处：** 随着网络数量增加，这种复杂的网格连接将变得无法维持。AWS Transit Gateway 提供易于维护的轴辐式模型，允许在您的多个网络中路由流量。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 轴辐式拓扑优先于多对多网格。如果通过 VPC 对等连接、AWS Direct Connect 或 VPN 连接的网络地址空间超过两个（VPC，本地网络），则使用与 AWS Transit Gateway 所提供的模型类似的轴辐式模型。 + 如果只有两个此类网络，您只需将其相互连接即可，但随着网络数量的增长，这种复杂的网格连接将变得无法维持。AWS Transit Gateway 提供易于维护的轴辐式模型，允许在您的多个网络中路由流量。 + [什么是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助您规划联网的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=network) + [适用于网络基础设施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) + [多数据中心 HA 网络连接](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) + [VPC 终端节点和 VPC 终端节点服务 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) + [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) + [什么是 Transit Gateway？](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) **相关视频：** + [AWS re:Invent 2018：Amazon VPC 的高级 VPC 设计和新功能（NET303）](https://youtu.be/fnxXNZdf6ew) + [AWS re:Invent 2019：适用于众多 VPC 的 AWS Transit Gateway 参考架构（NET406-R1）](https://youtu.be/9Nikqn_02Oc) # REL02-BP05 在互相连接的所有私有地址空间中强制实施非重叠的私有 IP 地址范围 多个 VPC 通过对等连接或 VPN 连接时，各个 VPC 的 IP 地址范围不得重叠。与之类似，您必须避免 VPC 和本地部署环境或与其他您使用的云提供商之间出现 IP 地址冲突。您还必须能够在需要时分配私有 IP 地址范围。 IP 地址管理 (IPAM) 系统可以帮助解决这个问题。AWS Marketplace 提供多个 IPAM。 **常见反模式：** + 在 VPC 中使用与本地部署或企业网络相同的 IP 范围。 + 不必追踪用于部署工作负载的 VPC 的 IP 范围。 **建立此最佳实践的好处：** 主动规划网络可确保您不会遇到互连网络中多次出现相同 IP 地址的情况。这可防止使用不同应用程序的工作负载部分出现路由问题。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 监控和管理您的 CIDR 使用。评估您在 AWS 上的可能使用量、将 CIDR 范围添加到现有 VPC 并创建 VPC 以便使用量实现计划增长。 + 捕获当前的 CIDR 使用量（例如，VPC、子网） + 使用服务 API 操作收集当前的 CIDR 使用量数据。 + 捕获您当前的子网使用量。 + 使用服务 API 操作在每个区域中按 VPC 收集子网。 + [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) + 记录当前使用量。 + 确定您是否创建了任何重叠 IP 范围。 + 计算备用容量。 + 记录重叠的 IP 范围。您可以迁移到新地址范围，或使用 AWS Marketplace 的网络和端口转换（NAT）设备（如果需要连接重叠范围）。 ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助您规划联网的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=network) + [适用于网络基础设施的 AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) + [Amazon Virtual Private Cloud 连接选项白皮书](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) + [多数据中心 HA 网络连接](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) + [什么是 Amazon VPC？](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) + [什么是 IPAM？](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) **相关视频：** + [AWS re:Invent 2018：Amazon VPC 的高级 VPC 设计和新功能（NET303）](https://youtu.be/fnxXNZdf6ew) + [AWS re:Invent 2019：适用于众多 VPC 的 AWS Transit Gateway 参考架构（NET406-R1）](https://youtu.be/9Nikqn_02Oc) # 工作负载架构 **Topics** + [ # REL 3  如何设计工作负载服务架构？ ](w2aac19b9b7b5.md) + [ # REL 4  您如何在分布式系统中设计交互以预防发生故障？ ](w2aac19b9b7b7.md) + [ # REL 5  您如何在分布式系统中进行交互设计，从而缓解或经受住故障影响？ ](w2aac19b9b7b9.md) # REL 3  如何设计工作负载服务架构？ 使用面向服务的架构 (SOA) 或微服务架构构建高度可扩展的可靠工作负载。面向服务的架构 (SOA) 可通过服务接口使软件组件可重复使用。微服务架构则进一步让组件变得更小、更简单。 **Topics** + [ # REL03-BP01 选择如何划分工作负载 ](rel_service_architecture_monolith_soa_microservice.md) + [ # REL03-BP02 构建专注于特定业务领域和功能的服务 ](rel_service_architecture_business_domains.md) + [ # REL03-BP03 根据 API 提供服务合同 ](rel_service_architecture_api_contracts.md) # REL03-BP01 选择如何划分工作负载 在确定应用程序的弹性要求时，工作负载划分很重要。应尽可能避免使用整体式架构。相反，应仔细考虑哪些应用程序组件可以分解为多项微服务。根据您的应用程序要求，最终应尽可能采用服务导向型架构（SOA）与微服务组合的形式。能够实现无状态的工作负载更容易部署为微服务。 **期望结果：** 工作负载应该可支持、可扩展，并尽可能地松散耦合。 在选择如何划分工作负载时，要权衡其优点和复杂性。适用于即将首次发布的新产品的功能有别于从一开始就构建用于扩展的工作负载的需求。重构一个现有的整体架构时，您需要考虑应用程序对无状态分解的支持程度。通过将服务分解为较小的部分，可以让职责明确的小型团队来开发和管理它们。然而，较小的服务会带来复杂性，包括可能会增加延迟，调试变得更复杂，而且加重运营负担。 **常见反模式：** + 如示例所示， [微服务 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是这样一种情况：原子组件变得高度相互依赖，牵一发而动全身，使组件像一块整体一样死板而又脆弱。 **建立此实践的好处：** + 更多特定分段可以提高敏捷性、组织灵活性和可扩展性。 + 减小了服务中断的影响。 + 应用程序组件可能有不同的可用性要求，可通过更加原子化的分段来满足这些要求。 + 支持工作负载的团队职责分明。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 请根据工作负载的分段方式选择架构类型。选择 SOA 或微服务架构（极少数情况下是整体架构）。即便在刚开始选择整体架构，您必须确保它是模块化的，而且由于您的产品随着采用的用户增加而扩展，它最终也可转变成为 SOA 或微服务架构。SOA 和微服务各自提供较小的区段，它们是现代可扩展和可靠架构的首选，但您需要认真权衡利弊，尤其在部署微服务架构时。 一项主要的权衡是您现在使用的是分布式计算架构，可能更难实现用户延迟要求，还增加了调试和跟踪用户交互的复杂性。您可以使用 AWS X-Ray 来帮助解决此问题。需要考虑的另一个影响是，您管理的应用程序数量增加时，运营复杂性也会随之增加，这要求部署多个相互独立组件。 ![\[整体架构、服务导向型架构和微服务架构之间的比较图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png) ## 实施步骤 + 确定构建或重构应用程序所需的适当架构。SOA 和微服务分别提供较小分段，这是现代可扩展的可靠架构的首选。要在实现较小分段的同时避免一些微服务复杂性，SOA 是很好的折中方案。有关更多详细信息，请参阅 [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html). + 如果您的工作负载适合，并且您的组织可以支持，则应使用微服务架构来实现最佳敏捷性和可靠性。有关更多详细信息，请参阅 [在 AWS 上实施微服务。](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + 考虑遵循 [*Strangler Fig* 模式，](https://martinfowler.com/bliki/StranglerFigApplication.html) 将整体架构重构为较小的组件。这包括逐步用新的应用程序和服务替换特定的应用程序组件。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 作为增量重构的起点。有关更多详细信息，请参阅 [使用绞杀者模式无缝迁移本地传统工作负载](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)。 + 实施微服务可能需要采用一种服务发现机制，让这些分布式服务能够相互通信。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 可用于服务导向型架构，以实现可靠的发现和服务访问。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 也可用于动态的基于 DNS 的服务发现。 + 如果您要从整体架构迁移到 SOA，[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 可作为服务总线来帮助弥合这一差距（在云中重新设计传统应用程序时）。 + 对于具有单个共享数据库的现有整体架构，请选择将数据重组为较小分段的方式。可以按业务部门、访问模式或数据结构来划分。在重构过程的这一阶段，应选择是使用关系型还是非关系型（NoSQL）数据库来继续操作。有关更多详细信息，请参阅 [从 SQL 到 NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html). **实施计划的工作量级别：** 高 ## 资源 **相关最佳实践：** + [REL03-BP02 构建专注于特定业务领域和功能的服务](rel_service_architecture_business_domains.md) **相关文档：** + [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) + [什么是服务导向型架构？](https://aws.amazon.com/what-is/service-oriented-architecture/) + [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) + [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) + [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) + [AWS 上的微服务](https://aws.amazon.com/microservices/) + [什么是 AWS App Mesh？](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) **相关示例：** + [迭代应用程序现代化研讨会](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) **相关视频：** + [利用 AWS 上的微服务实现卓越](https://www.youtube.com/watch?v=otADkIyugzY) # REL03-BP02 构建专注于特定业务领域和功能的服务 面向服务的架构（SOA，Service-Oriented Architecture）采用由业务需求定义的划分明确的功能来构建服务。微服务则使用领域模型和有界上下文对此进行进一步限制，使每项服务都只用于一种用途。专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。 在设计微服务架构时，借助于领域驱动设计 (DDD) 对使用实体的业务问题进行建模十分有帮助。以 Amazon.com 网站为例，实体可能包括包装、配送、时间表、价格、折扣和货币。然后，该模型会使用 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)进一步细分为更小的模型，具有相似功能和属性的实体在边界上下文中被分到一组。因此，在 Amazon.com 例子中，包装、配送和时间表是装运上下文的一部分，而价格、折扣和货币是定价上下文的一部分。通过将模型细分为不同的上下文，即可得到如何确定微服务边界的模板。 ![\[如何确定微服务边界的模型模板\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/building-services.png) **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 根据业务领域及各自的功能设计工作负载。专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。 + 执行领域分析，为您的工作负载制定领域驱动设计 (DDD) 方案。然后，您可以选择一个架构类型，以满足您的工作负载需求。 + [如何将整体式架构分解为多项微服务](https://martinfowler.com/articles/break-monolith-into-microservices.html) + [在被遗留系统包围时通过 DDD 开始着手](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) + [Eric Evans“领域驱动设计：解决软件核心的复杂性”](https://www.amazon.com/gp/product/0321125215) + [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + 将服务分解成尽可能小的组件。借助微服务架构，您可以将工作负载分解成功能最小的组件，以便支持组织的可扩展性和敏捷性。 + 根据工作负载及其设计目标、限制和任何其他使用注意事项来定义 API。 + 定义 API。 + API 定义应允许增加参数。 + 定义设计可用性。 + 您的 API 可以具有针对不同功能的多个设计目标。 + 设置限制 + 通过测试来确定工作负载的功能限制。 ## 资源 **相关文档：** + [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) + [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) + [Eric Evans“领域驱动设计：解决软件核心的复杂性”](https://www.amazon.com/gp/product/0321125215) + [在被遗留系统包围时通过 DDD 开始着手](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) + [如何将整体式架构分解为多项微服务](https://martinfowler.com/articles/break-monolith-into-microservices.html) + [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) + [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) + [AWS 上的微服务](https://aws.amazon.com/microservices/) # REL03-BP03 根据 API 提供服务合同 服务合同是团队之间关于服务集成的成文协议，它包括机器可读的 API 定义、速率限制和性能预期。版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。只要遵守合同，即可随时进行部署。服务提供商团队可以使用自己选择的技术堆栈来满足 API 合同要求。同样，服务使用者可以使用自己的技术。 微服务将面向服务的架构（SOA，Service-Oriented Architecture）的概念提升到创建具有最小功能集的服务。每项服务都会发布一个 API，以及使用相应服务的设计目标、限制和其他注意事项。这会通过调用 *应用程序* 建立合同。这可以实现三个主要优势： + 服务具有一个需要解决的简明的业务问题，以及出现该业务问题的小型团队。这有助于更好地扩展组织。 + 只要满足 API 和其他合同要求，团队就可以随时进行部署。 + 只要满足 API 和其他合同要求，团队就可以使用他们想用的任何技术堆栈。 Amazon API Gateway 是一种完全托管式服务，可以帮助开发人员轻松创建、发布、维护、监控和保护任意规模的 API。它负责处理多达数十万个并发 API 调用的接受和处理过程中涉及的所有任务，包括流量管理、授权和访问控制、监控以及 API 版本管理。采用 OpenAPI 规范 (OAS)，亦即之前的 Swagger 规范，您可以定义 API 合同并将其导入到 API Gateway。然后，您便可以通过 API Gateway 对 API 进行版本控制与部署。 **未建立这种最佳实践的情况下暴露的风险等级：** 低 ## 实施指导 + 按照不同 API 提供服务合同：服务合同是团队之间关于服务集成的记录在案的协议，它包括机器可读的 API 定义、速率限制和性能预期等。 + [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) + 版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。 + Amazon API Gateway 是一种完全托管式服务，可以帮助开发人员轻松创建任意规模的 API。采用 OpenAPI 规范（OAS，OpenAPI Specification），亦即之前的 Swagger 规范，您可以定义 API 合同并将其导入到 API Gateway。然后，您便可以通过 API Gateway 对 API 进行版本控制与部署。 ## 资源 **相关文档：** + [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) + [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) + [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) + [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) + [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) + [AWS 上的微服务](https://aws.amazon.com/microservices/) # REL 4  您如何在分布式系统中设计交互以预防发生故障？ 分布式系统依赖于通信网络实现组件（例如服务器或服务）的互联。尽管这些网络中存在数据丢失或延迟，但是您的工作负载必须可靠运行。分布式系统组件的运行方式不得对其他组件或工作负载产生负面影响。这些最佳实践能够预防故障，并改善平均故障间隔时间（MTBF）。 **Topics** + [ # REL04-BP01 确定需要哪种类型的分布式系统 ](rel_prevent_interaction_failure_identify.md) + [ # REL04-BP02 实施松耦合的依赖关系 ](rel_prevent_interaction_failure_loosely_coupled_system.md) + [ # REL04-BP03 持续工作 ](rel_prevent_interaction_failure_constant_work.md) + [ # REL04-BP04 使所有响应幂等 ](rel_prevent_interaction_failure_idempotent.md) # REL04-BP01 确定需要哪种类型的分布式系统 硬性实时分布式系统需要同步并快速地做出响应，而软性实时系统有更宽松的以分钟计的时间窗口，或更多响应。离线系统会对响应进行批处理或异步处理。硬性实时分布式系统具有最严格的可靠性要求。 硬性实时分布式系统 [要面对分布式系统中的](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 最艰巨的挑战，又被称作请求/回复服务。因为收到请求的时间不可预测，而响应必须迅速（例如，客户正急切地等待响应）。此类示例包括，前端 Web 服务器、指令管道、信用卡交易，以及每个 AWS API 和语音通话。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 确定需要哪种类型的分布式系统。分布式系统要应对的挑战包括延迟、扩展、了解联网 API、对数据进行集结与解集，以及 Paxos 等算法的复杂性。随着系统规模扩大并呈现出更明显的分布态势，我们现在需要在日常生活中面对过去只存在于理论中的边缘情况。 + [Amazon Builders' Library：分布式系统相关挑战](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + 硬性实时分布式系统需要快速的同步响应。 + 软性实时系统则有更宽松的以分钟计的时间窗口，或更好响应。 + 离线系统会对响应进行批处理或异步处理。 + 硬性实时分布式系统具有最严格的可靠性要求。 ## 资源 **相关文档：** + [Amazon EC2：确保幂等性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library：分布式系统相关挑战](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library：可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) **相关视频：** + [2019 年 AWS 纽约峰会：介绍事件驱动型架构和 Amazon EventBridge（MAD205）](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括松耦合、持续工作和静态稳定性）](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://youtu.be/h46IquqjF3E) # REL04-BP02 实施松耦合的依赖关系 队列系统、流系统、工作流和负载均衡器等依赖关系是松耦合的。松耦合有助于隔离某个组件的行为与依赖于它的其他组件的行为，从而提升弹性和敏捷性。 如果对一个组件的更改会强迫其他依赖于它的组件也发生更改，则它们之间的关系为 *紧密* 耦合。 *松散* 耦合会打破这种依赖关系，使存在依赖关系的组件只需了解经过版本控制而且已发布的接口。在依赖项之间实施松散耦合将隔离一个组件中的故障，防止对其他组件造成影响。 松散耦合让您可以为组件增加额外的代码或功能，同时在最大程度上降低依赖于它的组件的风险。而且，随着您可以横向扩展，或甚至更改依赖项的底层实施，可扩展性也得到改善。 要通过松散耦合进一步提升弹性，在可能的情况下采用异步组件交互。若确定对请求进行注册已足够，则此模型适用于无需立即响应的任何交互。它包含一个生成事件的组件和另外一个使用事件的组件。两个组件不会通过直接点对点交互，但通常经由中间持久存储层集成，例如，SQS 队列或诸如 Amazon Kinesis 或 AWS Step Functions 流数据平台。 ![\[显示队列系统和负载均衡器等依赖关系是松耦合的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png) Amazon SQS 队列和 Elastic Load Balancer 只是为松散耦合增加中间层的两种方式。您还可以使用 Amazon EventBridge 在 AWS 云 中构建事件驱动型架构，而前者可从其依赖的服务（事件使用器）中提取客户端（事件产生器）。当您需要进行高吞吐量、基于推送的多对多消息收发时，Amazon Simple Notification Service（Amazon SNS）是可供选择的高效解决方案。通过 Amazon SNS 主题，您的发布者系统可以呈扇形将消息分发到大量订阅者终端节点以便进行并行处理。 虽然队列具有多项优点，但在大多数硬性实时系统中，早于阈值时间（通常为秒）的请求应被视为过时（客户端已放弃而且不再等待响应）而不被处理。因此，较新（而且可能依然有效）的请求会被处理。 **常见反模式：** + 将单一实例作为工作负载的一部分部署。 + 直接在工作负载层之间调用 API，不具备故障转移或异步处理请求的功能。 **建立此最佳实践的好处：** 松耦合有助于隔离某个组件的行为与依赖于它的其他组件的行为，从而提升弹性和敏捷性。组件中的故障相互隔离。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 实施松耦合的依赖关系。队列系统、流系统、工作流和负载均衡器等依赖关系是松耦合的。松耦合有助于隔离某个组件的行为与依赖于它的其他组件的行为，从而提升弹性和敏捷性。 + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) + 您可借助 Amazon EventBridge 构建松耦合的分布式事件驱动型架构。 + [2019 年 AWS 纽约峰会：介绍事件驱动型架构和 Amazon EventBridge（MAD205）](https://youtu.be/tvELVa9D9qU) + 如果对一个组件的更改会强迫其他依赖于它的组件也发生更改，则它们之间的关系为紧耦合。松耦合会打破这种依赖关系，使存在依赖关系的组件只需了解经过版本控制而且已发布的接口。 + 让组件在可能的情况下进行异步交互。此模型适用于无需立即响应，只需确认请求已注册就足够的任何交互。 + [AWS re:Invent 2019：使用 Amazon SQS 和 Lambda 的可扩展无服务器事件驱动型应用程序（API304）](https://youtu.be/2rikdPIFc_Q) ## 资源 **相关文档：** + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon EC2：确保幂等性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library：分布式系统相关挑战](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library：可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) **相关视频：** + [2019 年 AWS 纽约峰会：介绍事件驱动型架构和 Amazon EventBridge（MAD205）](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括松耦合、持续工作和静态稳定性）](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://youtu.be/h46IquqjF3E) + [AWS re:Invent 2019：使用 Amazon SQS 和 Lambda 的可扩展无服务器事件驱动型应用程序（API304）](https://youtu.be/2rikdPIFc_Q) # REL04-BP03 持续工作 系统会在负载中存在剧烈快速更改时失败。例如，如果您的工作负载执行的一项运行状况检查监控着数千个服务器的运行状况，每次都应发送相同大小的有效负载（当前状态的完整快照）。无论是否有服务器或有多少服务器发生故障，运行状况检查系统都会持续工作，而不会有剧烈、快速的变动。 例如，如果运行状况检查系统正在监控 100000 个服务器，它的标称负载低于通常而言较低的服务器故障率。但如果发生重大事件使一半的服务器运行不正常，则运行状况检查系统会因为尝试更新通知系统以及向其客户端传送状态而变得不堪重负。因此，运行状况检查系统每次应发送当前状态的完整快照。100000 个服务器的运行状况，若每个以一个比特代表，则仅需要 12.5-KB 有效负载。无论是没有服务器发生故障还是所有服务器都发生故障，运行状况检查系统都会持续工作，而大幅度骤变也不会威胁到系统的稳定性。这实际上是 Amazon Route 53 处理端点（例如 IP 地址）的运行状况检查来确定最终用户如何路由到这些端点的方式。 **未建立这种最佳实践的情况下暴露的风险等级：** 低 ## 实施指导 + 持续工作，使系统不会在负载出现骤变时失败。 + 实施松耦合的依赖关系。队列系统、流系统、工作流和负载均衡器等依赖关系是松耦合的。松耦合有助于隔离某个组件的行为与依赖于它的其他组件的行为，从而提升弹性和敏捷性。 + [Amazon Builders' Library：可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括持续工作）](https://youtu.be/O8xLxNje30M?t=2482) + 例如，如果运行状况检查系统正在监控 10 万台服务器工程设计工作负载，不论成功或失败的次数，有效负载大小均能保持稳定。 ## 资源 **相关文档：** + [Amazon EC2：确保幂等性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library：分布式系统相关挑战](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library：可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/) **相关视频：** + [2019 年 AWS 纽约峰会：介绍事件驱动型架构和 Amazon EventBridge（MAD205）](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括持续工作）](https://youtu.be/O8xLxNje30M?t=2482) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括松耦合、持续工作和静态稳定性）](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://youtu.be/h46IquqjF3E) # REL04-BP04 使所有响应幂等 幂等服务承诺每个请求只完成一次，因此发起多个相同请求与进行单个请求的效果相同。幂等服务使客户端可以轻松进行重试，而不必担心错误地处理多次。要执行此操作，客户端可以发出具有幂等性令牌的 API 请求，每当重复请求时都会使用同一令牌。幂等服务 API 使用令牌返回响应，该响应与首次完成请求时返回的响应相同。 在分布式系统中，至多（客户端仅发起一个请求）或至少（持续发起请求直到客户端收到成功确认）执行某项操作一次并不难。难就难在要保证某项操作具有幕等性，亦即它被 *恰好* 执行一次，从而使发起多个相同的请求与发起一个请求的效果相同。在 API 中使用幕等性令牌，服务可以一次或多次收到变异请求，而不会创建重复记录或产生副作用。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 使所有响应幂等。幂等服务承诺每个请求只完成一次，因此发起多个相同请求与进行单个请求的效果相同。 + 客户端可以发出具有幂等性令牌的 API 请求，每当重复请求时都会使用同一令牌。幂等服务 API 使用令牌返回响应，该响应与首次完成请求时返回的响应相同。 + [Amazon EC2：确保幂等性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) ## 资源 **相关文档：** + [Amazon EC2：确保幂等性](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library：分布式系统相关挑战](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library：可靠性、持续工作和安然无忧](https://aws.amazon.com/builders-library/reliability-and-constant-work/) **相关视频：** + [2019 年 AWS 纽约峰会：介绍事件驱动型架构和 Amazon EventBridge（MAD205）](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018：闭环系统和开放思维：如何掌控不同规模的系统（ARC337）（包括松耦合、持续工作和静态稳定性）](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019：迁移到事件驱动型架构（SVS308）](https://youtu.be/h46IquqjF3E) # REL 5  您如何在分布式系统中进行交互设计，从而缓解或经受住故障影响？ 分布式系统依赖于通信网络以便使组件互相连接（如服务器或服务等）。尽管这些网络中存在数据丢失或延迟，但是您的工作负载必须可靠运行。分布式系统组件的运行方式不得对其他组件或工作负载产生负面影响。这些最佳实践使工作负载能够承受压力或故障，从中更快地恢复，并且降低此类伤害的影响。其结果是缩短平均恢复时间（MTTR）。 **Topics** + [ # REL05-BP01 实施轻松降级以将适用的硬依赖关系转换为软依赖关系 ](rel_mitigate_interaction_failure_graceful_degradation.md) + [ # REL05-BP02 限制请求 ](rel_mitigate_interaction_failure_throttle_requests.md) + [ # REL05-BP03 控制与限制重试调用 ](rel_mitigate_interaction_failure_limit_retries.md) + [ # REL05-BP04 快速失效机制和限制队列 ](rel_mitigate_interaction_failure_fail_fast.md) + [ # REL05-BP05 设置客户端超时 ](rel_mitigate_interaction_failure_client_timeouts.md) + [ # REL05-BP06 尽可能使服务为无状态 ](rel_mitigate_interaction_failure_stateless.md) + [ # REL05-BP07 实施紧急杠杆 ](rel_mitigate_interaction_failure_emergency_levers.md) # REL05-BP01 实施轻松降级以将适用的硬依赖关系转换为软依赖关系 某个组件的依赖关系运行不正常时，该组件仍可在性能降低的条件下运行。例如，当依赖关系调用失败时，进行故障转移，使用预先确定的静态响应。 假设被服务 A 调用的服务 B 反过来调用服务 C。 ![\[图中显示若服务 B 调用服务 C 失败，服务 B 向服务 A 返回降级响应\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/graceful-degradation.png) 当服务 B 调用服务 C 时，它会收到错误或超时消息。而服务 B，因为缺少来自服务 C（及其所包含数据）的响应，则会返回它能够做出的响应。它可以是最后缓存的正确值，或服务 B 可以使用预先确定的静态响应取代它收到的来自服务 C 的响应。然后，向调用方（即服务 A）返回降级响应。若无此静态响应，服务 C 的故障将级联传递至服务 B 和服务 A，因此而丧失可用性。 按照硬依赖关系可用性等式中的倍乘系数（见 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)），C 的可用性的任何降低将严重影响 B 的有效可用性。通过返回静态响应，服务 B 能够缓解 C 中的故障的影响，而且，虽然被降级，可使服务 C 看起来似乎 100% 可用（假设它在错误的情况下可靠地返回静态响应）。注意，静态响应是返回错误的简单替代，而不是使用其他方式对响应进行重新计算的尝试。此类采用完全不同的机制试图达到相同结果的尝试被称作回退行为，是一种要被避免的反模式。 优雅降级的另一个例子是 *断路器模式*.当故障为临时性时，应采用重试策略。若情况并非如此，而且操作很有可能失败，则断路器模式会防止客户端执行可能失败的请求。系统照常处理请求时，断路器会处于关闭状态，让请求正常通过。当远程系统开始返回错误或出现高延迟，断路器就会打开，依赖项被忽略，或者结果会被更轻松获取但较不全面的响应（可能只是响应缓存）所取代。系统将定期尝试调用依赖项，以确定它是否已恢复。出现这种情况时，断路器将处于关闭状态。 ![\[显示断路器处于开启和关闭状态的图表。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/circuit-breaker.png) 除了图表中显示的关闭和开启状态，在开启状态内的可配置时间段以后，断路器可能会变为半开启状态。在此状态中，它会以远低于正常水平的速率定期尝试调用服务。此探测器用于检查服务的运行状况。在半开启状态中多次成功以后，断路器会转为关闭，并恢复正常请求。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 实施轻松降级以将适用的硬依赖关系转换为软依赖关系。某个组件的依赖关系运行不正常时，该组件仍可在性能降低的条件下运行。例如，当依赖关系调用失败时，进行故障转移，使用预先确定的静态响应。 + 通过返回静态响应，您的工作负载会缓解其依赖项中发生的故障。 + [Well-Architected 实验室：第 300 级：实施运行状况检查和管理依赖项以提高可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) + 在重试操作可能失败时检测到该情况，并防止您的客户端使用断路器模式进行失败调用。 + [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html) ## 资源 **相关文档：** + [Amazon API Gateway：对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + [CircuitBreaker（对《发布它！》一书中的“断路器”部分进行的总结）](https://martinfowler.com/bliki/CircuitBreaker.html) + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + [Michael Nygard《发布它！ 设计和部署生产就绪的软件》（Release It\$1 Design and Deploy Production-Ready Software）](https://pragprog.com/titles/mnee2/release-it-second-edition/) + [Amazon Builders' Library：避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) + [Amazon Builders' Library：缓存挑战和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) + [Amazon Builders' Library：为超时、重试和回退引入抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) **相关视频：** + [重试、回退和抖动：AWS re:Invent 2019：介绍 Amazon Builders’ Library（DOP328）](https://youtu.be/sKRdemSirDM?t=1884) **相关示例：** + [Well-Architected 实验室：第 300 级：实施运行状况检查和管理依赖项以提高可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL05-BP02 限制请求 限制请求是对需求意外增加做出响应的缓解模式。部分请求会得到执行，但超出定义限制的请求会被拒绝，并返回说明它们已被限制的消息。客户端预期将会回退，并且放弃请求或以较低速率进行重试。 您的服务应设计为可以应对每个节点或单元格所能处理的已知请求容量。此容量可以通过负载测试确定。然后，您需要跟踪请求到达速率，如果临时到达速率超过此限制，则相应的响应是发出信号表明请求已被限制。这允许用户进行重试，或许会向可能具有可用容量的另一个节点或单元格发出请求。Amazon API Gateway 提供一些限制请求的方法。Amazon SQS 和 Amazon Kinesis 可对请求进行缓冲，平滑请求速率并降低对可异步处理的请求进行限制的需求。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 限制请求。这是对按需求意外增加做出响应的缓解模式。部分请求会得到执行，但超出定义限制的请求会被拒绝，并返回说明它们已被限制的消息。客户端预期将会回退，并且放弃请求或以较低速率进行重试。 + 使用 Amazon API Gateway + [对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) ## 资源 **相关文档：** + [Amazon API Gateway：对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + [Amazon Builders' Library：避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) + [Amazon Builders' Library：为超时、重试和回退引入抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) + [对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) **相关视频：** + [重试、回退和抖动：AWS re:Invent 2019：介绍 Amazon Builders’ Library（DOP328）](https://youtu.be/sKRdemSirDM?t=1884) # REL05-BP03 控制与限制重试调用 在逐渐延长的间隔以后使用指数回退进行重试。引入抖动使此类重试间隔随机化，并限制重试的最大次数。 分布式软件系统中的常见组件包括服务器、负载均衡器、数据库和 DNS 服务器。在操作中，受故障影响，任何此类组件都可能开始生成错误。处理错误的默认方式为，在客户端实施重试。此方法可提高应用程序的可靠性和可用性。不过，如果规模较大，而且客户端在错误发生时立即重试失败的操作，网络中的新请求和重试请求可能会快速导致饱和，并争用网络带宽。这可能导致 *重试风暴，* 从而降低服务的可用性。此模式可能会继续，直到发生全系统故障。 为避免出现此情况，应使用回退算法，如常用的 *指数回退* 。指数回退算法会逐渐降低执行重试的速率，从而避免网络阻塞。 很多开发工具包和软件库（包括 AWS 的开发工具包和软件库）都实施此类算法的一种版本。但是， **别心存侥幸地认为已采用回退算法，始终要进行测试和验证。** 仅依靠回退还不够，因为在分布式系统中，所有客户端都可能同步回退，形成重试调用集群。Marc Brooker 在他的博文 [指数回退和抖动](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)中解释了如何修改指数回退中的 wait() 函数以防止形成重试调用集群。他给出的解决办法 *是* 在 wait() 函数中增加抖动。要避免过长时间的重试，实施应为回退设置一个最大值限制。 最后，务必要配置 *最大重试次数* 或已用时间，在此以后，重试将失败。AWS 开发工具包将默认实施此操作，而且也可以对它进行配置。针对堆栈中较低的服务，最大重试限制为 0 或 1 可以限制风险，而且在将重试委派给堆栈较高的服务时依然有效。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 控制与限制重试调用。在逐渐延长的间隔以后使用指数回退进行重试。引入抖动使此类重试间隔随机化，并限制重试的最大次数。 + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + 默认情况下，Amazon SDK 实施重试和指数回退。在调用自己的依赖服务时，您需要在依赖关系层中执行类似的逻辑。根据您的使用案例确定超时以及何时停止重试。 ## 资源 **相关文档：** + [Amazon API Gateway：对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + [Amazon Builders' Library：避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) + [Amazon Builders' Library：缓存挑战和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) + [Amazon Builders' Library：为超时、重试和回退引入抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) **相关视频：** + [重试、回退和抖动：AWS re:Invent 2019：介绍 Amazon Builders’ Library（DOP328）](https://youtu.be/sKRdemSirDM?t=1884) # REL05-BP04 快速失效机制和限制队列 如果工作负载无法成功响应请求，则快速试错。这样可释放与请求关联的资源，并允许该服务在资源不足的情况下恢复。如果工作负载能够成功响应，但请求速率过高，则使用队列来对请求进行缓冲。不过，不要允许使用长队列，它可能导致处理已被客户端放弃的过时请求。 此最佳实践适用于请求的服务器端，或接收方。 请注意，可在系统的多个级别创建队列，它们可能严重妨碍快速恢复的能力，因为需要先处理较旧的过时请求（虽然不再需要响应），然后才会处理较新的请求。另外还要注意队列所在的位置。它们通常会隐藏在工作流或记录到数据库的工作中。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 快速失效机制和限制队列。如果工作负载无法成功响应请求，则快速试错。这样可释放与请求关联的资源，并允许该服务在资源不足的情况下恢复。如果工作负载能够成功响应，但请求速率过高，则使用队列来对请求进行缓冲。不过，不要允许使用长队列，它可能导致处理已被客户端放弃的过时请求。 + 在服务面临压力时执行快速失效机制。 + [快速试错](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) + 限制队列：在基于队列的系统中，如果在停止处理后消息仍不断涌入，则消息债务可能造成大量积压，从而增加处理时间。工作完成太晚，以至于结果无法发挥作用，从根本上导致了队列原本要避免的可用性打击问题。 + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) ## 资源 **相关文档：** + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + [快速试错](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) + [Amazon Builders' Library：避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) + [Amazon Builders' Library：缓存挑战和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) + [Amazon Builders' Library：为超时、重试和回退引入抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) **相关视频：** + [重试、回退和抖动：AWS re:Invent 2019：介绍 Amazon Builders’ Library（DOP328）](https://youtu.be/sKRdemSirDM?t=1884) # REL05-BP05 设置客户端超时 适当设置超时，对它们进行系统性验证，而且不要依靠默认值，因为默认值通常设置得过高。 此最佳实践适用于请求的客户端，或发送方。 为任何远程调用和大体上任何跨流程调用设置连接超时和请求超时。许多框架具有内置超时功能，但仍需谨慎，因为许多默认值为无限值或过高。过高的值会降低超时的实用性，因为客户端等待超时发生时，系统会继续消耗资源。过低的值可能因为要重试过多请求而导致后端流量增加以及延迟变长。在有些情况下，由于要对全部请求进行重试，从而可能导致完全中断。 要了解关于 Amazon 如何利用超时、重试和抖动回退的更多信息，请参阅 [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card). **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 为任何远程调用和大体上任何跨流程调用设置连接超时和请求超时。许多框架具有内置超时功能，但仍需谨慎，因为许多默认值为无限值或过高。过高的值会降低超时的实用性，因为客户端等待超时发生时，系统会继续消耗资源。过低的值可能因为要重试过多请求而导致后端流量增加以及延迟变长。在有些情况下，由于要对全部请求进行重试，从而可能导致完全中断。 + [AWS 开发工具包：重试次数和超时](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) ## 资源 **相关文档：** + [AWS 开发工具包：重试次数和超时](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) + [Amazon API Gateway：对 API 请求限流以提高吞吐量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + [AWS 中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) + [Amazon Builders' Library：为超时、重试和回退引入抖动](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) **相关视频：** + [重试、回退和抖动：AWS re:Invent 2019：介绍 Amazon Builders’ Library（DOP328）](https://youtu.be/sKRdemSirDM?t=1884) # REL05-BP06 尽可能使服务为无状态 服务应该不需要状态，或者在不同的客户端请求之间卸载状态，磁盘上和内存中本地存储的数据不存在依赖关系。这使任意替换服务器成为可能，而且不会对可用性产生影响。Amazon ElastiCache 或 Amazon DynamoDB 是卸载状态的理想目标位置。 ![\[在此无状态 Web 应用程序中，会话状态会被卸载到 Amazon ElastiCache。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/stateless-webapp.png) 当用户或服务与应用程序进行交互，它们通常会执行一系列交互并构成一次会话。对于用户来说，会话是他们在使用应用程序时持续存在于请求之间的特殊数据。无状态应用程序是无需掌握之前交互而且不会存储会话信息的应用程序。 若采用无状态设计，则您可以使用无服务器计算服务，如 AWS Lambda 或 AWS Fargate。 除了服务器替换，无状态应用程序的另一项优点是，由于任何可用的计算资源（如 EC2 实例和 AWS Lambda 函数）都可以处理任何请求，因此它们可以进行横向扩展。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 让应用程序无状态。无状态应用程序支持水平扩展，并且可以承受单个节点故障。 + 删除可能存储在请求参数中的状态。 + 在检查是否需要状态之后，将任何状态追踪移动到具有弹性的多区域缓存或数据存储（如 Amazon ElastiCache、Amazon RDS、Amazon DynamoDB 或第三方分布式数据解决方案）。存储无法移动到弹性数据存储的状态。 + 某些数据（例如 cookie）可能在标头或查询参数中传递。 + 进行重构，从而删除可能在请求中快速传递的状态。 + 提交请求时实际上并不需要某些数据，这些数据可以按需检索。 + 删除可以异步检索的数据。 + 确定满足所需状态要求的数据存储。 + 考虑针对非关系型数据使用 NoSQL 数据库。 ## 资源 **相关文档：** + [Amazon Builders' Library：避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) + [Amazon Builders' Library：避免无法克服的队列积压](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) + [Amazon Builders' Library：缓存挑战和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) # REL05-BP07 实施紧急杠杆 紧急杠杆是可帮助您的工作负载减轻可用性影响的快速流程。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 实施紧急杠杆。这些是可帮助您的工作负载减轻可用性影响的快速流程。即使未找到根本原因，它们也可以运行。理想的紧急杠杆可通过提供完全确定的激活与停用标准，将解析器的认知负担降低到零。杠杆通常需要手动操作，但也可实现自动化 + 杠杆示例包括， + 阻止所有机器人流量 + 为静态页面而非动态页面提供服务 + 减少对依赖项的调用频率 + 限制来自依赖项的调用 + 关于实施和使用紧急杠杆的提示 + 当杠杆被激活时，求少不求多 + 保持简单，避免双模态行为 + 定期测试您的杠杆 + 以下为非紧急杠杆的操作示例 + 添加容量 + 号召依赖您的服务的客户端服务所有者，要求他们降低调用 + 更改代码并将其释放 # 变更管理 **Topics** + [ # REL 6  如何监控工作负载资源？ ](w2aac19b9b9b5.md) + [ # REL 7  您如何设计工作负载，以适应不断变化的需求？ ](w2aac19b9b9b7.md) + [ # REL 8  如何实施更改？ ](w2aac19b9b9b9.md) # REL 6  如何监控工作负载资源？ 日志和指标是用于了解工作负载运行状况的强大工具。您可以配置工作负载以监控日志和指标，并在超出阈值或发生重大事件时发送通知。监控让您的工作负载可以发现超出低性能阈值和发生故障的情形，从而在响应中自动恢复。 **Topics** + [ # REL06-BP01 为工作负载监控全部组件（生成） ](rel_monitor_aws_resources_monitor_resources.md) + [ # REL06-BP02 定义与计算指标（聚合） ](rel_monitor_aws_resources_notification_aggregation.md) + [ # REL06-BP03 发送通知（实时处理和报警） ](rel_monitor_aws_resources_notification_monitor.md) + [ # REL06-BP04 自动响应（实时处理和告警） ](rel_monitor_aws_resources_automate_response_monitor.md) + [ # REL06-BP05 分析 ](rel_monitor_aws_resources_storage_analytics.md) + [ # REL06-BP06 定期进行审核 ](rel_monitor_aws_resources_review_monitoring.md) + [ # REL06-BP07 对通过系统的请求进行端到端跟踪监控 ](rel_monitor_aws_resources_end_to_end.md) # REL06-BP01 为工作负载监控全部组件（生成） 使用 Amazon CloudWatch 或第三方工具监控工作负载组件。使用 AWS Health 控制面板监控 AWS 服务。 应监控您的工作负载的全部组件，包括前端、业务逻辑和存储层。定义关键指标，描述如何将其从日志中提取出来（如有必要），并且设置用于触发对应警报事件的阈值。确保这些指标与您工作负载的关键性能指标（KPI，Key Performance Indicator）相关，并使用指标和日志来确定服务性能下降的早期警告信号。例如，每分钟成功处理的订单数等与业务成果相关的指标，相比 CPU 利用率等技术指标，可以更快地指示工作负载问题。使用 AWS Health 控制面板提供 AWS 资源底层的 AWS 服务的性能和可用性的个性化视图。 云中监控创造新的机会。大多数云提供商都已经开发出可自定义的挂钩，可以提供分析洞察来帮助您监控工作负载的多个层。Amazon CloudWatch 等 AWS 服务应用统计和机器学习算法，集中分析系统与应用程序的指标，确定正常基准，并发现异常，同时最大程度地减少用户干预。异常检测算法考虑了指标的季节性和趋势变动。 AWS 提供了丰富的监控和日志信息以供使用，这些信息可用于定义特定于工作负载的指标、需求变化流程并且采用机器学习技术而无需机器学习专业知识。 此外还会监控您的所有外部端点，确保它们独立于基本实施。这种主动监控可通过合成事务（有时被称为 *用户金丝雀*，但不要与金丝雀部署相混淆）实现，它们会按照工作负载的客户端所执行的操作，定期执行许多常见任务。请确保这些任务的持续时间较短，并且在测试期间不要使您的工作流过载。Amazon CloudWatch Synthetics 使您能够 [创建合成金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 以便监控您的终端节点和 API。您还可以整合 Synthetic Canary 客户端节点和 AWS X-Ray 控制台，精确定位哪些 Synthetic Canary 遇到错误、故障，或对指定时段的速率进行限制的问题。 **期望结果：** 从工作负载的所有组件收集并使用关键指标，用于确保工作负载的可靠性和提供最佳用户体验。通过检测未能实现业务成果的工作负载，您可以快速发现灾难并从意外事件中恢复。 **常见反模式：** + 仅监控连接到工作负载的外部接口。 + 未生成任何特定于工作负载的指标，并且只依靠工作负载所用的 AWS 服务提供给您的指标。 + 仅使用工作负载中的技术指标，不监控与工作负载所带来的非技术 KPI 相关的任何指标。 + 依靠生产流量和简单的运行状况检查来监控并评估工作负载状态。 **建立此最佳实践的好处：** 在工作负载的所有层级进行监控，方便您更快地预测并解决组成工作负载的组件中的问题。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 1. **启用日志记录功能（如适用）。** 应从工作负载的所有组件获取监控数据。启用额外的日志记录，例如 S3 访问日志，并使工作负载记录特定于工作负载的数据。从 Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling 和 Amazon EMR 等服务收集 CPU、网络 I/O 和磁盘 I/O 平均值等指标。请参阅 [发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 以了解将指标发布到 CloudWatch 的 AWS 服务列表。 1. **审查所有默认指标并探究任何数据收集欠缺。** 每项服务都生成默认指标。通过收集默认指标，您可以更好地了解工作负载组件之间的依赖关系，以及组件的可靠性和性能如何影响工作负载。您还可以 [使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) AWS CLI 或 API 创建自己的指标并发布到 CloudWatch。这将 1. **评估所有指标，以确定对于工作负载中的每个 AWS 服务，需要针对哪些指标发布警报。** 您还可以选择对工作负载可靠性有重大影响的指标的子集。专注于关键指标和阈值让您可以精调 [警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 的数量，并可帮助尽可能减少误报。 1. **定义警报，以及在触发警报之后工作负载的恢复流程。** 通过定义警报，您可以快速通知、上报意外事件，按照必要的步骤从意外事件中恢复，并满足规定的恢复时间目标（RTO，Recovery Time Objective）。您可以使用 [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) ，根据定义的阈值来调用自动工作流并启动恢复程序。 1. **探索使用合成事务来收集有关工作负载状态的相关数据。** 合成监控遵循与客户相同的路线并执行相同的操作，这使得您可以持续验证客户体验，甚至在您的工作负载上没有任何客户流量时也可以。通过使用 [合成事务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)，您可以先于客户发现问题。 ## 资源 **相关最佳实践：** + [REL11-BP03 自动修复所有层](rel_withstand_component_failures_auto_healing_system.md) **相关文档：** + [开始使用 AWS Health 控制面板 – 账户的运行状况](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) + [发布 CloudWatch 指标的 AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [Network Load Balancer 的访问日志](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) + [应用程序负载均衡器的访问日志](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) + [访问 AWS Lambda 的 Amazon CloudWatch Logs](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) + [Amazon S3 服务器访问日志记录](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) + [启用 Classic Load Balancer 的访问日志](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) + [将日志数据导出到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) + [在 Amazon EC2 实例上安装 CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) + [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [什么是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) **用户指南：** + [创建跟踪记录](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) + [监控 Amazon EC2 Linux 实例的内存和磁盘指标](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) + [结合使用 CloudWatch Logs 与容器实例](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [VPC 流日志](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) + [什么是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) **相关博客：** + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) **相关示例和研讨会：** + [AWS Well-Architected 实验室：卓越运营 – 依赖项监控](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [可观测性研讨会](https://catalog.workshops.aws/observability/en-US) # REL06-BP02 定义与计算指标（聚合） 存储日志数据并在必要时应用筛选条件以计算指标，例如，特定日志事件的数量，或从日志事件时间戳计算得到的延迟。 Amazon CloudWatch 和 Amazon S3 充当主要聚合层和存储层。某些服务（如 AWS Auto Scaling 和 Elastic Load Balancing）针对整个集群或实例，默认情况下为 CPU 负载或平均请求延迟提供了一些默认指标。对于流式处理服务（如 VPC 流日志和 AWS CloudTrail），事件数据将被转发给 CloudWatch Logs，您需要定义和应用指标筛选条件，才能从事件数据中提取指标。这为您提供了时间序列数据，可被输入到您定义的触发提醒的 CloudWatch 警报。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 定义与计算指标（聚合）。存储日志数据并在必要时应用筛选条件以计算指标，例如，特定日志事件的数量，或从日志事件时间戳计算得到的延迟 + 指标筛选条件定义在将日志数据发送到 CloudWatch Logs 中时所查找的术语和模式。CloudWatch Logs 使用这些指标筛选条件将日志数据转换为 CloudWatch 数字指标，您可以对这些指标绘制图形或设置警报。 + [搜索和筛选日志数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + 使用受信任第三方来聚合日志。 + 遵循第三方的说明。大多数第三方产品可以与 CloudWatch 和 Amazon S3 集成。 + 某些 AWS 服务可以直接向 Amazon S3 发布日志。如果您的主要需求是将日志存储在 Amazon S3 中，则可以让生成日志的服务轻松将其直接发送至 Amazon S3，无需设置额外的基础设施。 + [将日志直接发送到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) ## 资源 **相关文档：** + [Amazon CloudWatch Logs Insights 查询示例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [可观测性研讨会](https://observability.workshop.aws/) + [搜索和筛选日志数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + [将日志直接发送到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) # REL06-BP03 发送通知（实时处理和报警） 发生重大事件时，需要知晓的组织会收到通知。 警报可以发送到 Amazon Simple Notification Service（Amazon SNS）主题中，然后推送给任意数量的订阅者。例如，Amazon SNS 可以将提醒转发给某个电子邮件别名，以便技术人员可以回复。 **常见反模式：** + 配置过低的告警阈值，导致发送过多通知。 + 未存档告警以备将来查看。 **建立此最佳实践的好处：** 事件通知（即使是可以响应并自动解决的事件）允许您记录事件，还可用于在将来通过其他方式处理事件。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 执行实时处理和报警。发生重大事件时，需要知晓的组织会收到通知 + Amazon CloudWatch 控制面板是 CloudWatch 控制台中的可自定义主页，方便您通过单一视图监控您的资源，即使这些资源分布在不同区域中。 + [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + 创建指标超过限制时发出的警报。 + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## 资源 **相关文档：** + [可观测性研讨会](https://observability.workshop.aws/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) # REL06-BP04 自动响应（实时处理和告警） 检测到事件后，利用自动化功能执行操作；例如，更换故障组件。 提醒可以触发 AWS Auto Scaling 事件，以便集群对需求的变化做出反应。警报还可以发送到 Amazon Simple Queue Service（Amazon SQS），后者可充当第三方票证系统的集成点。AWS Lambda 还可以订阅警报，为用户提供一种无服务器的异步模式，以动态方式应对更改。AWS Config 会持续监视和记录您的 AWS 资源配置，并且可以触发 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 以修正问题。 Amazon DevOps Guru 可以自动监控应用程序资源的异常行为并提供针对性的建议，以缩短识别问题和进行修复所需的时间。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 使用 Amazon DevOps Guru 执行自动化操作。Amazon DevOps Guru 可以自动监控应用程序资源的异常行为并提供针对性的建议，以缩短识别问题和进行修复所需的时间。 + [什么是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + 使用 AWS Systems Manager 执行自动化操作。AWS Config 会持续监控和记录您的 AWS 资源配置，还可以触发 AWS Systems Manager Automation 以修正问题。 + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + 创建和使用 Systems Manager Automation 文档。它们可定义当自动化流程运行时，Systems Manager 对托管实例和其他 AWS 资源执行的操作。 + [使用自动化文档（行动手册）](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) + Amazon CloudWatch 将警报状态更改事件发送到 Amazon EventBridge。创建 EventBridge 规则以自动做出响应。 + [创建通过 AWS 资源中的事件触发的 EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) + 创建和执行自动响应计划。 + 盘点所有警报响应程序。您必须在对任务排名之前制定警报响应计划。 + 盘点所有必须执行特定操作的任务。大多数操作均已记录在运行手册中。您还必须具有针对意外事件的警报行动手册。 + 检查所有可自动化操作的运行手册和行动手册。一般而言，可定义的操作很可能可以实现自动化。 + 将容易出错或耗时的活动排在前列。这非常有助于删除错误源和缩短解决问题的时间。 + 制定计划，完成自动化。维护有效计划，以自动执行并更新自动化。 + 检查手动要求，寻找自动化机会。挑战手动流程，发现自动化机会。 ## 资源 **相关文档：** + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [创建通过 AWS 资源中的事件触发的 EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) + [可观测性研讨会](https://observability.workshop.aws/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [什么是 Amazon DevOps Guru？](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [使用自动化文档（行动手册）](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) # REL06-BP05 分析 收集日志文件和指标历史，并对其进行分析以获得更广泛的趋势和工作负载见解。 Amazon CloudWatch Logs Insights 支持 [简单但强大的查询语言，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) 您可以用它分析日志数据。Amazon CloudWatch Logs 还支持订阅，允许数据无缝流动到 Amazon S3（您可以在其中使用此类数据）或 Amazon Athena 以便对数据进行查询。它还支持查询多种格式。请参阅 [支持的 SerDes 和数据格式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) （参见 Amazon Athena 用户指南）。针对大型日志文件集的分析，您可以运行 Amazon EMR 集群以执行 PB 级分析。 AWS 合作伙伴和第三方提供了许多用于聚合、处理、存储和分析的工具。这些工具包括 New Relic、Splunk、Loggly、Logstash、CloudHealth 和 Nagios。但是，系统和应用程序日志之外的生成对于每个云提供商，甚至每个服务来说都是独一无二的。 监控过程中常常被忽视的部分是数据管理。您需要确定数据监控的保留要求，然后相应地应用生命周期策略。Amazon S3 支持 S3 存储桶级别的生命周期管理。此生命周期管理可以通过不同的方式应用到存储桶中的不同路径。您可以在生命周期临近结束时，将数据转移到 Amazon Glacier 进行长期存储，然后在保留期结束后让它们过期。S3 智能分层存储类旨在通过将数据自动移动到最具成本效益的访问层，而不会对性能或运营开销产生影响，从而实现优化成本的目的。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 借助 CloudWatch Logs Insights，您可对 Amazon CloudWatch Logs 中的日志数据进行交互搜索和分析。 + [使用 CloudWatch Logs Insights 分析日志数据](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [Amazon CloudWatch Logs Insights 查询示例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) + 使用 Amazon CloudWatch Logs 将日志发送到 Amazon S3，您可以在此处使用这些日志或者使用 Amazon Athena 来查询数据。 + [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) + 为服务器访问日志存储桶创建 S3 生命周期策略。配置生命周期策略以定期删除日志文件。这样做可以减少 Athena 针对每次查询分析的数据量。 + [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) ## 资源 **相关文档：** + [Amazon CloudWatch Logs Insights 查询示例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [使用 CloudWatch Logs Insights 分析日志数据](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [如何为 S3 存储桶创建生命周期策略？](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) + [如何使用 Athena 分析我的 Amazon S3 服务器访问日志？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) + [可观测性研讨会](https://observability.workshop.aws/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) # REL06-BP06 定期进行审核 经常审核工作负载监控的实施情况，并根据重大事件和变更加以更新。 关键业务指标可促进有效监控。确保随着业务优先事项的变化在您的工作负载中对这些指标进行调整。 审计监控有助于确保您了解应用程序何时达到其可用性目标。根本原因分析需要具备在出现故障时发现具体情况的能力。AWS 提供的服务让您能够在意外事件发生期间跟踪服务的状态： + **Amazon CloudWatch Logs：** 您可以将日志存储在此服务中并检查日志内容。 + **Amazon CloudWatch Logs Insights**：是一项完全托管式服务，让您可以在数秒内分析大量日志。它为您提供快速、交互式的查询和可视化。  + **AWS Config：** 您可以查看在不同的时间点使用了哪些 AWS 基础设施。 + **AWS CloudTrail：** 您可以查看哪些委托人在什么时候调用了哪些 AWS API。 AWS 每周召开一次会议， [以审查运营性能](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 并在团队之间分享经验。因为 AWS 有很多团队，我们设置了 [The Wheel](https://aws.amazon.com/blogs/opensource/the-wheel/) 以随机挑选一个工作负载进行审查。定期开展运营性能审查和知识共享，有助于您增强帮助运营团队提高绩效的能力。 **常见反模式：** + 仅收集默认指标。 + 设置监控策略后不再过问。 + 部署重大更改后不讨论监控问题。 **建立此最佳实践的好处：** 定期审核监控可主动预测潜在问题，而不是当预测问题真实发生后被动应对通知。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 为工作负载创建多个控制面板。您必须具有顶级控制面板，其中包含关键业务指标，以及已确定与使用情况发生变化时工作负载的预期运行状况最相关的技术指标。您还应该具有可以检查各种应用程序层和依赖项的控制面板。 + [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + 计划和执行工作负载控制面板常规检查。执行控制面板常规检查。您可能对检查深度具有不同的安排。 + 检查指标中的趋势。对比指标值与历史值，了解是否有趋势表明需要调查某些情况。这种情况的示例包括：延迟增加、主要业务功能减少以及故障响应增加。 + 检查指标中的离群值/异常值。平均值或中值会掩盖离群值和异常值。查看时间范围内的最高值和最低值，调查出现这些极值的原因。当您继续消除这些原因时，降低对极值的定义可以使您继续提高工作负载性能的一致性。 + 查找清晰的行为变化。指标数量或方向的立即更改可能表示应用程序出现更改，或者出现了您需要添加额外指标进行跟踪外部因素。 ## 资源 **相关文档：** + [Amazon CloudWatch Logs Insights 查询示例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [可观测性研讨会](https://observability.workshop.aws/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [使用 Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) # REL06-BP07 对通过系统的请求进行端到端跟踪监控 利用 AWS X-Ray 或第三方工具，开发人员可以更轻松地分析与调试分布式系统，了解他们的应用程序及其底层服务的表现。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 对通过系统的请求进行端到端跟踪监控。AWS X-Ray 服务用于收集有关应用程序所服务的请求的数据，并提供工具来供您用来查看、筛选和深入了解该数据，以识别问题和优化机会。对于有关应用程序的任何跟踪请求，您将不仅可以查看有关请求和响应的详细信息，还可以查看应用程序对下游 AWS 资源、微服务、数据库和 Web API 进行调用的详细信息。 + [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) ## 资源 **相关文档：** + [使用 Amazon CloudWatch Synthetics 和 AWS X-Ray 进行调试](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) + [可观测性研讨会](https://observability.workshop.aws/) + [Amazon Builders' Library：检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) # REL 7  您如何设计工作负载，以适应不断变化的需求？ 可扩展工作负载具有自动添加或移除资源的弹性，因此确保在任何时间点都能准确满足当前的需求。 **Topics** + [ # REL07-BP01 在获取或扩展资源时利用自动化 ](rel_adapt_to_changes_autoscale_adapt.md) + [ # REL07-BP02 在检测到对工作负载的破坏时获取资源 ](rel_adapt_to_changes_reactive_adapt_auto.md) + [ # REL07-BP03 当检测到某个工作负载需要更多资源时，就会获取资源 ](rel_adapt_to_changes_proactive_adapt_auto.md) + [ # REL07-BP04 对工作负载进行负载测试 ](rel_adapt_to_changes_load_tested_adapt.md) # REL07-BP01 在获取或扩展资源时利用自动化 在替换被损坏的资源或扩展您的工作负载时，通过采用托管 AWS 服务（如 Amazon S3 和 AWS Auto Scaling）对流程进行自动处理。您还可以使用第三方工具和 AWS 开发工具包自动扩展。 托管 AWS 服务包括 Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda、Amazon DynamoDB、AWS Fargate 和 Amazon Route 53。 AWS Auto Scaling 让您可以检测与替换被破坏的实例。它还可以帮助您为资源制定扩展计划，包括 [Amazon EC2](https://aws.amazon.com/ec2/) 实例和 Spot 队列、 [Amazon ECS](https://aws.amazon.com/ecs/) 任务、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 表和索引，以及 [Amazon Aurora](https://aws.amazon.com/aurora/) 副本。 在扩展 EC2 实例时，请确保您使用多个可用区（最好至少三个）并增加或减少容量以保持这些可用区之间的平衡。ECS 任务或 Kubernetes 容器组（pod）（使用 Amazon Elastic Kubernetes Service 时）也应分布在多个可用区中。 如果使用 AWS Lambda，实例会自动扩展。每次收到关于您的函数的事件通知时，AWS Lambda 会快速找到其计算队列中的可用容量，然后运行您的代码至分配的并发值。您需要确保在特定的 Lambda 上，以及在您的Service Quotas中配置必要的并发值。 Amazon S3 会自动扩展以处理较高的请求速率。例如，您的应用程序可以在存储桶中为每个前缀每秒至少发送 3500 个 PUT/COPY/POST/DELETE 或 5500 个 GET/HEAD 请求。存储桶中的前缀数量没有限制。您可以通过并行化读取提高您的读取或写入性能。例如，如果在 Amazon S3 存储桶中创建 10 个前缀以便对读取进行并行化，您可以将读取性能扩展至每秒 55000 个读取请求。 配置和使用 Amazon CloudFront 或受信任的内容分发网络（CDN，Content Delivery Network）。CDN 可以缩短最终用户的响应时间，并从缓存中为请求提供内容，从而减少扩展工作负载的请求。 **常见反模式：** + 实施 Auto Scaling 组进行自动修复，但无法实施弹性。 + 使用 Auto Scaling 响应流量激增。 + 部署高状态应用程序，消除了部署弹性选项。 **建立此最佳实践的好处：** 自动化可以避免部署和淘汰资源时的潜在手动错误。自动化可以避免由于缓慢响应部署或淘汰需求而导致的服务超支和拒绝服务风险。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 配置和使用 AWS Auto Scaling。它会监控您的应用程序，并自动调整容量来维持稳定、可预测的性能，并且成本最低。使用 AWS Auto Scaling，您可以跨多个服务为多个资源轻松设置应用程序扩展。 + [什么是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) + 在您的 Amazon EC2 实例和竞价型实例集、Amazon ECS 任务、Amazon DynamoDB 表和索引、Amazon Aurora 副本以及 AWS Marketplace 设备上配置自动扩展（如果适用）。 + [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + 使用服务 API 操作来指定警报、扩展策略、预热时间和冷却时间。 + 使用 Elastic Load Balancing。负载均衡器可以按路径或网络连接分配负载。 + [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + Application Load Balancers 可以按路径分配负载。 + [什么是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + 配置 Application Load Balancer，根据域名下的路径将流量分配给不同的工作负载。 + Application Load Balancers 可以与 AWS Auto Scaling 集成来分配负载，以便管理需求。 + [将负载均衡器与自动扩缩组配合使用](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) + 网络负载均衡器可以按连接分配负载。 + [什么是网络负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) + 配置网络负载均衡器，以便使用 TCP 将流量分配给不同的工作负载，或者为工作负载指定一组恒定的 IP 地址。 + 网络负载均衡器可以与 AWS Auto Scaling 集成来分配负载，以便管理需求。 + 使用高度可用的 DNS 提供商。使用 DNS 名称，用户可以输入名称而不是 IP 地址来访问您的工作负载，并将该信息分发到指定的范围内，通常面向全局范围内工作负载的所有用户。 + 使用 Amazon Route 53 或可信 DNS 提供商。 + [什么是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + 使用 Route 53 管理 CloudFront 分配和负载均衡器。 + 确定要管理的域和子域。 + 使用 ALIAS 或 CNAME 记录来创建适当的记录集。 + [使用记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) + 使用 AWS 全球网络可优化用户与应用程序之间的路径。AWS Global Accelerator 持续监控应用程序端点的运行状况，可在 30 秒内将流量重定向到运行状况良好的端点。 + AWS Global Accelerator 是一项可帮助本地或全球用户提高应用程序可用性和性能的服务。它提供的静态 IP 地址可用作从单个或多个 AWS 区域 区域（例如 Application Load Balancers、网络负载均衡器或 Amazon EC2 实例）访问应用程序端点的固定入口点。 + [什么是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + 配置和使用 Amazon CloudFront 或受信任的内容分发网络（CDN，Content Delivery Network）。内容分发网络可以缩短最终用户的响应时间，还可以对可能导致工作负载进行不必要扩展的内容请求做出响应。 + [什么是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) + 针对您的工作负载配置 Amazon CloudFront 分配，或者使用第三方 CDN。 + 您可以通过在端点安全组或访问策略中使用 CloudFront 的 IP 范围，将对工作负载的访问限制为只能从 CloudFront 访问。 ## 资源 **相关文档：** + [APN 合作伙伴：可以帮您制定自动计算解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) + [AWS Auto Scaling：扩展计划的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace：可以与 Auto Scaling 一起使用的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [将负载均衡器与自动扩缩组配合使用](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) + [什么是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + [什么是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [什么是 AWS Auto Scaling？](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) + [什么是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) + [什么是 Amazon Route 53？](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [什么是 Elastic Load Balancing？](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + [什么是网络负载均衡器？](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) + [什么是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + [使用记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) # REL07-BP02 在检测到对工作负载的破坏时获取资源 如果可用性受到影响，在必要时被动扩展资源，从而还原工作负载的可用性。 首先，您必须配置运行状况检查和关于此类检查的标准，表示在什么时候可用性会因缺少资源而受到影响。然后，通知适当的人员手动扩展资源，或触发自动化以对其进行自动扩展。 可以为您的工作负载手动调整扩展，例如，通过 AWS 管理控制台 或 AWS CLI 更改自动扩缩组中 EC2 实例的数量，或者修改 DynamoDB 表的吞吐量来实现。不过，应在可能的情况下尽量使用自动化（请参阅 **在获取或扩展资源时利用自动化**）。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 在检测到对工作负载的破坏时获取资源。如果可用性受到影响，在必要时被动扩展资源，从而还原工作负载的可用性。 + 使用扩展计划来配置指令集以用于扩展您的资源，扩展计划是 AWS Auto Scaling 的核心组件。如果使用 AWS CloudFormation 或为 AWS 资源添加标签，您可以根据应用程序为不同的资源集设置扩展计划。AWS Auto Scaling 提供了针对每个资源自定义的扩展策略建议。创建扩展计划后，AWS Auto Scaling 结合了动态扩展和预测式扩缩方法来支持扩展策略。 + [AWS Auto Scaling：扩展计划的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + Amazon EC2 Auto Scaling 有助于确保您拥有适量的 Amazon EC2 实例，可处理您的应用程序负载。您可创建 EC2 实例集合，称为 Auto Scaling 组。您可以指定每个自动扩缩组中的最小实例数量，Amazon EC2 Auto Scaling 会确保您组中的实例绝不会低于该数量。您可以指定每个自动扩缩组中的最大实例数量，Amazon EC2 Auto Scaling 会确保您组中的实例绝不会高于该数量。 + [什么是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + Amazon DynamoDB Auto Scaling 使用 AWS Application Auto Scaling 服务，代表您动态调整预置的吞吐能力，以响应实际的流量模式。这将使表或全局二级索引提高预置读取和写入容量，从而不受限制地应对流量突增。 + [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) ## 资源 **相关文档：** + [APN 合作伙伴：可以帮您制定自动计算解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) + [AWS Auto Scaling：扩展计划的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace：可以与 Auto Scaling 一起使用的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [什么是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL07-BP03 当检测到某个工作负载需要更多资源时，就会获取资源 主动扩展资源以满足需求并避免影响可用性。 很多 AWS 服务会自动扩展以满足需求。如果使用 Amazon EC2 实例或 Amazon ECS 集群，您可以根据与您的工作负载的需求对应的使用指标，配置它们会在何时自动扩展。针对 Amazon EC2，平均 CPU 利用率、负载均衡器请求数量，或网络带宽可被用于扩展（或缩减）EC2 实例。而对于 Amazon ECS，可使用平均 CPU 利用率、负载均衡器请求数量和内存利用率横向扩展（或横向缩减）ECS 任务。在 AWS 上使用 Target Auto Scaling，Autoscaler 将扮演“家用恒温器”的角色，增加或减少资源以保持您所指定的目标值（例如，70% CPU 利用率）。 AWS Auto Scaling 还可以执行 [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)，该操作利用机器学习来分析每个资源的历史工作负载，并且定期预测未来两天的负载。 利特尔法则可帮助计算您需要多少计算实例（EC2 实例、并发 Lambda 函数，等等）。 *L* = *λW* L = 实例数量（或系统中的平均并发值） λ = 收到请求的平均速率（请求数量/秒） W = 每个请求在系统中所花的平均时间（秒） 例如，假设每秒请求数为 100，若每个请求所需的处理时间为 0.5 秒，您将需要 50 个实例才能满足需求。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 当检测到某个工作负载需要更多资源时，就会获取资源。主动扩展资源以满足需求并避免影响可用性。 + 计算处理给定请求速率需要多少计算资源（计算并发）。 + [讲述与利特尔法则有关的故事](https://brooker.co.za/blog/2018/06/20/littles-law.html) + 当您具有历史使用模式时，请为 Amazon EC2 Auto Scaling 设置计划扩展。 + [Amazon EC2 Auto Scaling 的计划扩缩](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) + 使用 AWS 预测式扩缩。 + [由机器学习提供支持的 EC2 预测式扩缩](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) ## 资源 **相关文档：** + [AWS Auto Scaling：扩展计划的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace：可以与 Auto Scaling 一起使用的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [使用 DynamoDB Auto Scaling 自动管理吞吐能力](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [由机器学习提供支持的 EC2 预测式扩缩](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) + [Amazon EC2 Auto Scaling 的计划扩缩](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) + [讲述与利特尔法则有关的故事](https://brooker.co.za/blog/2018/06/20/littles-law.html) + [什么是 Amazon EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL07-BP04 对工作负载进行负载测试 采用负载测试方法来衡量扩展活动能否满足工作负载要求。 持续开展负载测试，这一点很重要。负载测试用于发现工作负载的断点并测试工作负载的性能。利用 AWS，您可以轻松设置能够模拟生产工作负载规模的临时测试环境。在云中，您可以根据需要创建一套生产规模等级的测试环境，完成测试，然后停用资源。由于测试环境只需在运行时付费，您模拟真实环境的成本仅为本地测试成本的一小部分。 生产中的负载测试还应该被视为实际试用活动的一部分，因为在客户使用量降低的那几个小时内，在场的所有员工都忙于解读结果与处理任何出现的问题，生产系统承受着很大的压力。 **常见反模式：** + 对与您的生产采用不同配置的部署执行负载测试。 + 仅对单个工作负载分段（而非整个工作负载）执行负载测试。 + 使用请求子集，而不是具有代表性的实际请求集执行负载测试。 + 对超出预期负载的较小安全系数执行负载测试。 **建立此最佳实践的好处：** 您知道架构中哪些组件会在负载下失败，而且能够确定要监控哪些可指示您即将达到该负载的指标，从而及时解决问题，防止故障影响。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 执行负载测试，确定工作负载的哪些方面表明您必须添加或移除容量。负载测试应具有您在生产中接收的流量类似的代表性流量。增加负载，同时监视所有已检测指标，以便确定哪种指标指示何时必须添加或移除资源。 + [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + 确定请求组合。您可能拥有不同的请求组合，因此应当在确定流量组合时查看不同的时间范围。 + 实施负载驱动程序。您可以使用自定义代码、开源或商用软件来实施负载驱动程序。 + 最初使用小容量进行负载测试。通过将负载降低到较小容量（可能小到一个实例或容器），可能会有立竿见影的效果。 + 针对更大的容量进行负载测试。分布式负载的效果会有所不同，因此您必须对尽量接近生产环境的目标进行测试。 ## 资源 **相关文档：** + [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) # REL 8  如何实施更改？ 要部署新功能，必须对更改加以控制，以确保工作负载和操作环境正在运行已知的软件，并以可预测的方式进行修补和替换。如果此类更改不受控制，您将难以预测这些更改的影响，或难以处理由它们引发的问题。 **Topics** + [ # REL08-BP01 对部署等标准活动使用运行手册 ](rel_tracking_change_management_planned_changemgmt.md) + [ # REL08-BP02 将功能测试作为部署的一部分进行集成 ](rel_tracking_change_management_functional_testing.md) + [ # REL08-BP03 将弹性测试作为部署的一部分进行集成 ](rel_tracking_change_management_resiliency_testing.md) + [ # REL08-BP04 使用不可变基础设施进行部署 ](rel_tracking_change_management_immutable_infrastructure.md) + [ # REL08-BP05 使用自动化功能部署更改 ](rel_tracking_change_management_automated_changemgmt.md) # REL08-BP01 对部署等标准活动使用运行手册 运行手册是用来实现特定结果的预定义程序。使用运行手册执行标准活动，无论这些活动是手动还是自动执行。其中的示例包括部署工作负载，修补工作负载，或修改 DNS。 例如，实施流程以 [确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments).确保您可以为客户进行部署回滚而不会出现中断，这是保证服务可靠的关键。 针对运行手册程序，从一个有效的手动流程开始，用代码进行实施，并在适当的情况下触发其自动运行。 即使是高度自动化的复杂工作负载，运行手册同样适用于 [运行实际试用](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 或用于满足严格的报告和审计要求。 请注意，行动手册可用于对特定事件做出响应，运行手册则用来达成特定的结果。通常，运行手册适用于例行活动，而行动手册则被用于对非例行事件做出响应。 **常见反模式：** + 对生产中的配置执行计划外更改。 + 跳过计划中的步骤以加快部署速度，导致部署失败。 + 在未测试反向更改的情况下做出更改。 **建立此最佳实践的好处：** 有效更改计划有助于您成功执行更改，因为您知道所有受影响的系统。在测试环境中验证更改能够增强您的信心。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 通过在运行手册中记录程序，实现对为人熟知的事件的一致且及时的响应。 + [AWS Well-Architected Framework：概念：运行手册](https://wa.aws.amazon.com/wat.concept.runbook.en.html) + 使用基础设施即代码的原则定义您的基础设施。通过使用 AWS CloudFormation（或受信任的第三方）来定义您的基础设施，您可以使用版本控制软件对更改实施版本控制并进行跟踪。 + 使用 AWS CloudFormation（或受信任的第三方提供商）定义您的基础设施。 + [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + 使用良好的软件设计原则创建单个解耦模板。 + 确定实施的权限、模板和责任方。 + [ 使用 AWS Identity and Access Management 控制访问权限 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) + 使用源代码控制（例如 AWS CodeCommit 或受信任的第三方工具）进行版本控制。 + [什么是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助您创建自动化部署解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=devops) + [AWS Marketplace：可用于自动实施部署的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) + [AWS Well-Architected Framework：概念：运行手册](https://wa.aws.amazon.com/wat.concept.runbook.en.html) + [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [什么是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) **相关示例：** + [使用行动手册和运行手册自动完成操作](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) # REL08-BP02 将功能测试作为部署的一部分进行集成 功能测试作为自动化部署的一部分运行。若未满足成功条件，则相关管道会中止或回滚。 这些测试在预生产环境中运行，该环境会在管道中的生产开始前被暂存。在理想情况下，此操作是部署管道的一部分。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 将功能测试作为部署的一部分进行集成。功能测试作为自动化部署的一部分运行。若未满足成功条件，则相关管道会中止或回滚。 + 当在 AWS CodePipeline 中建模的软件发布管道执行“测试操作”时，调用 AWS CodeBuild。此功能使您能够对代码轻松运行各种测试，例如单元测试、静态代码分析和集成测试。 + [AWS CodePipeline 增加了对通过 AWS CodeBuild 进行单位和自定义集成测试的支持](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) + 使用 AWS Marketplace 解决方案，将自动化测试作为软件交付管道的一部分执行。 + [软件测试自动化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) ## 资源 **相关文档：** + [AWS CodePipeline 增加了对通过 AWS CodeBuild 进行单位和自定义集成测试的支持](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) + [软件测试自动化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) + [什么是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) # REL08-BP03 将弹性测试作为部署的一部分进行集成 将弹性测试（使用 [混沌工程的原则](https://principlesofchaos.org/)）作为预生产环境中自动化部署管道的一部分执行。 这些测试会在预生产环境的管道中暂存并运行。它们应在生产中运行，作为 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays)的一部分。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 将弹性测试作为部署的一部分进行集成。混沌工程是对工作负载进行试验的规范，用于建立人们对工作负载能够在生产中经受住混乱情形的信心。 + 弹性测试会注入故障或资源降级，以此评估您的工作负载能否以预期弹性做出响应。 + [Well-Architected 实验室：第 300 级：测试 EC2 RDS 和 S3 的弹性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) + 这些测试可以在自动部署管道的预生产环境中定期执行。 + 它们还应作为计划实际演练的一部分在生产环境中运行。 + 使用混沌工程原则，提出有关工作负载在各种破坏情况下如何表现的假设，然后使用弹性测试验证您的假设。 + [混沌工程的原则](https://principlesofchaos.org/) ## 资源 **相关文档：** + [混沌工程的原则](https://principlesofchaos.org/) + [什么是 AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) **相关示例：** + [Well-Architected 实验室：第 300 级：测试 EC2 RDS 和 S3 的弹性](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) # REL08-BP04 使用不可变基础设施进行部署 不可变基础设施模式要求在生产系统上不会出现就地更新、安全补丁或配置更改。需要更改时，会在新的基础设施上构建架构，并将其部署到生产环境中。 最常被实施的不可变基础设施范式为 ***不可变服务器***.这意味着，若服务器需要更新或修复，将部署新的服务器，而不是对使用中的服务器进行更新。因此，相对于通过 SSH 登录到服务器并更新软件版本，应用程序的每次更改都会在开始时将软件推送到代码库，如 git 推送。由于在不可变基础设施中不允许更改，您可以确定已部署系统的状态。不可变基础设施在本质上具有更稳定、可靠和可预测的特性，它们对软件开发和运行的多个方面进行了简化。 当您在不可变基础设施中部署应用程序时，使用 Canary 或蓝绿部署。 [https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 是将您的少量客户引导到新版本的做法，它通常在单个服务实例 (Canary) 上运行。然后，您可以深入检查生成的任何行为更改或错误。如果遇到了严重问题，您可以将 Canary 中的流量删除，并将用户发回到以前的版本。如果部署成功，您可以继续以期望的速度进行部署，同时监控更改以便发现错误，直到所有部署完成。AWS CodeDeploy 的部署配置可以配置为启用金丝雀部署。 [https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 与金丝雀部署类似，只是会并行部署一整套应用程序。您可以在两个堆栈（蓝和绿）之间轮流部署。同样，您可以将流量发送到新版本中，如果发现部署中存在问题，可以对其进行故障恢复，然后送回旧版本中。通常来说，所有流量会被一次性切换，但您也可以通过 Amazon Route 53 的加权 DNS 路由功能向每个版本发送部分流量，以加快采用新版本的速度。AWS CodeDeploy 和 AWS Elastic Beanstalk 的部署配置可以配置为启用蓝绿部署。 ![\[图中显示了使用 AWS Elastic Beanstalk 和 Amazon Route 53 进行的蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png) 不可变基础设施的优点： + **减小配置偏差：** 通过从基本、已知，而且版本受控的配置频繁替换服务器，基础设施会被 **重置** 为已知状态，以避免配置偏差。 + **简化部署**：由于无需支持升级，部署得到简化。升级即意味着新的部署。 + **可靠的原子部署：** 成功完成部署，或没有任何更改。它让您更信任部署流程。 + **采用快速回滚和恢复流程的更安全部署：** 由于之前运行的版本未发生更改，因此部署变得更安全。您可以在检测到错误时进行回滚。 + **一致的测试和调试环境：** 由于所有服务器都使用相同的映像，因此环境之间没有任何差异。同一个版本被部署到多个环境。它还防止出现不一致的环境，并且简化测试与调试。 + **增强可扩展性：** 服务器都使用一个基础映像，它们是一致、可重复的，自动扩展并不重要。 + **简化工具链：**您无需采用配置管理工具对生产软件升级进行管理，因此工具链也得到简化。也不需要在服务器上安装其他工具或代理。对基础映像进行更改，然后在经过测试后实施。 + **提高安全性：** 通过拒绝对服务器的所有更改，您可以在实例上禁用 SSH 并移除密钥。这样做可以减少攻击载体，改善您的组织的安全状况。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 使用不可变基础设施进行部署。不可变基础设施是一个不会在生产系统上 *就地* 发生更新、安全修补或配置更改的模型。如果需要任何更改，则会构建架构的新版本，并将其部署到生产环境中。 + [蓝绿部署概览](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) + [逐步部署无服务器应用程序](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) + [不可改变基础设施：通过不可改变特性带来的可靠性、一致性和信心](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) + [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html) ## 资源 **相关文档：** + [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html) + [逐步部署无服务器应用程序](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) + [不可改变基础设施：通过不可改变特性带来的可靠性、一致性和信心](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23) + [蓝绿部署概览](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green) + [Amazon Builders' Library：确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) # REL08-BP05 使用自动化功能部署更改 自动部署与修补以消除负面影响。 对许多组织来说，对生产系统进行变更是风险最大的工作之一。除了软件解决的业务问题外，我们认为部署也是亟待解决的首要问题。如今，这意味着根据实际情况在操作中使用自动化，包括测试和部署更改、添加或删除容量以及迁移数据。AWS CodePipeline 让您可以管理释放您的工作负载所需的步骤。其中包括，采用 AWS CodeDeploy 将应用程序代码自动部署到 Amazon EC2 实例、本地实例、无服务器 Lambda 函数或 Amazon ECS 服务的部署状态。 **推荐** 虽然传统智慧告诉我们，循环中最困难的操作程序应该由人来负责，但出于相同的原因，我们建议您将最困难的程序自动化。 **常见反模式：** + 手动执行更改。 + 通过紧急工作流程跳过自动化中的步骤。 + 未遵守您的计划。 **建立此最佳实践的好处：** 通过自动化功能部署所有更改，可消除引入人为错误的可能性，还能在更改生产之前进行测试，从而确保计划完成。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 实现部署管道的自动化。借助部署管道，您可以调用自动化测试和异常检测，并且能够在生产部署前的某个步骤停止管道，或自动回滚更改。 + [Amazon Builders' Library：确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) + [Amazon Builders' Library：采用持续交付，加速交付进度](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) + 使用 AWS CodePipeline（或受信任的第三方产品）定义和运行您的管道。 + 将管道配置为在将更改实施到代码存储库后开始。 + [什么是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + 使用 Amazon Simple Notification Service（Amazon SNS）和 Amazon Simple Email Service（Amazon SES）在管道中发送有关问题的通知，或者与 Amazon Chime 等团队聊天工具集成。 + [什么是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) + [什么是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) + [什么是 Amazon Chime？](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html) + [使用 Webhook 自动发送聊天消息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助您创建自动化部署解决方案的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=devops) + [AWS Marketplace：可用于自动实施部署的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) + [使用 Webhook 自动发送聊天消息。](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) + [Amazon Builders' Library：确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) + [Amazon Builders' Library：采用持续交付，加速交付进度](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) + [什么是 AWS CodePipeline？](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) + [什么是 CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [AWS Systems Manager 补丁管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) + [什么是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) + [什么是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) **相关视频：** + [2019 年 AWS 峰会：AWS 上的 CI/CD](https://youtu.be/tQcF6SqWCoY) # 故障管理 **Topics** + [ # REL 9  如何备份数据？ ](w2aac19b9c11b5.md) + [ # REL 10  如何使用故障隔离来保护您的工作负载？ ](w2aac19b9c11b7.md) + [ # REL 11  如何将您的工作负载设计为可承受组件故障的影响？ ](w2aac19b9c11b9.md) + [ # REL 12  如何测试可靠性？ ](w2aac19b9c11c11.md) + [ # REL 13  如何规划灾难恢复 (DR)？ ](w2aac19b9c11c13.md) # REL 9  如何备份数据？ 备份数据、应用程序和配置，以满足恢复时间目标（RTO）和恢复点目标（RPO）的要求。 **Topics** + [ # REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据 ](rel_backing_up_data_identified_backups_data.md) + [ # REL09-BP02 保护并加密备份 ](rel_backing_up_data_secured_backups_data.md) + [ # REL09-BP03 自动执行数据备份 ](rel_backing_up_data_automated_backups_data.md) + [ # REL09-BP04 定期执行数据恢复以验证备份完整性和流程 ](rel_backing_up_data_periodic_recovery_testing_data.md) # REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据 所有 AWS 数据存储均提供备份功能。Amazon RDS 和 Amazon DynamoDB 等服务还额外地支持可实现时间点故障恢复（PITR，Point-In-Time Recovery）的自动备份，这使您可以将备份恢复到距当前时间不超过五分钟的任意时间点。许多 AWS 服务提供了将备份复制到其他 AWS 区域 的功能。AWS Backup 工具向您提供了跨 AWS 服务来集中实现自动化数据保护的功能。 Amazon S3 可用作自行管理数据来源和 AWS 托管数据来源的备份目标。Amazon EBS、Amazon RDS 和 Amazon DynamoDB 等 AWS 服务具有可用于创建备份的内置功能。此外，也可使用第三方备份软件。 本地数据可以备份到 AWS 云 中（通过使用 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 或者 [AWS DataSync）](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)。Amazon S3 存储桶可用于在 AWS 上存储此数据。Amazon S3 提供了多种存储层，例如 [Amazon Glacier 或 S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) ，可用于降低数据存储的成本。 您可以从其他来源复制数据，以此来满足数据恢复需求。例如， [Amazon Elasticache 复制节点](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) 或者 [RDS 只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) 可用于在主来源丢失时复制数据。如果此类来源可用于满足您的 [恢复点目标（RPO，Recovery Point Objective）和恢复时间目标（RTO，Recovery Time Objective）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)，则您可能无需备份。在另一个例子中，如果使用 Amazon EMR，只要可以将数据从 S3 复制到 EMR 中， [就无需备份您的 HDFS 数据存储](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/)。 在选择备份策略时，请考虑恢复数据所用的时间。恢复数据所需的时间取决于备份的类型（在采用备份策略时）或数据复制机制的复杂性。此时间应该符合工作负载的 RTO。 **期望结果：** 数据来源已确定，并根据重要性进行了分类。然后，根据 RPO 为数据恢复建立了策略。此策略涉及到备份这些数据来源，或者能够从其他来源复制数据。在出现数据丢失的情况下，所实施的策略可以在定义的 RPO 和 RTO 内实现数据的恢复或再现。 **云成熟度阶段：** 基础 **常见反模式：** + 并不了解工作负载的所有数据来源及其重要性。 + 没有对关键数据来源进行备份。 + 仅对部分数据来源进行备份，但没有考虑重要性标准。 + 没有定义 RPO，或者备份频率无法满足 RPO。 + 没有评估备份是否必需或者是否可以从其他来源复制数据。 **建立此最佳实践的好处：** 确定需要备份的位置并实施某种机制来创建备份，或者具备从外部来源复制数据的能力，这样可以提高在停机期间还原和恢复数据的能力。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 了解并使用工作负载所用的 AWS 服务和资源的备份功能。大部分 AWS 服务提供了备份工作负载数据的功能。 **实施步骤：** 1. **确定工作负载的所有数据来源**。数据可以存储在多种资源中，例如 [数据库](https://aws.amazon.com/products/databases/)， [卷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)， [文件系统](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)， [日志记录系统](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)和 [对象存储](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)。请参阅 **资源** 部分以查找 **相关文档，** 了解存储数据的不同 AWS 服务，以及这些服务提供的备份功能。 1. **根据重要性对数据来源进行分类**。对于工作负载，不同数据集具有不同的重要程度，因此对弹性具有不同的要求。例如，一些数据可能会非常重要，要求接近于零的 RPO，而另一些数据则不那么重要，可以承受较高的 RPO 和某种程度的数据丢失。与此类似，不同数据集也可能会有不同的 RTO 要求。 1. **使用 AWS 或第三方服务来创建数据的备份**。 [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 是一种托管服务，可用于为 AWS 上的各种数据来源创建备份。大部分这些服务还具有原生的创建备份功能。AWS Marketplace 有许多解决方案同样提供了这些功能。请参阅以下列出的 **资源** ，了解如何从不同 AWS 服务创建数据备份的信息。 1. **对于没有备份的数据，请建立数据复制机制**。您可能会出于各种原因，不对可从其他来源复制的数据进行备份。您可能会遇到一种情况，在需要时从来源复制数据的成本相比创建备份更低，因为可能会有与存储备份相关的成本。另一个例子是从备份进行还原的时间比从来源复制数据用时更长，使得备份不符合 RTO 要求。在此类情况下请做出权衡，并建立明确定义的流程，确定在需要进行恢复时如何从这些来源复制数据。例如，如果您从 Amazon S3 将数据加载到数据仓库（如 Amazon Redshift）或 MapReduce 集群（如 Amazon EMR），以便对此类数据进行分析，这就是可从其他来源复制数据的例子。只要此类分析的结果被存储在某位置，或者可重现，您不会因为数据仓库或 MapReduce 集群故障而遭遇数据丢失的情况。其他可从数据源复制数据的例子包括，缓存（如 Amazon ElastiCache）或 RDS 只读副本。 1. **建立备份数据的频率**。创建数据来源的备份是一个定期执行的流程，其频率取决于 RPO。 **实施计划的工作量级别：** 适中 ## 资源 **相关最佳实践：** [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md) [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md) **相关文档：** + [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) + [什么是 AWS DataSync？](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) + [什么是卷网关？](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) + [AWS 合作伙伴：可以帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup) + [AWS Marketplace：可以用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) + [Amazon EBS 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) + [备份 Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) + [备份 Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) + [ElastiCache for Redis 备份和还原](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html) + [在 Neptune 中创建数据库集群快照](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) + [创建数据库快照](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) + [创建按计划触发的 EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) + [跨区域复制](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) （使用 Amazon S3） + [EFS 到 EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) + [将日志数据导出到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) + [对象生命周期管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) + [DynamoDB 的按需备份和还原](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html) + [DynamoDB 的时间点恢复](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) + [使用 Amazon OpenSearch Service 索引快照](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html) **相关视频：** + [AWS re:Invent 2021 – 使用 AWS 进行备份、灾难恢复和勒索软件防护](https://www.youtube.com/watch?v=Ru4jxh9qazc) + [AWS Backup 演示：跨账户和跨区域备份](https://www.youtube.com/watch?v=dCy7ixko3tE) + [AWS Backup re:Invent 2019：深入了解 AWS，主讲：Rackspace（STG341）](https://youtu.be/av8DpL0uFjc) **相关示例：** + [Well-Architected 实验室：为 Amazon S3 实施双向跨区域复制（CRR，Cross-Region Replication）](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) + [Well-Architected 实验室：测试数据的备份与还原](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) + [Well-Architected 实验室：面向分析工作负载的备份和还原（具备故障恢复功能）](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) + [Well-Architected 实验室：灾难恢复 – 备份与还原](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) # REL09-BP02 保护并加密备份 使用 AWS IAM 等身份验证和授权服务，控制并检测对备份的访问。使用加密功能，防止并检测备份的数据完整性是否受到损坏。 Amazon S3 支持多种对您的静态数据进行加密的方式。借助服务器端加密功能，Amazon S3 以未加密数据的形式接受您的对象，然后在存储此类数据时进行加密。若采用客户端加密，您的工作负载应用程序需要负责在将其发送到 Amazon S3 之前加密数据。这两种方式都让您可以使用 AWS Key Management Service（AWS KMS）创建并存储数据密钥，或者您也可以提供自己的密钥并自行对其负责。使用 AWS KMS，您可以通过 IAM 设置策略，决定谁可以以及谁不可以访问您的数据密钥与解密数据。 针对 Amazon RDS，如果您已选择对数据库进行加密，那么您的备份也会被加密。DynamoDB 备份则始终被加密。 **常见反模式：** + 对备份和还原自动化的访问权限与对数据的访问权限相同。 + 未加密您的备份。 **建立此最佳实践的好处：** 保护备份安全可防止篡改数据，而加密数据可防止数据意外暴露时对其访问。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 对每个数据存储使用加密功能。如果源数据已加密，则备份也将被加密。 + 在 RDS 中启用加密功能。当您创建 RDS 实例时，可以使用 AWS Key Management Service 配置静态加密。 + [加密 Amazon RDS 资源](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) + 在 EBS 卷中启用加密。您可以配置默认加密或在创建卷时指定唯一密钥。 + [Amazon EBS 加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) + 使用所需的 Amazon DynamoDB 加密。DynamoDB 会加密所有静态数据。您可以使用 AWS 拥有的 AWS KMS 密钥或者 AWS 托管 KMS 密钥，指定存储在您账户中的密钥。 + [DynamoDB 静态加密](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) + [管理加密的表](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) + 加密 Amazon EFS 中存储的数据。在创建文件系统时配置加密。 + [在 EFS 中加密数据和元数据](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) + 在源和目标区域中配置加密功能。您可以使用 KMS 中存储的密钥配置 Amazon S3 中的静态加密，但这些密钥是特定于区域的。您在配置复制时可以指定目标密钥。 + [CRR 附加配置：复制通过存储在 AWS KMS 中的加密密钥、使用服务器端加密（SSE，Server-Side Encryption）创建的对象](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) + 实施用于访问您的备份的最低权限。请遵循最佳实践，根据安全最佳实践来限制对备份、快照和副本的访问。 + [安全性支柱：AWS Well-Architected](./wat.pillar.security.en.html) ## 资源 **相关文档：** + [AWS Marketplace：可以用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) + [Amazon EBS 加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) + [Amazon S3：利用加密保护数据](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) + [CRR 附加配置：复制通过存储在 AWS KMS 中的加密密钥、使用服务器端加密（SSE，Server-Side Encryption）创建的对象](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) + [DynamoDB 静态加密](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) + [加密 Amazon RDS 资源](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) + [在 EFS 中加密数据和元数据](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) + [AWS 中的备份的加密](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) + [管理加密的表](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) + [安全性支柱：AWS Well-Architected](./wat.pillar.security.en.html) **相关示例：** + [Well-Architected 实验室：为 Amazon S3 实施双向跨区域复制（CRR，Cross-Region Replication）](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) # REL09-BP03 自动执行数据备份 将备份配置为根据遵循恢复点目标（RPO，Recovery Point Objective）的定期计划自动备份，或者在数据集发生更改时自动备份。具有低数据丢失需求的关键数据资产需要频繁地自动备份，而可以接受某些丢失的较不重要数据的备份频率可以更低。 AWS Backup 可用于创建各种 AWS 数据来源的自动数据备份。Amazon RDS 实例可以按照五分钟的频率进行几乎连续的备份，Amazon S3 对象可以按照十五分钟的频率进行几乎连续的备份，提供可恢复到备份历史记录中的特定时间点的时间点故障恢复（PITR，Point-In-Time Recovery）功能。对于其他 AWS 数据来源，例如 Amazon EBS 卷、Amazon DynamoDB 表或 Amazon FSx 文件系统，AWS Backup 最快可以按每小时的频率运行自动备份。这些服务还提供了原生备份功能。以下 AWS 服务提供了具备时间点故障恢复的自动备份功能： [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html)， [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)和 [Amazon Keyspaces（Apache Cassandra 兼容）](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) – 这些备份可以恢复到备份历史记录中的特定时间点。大部分其他 AWS 数据存储服务提供了计划定期备份的功能，频率最快为每小时一次。 Amazon RDS 和 Amazon DynamoDB 提供支持时间点故障恢复的持续备份。一旦启用，Amazon S3 版本控制就会自动执行。[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) 可用于自动创建、复制和删除 Amazon EBS 快照。它还可以自动创建、复制、弃用和取消注册 Amazon EBS 支持的亚马逊云机器镜像（AMI，Amazon Machine Image）及其底层 Amazon EBS 快照。 针对您的备份自动化和历史的集中式视图，AWS Backup 提供完全托管的基于策略的备份解决方案。它会使用 AWS Storage Gateway 将云端和本地的多项 AWS 服务的数据备份集中在一起并自动处理。 除了版本控制，Amazon S3 还具有复制功能。整个 S3 存储桶都可自动复制到相同或不同 AWS 区域 中的其他存储桶。 **期望结果：** 按照确定的节奏创建数据来源备份的自动流程。 **常见反模式：** + 手动执行备份。 + 使用具有备份功能的资源，但不包括自动化中的备份。 **建立此最佳实践的好处：** 自动化备份可以确保按照 RPO 执行备份，并在未备份时发出警报。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 1. **确定当前** 在手动备份的数据来源。请参阅 [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md) 以获取有关此项的指南。 1. **确定工作负载的** RPO。请参阅 [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md) 以获取有关此项的指南。 1. **使用自动化备份解决方案或托管服务**。AWS Backup 是一项完全托管的服务，它简化了 [跨 AWS 服务、云端以及本地以集中方式自动进行数据保护的过程](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups)。备份计划是 AWS Backup 的功能，可用于创建规则来定义要备份的资源，以及创建这些备份的频率。此频率应遵循在第 2 步中确定的 RPO。 [本 WA 实验室](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 提供有关如何使用 AWS Backup 创建自动备份的动手实践指南。大多数存储数据的 AWS 服务提供了原生备份功能。例如，可以利用 RDS 来实现支持时间点故障恢复（PITR，Point-In-Time Recovery）的自动备份。 1. **对于** 自动备份解决方案或托管服务不支持的数据来源（如本地数据来源或消息队列），请考虑使用受信任的第三方解决方案来创建自动备份。或者，您可以使用 AWS CLI 或开发工具包创建自动化过程来完成此操作。您可以使用 AWS Lambda 函数或 AWS Step Functions 来定义创建数据备份中涉及的逻辑，并使用 Amazon EventBridge 按照基于 RPO 确定的频率来执行它（如第 2 步中所述）。 **实施计划的工作量级别：** 低 ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup) + [AWS Marketplace：可以用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) + [创建按计划触发的 EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) + [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) + [什么是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) **相关视频：** + [AWS Backup re:Invent 2019：深入了解 AWS，主讲：Rackspace（STG341）](https://youtu.be/av8DpL0uFjc) **相关示例：** + [Well-Architected 实验室：测试数据的备份与还原](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) # REL09-BP04 定期执行数据恢复以验证备份完整性和流程 通过执行恢复测试，验证您的备份流程实施是否满足恢复时间目标（RTO）和恢复点目标（RPO）要求。 使用 AWS，您可以构建一个测试环境，还原您的备份以评估 RTO 和 RPO 功能，并且对数据的内容和完整性执行测试。 此外，Amazon RDS 和 Amazon DynamoDB 还允许时间点恢复 (PITR)。您可以使用持续备份将您的数据集还原到其在指定日期与时间所处的状态。 **期望结果：** 使用明确定义的机制定期从备份恢复数据，确保可以按照为工作负载确定的恢复时间目标（RTO，Recovery Time Objective）来恢复数据。验证从备份进行还原可以得到包含原始数据的资源，而不会造成数据损坏或无法访问数据，并且数据丢失在恢复点目标（RPO，Recovery Point Objective）之内。 **常见反模式：** + 还原备份，但未查询或检索任何数据以确保还原操作可用。 + 假定采取了备份。 + 假定系统的备份完全正常运行，并且可从中恢复数据。 + 假定从备份还原或恢复数据的时间满足工作负载的 RTO。 + 假定备份中包含的数据满足工作负载的 RPO + 临时进行还原，没有使用运行手册或者没有按照确定的自动程序执行。 **建立此最佳实践的好处：** 测试备份的恢复过程可以确保在需要时能够将数据还原，不必担心数据可能丢失或损坏，可以按照工作负载要求的 RTO 还原和恢复，并且任何数据丢失都在工作负载的 RPO 以内。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 测试备份和还原功能可树立信心，确信能够在出现中断时执行这些操作。定期将备份还原到新的位置，并运行测试以验证数据的完整性。需要执行一些常见的测试，以检查 数据是否可用、没有损坏、是否可以访问并且任意数据丢失都符合工作负载的 RPO。此类测试还可以帮助确定恢复机制是否足够快以满足工作负载的 RTO 要求。 1. **确定当前** 所备份的数据来源以及存储这些备份的位置。请参阅 [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md) 以获取有关如何实施此项的指导。 1. **为每个** 数据来源建立数据验证标准。不同类型的数据具有不同的属性，这可能需要不同的验证机制。在将此数据用于生产之前，请考虑可以如何验证此数据。一些验证数据的常见方法包括使用数据和备份属性，例如数据类型、格式、校验和、大小，或者将这些属性与自定义的验证逻辑结合使用。例如，可以将所恢复资源的校验和值，与创建备份时数据来源的校验和值进行比较。 1. **建立 RTO 和 RPO** 以根据数据重要性来还原数据。请参阅 [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md) 以获取有关如何实施此项的指导。 1. **评估数据恢复能力**。检查备份和还原策略，了解它是否可以满足您的 RTO 和 RPO，并根据需要调整策略。使用 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)，您可以对工作负载运行评估。该评估根据弹性策略评估您的应用程序配置，并报告是否能够满足 RTO 和 RPO 目标。 1. **使用当前** 为生产环境中数据还原所确立的流程执行测试还原。这些流程依赖于对原始数据来源进行备份的方法，备份本身的格式和存储位置，或者数据是否从其他来源复制。例如，如果您使用 [AWS Backup 等托管服务，则此过程可能就是简单地将备份恢复到新的资源](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html)。如果您使用 AWS 弹性灾难恢复，则可以 [启动恢复演习。](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)。 1. **根据您之前在** 第 2 步中为数据验证确立的标准，从还原后的资源（来自上一步）验证数据恢复。还原和恢复的数据是否包含备份时的最新记录/项目？ 此数据是否在工作负载的 RPO 之内？ 1. **测量** 还原和恢复所需的时间，并与在之前在第 3 步中确立的 RTO 进行比较。此流程是否符合工作负载的 RTO？ 例如，比较还原进程开始时的时间戳以及恢复验证完成时的时间戳，以计算此进程的用时。所有 AWS API 调用均有时间戳，此信息在 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)中提供。虽然此信息可以提供还原进程何时开始的详细信息，但验证完成时的结束时间戳应该由您的验证逻辑来记录。如果使用自动化进程，则 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 等服务可用于存储此信息。此外，许多 AWS 服务提供了事件历史记录，其中可提供发生特定操作时的时间戳信息。在 AWS Backup 中，备份和还原操作称为 *作业*，这些作业在其元数据中包含时间戳信息，可用于测量还原和恢复所需的时间。 1. **如果** 数据验证失败，或者如果还原和恢复所需的时间超过了为工作负载设定的 RTO，则通知利益相关方。在实施自动化以完成此操作时 [（例如在本实验中）](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)，可以使用 Amazon Simple Notification Service（Amazon SNS）等服务将推送通知（例如电子邮件或 SMS）发送给利益相关方。 [这些消息还可以发布到消息传递应用程序，例如 Amazon Chime、Slack 或 Microsoft Teams，](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) 或者 [通过使用 AWS Systems Manager OpsCenter 来创建 OpsItems 等任务](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html)。 1. **自动执行此流程以便定期运行**。例如，AWS Lambda 等服务或 AWS Step Functions 中的状态机可用于自动完成还原和恢复流程，Amazon EventBridge 可用于定期触发此自动工作流，如以下架构图中所示。了解如何 [使用 AWS Backup 自动完成数据恢复验证](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)。此外， [本 Well-Architected 实验室](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 提供动手实践体验，可用于练习针对此处的多个步骤实现自动化的方法。 ![\[图中显示自动化的备份和还原流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png) **实施计划的工作量级别：** 中到高，具体取决于验证条件的复杂性。 ## 资源 **相关文档：** + [使用 AWS Backup 自动完成数据恢复验证](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) + [AWS 合作伙伴：可以帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup) + [AWS Marketplace：可以用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) + [创建按计划触发的 EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) + [DynamoDB 的按需备份和还原](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html) + [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) + [什么是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [什么是 AWS 弹性灾难恢复](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) + [AWS 弹性灾难恢复](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) **相关示例：** + [Well-Architected 实验室：测试数据的备份与还原](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) # REL 10  如何使用故障隔离来保护您的工作负载？ 故障隔离边界可将一个工作负载内的故障影响限制于有限数量的组件。边界以外的组件不会受到故障的影响。使用多个故障隔离边界，您可以限制作用于您的工作负载的影响。 **Topics** + [ # REL10-BP01 将工作负载部署到多个位置 ](rel_fault_isolation_multiaz_region_system.md) + [ # REL10-BP02 为您的多位置部署选择合适的位置 ](rel_fault_isolation_select_location.md) + [ # REL10-BP03 组件的自动恢复受限于单个位置 ](rel_fault_isolation_single_az_system.md) + [ # REL10-BP04 采用隔板架构来限制影响范围 ](rel_fault_isolation_use_bulkhead.md) # REL10-BP01 将工作负载部署到多个位置 将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。可通过选择不同位置满足各种需求。 在 AWS，服务设计的其中一个基本原则是避免底层物理基础设施中存在单点故障。这促使我们构建使用多个可用区并能灵活应对单个可用区故障的软件和系统。同样，系统也被构建可灵活应对单个计算节点、单个存储卷或单个数据库实例故障。构建依赖冗余组件的系统时，务必要确保组件独立运行；如果是 AWS 区域，组件应自主运行。只有实现了这一点，采用冗余组件的理论可用性计算的优点才能发挥作用。 **可用区（AZ，Availability Zone）** AWS 区域由在设计上彼此相互独立的多个可用区组成。每个可用区之间都间隔相当的物理距离，以避免因环境公害（如火灾、洪水和龙卷风）导致的相互关联的故障情况。每个可用区还拥有独立的物理基础设施：专用的公用电源连接、独立备份电源、独立机械服务以及可用区内外的独立网络连接。此设计将任意这些系统的故障限制在受影响的那一个 AZ 中。尽管可用区在地理位置上相互分离，但它们位于相同的区域中，从而实现高吞吐量、低延迟的联网。整个 AWS 区域（跨多个可用区，由多个物理上独立的设计中心组成）可以视为工作负载的单个逻辑部署目标，包括同步复制数据（例如，在两个数据库之间）的能力。这样一来，您便能在主动/主动或主动/备用配置中使用可用区。 可用区是独立的，因此当工作负载采用了使用多个可用区的架构时，可以提高工作负载的可用性。一些 AWS 服务（包括 Amazon EC2 实例数据面板）作为严格的区级别服务部署，与其所在的可用区共存亡。其他 AZ 中的 Amazon EC2 实例不受影响，可以继续正常工作。与此类似，如果某个可用区中的故障导致 Amazon Aurora 数据库失败，则不受影响的 AZ 中的只读副本 Aurora 实例可以自动提升为主实例。另一方面，区域性 AWS 服务（例如 Amazon DynamoDB）在内部以主动/主动配置的形式使用多个可用区，以实现为该服务设定的可用性设计目标，而且无需您配置 AZ 置放。 ![\[图中显示跨三个可用区部署的多层架构。请注意，Amazon S3 和 Amazon DynamoDB 始终会自动部署到多个可用区。而 ELB 也会被部署到所有三个区。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png) 虽然 AWS 控制面板通常提供在整个区域（多个可用区）内管理资源的功能，但某些控制面板（包括 Amazon EC2 和 Amazon EBS）能够将结果筛选到单个可用区。完成筛选后，请求仅在指定可用区中进行处理，从而降低其他可用区的中断风险。此 AWS CLI 示例演示仅从 us-east-2c 可用区中获取 Amazon EC2 实例信息： ``` AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c ``` *AWS Local Zones* AWS Local Zones 在其各自的 AWS 区域内的作用与可用区相似，它们可被选择作为区级别 AWS 资源（如子网和 EC2 实例）的置放位置。特别之处在于，它们并不位于相关的 AWS 区域内，而是靠近目前还未设置 AWS 区域的人口密集的工业和 IT 中心。但是，您还是可以享有高带宽，并且能够在本地区域的本地工作负载与在 AWS 区域内运行的工作负载之间进行安全连接。您应该利用 AWS Local Zones 将工作负载尽量部署在接近用户的地方，以满足低延迟的要求。 **Amazon 全球边缘网络** Amazon 全球边缘网络由全球各大城市的边缘站点组成。Amazon CloudFront 使用此网络以较低的延迟向最终用户分发内容。您可以通过 AWS Global Accelerator 在这些边缘站点创建您的工作负载端点，以便在靠近您的用户的 AWS 全球网络进行接入。利用 Amazon API Gateway，使用 CloudFront 分配的边缘优化 API 端点可以通过最近的边缘站点方便客户端访问。 *AWS 区域* AWS 区域采用自主设计，因此通过多区域方法，您可以将服务的专用副本部署到每个区域。 多区域方法对于 *灾难恢复* 策略很常见，用于在偶发的大规模事件中满足恢复目标。请参阅 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 以了解有关这些策略的更多信息。不过，这里我们的重点是 *可用性*，旨在达成长期使用中的平均正常运行时间目标。对于高可用性目标，通常可以将多区域架构设计为主动/主动模式，各个服务副本（在其各自的区域中）处于活动状态（为请求提供服务）。 **推荐** 大多数工作负载的可用性目标都可通过在单个 AWS 区域内采用多 AZ 策略来实现。只有当工作负载具有极高的可用性要求或者其他业务目标时，才考虑多区域架构，在这些情况下需要使用多区域架构。 AWS 提供了跨区域运行服务的功能。例如，AWS 使用 Amazon Simple Storage Service（Amazon S3）复制、Amazon RDS 只读副本（包括 Aurora 只读副本）和 Amazon DynamoDB 全局表，提供了连续异步数据复制功能。通过连续复制，您的数据版本可近乎实时地供各个活动区域使用。 使用 AWS CloudFormation，您可以跨 AWS 账户和 AWS 区域定义基础设施并一致地进行部署。AWS CloudFormation StackSets 扩展了此功能，允许您通过单个操作，跨多个账户和区域创建、更新或删除 AWS CloudFormation 堆栈。对于 Amazon EC2 实例部署，亚马逊云机器镜像（AMI，Amazon Machine Image）可用于提供诸如硬件配置和已安装软件等信息。您可以实施 Amazon EC2 Image Builder 管道来创建所需的 AMI，并将这些 AMI 复制到您的活动区域。这可以确保这些 *Golden AMI* 具有您需要部署的所有内容，并可在各个新区域中扩展您的工作负载。 对于路由流量，Amazon Route 53 和 AWS Global Accelerator 均可定义策略来确定哪些用户转向哪个活动的区域端点。使用 Global Accelerator，您可以设置流量转盘，控制导向各个应用程序端点的流量的百分比。Route 53 支持这种百分比方法，还有多个其他策略可用，包括基于地理位置距离和延迟的策略。Global Accelerator 自动利用 AWS 边缘服务器广泛的网络，尽可能快地将流量载入到 AWS 主干网，从而得到较低的请求延迟。 所有这些功能在执行时，都保留了各个区域的自主性。这种方法有极少的例外，包括我们提供全球边缘交付的服务（例如 Amazon CloudFront 和 Amazon Route 53），以及 AWS Identity and Access Management（IAM）服务的控制面板。大多数服务都完全在单个区域中运行。 **本地数据中心** 对于在本地数据中心运行的工作负载来说，尽可能打造混合体验。AWS Direct Connect 提供从您的本地到 AWS 的专用网络连接，使您可以同时在两者中运行。 另一个选项是，通过 AWS Outposts 在本地运行 AWS 基础设施和服务。AWS Outposts 是一项完全托管式服务，可将 AWS 基础设施、AWS 服务、API 和工具延伸到您的数据中心。在您的设计中心会安装与 AWS 云 中使用的相同硬件基础设施。然后，AWS Outposts 会连接到最近的 AWS 区域。您可以使用 AWS Outposts 支持您的低延迟工作负载，或满足本地数据处理要求。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 使用多个可用区和 AWS 区域。将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。可通过选择不同位置满足各种需求。 + 区域性服务本质上是跨多个可用区部署的。 + 这包括 Amazon S3、Amazon DynamoDB 和 AWS Lambda（未连接到 VPC 时） + 将容器、实例和基于功能的工作负载部署到多个可用区中。使用包括缓存在内的多可用区数据存储。使用 EC2 Auto Scaling、ECS 任务置放、AWS Lambda 函数配置（在 VPC 中运行时）和 ElastiCache 集群的功能。 + 部署 Auto Scaling 组时，请使用单独可用区中的子网。 + [示例：跨多个可用区分布实例](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) + [Amazon ECS 任务置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + [配置 AWS Lambda 函数以访问 Amazon VPC 中的资源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) + [选择区域和可用区](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) + 部署 Auto Scaling 组时，请使用单独可用区中的子网。 + [示例：跨多个可用区分布实例](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) + 使用 ECS 任务置放参数，并指定数据库子网组。 + [Amazon ECS 任务置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + 配置要在 VPC 中运行的函数时，请使用多个可用区中的子网。 + [配置 AWS Lambda 函数以访问 Amazon VPC 中的资源](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) + 将多个可用区与 ElastiCache 集群配合使用。 + [选择区域和可用区](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) + 如果您的工作负载必须部署到多个区域，请选择一个多区域策略。大多数可靠性需求可通过在单个 AWS 区域中使用多可用区策略来满足。可在必要时使用多区域策略来满足您的业务需求。 + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + 备份到另一个 AWS 区域可以让您更加确信，数据在需要时可用。 + 有些工作负载具有法规要求，需要使用多区域策略。 + 评估您工作负载的 AWS Outposts。如果您的工作负载需要到本地部署数据中心的较低延迟，或具有本地数据处理要求，然后使用 AWS Outposts 在本地运行 AWS 基础设施和服务 + [什么是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) + 确定 AWS Local Zones 是否可以帮助您为用户提供服务。如果您有低延迟要求，请查看 AWS Local Zones 是否距离您的用户较近。如果是，则使用它将工作负载部署到离这些用户较近的位置。 + [AWS Local Zones 常见问题](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) ## 资源 **相关文档：** + [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure) + [AWS Local Zones 常见问题](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) + [Amazon ECS 任务置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + [选择区域和可用区](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) + [示例：跨多个可用区分布实例](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) + [全局表：使用 DynamoDB 的多区域复制](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) + [使用 Amazon Aurora 全局数据库](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) + [使用 AWS 服务创建多区域应用程序博客系列](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) + [什么是 AWS Outposts？](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + [AWS re:Invent 2019：AWS 全球网络基础设施的创新与运营（NET339）](https://youtu.be/UObQZ3R9_4c) # REL10-BP02 为您的多位置部署选择合适的位置 ## 期望结果 要实现高可用性，请始终（在可能时）将您的工作负载组件部署到多个可用区（AZ，Availability Zone），如图 10 中所示。对于具有极高弹性要求的工作负载，请谨慎评估用于多区域架构的选项。 ![\[图中显示一个弹性多 AZ 数据库部署，该部署备份到另一个 AWS 区域\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png) ## 常见反模式 + 在多 AZ 架构可以满足需求时选择设计多区域架构。 + 当应用程序部件之间的弹性和多位置需求不同时，没有考虑它们之间的依赖关系。 ## 建立此最佳实践的好处 要实现弹性，您应使用构建防御层的方法。其中一层使用多 AZ，通过构建高度可用的架构，防护较小规模的、更常见的中断。另一个防御层用于防御很少发生的事件，例如大范围的自然灾害和区域级别的中断。这个第二层涉及到设计应用程序的架构来跨越多个 AWS 区域。 + 99.5% 的可用性与 99.99% 的可用性相比，每个月的正常运行时间之差超过 3.5 小时。采用多 AZ 的工作负载的可用性，预期只能达到“四个九”。 + 通过在多个 AZ 中运行工作负载，您可以隔离电力、冷却和网络中的故障，以及火灾和洪水之类的大多数自然灾害。 + 为工作负载实施多区域策略，有助于防御影响到某个国家/地区中较大地理面积的大范围自然灾害，或者区域范围的技术故障。请注意，实施多区域架构会有很高的复杂性，对于大部分工作负载通常来说都是不必要的。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 对于一个可用区的中断或部分丢失而导致的灾难事件，在单个 AWS 区域内的多个可用区中实施高可用工作负载，有助于防范自然灾难和技术灾难。每个 AWS 区域由多个可用区组成，各个可用区之间实现了故障隔离并且间隔相当的物理距离。不过，对于可能造成间隔相当距离的多个可用区组件丢失风险的灾难事件，您应该实施灾难恢复选项，以防范整个区域的自然灾难和技术故障。对于需要极高弹性的工作负载（关键基础设施、与生命健康相关的应用程序、财务系统基础设施等），需要使用多区域策略。 ## 实施步骤 1. 评估您的工作负载并确定需要使用多 AZ 方法（单个 AWS 区域）还是多区域方法才能够满足弹性需求。实施多区域架构来满足这些需求会引入额外的复杂性，因此请谨慎考虑您的使用场景及其需求。弹性需求几乎总是可以使用单个 AWS 区域来满足。在确定您是否需要使用多区域时，请考虑以下可能的需求： 1. **灾难恢复（DR，Disaster Recovery）**：对于一个可用区的中断或部分丢失而导致的灾难事件，在单个 AWS 区域内的多个可用区中实施高可用工作负载，有助于防范自然灾难和技术灾难。对于可能造成间隔相当距离的多个可用区组件丢失风险的灾难事件，您应该实施跨多个区域的灾难恢复，以防范整个区域的自然灾难和技术故障。 1. **高可用性（HA，High Availability）**：多区域架构（在每个区域中使用多个 AZ）可用于实现四个 9 以上（> 99.99%）的可用性。 1. **堆栈本地化**：面向全球受众部署工作负载时，您可以将本地化的堆栈部署在不同的 AWS 区域中，以便服务于这些区域中的受众。本地化可以包括语言、货币和所存储数据的类型。 1. **靠近用户：** 面向全球受众部署工作负载时，您可以通过在靠近最终用户所在位置的 AWS 区域中部署堆栈，从而减少延迟。 1. **数据驻留**：一些工作负载面临着数据驻留要求，来自特定用户的数据必须保留在特定国家/地区的边界内。根据相关的法规，您可以选择将整个堆栈或者仅仅将数据部署到这些边界内的 AWS 区域中。 1. 以下是 AWS 服务提供的一些多 AZ 功能的示例： 1. 为了使用 EC2 或 ECS 保护工作负载，请在计算资源前端部署 Elastic Load Balancer。然后，Elastic Load Balancing 提供解决方案来检测未正常运行的区中的实例，并将流量路由到正常运行的区中。 1. [开始使用 Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html) 1. [开始使用网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html) 1. 当 EC2 实例运行不支持负载均衡的现成商用软件时，您可以通过实施多 AZ 灾难恢复方法来实现某种形式的容错能力。 1. [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md) 1. 对于 Amazon ECS 任务，将您的服务均匀地部署在三个 AZ 上以实现可用性与成本的平衡。 1. [Amazon ECS 可用性最佳实践 \$1 容器](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/) 1. 对于非 Aurora Amazon RDS，您可以选择多 AZ 作为配置选项。在主数据库实例出现故障时，Amazon RDS 会自动提升备用数据库，用于接收其他可用区中的流量。还可以创建多区域只读副本来改进弹性。 1. [Amazon RDS 多可用区部署](https://aws.amazon.com/rds/features/multi-az/) 1. [在不同 AWS 区域中创建只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html) 1. 以下是 AWS 服务提供的一些多区域功能的示例： 1. 对于 Amazon S3 工作负载，当服务自动提供了多 AZ 可用性时，如果需要多区域部署，请考虑多区域接入点。 1. [Amazon S3 中的多区域接入点](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) 1. 对于 DynamoDB 表，此时服务自动提供了多 AZ 可用性，您可以轻松地将现有表转换为全局表来利用多区域的优势。 1. [将单区域 Amazon DynamoDB 表转换为全局表](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/) 1. 如果您的工作负载采用 Application Load Balancers 或网络负载均衡器作为前端，请将流量引导到包含正常运行端点的多个区域，从而使用 AWS Global Accelerator 来改进应用程序的可用性。 1. [AWS Global Accelerator 中标准加速器的端点 – AWS Global Accelerator（amazon.com）](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html) 1. 对于利用 AWS EventBridge 的应用程序而言，请考虑使用跨区域总线来将事件转发到您选择的其他区域。 1. [在 AWS 区域之间发送和接收 Amazon EventBridge 事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 1. 对于 Amazon Aurora 数据库，请考虑使用跨多个 AWS 区域的 Aurora 全局数据库。可以对现有集群进行修改来添加新的区域。 1. [开始使用 Amazon Aurora 全局数据库](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html) 1. 如果您的工作负载包括 AWS Key Management Service（AWS KMS）加密密钥，请考虑多区域密钥是否适合您的应用程序。 1. [AWS KMS 中的多区域密钥](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 1. 对于其他 AWS 服务功能，请参阅此博客系列中的以下内容： [使用 AWS 服务创建多区域应用程序系列](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) **实施计划的工作量级别： **中到高 ## 资源 **相关文档：** + [使用 AWS 服务创建多区域应用程序系列](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) + [AWS 上的灾难恢复（DR，Disaster Recovery）架构，第 IV 部分：多站点主动/主动](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) + [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure) + [AWS Local Zones 常见问题](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) + [AWS 上的灾难恢复（DR，Disaster Recovery）架构，第 I 部分：云中的恢复策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) + [云中的灾难恢复不相同](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html) + [全局表：使用 DynamoDB 的多区域复制](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + [Auth0：多区域高可用性架构，可扩展至每月 15亿\$1 次登录，并具有自动故障转移功能](https://www.youtube.com/watch?v=vGywoYc_sA8) **相关示例：** + [AWS 上的灾难恢复（DR，Disaster Recovery）架构，第 I 部分：云中的恢复策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) + [DTCC 实现了本地部署无法企及的弹性](https://aws.amazon.com/solutions/case-studies/DTCC/) + [Expedia Group 使用具有专有 DNS 服务的多区域、多可用区架构来增加应用程序的弹性](https://aws.amazon.com/solutions/case-studies/expedia/) + [Uber：用于多区域 Kafka 的灾难恢复](https://eng.uber.com/kafka/) + [Netflix：实现多区域弹性的主动-主动架构](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b) + [我们如何为 Atlassian Cloud 构建数据驻留](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud) + [Intuit TurboTax 跨两个区域运行](https://www.youtube.com/watch?v=286XyWx5xdQ) # REL10-BP03 组件的自动恢复受限于单个位置 如果工作负载的组件只能在单个可用区或本地部署数据中心内运行，您必须实施相关功能，以在定义的恢复目标内彻底重建工作负载。 如果由于技术限制无法使用将工作负载部署到多个位置的最佳实践，您必须实施其他的弹性路径。在这种情况下，您必须让重建必要基础设施、重新部署应用程序和重建必要数据的操作实现自动化。 例如，Amazon EMR 会为相同可用区内的特定集群启动全部节点，因为在相同区内运行集群可以改善作业流的性能，提高数据访问速率。如果这是工作负载弹性所需的必要组件，则您必须设法重新部署集群及其数据。同样对于 Amazon EMR，您还应该通过除多可用区以外的方式对冗余进行预置。您可以预置 [多个节点](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html)。使用 [EMR 文件系统 (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)，EMR 中的数据可存储在 Amazon S3 内，进而可以实现跨多个可用区或 AWS 区域复制。 同样，对于 Amazon Redshift 来说，它默认会在您选择的 AWS 区域内随机选择可用区，然后对其中的集群进行预置。相同区内的全部集群节点都会被预置。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 实施自我修复。尽可能使用弹性伸缩部署实例或容器。如果不能使用弹性伸缩，则使用 EC2 实例的自动恢复功能，或者基于 Amazon EC2 或 ECS 容器生命周期事件实施自我修复自动化。 + 将 Auto Scaling 组用于对单个实例 IP 地址、私有 IP 地址、弹性 IP 地址和实例元数据没有要求的实例和容器工作负载。 + [什么是 EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [服务弹性伸缩](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) + 启动配置用户数据可以用于实现自动化，从而让大多数工作负载可以自我修复。 + 将 EC2 实例的自动恢复功能用于需要单个实例 ID 地址、私有 IP 地址、弹性 IP 地址和实例元数据的工作负载。 + [恢复您的实例。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + 自动恢复功能会在检测到实例故障时，向 SNS 主题发送恢复状态提醒。 + 在无法使用弹性伸缩或 EC2 恢复的情况下，请使用 EC2 实例生命周期事件或 ECS 事件实现自我修复自动化。 + [EC2 Auto Scaling 生命周期钩子](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) + [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) + 使用这些事件调用自动化，该自动化将根据您需要的流程逻辑来修复组件。 ## 资源 **相关文档：** + [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) + [EC2 Auto Scaling 生命周期钩子](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) + [恢复您的实例。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [服务弹性伸缩](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) + [什么是 EC2 Auto Scaling？](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL10-BP04 采用隔板架构来限制影响范围 类似于船上的隔板，此模式确保将故障限制在一小部分请求或客户端，受损的请求数量有限，因此大部分请求可以继续执行而不会受错误影响。数据的隔板经常被称作分区，而服务的隔板称为单元格。 在 *基于单元格的架构中*，每个单元格都是完整、独立的服务实例，而且都有固定的最大大小。当负载增加时，工作负载会通过添加更多单元格而变大。分区键用于传入流量，以确定哪个单元格将处理请求。任何故障都会被限制在它所发生的单个单元格内，因此受损请求的数量有限，而其他单元格将继续执行而不受错误影响。确定适当的分区键，最大限度地减少跨单元格交互，以便使每个请求无需使用复杂的映射服务，这一点非常重要。需要复杂映射的服务最终只是把问题转移到映射服务上，而需要跨单元格交互的服务会在单元格之间创建依赖关系（因此这样做会减少假定的可用性改进）。 ![\[图中显示基于 Cell 的架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png) Colm MacCarthaigh 在他的 AWS 博客中说明了 Amazon Route 53 如何利用 [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) 的概念来隔离客户请求以避免影响其他分区。在此情况下，一个分区由两个或更多单元格组成。根据分区键，来自客户（或资源，或其他您想要隔离的对象）的流量会被路由至其指定的分区。若有八个单元格（每个分区中有两个单元格），而且在四个分区中划分客户，25% 的客户将在出现问题时受到影响。 ![\[图中显示一个划分为传统分片的服务\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png) 通过随机分区，您可以创建由两个单元格组成的虚拟分区，然后将您的客户指定给其中的一个虚拟分区。当问题发生时，您还是会失去完整服务的四分之一，但分配客户或资源的方式意味着若采用随机分区，影响的范围会在很大程度上小于 25%。在八个单元格中，存在着 28 种由两个单元格组成的独特组合，亦即有 28 种可能的随机分区（虚拟分区）。如果您有数百或数千个客户，并将每个客户指定给一个随机分区，那么问题的影响范围仅为 1/28。这比正常分区的情况好七倍。 ![\[图中显示一个划分为随机分片的服务。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png) 除了单元格，分区还可用于服务器、队列或其他资源。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 采用隔板架构。类似于船上的隔板，此模式确保将故障限制在较小的请求或用户子集，受损的请求数量有限，因此大部分可以继续执行而不会受错误影响。数据的隔板经常被称作分区，而服务的隔板称为单元格。 + [Well-Architected 实验室：使用随机分区进行故障隔离](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) + [随机分片：AWS re:Invent 2019：Amazon Builders’ Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=1373) + [AWS re:Invent 2018：AWS 如何将故障的影响范围最小化（ARC338）](https://youtu.be/swQbA4zub20) + 评估工作负载的基于 Cell 的架构。在基于单元格的架构中，每个单元格都是完整、独立的服务实例，而且都有固定的最大大小。当负载增加时，工作负载会通过添加更多单元格而变大。分区键用于传入流量，以确定哪个单元格将处理请求。任何故障都会被限制在它所发生的单个单元格内，因此受损请求的数量有限，而其他单元格将继续执行而不受错误影响。确定适当的分区键，最大限度地减少跨单元格交互，以便使每个请求无需使用复杂的映射服务，这一点非常重要。需要复杂映射的服务最终只是把问题转移到映射服务上，而需要跨 Cell 交互的服务会降低 Cell 的自主性（因此，假定这样做可以提高可用性）。 + Colm MacCarthaigh 在他的 AWS 博客中说明了 Amazon Route 53 如何利用随机分片的概念来隔离客户请求以避免影响其他分片 + [随机分区：神奇的大规模故障隔离](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) ## 资源 **相关文档：** + [随机分区：神奇的大规模故障隔离](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) + [Amazon Builders' Library：采用随机分区进行工作负载隔离](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/) **相关视频：** + [AWS re:Invent 2018：AWS 如何将故障的影响范围最小化（ARC338）](https://youtu.be/swQbA4zub20) + [随机分片：AWS re:Invent 2019：Amazon Builders’ Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=1373) **相关示例：** + [Well-Architected 实验室：使用随机分区进行故障隔离](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) # REL 11  如何将您的工作负载设计为可承受组件故障的影响？ 在设计具有高可用性和较短平均恢复时间（MTTR）要求的工作负载时必须考虑到弹性。 **Topics** + [ # REL11-BP01 监控工作负载的所有组件以检测故障 ](rel_withstand_component_failures_monitoring_health.md) + [ # REL11-BP02 失效转移到运行状况良好的资源 ](rel_withstand_component_failures_failover2good.md) + [ # REL11-BP03 自动修复所有层 ](rel_withstand_component_failures_auto_healing_system.md) + [ # REL11-BP04 恢复期间依赖于数据面板而不是控制面板 ](rel_withstand_component_failures_avoid_control_plane.md) + [ # REL11-BP05 使用静态稳定性来防止双模态行为 ](rel_withstand_component_failures_static_stability.md) + [ # REL11-BP06 当事件影响可用性时发出通知 ](rel_withstand_component_failures_notifications_sent_system.md) # REL11-BP01 监控工作负载的所有组件以检测故障 持续监控您的工作负载的运行状况，以便您和您的自动化系统立即发现任何性能下降或故障情况。监控基于商业价值的关键性能指标（KPI）。 所有恢复和修复机制必须从快速检测问题的能力入手。首先，应该检测技术故障并加以解决。不过，可用性基于您的工作负载创造商业价值的能力，因此衡量它的关键性能指标（KPI，Key Performance Indicator）需要成为您的检测和补救策略一部分。 **常见反模式：** + 由于未配置警报，因此在发生中断时不会进行通知。 + 虽然存在警报，但只有在达到阈值时才会发出警报，导致没有足够的响应时间。 + 收集指标的频率不够高，无法满足恢复时间目标（RTO）。 + 只有面向客户的工作负载层才会受到主动监控。 + 只收集技术指标，不收集业务功能指标。 + 没有衡量工作负载用户体验的指标。 **建立此最佳实践的好处：** 如果您在所有层面都设置了适当的监控，则可以通过减少检测时间来减少恢复时间。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 根据恢复目标确定您的组件的收集间隔。 + 您的监控间隔取决于您必须实现的恢复速度。您的恢复时间取决于恢复所需的时间，因此您在确定收集频率时，必须考虑此时间和恢复时间目标（RTO）。 + 为组件配置详细监控。 + 确定是否需要为 EC2 实例和 Auto Scaling 配置详细监控。详细监控以 1 分钟为间隔提供指标，默认监控以 5 分钟为间隔提供指标。 + [为您的实例启用或禁用详细监控](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [使用 Amazon CloudWatch 监控自动扩缩组和实例](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + 确定是否需要为 RDS 设置增强监控。增强监控使用 RDS 实例上的代理来获取关于 RDS 实例上不同进程或线程的有用信息。 + [增强监控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + 创建自定义指标来测量业务关键性能指标（KPI，Key Performance Indicator）。工作负载实现关键业务功能。这些功能应用作 KPI 来帮助在发生间接问题时确定这些问题。 + [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 使用用户金丝雀来监控用户的故障体验。可以运行综合事务测试（又称为“金丝雀测试”，但不要和金丝雀部署相混淆）模拟客户的行为，这是最重要的测试流程之一。从不同的远程位置针对您的工作负载端点持续地运行此类测试。 + [Amazon CloudWatch Synthetics 使您能够创建用户金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + 创建跟踪用户体验的自定义指标。如果您可以衡量客户体验，就可以确定发生了客户体验下降。 + [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + 设置告警，以在检测到工作负载未正常运行时发出告警，并指示什么时候对资源进行弹性伸缩。告警可以显示在控制面板上，可通过 Amazon SNS 或电子邮件发送提醒，并使用 Auto Scaling 来纵向扩展或缩减工作负载的资源。 + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + 创建控制面板以可视化形式呈现指标。可以使用控制面板直观地查看趋势、离群值和表示其他潜在问题的指标，或者提供您可能需要进行调查的问题的指示。 + [使用 CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) ## 资源 **相关文档：** + [Amazon CloudWatch Synthetics 使您能够创建用户金丝雀](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [为您的实例启用或禁用详细监控](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) + [增强监控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) + [使用 Amazon CloudWatch 监控自动扩缩组和实例](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) + [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) **相关示例：** + [Well-Architected 实验室：第 300 级：实施运行状况检查和管理依赖项以提高可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP02 失效转移到运行状况良好的资源 确保如果某个资源发生故障，该运行状况良好的资源可以继续为请求提供服务。对于位置故障（如可用区或 AWS 区域），确保您拥有适当的系统以失效转移到未受损位置内运行状况良好的资源。 Elastic Load Balancing 和 AWS Auto Scaling 等 AWS 服务有助于跨资源和可用区分配负载。因此，可以通过将流量转移到运行状况良好的剩余资源，缓解单个资源（例如 EC2 实例）的故障或可用区的损坏。对于多区域工作负载就比较复杂。例如，跨区域只读副本让您可以将数据部署到多个 AWS 区域，但在发生失效转移时，您仍必须提升只读副本至主节点，并将流量指向该节点。Amazon Route 53 和 AWS Global Accelerator 可以帮助跨 AWS 区域路由流量。 如果您的工作负载使用 Amazon S3 或 Amazon DynamoDB 等 AWS 服务，则它们会自动部署到多个可用区。当发生故障时，AWS 控制面板会自动为您将流量路由至运行正常的位置。数据在多个可用区中进行冗余存储，并保持可用。针对 Amazon RDS，您必须选择多可用区作为配置选项，然后在发生故障时，AWS 会自动将流量定向至运行正常的实例。对于 Amazon EC2 实例、Amazon ECS 任务或 Amazon EKS 容器组（pod），您要选择部署到哪些可用区。然后，Elastic Load Balancing 会提供解决方案以检测运行不正常区内的实例，并将流量路由至运行正常的区。Elastic Load Balancing 甚至可以将流量路由至本地数据中心内的组件。 针对多区域方法（也可能包括本地数据中心），Amazon Route 53 会提供定义互联网域并指定路由策略的方式，而此类策略可能包含运行状况检查，以确保流量被路由至运行正常的区域。此外，AWS Global Accelerator 也可以提供静态 IP 地址作为您的应用程序的固定接入点，然后通过 AWS 全球网络而不是互联网路由至您选择的 AWS 区域内的终端节点，以提高性能和可靠性。 AWS 在设计服务时始终会考虑故障恢复功能。我们设计服务时会尽量缩短从故障恢复的时间并降低对数据的影响。我们的服务主要使用的数据存储，只有在数据持久存储在一个区域中的多个副本之后，才会确认请求。这些服务和资源包括 Amazon Aurora、Amazon Relational Database Service (Amazon RDS) 多可用区数据库实例、Amazon S3、Amazon DynamoDB、Amazon Simple Queue Service (Amazon SQS) 和 Amazon Elastic File System (Amazon EFS)。它们被构建为使用基于单元格的隔离，并使用可用区提供的故障隔离功能。我们在自己的运营过程中广泛使用自动化。我们还将替换和重新启动功能优化为可从中断快速恢复。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 失效转移到运行状况良好的资源。确保如果某个资源发生故障，该运行状况良好的资源可以继续为请求提供服务。对于位置故障（如可用区或 AWS 区域），确保您拥有适当的系统以失效转移到未受损位置内运行状况良好的资源。 + 如果您的工作负载使用 Amazon S3 或 Amazon DynamoDB 等 AWS 服务，则它们会自动部署到多个可用区。当发生故障时，AWS 控制面板会自动为您将流量路由至运行正常的位置。 + 针对 Amazon RDS，您必须选择多可用区作为配置选项，然后在发生故障时，AWS 会自动将流量定向至运行正常的实例。 + [Amazon RDS 的高可用性（多可用区）](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + 对于 Amazon EC2 实例或 Amazon ECS 任务，您要选择部署到哪些可用区。然后，Elastic Load Balancing 会提供解决方案以检测运行不正常区内的实例，并将流量路由至运行正常的区。Elastic Load Balancing 甚至可以将流量路由至本地数据中心内的组件。 + 针对多区域方案（也可能包括本地部署数据中心），要确保来自正常运行位置的数据和资源可以继续用于处理请求 + 例如，跨区域只读副本让您可以将数据部署到多个 AWS 区域，但在主要位置发生故障时，您仍必须提升只读副本至主节点，并将流量指向该节点。 + [Amazon RDS 只读副本概述](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + Amazon Route 53 提供定义互联网域并指定路由策略的方式，而此类策略可能包含运行状况检查，以确保流量被路由至运行正常的区域。此外，AWS Global Accelerator 也可以提供静态 IP 地址作为您的应用程序的固定接入点，然后通过 AWS 全球网络而不是互联网路由至您选择的 AWS 区域内的端点，以提高性能和可靠性。 + [Amazon Route 53：选择一个路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [什么是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助您实现容错自动化的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可以支持容错的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks：使用自动修复来更换失败的实例](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon Route 53：选择一个路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [Amazon RDS 的高可用性（多可用区）](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + [Amazon RDS 只读副本概述](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) + [Amazon ECS 任务置放策略](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) + [为多个可用区创建 Kubernetes 自动扩缩组](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) + [什么是 AWS Global Accelerator？](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) **相关示例：** + [Well-Architected 实验室：第 300 级：实施运行状况检查和管理依赖项以提高可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP03 自动修复所有层 在检测到故障时，使用自动化功能执行修复操作。 *重启功能* 是用于修复故障的重要工具。正如我们之前在分布式系统部分讨论过那样，最佳实践是尽可能使服务为无状态。它可以防止重启时数据丢失或可用性受损。您可以（而且在一般情况下也应该）在云中替换完整的资源（如 EC2 实例或 Lambda 函数），并将其作为重启的一部分。重启本身是从故障恢复的简单而可靠的方法。工作负载中会发生很多不同类型的故障。故障可能发生在硬件、软件、通信和操作上。将众多不同类别的故障映射到相同的恢复策略上，而不是构建新颖的机制来捕获、确定和纠正各个不同类型的故障。实例可能会因为硬件故障、操作系统错误、内存泄漏或其他原因而出现故障。系统不会针对每种情况构建自定义修复，而是会将它们全部视为实例故障。终止实例，并且允许使用 AWS Auto Scaling 进行取代。然后，在带外对故障资源进行分析。 另一个例子是重启网络请求功能。向网络超时以及依赖项返回错误的依赖性故障应用相同的恢复方法。这两个事件对系统具有类似的影响，应用类似的采用指数回退和抖动的有限重试策略，而不是尝试将各个事件当作特例进行处理。 *重启功能* 是面向恢复的计算和高可用性集群架构的特色恢复机制。 Amazon EventBridge 可用于监控和筛选事件，例如 CloudWatch 警报或其他 AWS 服务中的状态更改。根据事件信息，它可以触发 AWS Lambda、AWS Systems Manager Automation（或其他目标）在您的工作负载上执行自定义修复逻辑。 Amazon EC2 Auto Scaling 可以配置为对 EC2 实例的运行状况进行检查。若实例处于正在运行以外的任何状态，或系统状态受损，Amazon EC2 Auto Scaling 会认为实例的运行不正常，并且启动替换实例。如果使用 AWS OpsWorks，您可以在 OpsWorks 层级别配置 EC2 实例的自动修复。 针对大规模替换（如整个可用区受损），静态稳定性更适合高可用性，而不是立即尝试获取多个新的资源。 **常见反模式：** + 在实例或容器中单独部署应用程序。 + 在不使用自动恢复的情况下，部署无法部署到多个位置的应用程序。 + 手动修复自动扩展和自动恢复无法修复的应用程序。 **建立此最佳实践的好处：** 自动修复，即使工作负载一次只能部署到一个位置也能减少平均恢复时间，并确保工作负载的可用性。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 使用自动扩缩组在工作负载中部署多个层。Auto Scaling 可以对无状态应用程序执行自我修复，以及添加和移除容量。 + [AWS Auto Scaling 的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + 在部署了无法部署到多个位置，但在故障后允许重新启动的应用程序的 EC2 实例上，实施自动恢复。当无法将应用程序部署到多个位置时，可以使用自动恢复来替换发生故障的硬件并重新启动实例。实例元数据和关联的 IP 地址将被保留，Amazon EBS 卷以及 Elastic File System 或 File Systems for Lustre 和 File Systems for Windows 的挂载点也是如此。 + [Amazon EC2 Automatic Recovery](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store（Amazon EBS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System（Amazon EFS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [什么是 Amazon FSx for Lustre？](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [什么是 Amazon FSx for Windows File Server？](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) + 使用 AWS OpsWorks 时，您可以在层级别配置 EC2 实例的自动修复。 + [AWS OpsWorks：使用自动修复来更换失败的实例](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + 当您无法使用自动扩展或自动恢复时，或者自动恢复出故障时，使用 AWS Step Functions 和 AWS Lambda 实施自动恢复。当您无法使用自动扩展，并且无法使用自动恢复或自动恢复失败时，您可以使用 AWS Step Functions 和 AWS Lambda 进行自动修复。 + [什么是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [什么是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + Amazon EventBridge 可用于监控和筛选事件，例如 CloudWatch 警报或其他 AWS 服务中的状态更改。根据事件信息，它可以触发 AWS Lambda（或其他目标）在您的工作负载上运行自定义修复逻辑。 + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助您实现容错自动化的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可以支持容错的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [AWS OpsWorks：使用自动修复来更换失败的实例](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) + [Amazon EC2 Automatic Recovery](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) + [Amazon Elastic Block Store（Amazon EBS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) + [Amazon Elastic File System（Amazon EFS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) + [AWS Auto Scaling 的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [什么是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) + [什么是 Amazon FSx for Lustre？](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) + [什么是 Amazon FSx for Windows File Server？](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) **相关视频：** + [AWS 中的静态稳定性：AWS re:Invent 2019：Amazon Builders’ Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=704) **相关示例：** + [Well-Architected 实验室：第 300 级：实施运行状况检查和管理依赖项以提高可靠性](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) # REL11-BP04 恢复期间依赖于数据面板而不是控制面板 控制面板用于配置资源，数据面板可提供服务。数据面板通常比控制面板具有更高的可用性设计目标，并且通常不太复杂。在对可能影响弹性的事件实施恢复或缓解响应时，使用控制面板操作会降低架构的整体弹性。例如，您可以依靠 Amazon Route 53 数据面板，根据运行状况检查可靠地路由 DNS 查询，但更新 Route 53 路由策略时使用控制面板，因此不要依赖它进行恢复。 Route 53 数据面板回复 DNS 查询，并执行和评估运行状况检查。它们分布在全球各地，专为 [100% 可用性的服务等级协议（SLA，Service Level Agreement）而设计。](https://aws.amazon.com/route53/sla/) 您用于创建、更新和删除 Route 53 资源的 Route 53 管理 API 和控制台是在控制面板上运行的，而这些控制面板设计用于优先考虑您在管理 DNS 时所需的强一致性和持久性。为了实现这一点，控制面板位于单个区域 US East (N. Virginia) 中。虽然这两个系统都非常可靠，但控制面板不包含在 SLA 中。在极少数情况下，数据面板的弹性设计允许它保持可用性，而控制面板做不到。对于灾难恢复和失效转移机制，使用数据面板功能可提供尽可能好的可靠性。 有关数据面板、控制面板以及 AWS 如何构建服务以满足高可用性目标的更多信息，请参阅 [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 文章以及 [Amazon Builders’ Library。](https://aws.amazon.com/builders-library/) **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 使用 Amazon Route 53 进行灾难恢复时依赖数据面板而不是控制面板。Route 53 Application Recovery Controller 使用就绪性检查和路由控制来帮助您管理和协调失效转移。这些功能持续监控您的应用程序从故障中恢复的能力，并使您能够跨多个 AWS 区域、可用区和本地部署控制您的应用程序恢复。 + [什么是 Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [使用 Amazon Route 53 创建灾难恢复机制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 1 部分：单区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 2 部分：多区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + 了解哪些操作位于数据面板以及哪些位于控制面板。 + [Amazon Builders' Library：通过控制较小的服务来避免分布式系统中出现过载](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API（控制面板和数据面板）](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 执行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) （拆分为控制面板和数据面板） + [AWS Lambda 执行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) （拆分为控制面板和数据面板） ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助您实现容错自动化的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace：可以支持容错的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [Amazon Builders' Library：通过控制较小的服务来避免分布式系统中出现过载](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [Amazon DynamoDB API（控制面板和数据面板）](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [AWS Lambda 执行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) （拆分为控制面板和数据面板） + [AWS Elemental MediaStore 数据面板](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) + [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 1 部分：单区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 2 部分：多区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [使用 Amazon Route 53 创建灾难恢复机制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [什么是 Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) **相关示例：** + [Amazon Route 53 Application Recovery Controller 简介](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) # REL11-BP05 使用静态稳定性来防止双模态行为 双模态行为是指您的工作负载在正常和故障模式下展现出不同的行为，例如，可用区发生故障时依赖于启动新的实例。您应该构建静态稳定的工作负载，并且仅在一个模式下运行。在这种情况下，如果删除了一个可用区，要在每个可用区内预置足够的实例来处理工作负载，然后再使用 Elastic Load Balancing 或 Amazon Route 53 运行状况检查将负载从受损实例中转出。 适用于计算部署（如 EC2 实例或容器）的静态稳定性将提供最高水平的可靠性。您必须在稳定性水平和成本之间认真权衡。预置较小的计算容量，并在发生故障时依赖启动新实例，其成本较低。但对于大规模故障（如可用区故障）来说，此方法的效果较差，因为它依赖于对发生的损坏做出反应，而不会在损坏发生前做好准备。您选择的解决方案应在工作负载的可用性和成本需求之间做出取舍。若使用更多可用区，静态稳定性所需的额外计算量就会减少。 ![\[显示跨可用区的 EC2 实例的静态稳定性的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/static-stability.png) 在流量转移以后，使用 AWS Auto Scaling 异步替换故障区的实例，并且在运行正常的区内启动。 双模态行为的另一个例子是，网络超时可能会导致系统尝试刷新整个系统的配置状态。这会向另一个组件添加意外负载，进而可能导致该组件出现故障，触发其他意外后果。此负面的反馈环路会影响您的工作负载的可用性。您应该构建静态稳定的系统，并且仅在一个模式下运行。静态稳定的设计会持续工作，并且始终定期刷新配置状态。当调用失败时，工作负载会使用之前的缓存值，并触发警报。 双模态行为的另一个示例是允许客户端在故障发生时绕过您的工作负载缓存。这看起来似乎是可以满足客户端需求的解决方案但却不应该被允许，因为它会明显改变您的工作负载的需求，而且很有可能导致故障。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 使用静态稳定性来防止双模态行为。双模态行为是指您的工作负载在正常和故障模式下展现出不同的行为，例如，可用区发生故障时依赖于启动新的实例。 + [尽可能减小灾难恢复计划中的依赖关系](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library：使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) + [AWS 中的静态稳定性：AWS re:Invent 2019：Amazon Builders’ Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=704) + 您应该构建静态稳定的系统，并且仅在一个模式下运行。在这种情况下，在每个区内预置足够的实例来处理删除了一个工作区时的工作负载，然后再使用 Elastic Load Balancing 或 Amazon Route 53 运行状况检查将负载从受损实例中转出。 + 双模态行为的另一个示例是允许客户端在故障发生时绕过您的工作负载缓存。这看起来似乎是可以满足客户端需求的解决方案，但却不应该被允许，因为它会明显改变您的工作负载的需求，而且很有可能导致故障。 ## 资源 **相关文档：** + [尽可能减小灾难恢复计划中的依赖关系](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) + [Amazon Builders' Library：使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) **相关视频：** + [AWS 中的静态稳定性：AWS re:Invent 2019：Amazon Builders’ Library 简介（DOP328）](https://youtu.be/sKRdemSirDM?t=704) # REL11-BP06 当事件影响可用性时发出通知 在检测到重大事件时发送通知，即使由事件引发的问题已经自动解决。 自动修复使您的工作负载变得可靠。不过，它也可能会掩盖需要处理的潜在问题。实施适当的监控和措施，以便检测问题的模式，包括那些被自动修复的问题，从而从根本上解决问题。Amazon CloudWatch 警报会基于发生的故障触发。它们还可能由于执行自动修复操作而被触发。CloudWatch 警报可被配置为发送电子邮件，或使用 Amazon SNS 集成将事件记录到第三方事件跟踪系统。 **常见反模式：** + 发出不需要有人采取措施的告警。 + 执行自动修复，但不通知需要进行该修复。 **建立此最佳实践的好处：** 恢复事件通知将确保您不会忽略不经常发生的问题。 **未建立此最佳实践暴露的风险等级：** 中 ## 实施指导 + 在业务关键性能指标超出低阈值时发出警报：收到关于您的业务 KPI 的低阈值告警，可帮助您及时了解工作负载不可用或未正常工作的情况。 + [基于静态阈值创建 CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + 针对调用自动修复的事件发出告警：您可以使用任何已创建的自动化功能直接调用 SNS API 来发送通知。 + [什么是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) ## 资源 **相关文档：** + [基于静态阈值创建 CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 Amazon Simple Notification Service？](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) # REL 12  如何测试可靠性？ 在为您的工作负载采用弹性设计以应对生产压力以后，测试是确保其按设计预期运行，并且提供您所预期弹性的唯一方式。 **Topics** + [ # REL12-BP01 使用行动手册调查故障 ](rel_testing_resiliency_playbook_resiliency.md) + [ # REL12-BP02 在意外事件发生后执行分析 ](rel_testing_resiliency_rca_resiliency.md) + [ # REL12-BP03 测试功能要求 ](rel_testing_resiliency_test_functional.md) + [ # REL12-BP04 测试扩展和性能要求 ](rel_testing_resiliency_test_non_functional.md) + [ # REL12-BP05 使用混沌工程测试弹性 ](rel_testing_resiliency_failure_injection_resiliency.md) + [ # REL12-BP06 定期进行实际试用 ](rel_testing_resiliency_game_days_resiliency.md) # REL12-BP01 使用行动手册调查故障 通过在行动手册中记录调查流程，实现对并不十分了解的故障场景做出一致且及时的响应。行动手册是在确定哪些因素导致故障场景时要执行的预定义步骤。所有流程步骤的结果都将用于确定要采取的后续步骤，直到问题得到确定或上报。 行动手册是您必须要执行的主动计划，以便有效采取响应措施。当在生产中遇到行动手册未涉及的故障场景时，首先要解决问题（灭火）。然后回过头来思考您在解决问题时采取的措施，并将这些措施作为新条目添加到行动手册中。 请注意，行动手册可用于对特定事件做出响应，运行手册则用来达成特定的结果。通常，运行手册适用于例行活动，而行动手册则被用于对非例行事件做出响应。 **常见反模式：** + 计划在以下情况下部署工作负载：不清楚诊断问题或响应意外事件的流程。 + 关于在对事件进行调查时从哪些系统收集日志和指标的计划外的决定。 + 指标和事件保留的时间不够长，无法检索到数据。 **建立此最佳实践的好处：** 使用行动手册可确保始终如一地遵循程序。编写行动手册可以减少手动操作导致的错误。通过实现行动手册自动化，可以消除团队成员干预的需要，或者在他们开始干预时便向他们提供更多信息，从而缩短事件响应时间。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 使用行动手册来发现问题。管理手册是用于调查问题的书面程序。在行动手册中记录流程，实现对故障场景的一致而及时的响应。行动手册必须包含所需的信息和指导，让足够熟练的员工能够收集适用信息、确定故障的潜在来源、隔离故障，并确定成因（在意外事件发生后执行分析）。 + 以代码形式实施行动手册。为行动手册编写脚本，以代码形式执行运营，以确保一致性并减少由手动流程引起的错误。行动手册可以由代表不同步骤的多个脚本组成，这些步骤可能是确定问题成因所必需的。系统可能会在运行手册活动过程中触发或执行行动手册活动，也可能针对响应发现的事件而提示执行行动手册活动。 + [使用 AWS Systems Manager 自动执行您的运营手册](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) + [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [什么是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## 资源 **相关文档：** + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) + [使用 AWS Systems Manager 自动执行您的运营手册](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) + [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [什么是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) **相关示例：** + [使用行动手册和运行手册自动完成操作](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) # REL12-BP02 在意外事件发生后执行分析 审核影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，以限制或防止再次发生同类事件。制定程序以迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。如果需要，可将这些原因告知他人。 评估为什么现有测试找不到问题。如果还没有，增设测试。 **常见反模式：** + 查找事件成因，但不继续深入探究其他潜在问题和缓解问题的方法。 + 只找出人为错误原因，但不提供任何培训或可防止人为错误的自动化功能。 **建立此最佳实践的好处：** 如果其他工作负载实施了相同的故障因素，那么在意外事件发生后执行分析并共享分析结果可帮助缓解这些工作负载的故障风险，并使它们能够在意外事件发生之前实施缓解或自动恢复措施。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 制定事后分析标准。有效的事后分析让您有机会针对系统中其他地方使用的架构模式存在的问题提出常见的解决方案。 + 确保在提出事件成因时秉承诚实原则并且不苛责。 + 如果您不记录问题，就无法予以纠正。 + 确保事后分析不带苛责，这样您便可以冷静地看待建议的纠正措施，并在您的应用程序团队中促进诚实的自我评估和协作。 + 通过流程来确定事件成因。设置流程来确定和记录事件成因，以便制定缓解措施来限制或阻止事件再次发生，并且您还可以据此制定及时有效的应对措施。根据目标受众，适当传达成因。 + [什么是日志分析？](https://aws.amazon.com/log-analytics/) ## 资源 **相关文档：** + [什么是日志分析？](https://aws.amazon.com/log-analytics/) + [为什么您应该制定更正错误（COE，Correction of Error）措施](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) # REL12-BP03 测试功能要求 使用的技术包括用于验证所需功能的单元测试和集成测试。 如果这些测试作为构建和部署措施的一部分自动运行，则您可以获得最佳的结果。例如，使用 AWS CodePipeline，开发人员会在 CodePipeline 自动检测到变更时提交对源存储库的更改。执行更改，然后加以测试。在测试完成以后，构建的代码会被部署到用于测试的暂存服务器。CodePipeline 会从暂存服务器运行更多测试，如集成或负载测试等。在成功完成此类测试以后，CodePipeline 会将经过测试并获得批准的代码部署到生产实例。 此外，过去的经验告诉我们，可运行合成事务测试（又被称作 *金丝雀测试*，但不要和金丝雀部署相混淆）模拟用户行为，这是最重要的测试流程之一。从不同的远程位置针对您的工作负载端点持续地运行此类测试。Amazon CloudWatch Synthetics 使您能够 [创建 Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 以便监控您的终端节点和 API。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 测试功能要求。这包括用于验证所需功能的单元测试和集成测试。 + [将 CodePipeline 与 AWS CodeBuild 结合使用以测试代码和运行构建](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) + [AWS CodePipeline 增加了对通过 AWS CodeBuild 进行单位和自定义集成测试的支持](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) + [持续交付和持续集成](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) + [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [软件测试自动化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) ## 资源 **相关文档：** + [AWS 合作伙伴：可帮助实施持续集成管道的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration) + [AWS CodePipeline 增加了对通过 AWS CodeBuild 进行单位和自定义集成测试的支持](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) + [AWS Marketplace：可用于实现持续集成的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration) + [持续交付和持续集成](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) + [软件测试自动化](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) + [将 CodePipeline 与 AWS CodeBuild 结合使用以测试代码和运行构建](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) + [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) # REL12-BP04 测试扩展和性能要求 使用的技术包括负载测试以验证工作负载是否满足扩展和性能要求。 在云中，您可以按需为您的工作负载创建生产规模环境。如果在缩减的基础设施上运行这些测试，您必须根据您认为在生产中将会发生的情况扩展您观察到的结果。如果不想影响实际用户，您可以在生产中开展负载和性能测试，并且对您的测试数据进行标记，以避免它与真实的用户数据、损坏的使用情况统计或生产报告混在一起。 通过测试确保您的基础资源、扩展设置、服务限额和弹性设计能够在负载之下如预期运行。 **未建立这种最佳实践的情况下暴露的风险等级：** 高 ## 实施指导 + 测试扩展和性能要求。执行负载测试以验证工作负载是否满足扩展和性能要求。 + [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) + 将您的应用程序部署在与生产环境相同的环境中，然后执行负载测试。 + 使用基础设施即代码概念，以创建尽可能类似于生产环境的环境。 ## 资源 **相关文档：** + [AWS 上的分布式负载测试：模拟数千个连接的用户](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) # REL12-BP05 使用混沌工程测试弹性 在处于或尽可能接近生产的环境中定期运行混沌试验，以了解系统如何应对不利条件。 ** 期望结果： ** 除了在事件期间验证已知预期工作负载行为的弹性测试之外，还可以通过以故障注入实验或注入意外负载的形式应用混沌工程，定期验证工作负载的弹性。将混沌工程和弹性测试结合起来，您可以提升信心，相信工作负载能够经受组件故障，并可从意外中断中恢复，而影响极小甚至没有影响。 ** 常见反模式： ** + 进行弹性设计，但不验证故障发生时工作负载如何作为一个整体运行。 + 从不在真实环境和预期负载下进行试验。 + 不将实验视为代码，也不在整个开发周期中维护它们。 + 不将混沌实验作为 CI/CD 管道的一部分，也不在部署之外运行。 + 在确定要对哪些故障进行试验时，没有想到使用过去的意外事件后分析。 ** 建立此最佳实践的好处：** 注入故障来验证工作负载的弹性，这可以让您提升信心，相信您的弹性设计的恢复程序将在真正发生故障的情况下能够发挥作用。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 利用混沌工程，您的团队能够在服务提供商、基础设施、工作负载和组件级别，以可控的方式不断注入真实世界的干扰（模拟），而对客户的影响极小甚至没有影响。它使您的团队能够从故障中学习，观察、测量和提高工作负载的弹性，并验证在发生事件时，系统会发出警报并通知团队。 当持续执行时，混沌工程会突出工作负载中的缺陷，这些缺陷若不加以解决，可能会对可用性和运营产生负面影响。 **注意** 混沌工程是对系统进行试验以让人们确信系统能够在生产中经受住混乱情形的规范。– [混沌工程的原则](https://principlesofchaos.org/) 如果系统能够经受住这些干扰，那么应将混沌实验作为自动回归测试来加以维护。这样一来，应将混沌实验作为系统开发生命周期（SDLC）的一部分，以及作为 CI/CD 管道的一部分来执行。 为了确保您的工作负载能够承受组件故障，请在实验中注入实际事件。例如，对 Amazon EC2 实例的丢失或主 Amazon RDS 数据库实例的失效转移进行试验，并验证您的工作负载没有受到影响（或影响极小）。使用组件故障的组合来模拟可能因可用区中断而引起的事件。 对于应用程序级故障（如崩溃），您可以从内存和 CPU 耗尽等压力源开始。 为了验证因间歇性网络中断而引发的外部依赖项的 [回退或失效转移机制](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) ，您的组件应通过在指定时间段（从几秒到几小时不等）内阻止对第三方提供商的访问来模拟此类事件。 其他降级模式可能会影响功能的使用并降低响应速度，这通常会导致服务中断。性能下降的常见原因是，关键服务的延迟增加以及网络通信不可靠（丢包）。对于这些故障（包括延迟、丢弃的消息和 DNS 故障等网络效应）的实验可能包括无法解析名称、无法访问 DNS 服务或无法建立与依赖服务的连接。 **混沌工程工具：** AWS Fault Injection Service（AWS FIS）是一项完全托管式服务，用于运行故障注入实验，而这些实验可用作 CD 管道的一部分，或在管道之外使用。AWS FIS 是在混沌工程实际试用期间使用的一个不错选择。它支持在不同类型的资源中同时引入故障，包括 Amazon EC2、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service（Amazon EKS）和 Amazon RDS 等资源。这些故障包括终止资源、强制失效转移、对 CPU 或内存施加压力、节流、延迟和数据包丢失。由于它与 Amazon CloudWatch 警报集成，因此您可以设置停止条件作为防护机制，以在实验导致意外影响时回滚。 ![\[该图表显示 AWS Fault Injection Service 与 AWS 资源集成，使您能够为您的工作负载运行故障注入实验。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png) 故障注入实验也有多种第三方选项。其中包括开源工具，例如 [Chaos ToolKit](https://chaostoolkit.org/)、[Chaos Mesh](https://chaos-mesh.org/)和 [Litmus Chaos](https://litmuschaos.io/)以及商业选项，如 Gremlin。为了扩大可在 AWS 上注入的故障范围，AWS FIS [与 Chaos Mesh 和 Litmus Chaos 集成](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)，使您能够在多个工具之间协调故障注入工作流。例如，您可以使用 Chaos Mesh 或 Litmus 故障对容器组（pod）的 CPU 运行压力测试，同时使用 AWS FIS 故障操作终止随机选择的集群节点百分比。 ## 实施步骤 + 确定哪些故障要用于实验。 评估工作负载的设计是否具有弹性。这种设计（使用 [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)的最佳实践创建）考虑到了基于关键依赖关系、过去的事件、已知问题和合规性要求的风险。列出每个旨在保持弹性的设计元素及其旨在缓解的故障。有关创建此类列表的更多信息，请参阅 [《运营准备就绪情况审核》白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) ，该白皮书指导您如何创建流程来防止以前的事件再次发生。故障模式与影响分析（FMEA）流程为您提供了一个框架，用于对故障及其对工作负载的影响执行组件级分析。Adrian Cockcroft 在 [《Failure Modes and Continuous Resilience》](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5)中更详细地概述了 FMEA。 + 为每个故障指定一个优先级。 先进行粗略的分类，如高、中或低。要评估优先级，请考虑故障的频率和故障对整体工作负载的影响。 考虑给定故障的频率时，请分析此工作负载的以往数据（如有）。如果没有以往数据，则使用在类似环境中运行的其他工作负载的数据。 考虑给定故障的影响时，故障的范围越大，一般来说影响也越大。还要考虑工作负载设计和目的。例如，访问源数据存储的能力对于进行数据转换和分析的工作负载至关重要。在这种情况下，您将确定关于访问故障以及节流访问和延迟插入的实验的优先级。 意外事件后分析是了解故障模式的频率和影响的良好数据来源。 使用指定的优先级来确定首先用哪些故障进行实验，以及开发新的故障注入实验的顺序。 + 对于您执行的每项实验，请遵循混沌工程和连续弹性飞轮。 ![\[混沌工程和连续弹性飞轮图，显示了“改进”、“稳态”、“假设”、“进行实验”和“验证”阶段。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png) + 将稳态定义为指示正常行为的工作负载的一些可测量输出。 如果工作负载运行可靠且符合预期，则显示为稳态。因此，定义稳态之前，请验证您的工作负载正常运行。稳态并不一定意味着故障发生时对工作负载没有影响，因为一定百分比的故障可能在可接受的范围内。稳态是您在实验期间将观察到的基线，如果您在下一步中定义的假设结果不符合预期，它将突出显示异常。 例如，可以将某个支付系统的稳态定义为处理 300TPS，成功率为 99%，且往返时间为 500ms。 + 形成一个关于工作负载如何应对故障的假设。 一个好的假设是基于工作负载预计如何缓解故障以保持稳态。该假设指出，如果发生特定类型的故障，系统或工作负载将继续保持稳态，因为该工作负载在设计时就有特定的缓解措施。应在假设中具体说明特定的故障类型和缓解措施。 假设可以使用以下模板（但其他措辞也可以接受）： **注意** 如果发生 *特定故障* ，则 *工作负载名称* 工作负载将 *描述缓解控制措施* 维持 *业务或技术指标影响*。 例如： + 如果 Amazon EKS 节点组中 20% 的节点出现故障，则 Transaction Create API 将在不到 100ms 的时间内继续处理 99% 的请求（稳态）。Amazon EKS 节点将在五分钟内恢复，容器组（pod）将在实验开始后八分钟内得到调度并处理流量。警报将在三分钟内将发出。 + 如果发生单个 Amazon EC2 实例故障，订单系统的 Elastic Load Balancing 运行状况检查将导致 Elastic Load Balancing 仅向剩余的运行状况良好的实例发送请求，而 Amazon EC2 Auto Scaling 将替换故障实例，从而保持服务器端（5xx）错误增长率低于 0.01%（稳态）。 + 如果主 Amazon RDS 数据库实例发生故障，则供应链数据收集工作负载将失效转移并连接到备用 Amazon RDS 数据库实例，以保持不到 1 分钟的数据库读写错误（稳态）。 + 通过注入故障来进行实验。 默认情况下，实验应具有故障保护机制，可承受工作负载。如果您知道工作负载将发生故障，则不要进行实验。混沌工程应该用于寻找已知的不确定因素或未知的不确定因素。*已知的不确定因素* 是您知道但不完全理解的东西，而 *未知的不确定因素* 是您既不知道也不完全理解的东西。对您知道已经发生故障的工作负载进行试验不会为您提供新的见解。您应该对实验仔细规划，明确一个影响范围，并提供一种可在出现意外动荡时应用的回滚机制。如果尽职调查表明您的工作负载应该能经受住实验，那就继续这项实验。有几种注入故障的选项。对于 AWS 上的工作负载，[AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 提供了许多称为 [操作](https://docs.aws.amazon.com/fis/latest/userguide/actions.html)的预定义故障模拟。您还可以定义在 AWS FIS 中运行的自定义操作（使用 [AWS Systems Manager 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)）。 我们不鼓励使用自定义脚本进行混沌实验，除非这些脚本能够了解工作负载的当前状态，能够发出日志，并在可能的情况下提供回滚和停止条件的机制。 支持混沌工程的有效框架或工具集应跟踪实验的当前状态，发出日志，并提供回滚机制以支持实验的受控执行。从 AWS FIS 这样的成熟服务开始，该服务支持您在明确定义的范围内和安全机制下进行实验，如果实验引入了意外的动荡，则可以回滚实验。要了解更多使用 AWS FIS 的实验，另请参阅 [“通过混沌工程构建弹性且架构完善的应用程序”实验室](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)。此外， [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 将分析您的工作负载，并创建您可以选择在 AWS FIS 中实施和运行的实验。 **注意** 对于每项实验，要清楚地了解其范围及影响。我们建议首先在非生产环境中模拟故障，然后再在生产环境中运行。 应使用实际负载，通过 [金丝雀部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 在生产环境中进行实验，尽可能同时启动控制和实验系统部署。在非高峰时间进行实验是一种很好的做法，可以减小首次在生产环境中试验时的潜在影响。此外，如果使用实际的客户流量会带来太大的风险，您可以在生产基础设施上针对控制和实验部署使用合成流量进行实验。当不能使用生产环境时，在尽可能接近生产环境的预生产环境中进行实验。 您必须建立和监控防护机制，确保实验对生产流量或其他系统的影响不会超过可接受的限度。建立停止条件，以便在实验达到您定义的防护机制指标的阈值时停止实验。这应该包括工作负载的稳态指标，以及针对您要注入故障的组件的指标。A [合成监控器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) （也称为用户金丝雀）是一个通常应作为用户代理包含的指标。[AWS FIS 的停止条件](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) 应纳入实验模板中，每个模板最多可以有五个停止条件。 混沌的原则之一是尽量缩小实验范围并减小其影响： 虽然必须考虑到一些短期负面影响，但混沌工程师有责任和义务确保实验产生的影响极小且可控。 验证范围和潜在影响的一种方法是首先在非生产环境中进行实验（验证停止条件的阈值在实验期间按预期激活，并且可观测性到位以捕获异常），而不是直接在生产环境中进行实验。 运行故障注入实验时，确保所有责任方均知情。与适当的团队（如运营团队、服务可靠性团队和客户支持团队）沟通，让他们知道实验将在何时运行以及预期会发生什么。为这些团队提供沟通工具，以便在他们看到任何不利影响时通知进行实验的人员。 必须将工作负载及其底层系统恢复到最初的已知良好状态。通常，工作负载的弹性设计会自我修复。但一些故障设计或失败的实验可能会使您的工作负载处于意外的失败状态。在实验结束时，您必须意识到这一点，并恢复工作负载和系统。使用 AWS FIS，您可以在操作参数中设置回滚配置（也称为后期操作）。后期操作将目标返回到运行该操作之前的状态。无论是自动执行（如使用 AWS FIS）还是手动执行，这些后期操作都应包含在描述如何检测和处理故障的行动手册中。 + 验证假设。 [混沌工程的原则](https://principlesofchaos.org/) 为如何验证工作负载的稳态提供了以下指导： 关注系统的可测量输出，而不是系统的内部属性。短时间内对该输出的测量构成了系统稳态的代理。整个系统的吞吐量、错误率和延迟百分比都可以是代表稳态行为的相关指标。通过关注实验过程中的系统行为模式，混沌工程验证系统确实在工作，而不是试图验证它如何工作。 在之前的两个示例中，我们包括了服务器端（5xx）错误增长率低于 0.01% 和数据库读写错误持续时间不到 1 分钟的稳态指标。 5xx 错误是一个很好的指标，因为它们是工作负载客户端将直接经历的故障模式的结果。数据库错误测量适合作为故障的直接结果，但是还应补充一个客户端影响测量，例如失败的客户请求或向客户端显示的错误。此外，在工作负载客户端直接访问的任何 API 或 URI 上包括一个合成监控器（也称为用户金丝雀）。 + 改进工作负载设计，以提高弹性。 如果未保持稳态，则调查如何改进工作负载设计以缓解故障，应用 [AWS Well-Architected 可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)的最佳实践。可以在 [AWS Builder’s Library](https://aws.amazon.com/builders-library/)中找到其他指导和资源，其中包含有关如何 [改进运行状况检查](https://aws.amazon.com/builders-library/implementing-health-checks/) 或 [在应用程序代码中结合采用重试与回退](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)的文章，等等。 实施这些更改后，再次进行实验（如混沌工程飞轮中的虚线所示），以确定其有效性。如果验证步骤表明假设成立，那么工作负载将处于稳态，循环将继续。 + 定期进行实验。 混沌实验是一个循环，作为混沌工程的一部分，应定期进行实验。在工作负载满足实验的假设后，实验应实现自动化，作为 CI/CD 管道的回归部分持续运行。要了解如何做到这一点，请参阅关于 [如何使用 AWS CodePipeline 进行 AWS FIS 实验](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)的博客。这个关于反复 [在 CI/CD 管道中进行 AWS FIS 实验](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) 的实验室使您能够动手实践。 故障注入实验也是实际试用的一部分（请参阅 [REL12-BP06 定期进行实际试用](rel_testing_resiliency_game_days_resiliency.md)）。实际试用会模拟故障或事件，以便验证系统、流程和团队的响应。其目的是实际执行团队在发生意外事件时会执行的操作。 + 捕获和存储实验结果。 必须捕获并持久保存故障注入实验的结果。包括所有必要的数据（如时间、工作负载和条件），以便以后能够分析实验结果和趋势。结果示例可能包括控制面板的屏幕截图、从指标数据库进行的 CSV 转储，或实验中事件和观察结果的手写记录。[使用 AWS FIS 进行实验记录](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) 可作为这种数据捕获的一部分。 ## 资源 **相关最佳实践：** + [REL08-BP03 将弹性测试作为部署的一部分进行集成](rel_tracking_change_management_resiliency_testing.md) + [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md) **相关文档：** + [什么是 AWS Fault Injection Service？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) + [什么是 AWS Resilience Hub？](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) + [混沌工程的原则](https://principlesofchaos.org/) + [混沌工程：规划您的首次实验](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) + [弹性工程：学会接受故障](https://queue.acm.org/detail.cfm?id=2371297) + [混沌工程案例](https://github.com/ldomb/ChaosEngineeringPublicStories) + [避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) + [用于混沌实验的金丝雀部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) **相关视频：** + [AWS re:Invent 2020：使用混沌工程测试弹性（ARC316）](https://www.youtube.com/watch?v=OlobVYPkxgg) + [AWS re:Invent 2019：通过混沌工程提高弹性（DOP309-R1）](https://youtu.be/ztiPjey2rfY) + [AWS re:Invent 2019：在无服务器世界中执行混沌工程（CMY301）](https://www.youtube.com/watch?v=vbyjpMeYitA) **相关示例：** + [Well-Architected 实验室：第 300 级：测试 Amazon EC2、Amazon RDS 和 Amazon S3 的弹性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) + [“混沌工程在 AWS 上的应用”实验室](https://chaos-engineering.workshop.aws/en/) + [“通过混沌工程构建弹性且架构完善的应用程序”实验室](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US) + [“无服务器混沌”实验室](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless) + [“使用 AWS Resilience Hub 测量和提高应用程序弹性”实验室](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab) ** 相关工具： ** + [AWS Fault Injection Service](https://aws.amazon.com/fis/) + AWS Marketplace： [Gremlin 混沌工程平台](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) + [Chaos ToolKit](https://chaostoolkit.org/) + [Chaos Mesh](https://chaos-mesh.org/) + [Litmus](https://litmuschaos.io/) # REL12-BP06 定期进行实际试用 利用实际试用活动，在尽可能接近生产环境的环境中（包括在生产环境中），与将参与实际故障情景的人员一起为应对事件和故障而练习如何使用您的程序。实际试用会强制执行相关措施，以确保生产事件不会影响用户。 实际试用会模拟故障或事件，以便测试系统、流程和团队的响应。其目的是实际执行团队在发生意外事件时会执行的操作。这将帮助您了解可以从哪些方面作出改进，并有助于培养组织处理各种事件的经验。这些操作应该定期进行，让团队建立起关于响应方式的 *肌肉记忆* 。 在非生产环境中对您的弹性设计进行测试以后，可通过 Game Day 确保生产中的一切按照计划运行。Game Day，尤其如果是首次开展，是所有人员都应该参加的活动，工程师和运营团队都会得到关于开展时间以及活动内容的信息。运行手册准备就绪。以规定的方式在生产系统中执行模拟事件（包括可能出现的故障事件），并评估影响。如果所有系统如设计运行，检测和自我修复不会产生或只会产生非常轻微的影响。但如果观察到负面影响，测试将会回滚，并且（使用运行手册）修复问题，在必要时手动修复。由于实际试用经常在生产中进行，所以应采取全部预防措施，以确保不会对客户造成可用性影响。 **常见反模式：** + 记录您的程序，但不要执行。 + 不要让业务决策者参与测试练习。 **建立此最佳实践的好处：** 定期执行实际试用可确保在发生实际事件时，所有员工都遵守策略和程序，并且能够验证这些策略和程序是否合适。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 安排实际试用，以定期运用运行手册和行动手册。生产事件中涉及的所有人员均需参与实际试用：业务负责人、开发人员、运营人员和事件响应团队。 + 运行负载或性能测试，然后运行故障注入。 + 寻找运行手册中的异常，并利用这些异常机会练习使用行动手册。 + 如果您违反运行手册，请完善运行手册或纠正相应行为。如果练习使用行动手册，请确定应使用的运行手册，或者创建一个新运行手册。 ## 资源 **相关文档：** + [什么是 AWS 实际试用？](https://aws.amazon.com/gameday/) **相关视频：** + [AWS re:Invent 2019：通过混沌工程提高弹性（DOP309-R1）](https://youtu.be/ztiPjey2rfY) **相关示例：** + [AWS Well-Architected 实验室 – 测试弹性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) # REL 13  如何规划灾难恢复 (DR)？ 拥有适当的备份和冗余工作负载组件是您的 DR 策略的开始。[RTO 和 RPO 是您恢复工作负载的](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 目标。根据业务需求设置这些目标。通过实施策略来实现这些目标，同时考虑工作负载资源和数据的位置和功能。中断概率和恢复成本也是关键因素，有助于了解为工作负载提供灾难恢复的商业价值。 **Topics** + [ # REL13-BP01 定义停机和数据丢失的恢复目标 ](rel_planning_for_recovery_objective_defined_recovery.md) + [ # REL13-BP02 使用定义的恢复策略来实现恢复目标 ](rel_planning_for_recovery_disaster_recovery.md) + [ # REL13-BP03 测试灾难恢复实施以验证实施效果 ](rel_planning_for_recovery_dr_tested.md) + [ # REL13-BP04 管理 DR 站点或区域的配置偏差 ](rel_planning_for_recovery_config_drift.md) + [ # REL13-BP05 自动执行恢复 ](rel_planning_for_recovery_auto_recovery.md) # REL13-BP01 定义停机和数据丢失的恢复目标 工作负载具有恢复时间目标（RTO）和恢复点目标（RPO）。 *恢复时间目标 (RTO)* 是指服务中断和服务恢复之间的最大可接受延迟。这可以确定在服务不可用时被视为可接受的时间窗口。 *恢复点目标 (RPO)*  是指自上一个数据恢复点以来的最大可接受时间。这可以确定在上一个恢复点和服务中断之间可接受的数据丢失程度。 在为您的工作负载选择合适的灾难恢复（DR，Disaster Recovery）策略时，RTO 和 RPO 值是重要的考虑因素。这些目标由业务部门确定，然后由技术团队用来选择和实施 DR 策略。 **期望结果：**  每个工作负载都有一个根据业务影响定义的指定 RTO 和 RPO。工作负载被分配到一个预定义的层，该层定义服务可用性和可接受的数据丢失，以及关联的 RTO 和 RPO。如果无法进行这样的分层，那么可以为每个工作负载分配定制的分层，用于以后创建层。在为工作负载选择灾难恢复策略实施时，使用 RTO 和 RPO 作为主要考虑因素之一。在选择 DR 策略时还要考虑成本约束、工作负载依赖关系和运维需求。 对于 RTO，了解基于中断持续时间的影响。是线性的还是非线性的影响？（例如，四小时后，您关闭一条生产线，直到下一班开始）。 如下所示的灾难恢复矩阵可以帮助您了解工作负载的重要性与恢复目标之间的关系。（请注意，X 轴和 Y 轴的实际值应根据您组织的需求进行定制）。 ![\[显示灾难恢复矩阵的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png) **常见反模式：** + 未定义恢复目标。 + 选择任意恢复目标。 + 选择过于宽松并且不符合业务目标的恢复目标。 + 不了解停机和数据丢失的影响。 + 选择不切实际的恢复目标，如零恢复时间和零数据丢失，这对于您的工作负载配置可能无法实现。 + 选择比实际业务目标更严格的恢复目标。这将强制实施比工作负载所需的成本更高并且更复杂的 DR。 + 选择与所依赖工作负载的恢复目标不兼容的恢复目标。 + 您的恢复目标没有考虑法规合规性要求。 + 为工作负载定义了 RTO 和 RPO，但从未测试过。 **建立此最佳实践的好处：** 在指导您的 DR 实施时，需要您的恢复时间目标和数据丢失恢复目标。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 对于给定的工作负载，您必须了解停机和数据丢失对业务的影响。随着停机时间或数据丢失的增加，影响通常会越来越大，但这种增长的形式可能会因工作负载类型而异。例如，您也许可以容忍长达一小时的停机时间而没有多大影响，但在一小时之后影响会迅速上升。对业务的影响表现为多种形式，包括货币成本（如收入损失）、客户信任（以及对声誉的影响）、运维问题（如错过工资发放或生产力下降）和监管风险。使用以下步骤了解这些影响，并为您的工作负载设置 RTO 和 RPO。 **实施步骤** 1. 确定此工作负载的业务利益相关者，并与他们一起实施这些步骤。工作负载的恢复目标是一项业务决策。然后，技术团队与业务利益相关者合作，使用这些目标来选择 DR 策略。 **注意** 对于步骤 2 和 3，您可以使用 [实施工作表](#implementation-worksheet). 1. 通过回答以下问题，收集必要的信息来做出决策。 1. 在组织中，您是否对工作负载影响的重要性进行了分类或分级？ 1. 如果有，请将此工作负载分配到一个类别 1. 如果没有，则建立这些类别。创建不超过五个类别，并细化每个类别的恢复时间目标范围。类别示例包括：关键、高、中、低。要了解工作负载如何映射到类别，请考虑工作负载是任务关键型、业务重要型还是非业务驱动型。 1. 根据类别设置工作负载 RTO 和 RPO。始终选择比进入此步骤时计算的原始值更严格的类别（更低的 RTO 和 RPO）。如果这导致值发生了不适当的较大改变，那么考虑创建一个新类别。 1. 根据这些答案，为工作负载分配 RTO 和 RPO 值。这可以直接完成，也可以通过将工作负载分配给预定义的服务层来完成。 1. 在工作负载团队和利益相关者可访问的位置，记录此工作负载的灾难恢复计划（DRP，disaster recovery plan），此计划是组织的 [业务连续性计划（BCP，Business Continuity Plan）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)的一部分 1. 记录 RTO 和 RPO，以及用于确定这些值的信息。包括用于评估工作负载对业务影响的策略 1. 除 RTO 和 RPO 之外，记录您根据灾难恢复目标正在跟踪或计划跟踪的其他指标 1. 在进行创建时，您将 DR 策略和运行手册的详细信息添加到此计划中。 1. 通过在如图 15 所示的矩阵中查找工作负载的重要性，您可以开始建立为组织定义的预定义服务层。 1. 根据 实施 DR 策略（或 DR 策略的概念验证）之后，[REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md)测试此策略以确定工作负载的实际 RTC（Recovery Time Capability，恢复时间能力）和 RPC（Recovery Point Capability，恢复点能力）。如果这些能力没有达到所预期的恢复目标，那么，要么与您的业务利益相关者一起调整这些目标，要么对 DR 策略进行更改以便实现预期的目标。 **主要问题** 1. 在对业务产生严重影响之前，工作负载可以停止的最长时间是多少 1. 确定在工作负载中断时，每分钟业务的货币成本（直接财务影响）。 1. 请注意，影响并不总是线性的。影响可能在一开始是有限的，然后在超过一个关键时间点后迅速增加。 1. 在对业务造成严重影响之前，可以丢失的最大数据量是多少 1. 对于最关键的数据存储，请考虑此值。确定其他数据存储的各自关键性。 1. 如果工作负载数据丢失，是否可以重新创建？ 如果这在操作上比备份和还原更容易，那么根据用于重新创建工作负载数据的源数据的重要性来选择 RPO。 1. 此工作负载所依赖的工作负载（下游）或依赖于此工作负载的工作负载（上游）的恢复目标和可用性期望是什么？ 1. 选择使此工作负载能够满足上游依赖项要求的恢复目标 1. 根据下游依赖项的恢复能力，选择可实现的恢复目标。非关键的下游依赖项（您可以“绕过”它们）可以排除。或者，处理关键的下游依赖项，在必要时提高其恢复能力。 **其他问题** 考虑以下问题，以及它们如何应用于此工作负载： 1. 根据中断类型（区域与可用区等），您是否有不同的 RTO 和 RPO？ 1. 您的 RTO/RPO 是否会在特定时间（季节性、销售活动、产品发布）发生变化？ 如果是这样，不同的测量和时间边界是什么？ 1. 如果工作负载中断，会有多少客户受到影响？ 1. 如果工作负载中断，对声誉有何影响？ 1. 如果工作负载中断，可能会产生哪些其他运营影响？ 例如，如果电子邮件系统不可用或工资单系统无法提交事务，则会影响员工的工作效率。 1. 工作负载 RTO 和 RPO 如何与业务线和组织 DR 策略保持一致？ 1. 是否存在提供服务的内部合同义务？ 不履行这些义务会受到处罚吗？ 1. 数据的监管或合规性约束是什么？ ## 实施工作表 您可以将此工作表用于实施步骤 2 和 3。您可以调整此工作表以满足您的特定需求，例如添加其他问题。 ![\[工作表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/worksheet.png) **实施计划的工作量级别： **低 ## 资源 **相关最佳实践：** + [REL09-BP04 定期执行数据恢复以验证备份完整性和流程](rel_backing_up_data_periodic_recovery_testing_data.md) + [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md) + [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md) **相关文档：** + [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) + [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) + [使用 AWS Resilience Hub 管理弹性策略](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) + [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) + [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + [AWS 上工作负载的灾难恢复](https://www.youtube.com/watch?v=cJZw5mrxryA) # REL13-BP02 使用定义的恢复策略来实现恢复目标 定义满足工作负载恢复目标的灾难恢复（DR, disaster recovery）策略。选择一种策略，例如：备份和还原；备用（主动/被动）；或主动/主动。 DR 策略依赖于在主位置无法运行工作负载的情况下，在恢复站点中支持工作负载的能力。最常见的恢复目标是 RTO 和 RPO，相关讨论内容位于 [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md). 跨单个 AWS 区域 内的多个可用区（AZ）的 DR 策略可以缓解火灾、洪水和重大停电等灾难事件。如果需要实施保护措施，为工作负载无法在给定 AWS 区域 中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的 DR 策略。 在跨多个区域构建 DR 策略时，您应该选择以下策略之一。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。 *恢复区域* 指的是 AWS 区域，而不是用于工作负载的主要区域。 ![\[显示 DR 策略的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png) + **备份和还原** （RPO 以小时为单位，RTO 为 24 小时或以内）：将您的数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复，在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。 + **指示灯** （RPO 以分钟为单位，RTO 为数十分钟）：在恢复区域中预置核心工作负载基础设施的副本。将您的数据复制到恢复区域并在那里创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。 + **热备用** （RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复，而且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速扩展以处理生产负载。热备用系统的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为 **热备用服务器**。 + **多区域（多站点）主动-主动** （RPO 接近于零，RTO 可能为零）：您的工作负载被部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，这会很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。 **注意** 指示灯和热备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而热备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而热备用只需要您纵向扩展（所有内容都已部署并运行）。根据您的 RTO 和 RPO 需求在两者之间进行选择。 **期望结果：** 对于每个工作负载，都有一个已定义和实施的 DR 策略，使该工作负载能够实现 DR 目标。工作负载之间的 DR 策略利用可重用模式（如前面描述的策略）。 **常见反模式：** + 为具有类似 DR 目标的工作负载实施不一致的恢复过程。 + 在发生灾难时临时实施 DR 策略。 + 没有 DR 计划。 + 恢复期间依赖于控制面板操作。 **建立此最佳实践的好处：** + 通过定义恢复策略，您可以使用常用工具和测试步骤。 + 通过使用定义的恢复策略，可以在团队之间更高效地共享知识，并更容易地在他们自己的工作负载上实施 DR。 **未建立此最佳实践暴露的风险等级：** 高 + 若没有经过计划、实施和测试的 DR 策略，在发生灾难时不太可能实现恢复目标。 ## 实施指导 对于每个步骤，请参见下面的详细信息。 1. 确定将满足此工作负载恢复要求的 DR 策略。 1. 查看如何实施所选 DR 策略的模式。 1. 评估工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。 1. 确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。 1. 确定并实施措施，以在需要时（在灾难事件期间）可以重新路由流量进行失效转移。 1. 设计工作负载的故障恢复计划。 **实施步骤** 1. **确定将满足此工作负载恢复要求的 DR 策略。** 选择 DR 策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。您应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。 例如，在下图中，企业已经确定了他们允许的最大 RTO 以及他们可以在服务恢复策略上花费的费用限额。鉴于企业目标，指示灯或热备用这样的 DR 策略将同时满足 RTO 和成本标准。 ![\[显示根据 RTO 和成本选择 DR 策略的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png) 如需了解更多信息，请参阅 [业务连续性计划（BCP，Business Continuity Plan）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。 1. **查看如何实施所选 DR 策略的模式。** 这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域 作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为 DR 策略，这将利用多个策略的元素。 在这一步之后的后续步骤中，您将对特定的工作负载应用策略。 **备份和还原**  *备份和还原* 是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，从而导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（如另一个 AWS 区域）。 ![\[显示备份和还原架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png) 有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 II 部分：使用快速恢复功能的备份与还原](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。 **指示灯** 利用 *指示灯* 方法，您可以将数据从主要区域复制到恢复区域。用于工作负载基础设施的核心资源部署在恢复区域中，但仍需要额外的资源和所有依赖项才能使此恢复区域成为功能堆栈。例如，在图 20 中，没有部署计算实例。 ![\[显示指示灯架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png) 有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 **热备用** 热 *备用* 方法涉及到确保在另一个区域中存在生产环境的规模缩减但功能齐全的副本。这种方法扩展了指示灯概念并减少了恢复时间，因为您的工作负载始终在另一个区域中运行。如果恢复区域以满容量部署，那么这种方式称为 *热备用服务器*。 ![\[显示热备用架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png) 使用热备用或指示灯需要扩展恢复区域中的资源。为确保在需要时有可用的容量，请考虑使用 EC2 实例的 [容量预留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 。如果使用 AWS Lambda，那么 [预置并发](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 可以确保执行环境，以便它们准备好立即响应函数的调用。 有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 **多站点主动/主动** 作为 *多站点主动/主动* 策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于 DR 以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载时（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）使用此策略。作为一种 DR 策略，如果工作负载在部署此策略的某个 AWS 区域 中不能得到支持，那么该区域将被撤出，使用其余区域维护可用性。多站点主动/主动策略是 DR 策略中操作最复杂的策略，只有在业务需求时才应选择它。 ![\[显示多站点主动/主动架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png) 有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR，Disaster Recovery）架构，第 IV 部分：多站点主动/主动](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。 **其他保护数据的实践** 对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。 **使用单个 AWS 区域 内的多个可用区（AZ）** 使用单个区域内的多个 AZ 时，您的 DR 实施会使用上述策略的多个元素。首先，您必须使用多个 AZ 创建一个高可用性（HA，High Availability）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 [Amazon EC2 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 和 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 在多个 AZ 中部署了资源，主动处理请求。此架构还演示了热备用服务器方法，如果主 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 实例出现故障（或 AZ 本身出现故障），则备用实例将提升为主实例。 ![\[显示多可用区架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png) 除了这种 HA 架构之外，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 [Amazon EBS 卷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 或者 [Amazon Redshift 集群](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)。如果一个 AZ 发生故障，您需要将这些数据恢复到另一个 AZ。如果可能，您还应该将数据备份复制到另一个 AWS 区域，作为额外的保护层。 下面的博客文章中介绍了一种不太常见的单区域多可用区 DR 的替代方法： [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 1 部分：单区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)。这里的策略是尽可能保持 AZ 之间的隔离，就像区域的运作方式一样。使用这种替代策略，您可以选择主动/主动或主动/被动方法。 注意：某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 AWS 区域的位置的工作负载，那么多区域将不适合您的业务需求。多可用区策略可以很好地抵御大多数灾难。 1. **评估工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。** 对于基础设施和 AWS 资源，使用基础设施即代码功能（如 [AWS CloudFormation](https://aws.amazon.com/cloudformation) ）或第三方工具（如 Hashicorp Terraform）。要使用单个操作跨多个账户和区域部署，您可以使用 [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。对于多站点主动/主动和热备用服务器策略，恢复区域中部署的基础设施具有与主区域相同的资源。对于指示灯和热备用策略，部署的基础设施将需要额外的操作才可用于生产。使用 CloudFormation [参数](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 和 [条件逻辑](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)，您可以通过单个模板控制部署的堆栈是活动的还是备用的。此 CloudFormation 模板示例见 [这篇博客文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。 所有 DR 策略都要求在 AWS 区域 内备份数据源，然后将这些备份复制到恢复区域。[AWS Backup](https://aws.amazon.com/backup/) 提供了一个集中视图，您可以在其中配置、调度和监控这些资源的备份。对于指示灯、热备用和多站点主动/主动方法，您还应该将数据从主区域复制到恢复区域中的数据资源，例如 [Amazon Relational Database Service（Amazon RDS）](https://aws.amazon.com/rds) 数据库实例或 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 表。因此，这些数据资源处于活动状态，可以随时处理恢复区域中的请求。 要了解更多关于 AWS 服务如何跨区域运行的信息，请参阅以下博客系列： [使用 AWS 服务创建多区域应用程序](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)。 1. **确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。** 对于多站点主动/主动策略，失效转移意味着撤离一个区域，并依赖剩余的活动区域。通常，这些区域已准备好接受流量。对于指示灯和热备用策略，恢复操作将需要部署缺失的资源（如图 20 中的 EC2 实例），以及任何其他缺失的资源。 对于上述所有策略，您可能需要将数据库的只读实例提升为主读/写实例。 对于备份和还原，从备份中还原数据时会为该数据创建资源，例如 EBS 卷、RDS 数据库实例和 DynamoDB 表。您还需要还原基础设施并部署代码。您可以使用 AWS Backup 来还原恢复区域中的数据。请参阅 [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md) 了解更多详细信息。重建基础设施包括创建资源，例如，EC2 实例以及所需的 [Amazon Virtual Private Cloud（Amazon VPC）、](https://aws.amazon.com/vpc)子网和安全组。您可以自动执行大部分还原过程。要了解具体方法，请参阅 [这篇博客文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。 1. **确定并实施措施，以在需要时（在灾难事件期间）可以重新路由流量进行失效转移。** 此失效转移操作可以自动或手动启动。应谨慎使用基于运行状况检查或警报自动启动的失效转移，因为不必要的失效转移（误报）会产生不可用和数据丢失等成本。因此，通常会手动启动的失效转移。在这种情况下，您仍然应该自动执行失效转移步骤，这样手动启动就像按一下按钮一样简单。 在使用 AWS 服务时，需要考虑几个流量管理选项。一种选项是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以将一个或多个 AWS 区域 中的多个 IP 端点与一个 Route 53 域名相关联。要实施手动启动的失效转移，您可以使用 [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)，它提供高度可用的数据面板 API 以将流量重新路由到恢复区域。实施失效转移时，使用数据面板操作并避免控制面板操作，如 [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](rel_withstand_component_failures_avoid_control_plane.md). 要了解有关此选项和其他选项的更多信息，请参阅 [灾难恢复白皮书的这一部分](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)。 1. **设计工作负载的故障恢复计划。** 故障恢复是指在灾难事件消除后将工作负载操作返回主区域。向主区域预置基础设施和代码通常遵循最初使用的相同步骤，依赖于基础设施即代码和代码部署管道。故障恢复的挑战是还原数据存储，并确保它们与运行中的恢复区域保持一致。 在失效转移状态下，恢复区域中的数据库处于活动状态，并且具有最新数据。然后，目标是从恢复区域重新同步到主区域，确保主区域是最新的。 某些 AWS 服务会自动执行此操作。如果使用 [Amazon DynamoDB 全局表](https://aws.amazon.com/dynamodb/global-tables/)，即使主区域中的表不可用，当它重新联机时，DynamoDB 也会继续传播任何挂起的写操作。如果使用 [Amazon Aurora 全局数据库](https://aws.amazon.com/rds/aurora/global-database/) 并使用 [托管的计划失效转移](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)，则维护 Aurora 全局数据库的现有复制拓扑。因此，主区域中以前的读/写实例将成为副本，并从恢复区域接收更新。 如果这不是自动执行的，您将需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。例如，有关如何使用 Amazon Aurora 全局数据库对 *计划外* 失效转移执行此操作的说明，请参阅下面的实验： [全局数据库的故障恢复](https://awsauroralabsmy.com/global/failback/)。 失效转移后，如果您可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。 失效转移和故障恢复所需的所有步骤都应保存在行动手册且可供所有团队成员使用，并定期进行审查。 **实施计划的工作量级别：**高 ## 资源 **相关最佳实践：** + [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md) + [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](rel_withstand_component_failures_avoid_control_plane.md) + [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md) **相关文档：** + [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) + [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) + [云中的灾难恢复选项](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) + [在一小时内构建无服务器多区域、主动-主动后端解决方案](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf) + [多区域无服务器后端 – 重新加载](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0) + [RDS：跨区域复制只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn) + [Route 53：配置 DNS 故障转移](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) + [S3：跨区域复制](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) + [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) + [什么是 Route 53 Application Recovery Controller？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [AWS 弹性灾难恢复](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) + [HashiCorp Terraform：入门 – AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) + [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) + [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) **相关视频：** + [AWS 上工作负载的灾难恢复](https://www.youtube.com/watch?v=cJZw5mrxryA) + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + [开始使用 AWS 弹性灾难恢复 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) **相关示例：** + [AWS Well-Architected 实验 – 灾难恢复](https://wellarchitectedlabs.com/reliability/disaster-recovery/) – 说明 DR 策略的系列研讨会 # REL13-BP03 测试灾难恢复实施以验证实施效果 定期测试到恢复站点的失效转移，以确保正常运行，并满足 RTO 和 RPO。 要避免的模式是制定了恢复路径但很少测试。例如，您可能有一个用于只读查询的辅助数据存储。当您写入某个数据存储，却发现主存储故障时，您可能希望将故障转移到辅助数据存储。如果您不经常测试此故障转移，可能会发现您关于辅助数据存储容量的假设是错误的。辅助数据存储容量在您上次测试时可能是足够的，但可能无法再容纳这次情况下的负载。我们的经验表明，唯一有效的错误恢复是您经常测试的路径。因此，最好只开发几条恢复路径。您可以建立恢复模式并定期对其进行测试。如果恢复路径比较复杂或至关重要，您仍需定期在生产环境中测试该故障，确保恢复路径有效。在我们刚才讨论的示例中，您应该定期将故障转移到备用存储，无论是否有需要。 **常见反模式：** + 从不在生产环境中测试失效转移。 **建立此最佳实践的好处：** 定期测试您的灾难恢复计划，确保该计划在需要时能够正常发挥作用，并且您的团队知道如何执行该策略。 **未建立此最佳实践暴露的风险等级：** 高 ## 实施指导 + 为灾难恢复设计工作负载。定期测试恢复路径：面向恢复的计算可识别系统中能够增强恢复功能的特性。这些特性包括：隔离和冗余，系统范围回滚更改的能力，监控并确定运行状况的能力，提供诊断、自动恢复、模块化设计的能力，以及重启的能力。练习恢复路径，以确保您可以在指定时间内恢复到指定状态。在此恢复过程中使用运行手册来记录问题，并在下一次测试之前找到问题的解决方案。 + [加州大学伯克利分校/斯坦福大学的面向恢复的计算项目](http://roc.cs.berkeley.edu/) + 使用 CloudEndure Disaster Recovery 来实施和测试您的 DR 策略。 + [使用 CloudEndure 测试灾难恢复解决方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm) + [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) + [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) + [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) + [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) + [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) + [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) + [使用 CloudEndure 测试灾难恢复解决方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm) + [加州大学伯克利分校/斯坦福大学的面向恢复的计算项目](http://roc.cs.berkeley.edu/) + [什么是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) + [AWS re:Invent 2019：AWS 的备份与还原，以及灾难恢复解决方案（STG208）](https://youtu.be/7gNXfo5HZN8) **相关示例：** + [AWS Well-Architected 实验 – 测试弹性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) # REL13-BP04 管理 DR 站点或区域的配置偏差 确保 DR 站点或区域的基础设施、数据和配置满足需求。例如，检查 AMI 和服务限额是否为最新。 AWS Config 会持续监控和记录 AWS 资源配置。它可以检测到偏差并触发 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 进行修复和发出警报。AWS CloudFormation 还可以在您已部署的堆栈中检测到偏差。 **常见反模式：** + 在主位置进行配置或基础设施更改时，未能在恢复位置进行更新。 + 不考虑主位置和恢复位置的潜在限制（如服务区别）。 **建立此最佳实践的好处：** 确保您的 DR 环境与现有环境一致，可保证完整恢复。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 确保您的交付管道可交付到主站点和备份站点。用于将应用程序部署到生产中的交付管道必须分布到所有指定的灾难恢复策略位置，包括开发和测试环境。 + 启用 AWS Config 来跟踪潜在偏差位置。使用 AWS Config 规则来创建可强制实施灾难恢复策略并在检测到偏差时生成提醒的系统。 + [按照 AWS Config 规则 修正不合规 AWS 资源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + 使用 AWS CloudFormation 部署基础设施。AWS CloudFormation 可以检测 CloudFormation 模板指定的内容和实际部署内容之间的偏差。 + [AWS CloudFormation：在整个 CloudFormation 堆栈上检测偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) + [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) + [AWS CloudFormation：在整个 CloudFormation 堆栈上检测偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) + [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) + [如何在 AWS 上实施基础设施配置管理解决方案？](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected) + [按照 AWS Config 规则 修正不合规 AWS 资源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) # REL13-BP05 自动执行恢复 利用 AWS 或第三方工具自动进行系统恢复，并将流量路由至 DR 站点或区域。 根据已配置的运行状况检查，Elastic Load Balancing 和 AWS Auto Scaling 等 AWS 服务可将负载分配到运行正常的可用区，而 Amazon Route 53 和 AWS Global Accelerator 等服务则可将负载路由到运行正常的 AWS 区域。Amazon Route 53 Application Recovery Controller 可帮助您使用就绪检查和路由控制功能来管理和协调失效转移操作。这些功能持续监控您的应用程序从故障中恢复的能力，因此您可以跨多个 AWS 区域、可用区和本地部署控制您的应用程序恢复。 对于现有的物理或虚拟数据中心或私有云上的工作负载， [AWS 弹性灾难恢复](https://aws.amazon.com/cloudendure-disaster-recovery/)（通过 AWS Marketplace 提供）使组织能够设置自动向 AWS 进行灾难恢复的策略。CloudEndure 还支持 AWS 中的跨区域/跨可用区灾难恢复。 **常见反模式：** + 实施相同的自动故障转移和故障恢复可能会导致在故障时发生摆动。 **建立此最佳实践的好处：** 自动恢复通过消除发生手动错误的可能性来缩短恢复时间。 **未建立这种最佳实践的情况下暴露的风险等级：** 中 ## 实施指导 + 恢复路径自动化。如果恢复时间很短，人工判断和操作无法用于可用性非常高的场景。在这种情况下，系统每次必须自动进行恢复。 + 使用 CloudEndure Disaster Recovery 自动执行失效转移和故障恢复操作。CloudEndure Disaster Recovery 可持续将您的计算机（包括操作系统、系统状态配置、数据库、应用程序和文件）复制到目标 AWS 账户和首选区域中的低成本暂存区域。在发生灾难时，您可以指示 CloudEndure Disaster Recovery 在几分钟内自动启动数千台处于完全预置状态的计算机。 + [执行灾难恢复故障转移和故障恢复](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm) + [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) ## 资源 **相关文档：** + [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) + [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) + [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L) + [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) **相关视频：** + [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)