# 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-BP07 构建产品以满足可用性目标和正常运行时间服务水平协议（SLA）](rel_withstand_component_failures_service_level_agreements.md)
# REL11-BP01 监控工作负载的所有组件以检测故障
持续监控工作负载的运行状况，以便您和您的自动化系统立即发现任何故障或性能下降情况。监控基于商业价值的关键性能指标（KPI）。
所有恢复和修复机制必须从快速检测问题的能力入手。首先，应该检测技术故障并加以解决。不过，可用性基于工作负载创造商业价值的能力，因此衡量它的关键性能指标（KPI）需要成为检测和补救策略的一部分。
**期望结果：**独立监控工作负载的重要组成部分，对故障发生的时间和位置进行检测，再根据检测结果发出警报。
**常见反模式：**
+ 未配置警报，因此不会在发生中断时进行通知。
+ 虽然配置了警报，但只有在达到阈值时才会发出警报，导致没有足够的响应时间。
+ 收集指标的频率不够高，无法满足恢复时间目标（RTO）。
+ 仅主动监控工作负载中面向客户的接口。
+ 只收集技术指标，不收集业务功能指标。
+ 没有衡量工作负载用户体验的指标。
+ 创建的监控太多。
**建立此最佳实践的好处：**如果在所有层都设置了适当的监控，则可以通过减少检测时间来缩短恢复时间。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
确定将接受审查以决定是否监控的所有工作负载。确定工作负载中所有需要监控的组件后，就需要确定监控间隔。根据检测故障所花费的时间，监控间隔将直接影响启动恢复的速度。平均检测时间（MTTD）是从故障发生到修复操作开始之间的时间。服务列表应广泛而完整。
监控必须覆盖应用程序堆栈的所有层，包括应用程序、平台、基础设施和网络。
监控策略应考虑*灰色故障*的影响。有关灰色故障的更多详细信息，请参阅《Advanced Multi-AZ Resilience Patterns》白皮书中的 [Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)。
### 实施步骤
+ 监控间隔取决于必须以多快的速度恢复。恢复时间取决于恢复所需的时间，因此在确定收集频率时，必须考虑此时间和恢复时间目标（RTO）。
+ 为组件和托管服务配置详细监控。
+ 确定[详细监控对于 EC2 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)和[自动扩缩](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)来说是否有必要。详细监控以 1 分钟为间隔提供指标，默认监控以 5 分钟为间隔提供指标。
+ 确定是否需要为 RDS 设置[增强监控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)。增强监控使用 RDS 实例上的代理，获取关于不同进程或线程的有用信息。
+ 确定以下各项的关键无服务器组件的监控要求：[Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html)、[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)、[Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs)，以及所有类型的[负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)。
+ 确定以下各项的存储组件的监控要求：[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html)、[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html)、[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html) 和 [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html)。
+ 创建[自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)来测量业务关键性能指标（KPI）。工作负载会实现关键业务功能，这些功能应用作 KPI 来协助在发生间接问题时予以识别。
+ 使用用户金丝雀来监控用户的故障体验。可运行并模拟客户行为的[综合事务测试](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)（又称为“金丝雀测试”，但与金丝雀部署不同）是一项重要的测试流程。从不同的远程位置针对工作负载端点持续地运行此类测试。
+ 创建跟踪用户体验的[自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。如果您可以衡量客户体验，就可以确定发生了客户体验下降。
+ [设置警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)，在检测到工作负载的任何部分未正常运行时发出警报，并指示什么时候自动扩展资源。警报可以直观地显示在控制面板上，通过 Amazon SNS 或电子邮件发送警报，并与自动扩缩功能结合使用来纵向扩展或缩减工作负载资源。
+ 创建[控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)，以可视化形式呈现指标。可以使用控制面板直观地查看趋势、离群值和表示其他潜在问题的指标，或者提供您可能需要调查的问题的指示。
+ 为服务创建[分布式跟踪监控](https://aws.amazon.com/xray/faqs/)。使用分布式监控，您可以了解应用程序及其底层服务的运行情况，以便确定和诊断性能问题及错误的根本原因。
+ 在单独的区域和账户中创建监控系统（使用 [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 或 [X-Ray](https://aws.amazon.com/xray/faqs/)）控制面板和数据收集。
+ 随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的服务降级情况。通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) [创建要发送到电子邮件和聊天渠道且契合目标的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，并以编程方式[通过 Amazon EventBridge 与监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。
## 资源
**相关最佳实践：**
+ [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 当事件影响可用性时发送通知](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.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)
+ [Monitoring Your Auto Scaling Groups and Instances Using 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)
+ [使用跨区域跨账户的 CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [使用跨区域跨账户的 X-Ray 跟踪](https://aws.amazon.com/xray/faqs/)
+ [Understanding availability](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**相关视频：**
+ [Mitigating gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**相关示例：**
+ [One Observability Workshop: Explore X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**相关工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP02 失效转移到运行状况良好的资源
如果资源发生故障，运行状况良好的资源应继续为请求提供服务。对于位置受损（如可用区或 AWS 区域 受损），确保拥有适当的系统，可失效转移到未受损位置内运行状况良好的资源。
设计服务时，应在资源、可用区或区域之间分配负载。因此，可以通过将流量转移到运行状况良好的剩余资源，缓解单个资源的故障或损坏。考虑在出现故障时如何发现服务并将流量路由到相应服务。
在设计服务时要考虑故障恢复。在 AWS，我们设计服务时会尽量缩短从故障恢复的时间并降低对数据的影响。我们的服务主要使用的数据存储，只有在数据持久存储在一个区域中的多个副本之后，才会确认请求。它们经构建为使用基于单元的隔离，并使用可用区提供的故障隔离功能。我们在自己的运营过程中广泛使用自动化。我们还将替换和重新启动功能优化为可从中断快速恢复。
允许失效转移的模式和设计因各项 AWS 平台服务而异。许多 AWS 原生托管服务（如 Lambda 或 API Gateway）本质上是跨多个可用区部署的服务。其他 AWS 服务（如 EC2 和 EKS）需要特定的最佳实践设计，才能支持跨可用区的资源或数据存储的失效转移。
应设置监控功能，检查失效转移资源的运行状况，跟踪资源失效转移的进度，并监控业务流程的恢复情况。
**期望结果：**系统能够自动使用新资源从降级中恢复，或手动恢复。
**常见反模式：**
+ 规划和设计阶段未考虑如何应对故障。
+ 未设立 RTO 和 RPO。
+ 监控不足，无法检测出故障的资源。
+ 适当隔离故障域。
+ 不考虑多区域失效转移。
+ 在决定是否进行失效转移时，故障检测过于敏感或过于激进。
+ 未测试或验证失效转移设计。
+ 执行自动修复，但不通知需要进行该修复。
+ 缺少缓冲期，无法避免太快进行失效自动恢复。
**建立此最佳实践的好处：**可以构建更具韧性的系统，在遇到故障时，通过优雅降级和快速恢复来保持可靠性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
AWS 服务（例如[弹性负载均衡](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html)和 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)）有助于跨资源和可用区分配负载。因此，可以通过将流量转移到运行状况良好的剩余资源，缓解单个资源（例如 EC2 实例）的故障或可用区的损坏。
对于多区域工作负载，设计就比较复杂。例如，跨区域只读副本允许您将数据部署到多个 AWS 区域。但是，仍需要进行失效转移才能将只读副本提升为主副本，然后将流量指向新的端点。Amazon Route 53、[Amazon 应用程序恢复控制器 (ARC)](https://aws.amazon.com/application-recovery-controller/)、Amazon CloudFront 和 AWS Global Accelerator 可以协助跨 AWS 区域路由流量。
Amazon S3、Lambda、API Gateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon Pinpoint、Amazon ECR、AWS Certificate Manager、EventBridge 或 Amazon DynamoDB 等 AWS 服务将通过 AWS 自动部署到多个可用区。如果出现故障，这些 AWS 服务会自动将流量路由到运行状况良好的位置。数据在多个可用区中进行冗余存储，并保持可用。
对于 Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS 或 Amazon ECS，多可用区是一个配置选项。如果启动了失效转移，AWS 可以将流量引导到运行状况良好的实例。此失效转移操作可由 AWS 执行，或根据客户要求执行
对于 Amazon EC2 实例、Amazon Redshift、Amazon ECS 任务或 Amazon EKS 容器组，您要选择部署到哪些可用区。对于某些设计，弹性负载均衡会提供解决方案来检测运行状况不佳的可用区内的实例，并将流量路由至运行状况良好的可用区。弹性负载均衡还可以将流量路由至本地数据中心内的组件。
对于多区域流量失效转移，重新路由可以利用 Amazon Route 53、Amazon 应用程序恢复控制器、AWS Global Accelerator、Route 53 Private DNS for VPC 或 CloudFront 提供一种方法，来定义互联网域并分配路由策略（包括运行状况检查），从而将流量路由到运行状况良好的区域。AWS Global Accelerator 提供静态 IP 地址，这些地址充当应用程序的固定入口点，然后使用 AWS 全球网络而不是互联网来路由到您选择的 AWS 区域中的端点，由此获得更高的性能和可靠性。
### 实施步骤
+ 为所有相应的应用程序和服务创建失效转移设计。隔离每个架构组件，为每个组件创建符合 RTO 和 RPO 的失效转移设计。
+ 使用失效转移计划所需的所有服务配置底层环境（例如开发或测试）。使用基础设施即代码（IaC）部署解决方案，确保可重复性。
+ 配置恢复站点（例如第二个区域）来实施并测试失效转移设计。如有必要，可以临时配置测试资源来限制额外成本。
+ 确定哪些失效转移计划由 AWS 自动执行，哪些可以通过 DevOps 流程自动执行，哪些可能需要手动执行。记录并测量每项服务的 RTO 和 RPO。
+ 创建失效转移行动手册，包括对每个资源、应用程序和服务进行失效转移的所有步骤。
+ 创建失效自动恢复行动手册，包括对每个资源、应用程序和服务进行失效自动恢复的所有步骤（包含时机）
+ 制定计划来启动行动手册并加以演练。使用模拟和混沌测试来测试行动手册步骤和自动化功能。
+ 对于位置受损（如可用区或 AWS 区域 受损），确保拥有适当的系统，可失效转移到未受损位置内运行状况良好的资源。在测试失效转移之前，请检查配额、自动扩展级别和正在运行的资源。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [REL13 – 制定灾难恢复计划](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)
+ [REL10 – 使用故障隔离来保护工作负载](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
**相关文档：**
+ [设立 RO 和 RPO 目标](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/)
+ [使用 Route 53 加权路由进行失效转移](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)
+ [Disaster Recovery with Amazon Application Recovery Controller](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [带自动扩缩功能的 EC2](https://github.com/adriaanbd/aws-asg-ecs-starter)
+ [EC2 部署 – 多可用区](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ECS 部署 – 多可用区](https://github.com/aws-samples/ecs-refarch-cloudformation)
+ [Switch traffic using Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html)
+ [使用应用程序负载均衡器和失效转移的 Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html)
+ [ACM 复制和失效转移](https://github.com/aws-samples/amazon-ecr-cross-region-replication)
+ [Parameter Store 复制和失效转移](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d)
+ [ECR 跨区域复制和失效转移](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html)
+ [Secrets Manager 跨区域复制配置](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html)
+ [为 EFS 和失效转移启用跨区域复制](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/)
+ [EFS 跨区域复制和失效转移](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/)
+ [网络失效转移](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html)
+ [使用 MRAP 的 S3 端点失效转移](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap)
+ [为 S3 创建跨区域复制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Guidance for Cross Region Failover and Graceful Failback on AWS](https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/cross-region-failover-and-graceful-failback-on-aws.pdf)
+ [使用多区域全球加速器进行失效转移](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)
+ [使用 DRS 进行失效转移](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html)
**相关示例：**
+ [Disaster Recovery on AWS](https://disaster-recovery.workshop.aws/en/)
+ [Elastic Disaster Recovery on AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US)
# REL11-BP03 自动修复所有层
在检测到故障时，使用自动化功能执行修复操作。降级可能会通过内部服务机制自动修复，也可能需要通过补救措施重启或移除资源。
对于自我管理型应用程序和跨区域修复，可以从[现有最佳实践](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)中获取恢复设计和自动修复流程。
重启或移除资源是修复故障的重要方法。最佳实践是尽可能使服务为无状态。这可以防止重启资源时数据丢失或可用性受损。在云中，作为重启的一部分，您可以（而且在一般情况下也应该）替换完整的资源（例如计算实例或无服务器函数）。重启本身是从故障恢复的简单而可靠的方法。工作负载中会发生很多不同类型的故障。故障可能发生在硬件、软件、通信和操作上。
重启或重试也适用于网络请求。向网络超时以及依赖项返回错误的依赖性故障应用相同的恢复方法。这两个事件对系统具有类似的影响，可应用类似的采用指数回退和抖动的有限重试策略，而不是尝试将各个事件当作特例进行处理。重启功能是面向恢复的计算和高可用性集群架构的特色恢复机制。
**期望结果：**执行自动操作来修复检测到的故障。
**常见反模式：**
+ 预置资源，而不进行自动扩缩。
+ 在实例或容器中单独部署应用程序。
+ 在不使用自动恢复的情况下，部署无法部署到多个位置的应用程序。
+ 手动修复自动扩缩和自动恢复无法修复的应用程序。
+ 缺乏对数据库进行失效转移的自动化功能。
+ 缺乏将流量重新路由到新端点的自动化方法。
+ 缺乏存储复制功能。
**建立此最佳实践的好处：**自动修复可以缩短平均恢复时间，并提高可用性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
Amazon EKS 或其他 Kubernetes 服务的设计应包括最小和最大副本集或有状态集，以及最小集群和节点组大小。这些机制提供了最低数量的持续可用处理资源，同时使用 Kubernetes 控制面板自动修复任何故障。
使用计算集群通过负载均衡器访问的设计模式应利用自动扩缩组。弹性负载均衡（ELB）自动在一个或多个可用区（AZ）中的多个目标和虚拟设备之间分配传入的应用程序流量。
对于不使用负载平衡的基于集群计算的设计，其规模至少应能承受一个节点的中断。这将允许服务在恢复新节点时，使自身以可能降低的容量维持运行状态。示例服务有 Mongo、DynamoDB Accelerator、Amazon Redshift、Amazon EMR、Cassandra、Kafka、MSK-EC2、Couchbase、ELK 和 Amazon OpenSearch Service。其中许多服务都可以设计带有额外的自动修复功能。某些集群技术必须在节点丢失时生成警报，从而触发自动或手动工作流程来重新创建新节点。该工作流程可以使用 AWS Systems Manager 自动执行，从而快速修复问题。
Amazon EventBridge 可用于监控和筛选事件，例如 CloudWatch 警报或其他 AWS 服务中的状态更改。然后，其可根据事件信息调用 AWS Lambda、Systems Manager Automation 或其他目标，对工作负载运行自定义修复逻辑。可以配置 Amazon EC2 Auto Scaling 来检查 EC2 实例的运行状况。若实例处于正在运行以外的任何状态，或系统状态受损，Amazon EC2 Auto Scaling 会认为实例的运行状况不佳，继而启动替换实例。针对大规模替换（例如整个可用区丢失），静态稳定性更适合用来实现高可用性。
### 实施步骤
+ 使用自动扩缩组在工作负载中部署层。[自动扩缩](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)可以对无状态应用程序执行自我修复，以及添加或移除容量。
+ 对于前面提到的计算实例，可使用[负载均衡](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)，然后选择合适的负载均衡器类型。
+ 考虑 Amazon RDS 修复。对于备用实例，请配置[自动失效转移](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds)到备用实例。针对 Amazon RDS 只读副本，需要自动化工作流程，使只读副本成为主副本。
+ [在 EC2 实例上实施自动恢复](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)，这些实例中部署的应用程序无法部署到多个位置，但在故障后允许重新启动。当无法将应用程序部署到多个位置时，可以使用自动恢复来替换发生故障的硬件并重新启动实例。实例元数据和关联的 IP 地址，以及 [EBS 卷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)和 [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 或 [适用于 Lustre 的文件系统](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)和[适用于 Windows 的文件系统](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)的挂载点，都会得到保留。使用 [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) 时，您可以在层级别配置 EC2 实例的自动修复。
+ 当无法使用自动扩缩或自动恢复，或者自动恢复出故障时，可以使用 [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) 实施自动恢复。当无法使用自动扩缩，并且无法使用自动恢复或自动恢复失败时，可以使用 AWS Step Functions 和 AWS Lambda 进行自动修复。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 可用于监控和筛选事件，例如 [CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)或其他 AWS 服务中的状态更改。根据事件信息，该服务可以调用 AWS Lambda（或其他目标），在工作负载上运行自定义修复逻辑。
## 资源
**相关最佳实践：**
+ [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**相关文档：**
+ [AWS Auto Scaling 的工作原理](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.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)
+ [What is Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [什么是 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？](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)
+ [Amazon RDS 失效转移](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf)
+ [SSM – Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html)
+ [韧性架构最佳实践](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
**相关视频：**
+ [Automatically Provision and Scale OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE)
+ [Amazon RDS Failover Automatically](https://www.youtube.com/watch?v=Mu7fgHOzOn0)
**相关示例：**
+ [Amazon RDS 失效转移讲习会](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance)
**相关工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP04 恢复期间依赖于数据面板而不是控制面板
控制面板提供用于创建、读取、描述、更新、删除和列出（CRUDL）资源的管理 API，而数据面板则处理日常服务流量。在对可能影响韧性的事件实施恢复或缓解响应时，着眼于使用最少数量的控制面板操作，实现对服务的恢复、重新扩缩、恢复、修复或失效转移。在这些降级事件期间，数据面板操作应凌驾于任何活动之上。
例如，以下是所有控制面板操作：启动新的计算实例、创建数据块存储和描述队列服务。启动计算实例时，控制面板必须执行多项任务，例如查找具有容量的物理主机、分配网络接口、准备本地数据块存储卷、生成凭证以及添加安全规则。控制面板往往是复杂的编排。
**期望结果：**当资源进入受损状态时，将流量从受损资源转移到运行状况良好的资源，能够自动或手动恢复系统。
**常见反模式：**
+ 依赖于通过更改 DNS 记录来重新路由流量。
+ 由于预置资源不足，依赖控制面板扩展操作来替换受损组件。
+ 依靠广泛、多服务、多 API 控制面板操作来修复任何类别的受损情况。
**建立此最佳实践的好处：**提高自动修复的成功率可以缩短平均恢复时间，并提高工作负载的可用性。
**在未建立这种最佳实践的情况下暴露的风险等级：**中。对于某些类型的服务降级，控制面板会受到影响。依赖于大量使用控制面板进行修复，可能会增加恢复时间（RTO）和平均恢复时间（MTTR）。
## 实施指导
要限制数据面板操作，请评测每项服务，了解恢复服务所需的操作。
利用 Amazon 应用程序恢复控制器来转移 DNS 流量。这些功能会持续监控应用程序从故障中恢复的能力，让您能够跨多个 AWS 区域、可用区和本地部署控制应用程序恢复。
Route 53 路由策略使用控制面板，因此不要依赖控制面板进行恢复。Route 53 数据面板会回复 DNS 查询，并执行和评估运行状况检查。它们分布在全球各地，专为 [100% 可用性的服务水平协议（SLA）](https://aws.amazon.com/route53/sla/)而设计。
用于创建、更新和删除 Route 53 资源的 Route 53 管理 API 和控制台是在控制面板上运行，而这些控制面板设计用于优先考虑在管理 DNS 时所需的强一致性和持久性。为了实现这一点，控制面板位于单个区域“美国东部（弗吉尼亚州北部）”中。虽然这两个系统都非常可靠，但控制面板不包含在 SLA 中。在极少数情况下，数据面板的韧性设计允许自身保持可用性，而控制面板做不到。对于灾难恢复和失效转移机制，使用数据面板功能可提供尽可能高的可靠性。
将计算基础设施设计为静态稳定，以避免在事故发生期间使用控制面板。例如，如果您使用的是 Amazon EC2 实例，请避免手动配置新实例或指示自动扩缩组添加实例作为响应。要获得最高级别的韧性，请在集群中预置足够的容量用于失效转移。如果必须限制此容量阈值，请在整个端到端系统上设置限制，安全地限制到达有限资源集的总流量。
对于诸如 Amazon DynamoDB、Amazon API Gateway、负载均衡器和 AWS Lambda 无服务器之类的服务，使用这些服务时可以利用数据面板。但是，创建新函数、负载均衡器、API Gateway 或 DynamoDB 表是一项控制面板操作，应在降级之前完成，以便为事件和演练失效转移操作做准备。对于 Amazon RDS，数据面板操作允许访问数据。
有关数据面板、控制面板以及 AWS 如何构建服务来满足高可用性目标的更多信息，请参阅[使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)。
了解哪些操作位于数据面板，哪些位于控制面板。
### 实施步骤
对于降级事件后需要恢复的每个工作负载，请评估失效转移运行手册、高可用性设计、自动修复设计或高可用性（HA）资源恢复计划。确定可能被视为控制面板操作的每个操作。
考虑将控制面板操作更改为数据面板操作：
+ 自动扩缩（控制面板）到预扩展 Amazon EC2 资源（数据面板）
+ Amazon EC2 实例扩展（控制面板）到 AWS Lambda 扩展（数据面板）
+ 评测任何使用 Kubernetes 的设计以及控制面板操作的性质。在 Kubernetes 中，添加容器组是一项数据面板操作。操作应仅限于添加容器组而不是添加节点。使用[预置过度的节点](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/)是限制控制面板操作的首选方法
考虑允许数据面板操作影响相同修复措施的其他方法。
+ Route 53 记录更改（控制面板）或 Amazon 应用程序恢复控制器（数据面板）
+ [Route 53 运行状况检查，可获取更多自动更新](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
如果是任务关键型服务，可考虑使用辅助区域中的某些服务，以便在不受影响的区域内进行更多控制面板和数据面板操作。
+ 主区域中的 Amazon EC2 Auto Scaling 或 Amazon EKS 与辅助区域中的 Amazon EC2 Auto Scaling 或 Amazon EKS 相比，以及将流量路由到辅助区域（控制面板操作）
+ 在辅助区域中创建只读副本或在主区域中尝试相同的操作（控制面板操作）
## 资源
**相关最佳实践：**
+ [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**相关文档：**
+ [APN 合作伙伴：可帮助实现容错自动化的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace：可支持容错的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](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 Data Plane](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack](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/)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack](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/)
+ [What is Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Kubernetes 控制面板和数据面板](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**相关视频：**
+ [Back to Basics - Using Static Stability](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [Building resilient multi-site workloads using AWS global services](https://www.youtube.com/watch?v=62ZQHTruBnk)
**相关示例：**
+ [Introducing Amazon Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack ](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/)
+ [Building highly resilient applications using Amazon Application Recovery Controller, Part 2: Multi-Region stack](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/)
+ [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**相关工具：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP05 使用静态稳定性来防止双模态行为
工作负载应具有静态稳定性，并且仅在单一正常模式下运行。双模态行为是指工作负载在正常模式和故障模式下表现出不同的行为。
例如，您可能会尝试在不同的可用区中启动新实例，以便从可用区故障中恢复。在故障模式下，这可能会导致双模态响应。您应该构建静态稳定的工作负载，并且仅在一个模式下运行。在此示例中，这些实例应在出现故障之前，已经在第二个可用区中预置。这种静态稳定性设计可确保工作负载仅在单一模式下运行。
**期望结果：**在正常模式和故障模式下，工作负载不会表现出双模态行为。
**常见反模式：**
+ 假设无论故障范围如何，始终可以预置资源。
+ 尝试在故障期间动态获取资源。
+ 在出现故障之前，没有跨可用区或跨区域预置足够的资源。
+ 仅为计算资源考虑了静态稳定设计。
**建立此最佳实践的好处：**采用静态稳定设计运行的工作负载，在正常情况和故障事件期间能够得到可预测的结果。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
当工作负载在正常模式和故障模式下展现出不同的行为时，这就是双模态行为（例如，在可用区发生故障时依赖于启动新的实例）。双模态行为的一个例子是，稳定的 Amazon EC2 设计在每个可用区中预置了足够的实例，用于处理在移除了一个可用区时的工作负载。弹性负载均衡或 Amazon Route 53 运行状况将进行检查，将负载从受损实例上移开。在流量转移以后，使用 AWS Auto Scaling 异步替换故障可用区的实例，并在运行状况良好的可用区中启动。适用于计算部署（如 EC2 实例或容器）的静态稳定性将提供最高水平的可靠性。
![\[图中显示了跨可用区的 EC2 实例的静态稳定性\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/static-stability.png)
您必须就这一模型的成本以及在所有情况下保持工作负载韧性的业务价值进行权衡。预置较少的计算容量并依赖于在出现故障时启动新实例，这种方法的成本较低，但是对于大规模故障（例如可用区或区域受损），这种方法效果较差，因为它既依赖于运营层面，也依赖未受影响的可用区或区域中有足够的可用资源。
您的解决方案还需要在工作负载的可靠性和成本需求之间做出取舍。静态稳定性架构适用于各种架构，包括跨多个可用区的计算实例、数据库只读副本设计、Kubernetes（Amazon EKS）集群设计和多区域失效转移架构。
您还可以在每个可用区中使用更多资源，从而实施具有更好的静态稳定性的设计。通过添加更多可用区，您可以减少实现静态稳定性所需的额外计算容量。
双模态行为的一个例子是，网络超时可能会导致系统尝试刷新整个系统的配置状态。这会向另一个组件添加意外负载，进而可能导致该组件出现故障，引发其他意外后果。此负面的反馈环路会影响工作负载的可用性。相反，您可以构建静态稳定的系统，并且仅在一个模式下运行。静态稳定的设计会持续工作，并且始终定期刷新配置状态。当调用失败时，工作负载将使用先前缓存的值并启动警报。
双模态行为的另一个示例是允许客户端在故障发生时绕过工作负载缓存。这看起来似乎是可以满足客户端需求的解决方案，但它会明显改变工作负载的需求，而且很有可能导致故障。
评测关键工作负载，确定哪些工作负载需要这种韧性设计。对于被视为关键的工作负载，必须审核每个应用程序组件。需要静态稳定性评估的服务类型示例包括：
+ **计算**：Amazon EC2、EKS-EC2、ECS-EC2、EMR-EC2
+ **数据库**：Amazon Redshift、Amazon RDS、Amazon Aurora
+ **存储**：Amazon S3（单区）、Amazon EFS（挂载）、Amazon FSx（挂载）
+ **负载均衡器：**在某些设计下
### 实施步骤
+ 构建静态稳定的系统，并且仅在一个模式下运行。在这种情况下，应在每个可用区或区域中预置足够的实例，以便在移除了一个可用区或区域时处理工作负载容量。您可以使用多种服务来路由到运行状况良好的资源，例如：
+ [跨区域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 多区域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ 配置[数据库只读副本](https://aws.amazon.com/rds/features/multi-az/)，应对单个主实例或只读副本丢失的情况。如果流量由只读副本提供服务，则每个可用区和每个区域中的资源数量，应等于可用区或区域出现故障时的总体需求量。
+ 在 Amazon S3 存储中配置关键数据，设计为在可用区出现故障时可确保所存储数据的静态稳定性。如果使用 [Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 存储类，则不应将其视为静态稳定，因为丢失该可用区会将对所存储数据的可访问性降到最低。
+ [负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)有时服务于特定可用区，这可能是因为配置不正确，也可能是有意设计成这样。在这种情况下，静态稳定的设计可能需要采用更复杂的设计，将工作负载分布到多个可用区。出于安全、延迟或成本方面的考虑，可能会使用最初的设计来减少区域间流量。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
+ [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)
**相关文档：**
+ [Minimizing Dependencies in a Disaster Recovery Plan](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)
+ [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html)
+ [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [多可用区 RDS](https://aws.amazon.com/rds/features/multi-az/)
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [跨区域 DNS 路由](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html)
+ [MRAP Amazon S3 多区域路由](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [单区 Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/)
+ [Cross Zone Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html)
**相关视频：**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 当事件影响可用性时发送通知
在检测到突破阈值时发送通知，即使导致问题的事件已自动解决。
自动修复使您的工作负载变得可靠。不过，它也可能会掩盖需要处理的潜在问题。实施适当的监控和措施，以便检测问题的模式，包括那些被自动修复的问题，以便从根本上解决问题。
韧性系统经过精心设计，可以立即将性能下降事件传达给相应的团队。这些通知应通过一个或多个通信渠道发送。
**期望结果：**在突破阈值 [例如错误率、延迟或其他重要的关键绩效指标（KPI）] 时，系统会立即向运营团队发送警报，以便尽快解决这些问题，避免或最大限度地减少对用户的影响。
**常见反模式：**
+ 发送的警报过多。
+ 发送不可操作的警报。
+ 将警报阈值设置得太高（过于敏感）或太低（不够敏感）。
+ 不针对外部依赖项发送警报。
+ 在设计监控和警报时不考虑[灰色故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)。
+ 执行自动修复，但未通知相应的团队需要进行该修复。
**建立此最佳实践的好处：**恢复通知可以让运营和业务团队了解到服务性能下降的情况，这样他们就可以立即做出反应，尽可能地缩短平均检测时间（MTTD）和平均修复时间（MTTR）。恢复事件通知还可确保您不会忽略不经常发生的问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**中。未能实施适当的监控和事件通知机制，会导致未能检测到出现的问题模式，包括那些被自动修复的问题。只有当用户联系客户服务或者在偶然的情况下，团队才会了解到系统性能下降的情况。
## 实施指导
在定义监控策略时，触发的警报是常见事件。此事件可能包含警报的标识符、警报状态（例如 `IN ALARM` 或 `OK`），以及触发该警报的对象的详细信息。在许多情况下，系统应该检测到警报事件并发送电子邮件通知。这是对警报执行操作的示例。警报通知对于可观测性至关重要，因为它会告知相关人员所存在的问题。不过，当您的可观测性解决方案能够针对事件采取合理的操作时，它可以自动修复问题，而无需人工干预。
建立 KPI 监控警报后，在超过阈值时，应向相应的团队发送警报。这些警报还可用于触发自动流程，尝试修复性能下降问题。
对于更复杂的阈值监控，应考虑使用复合警报。复合警报使用多个 KPI 监控警报，根据运营业务逻辑创建警报。CloudWatch 警报可被配置为发送电子邮件，或使用 Amazon SNS 集成或 Amazon EventBridge 将事件记录到第三方事件跟踪系统。
### 实施步骤
根据监控工作负载的方式，创建各种类型的警报，例如：
+ 使用应用程序警报，检测工作负载的任何部分未正常工作的情况。
+ [基础设施警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)指明何时扩展资源。警报可以直观地显示在控制面板上，通过 Amazon SNS 或电子邮件发送警报，并与 Auto Scaling 结合使用来横向扩展或缩减工作负载资源。
+ 可以创建简单的[静态警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)，用于监控在指定数量的评估周期内，指标突破静态阈值的情况。
+ [复合警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)可以处理来自多个来源的复杂警报。
+ 创建警报后，请创建相应的通知事件。您可以直接调用 [Amazon SNS API](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 来发送通知，并关联任何自动化功能进行修复或通信。
+ 随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的服务降级情况。通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) [创建要发送到电子邮件和聊天渠道且契合目标的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，并以编程方式[通过 Amazon EventBridge 与监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。
## 资源
**相关的 Well-Architected 最佳实践：**
+ [可用性定义](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.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)
+ [What is Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.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/Create_Composite_Alarm.html)
+ [What's new in AWS Observability at re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/)
**相关工具：**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)
# REL11-BP07 构建产品以满足可用性目标和正常运行时间服务水平协议（SLA）
构建产品以满足可用性目标和正常运行时间服务水平协议（SLA）。如果您公开或私下同意可用性目标或正常运行时间 SLA，请确保架构和运营流程的设计支持它们。
**期望结果：**每个应用程序的性能指标都有明确的可用性和 SLA 目标，可以监控和维护目标，实现业务成果。
**常见反模式：**
+ 在不设置任何 SLA 的情况下设计和部署工作负载。
+ 在没有理由或业务需求的情况下将 SLA 指标设置得很高。
+ 在设置 SLA 时不考虑依赖项及其基础 SLA。
+ 设计应用程序时不考虑韧性的责任共担模式。
**建立此最佳实践的好处：**根据关键韧性目标设计应用程序，有助于实现业务目标并满足客户期望。这些目标有助于推动评估不同技术并考虑各种权衡的应用程序设计过程。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
应用程序设计必须考虑因业务、运营和财务目标而产生的各种要求。根据运营要求，工作负载需要具有特定的韧性指标目标，以便进行监控并予以支持。不得在部署工作负载之后才设置或引出韧性指标。这些指标应该在设计阶段得到定义，有助于指导作出各种决策和权衡。
+ 每个工作负载都应有自己的一组韧性指标。这些指标可能与其他业务应用程序的指标不同。
+ 减少依赖项可以对可用性产生积极影响。每个工作负载都应考虑自己的依赖项及其 SLA。一般来说，选择可用性目标等于或大于工作负载目标的依赖项。
+ 若可行，尽量考虑采用松耦合设计，让工作负载可以在依赖关系受损的情况下正常运行。
+ 减少控制面板依赖项，特别是在恢复或降级期间。评估可确保任务关键型工作负载静态稳定性的设计。使用资源节约来提高工作负载中这些依赖项的可用性。
+ 可观测性和检测能力对于通过减少平均检测时间（MTTD）和平均修复时间（MTTR）来实现 SLA 至关重要。
+ 降低故障频率（提高 MTBF）、缩短故障检测时间（缩短 MTTD）和缩短修复时间（缩短 MTTR）是提高分布式系统可用性的三项因素。
+ 设立并满足工作负载的韧性指标，这是所有有效设计的基础。这些设计必须在设计复杂性、服务依赖项、性能、扩展和成本之间作出权衡。
**实施步骤**
+ 检查并记录工作负载设计，考虑以下问题：
+ 在工作负载中的什么地方使用控制面板？
+ 工作负载如何实施容错？
+ 扩展、自动扩展、冗余和高可用性组件的设计模式是什么？
+ 数据一致性和可用性的要求是什么？
+ 是否考虑了资源节约或资源静态稳定性？
+ 有哪些服务依赖项？
+ 与利益相关方合作时，根据工作负载架构定义 SLA 指标。考虑工作负载使用的所有依赖项的 SLA。
+ 设立了 SLA 目标后，优化架构来满足 SLA。
+ 确定了满足 SLA 的设计后，实施侧重于减少 MTTD 和 MTTR 的运营更改、流程自动化和运行手册。
+ 部署之后，监控和报告 SLA。
## 资源
**相关最佳实践：**
+ [REL03-BP01 选择如何划分工作负载](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 自动修复所有层](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 使用混沌工程测试韧性](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md)
+ [了解工作负载运行状况](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**相关文档：**
+ [Availability with redundancy](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [可靠性支柱 – 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [衡量可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [韧性的责任共担模式](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 服务水平协议（SLA）](https://aws.amazon.com/legal/service-level-agreements/)
+ [Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS infrastructure ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Advanced Multi-AZ Resilience Patterns whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**相关服务：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)