# 故障管理
**Topics**
+ [REL 9. 您如何备份数据？](rel-09.md)
+ [REL 10. 如何使用故障隔离来保护工作负载？](rel-10.md)
+ [REL 11. 如何将工作负载设计为可承受组件故障的影响？](rel-11.md)
+ [REL 12. 如何测试可靠性？](rel-12.md)
+ [REL 13. 如何规划灾难恢复（DR）？](rel-13.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 识别并备份需要备份的所有数据或从源复制数据
了解并使用工作负载所用的数据服务和资源的备份功能。大多数服务提供了备份工作负载数据的功能。
**期望结果：**数据来源已确定，并根据重要性进行了分类。然后，根据 RPO 为数据恢复建立了策略。此策略涉及到备份这些数据来源，或者能够从其他来源复制数据。在出现数据丢失的情况下，所实施的策略可以在定义的 RPO 和 RTO 内实现数据的恢复或复制。
**云成熟度阶段：**基础
**常见反模式：**
+ 不了解工作负载的所有数据来源及其重要性。
+ 没有对关键数据来源进行备份。
+ 仅对部分数据来源进行备份，但没有考虑重要性标准。
+ 没有定义 RPO，或者备份频率无法满足 RPO。
+ 没有评估备份是否必需或者是否可以从其他来源复制数据。
**建立此最佳实践的好处：**确定需要备份的位置并实施某种机制来创建备份，或者具备从外部来源复制数据的能力，这样可以提高在停机期间还原和恢复数据的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
所有 AWS 数据存储均提供备份功能。Amazon RDS 和 Amazon DynamoDB 等服务还额外地支持可实现时间点故障恢复（PITR）的自动备份，这使您可以将备份恢复到距当前时间不超过五分钟的任意时间点。许多 AWS 服务提供了将备份复制到其他 AWS 区域的功能。AWS Backup 工具向您提供了在不同 AWS 服务中集中实现自动化数据保护的能力。[AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 使您可以从本地、跨可用区或跨区域复制完整的服务器工作负载并保持连续数据保护，恢复点目标（RPO）以秒为单位。
Amazon S3 可用作自行管理数据来源和 AWS 托管数据来源的备份目标。Amazon EBS、Amazon RDS、和 Amazon DynamoDB 等 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) 将本地数据备份到 AWS 云。Amazon S3 存储桶可用于在 AWS 中存储此数据。Amazon S3 提供多个存储层（例如 [Amazon Glacier 或 Amazon 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)或 [Amazon RDS 只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)可用于在主来源丢失时复制数据。如果像这样的来源可用于满足[恢复点目标（RPO）和恢复时间目标（RTO）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)要求，您可能不需要备份。在另一个例子中，如果使用 Amazon EMR，只要可以[将数据从 Amazon S3 复制到 Amazon EMR 中](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/)，则可能不需要备份 HDFS 数据存储。
在选择备份策略时，请考虑恢复数据所用的时间。恢复数据所需的时间取决于备份的类型（在采用备份策略时）或数据复制机制的复杂性。此时间应该符合工作负载的 RTO。
**实施步骤**
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 Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 处理到 AWS 区域的自动亚秒级数据复制。大多数 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)
+ [What is AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [What is Volume Gateway?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN 合作伙伴：可帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Backing Up Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Backing up Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Backup and Restore for ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Creating a DB Cluster Snapshot in 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)
+ [Creating an EventBridge Rule That Triggers on a Schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [使用 Amazon S3 进行跨区域复制](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [EFS 到 EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exporting Log Data to 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)
+ [Working with Amazon OpenSearch Service Index Snapshots](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
+ [什么是 AWS Elastic Disaster Recovery？](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**相关视频：**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP02 保护并加密备份
使用身份验证和授权功能来控制并检测对备份的访问。使用加密功能防止备份的数据完整性遭到破坏，以及检测其完整性是否遭到损坏。
实施安全控制措施，以防止未经授权访问备份数据。加密备份以保护数据的机密性和完整性。
**常见反模式：**
+ 对备份和还原自动化的访问权限与对数据的访问权限相同。
+ 不加密备份。
+ 未实施不可变性来防止删除或篡改。
+ 对生产系统和备份系统使用相同的安全域。
+ 未通过定期测试来验证备份完整性。
**建立此最佳实践的好处：**
+ 保护备份安全可防止篡改数据，而对数据进行加密可防止数据在意外暴露时遭到访问。
+ 增强了对勒索软件及其它针对备份基础设施的网络威胁的防护。
+ 通过经过验证的恢复流程，缩短了网络事件后的恢复时间。
+ 提高了安全事件期间的业务连续性能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
使用 AWS Identity and Access Management（IAM）等身份验证和授权服务来控制并检测对备份的访问。使用加密功能防止备份的数据完整性遭到破坏，以及检测其完整性是否遭到损坏。
Amazon S3 支持多种对静态数据进行加密的方式。借助服务器端加密功能，Amazon S3 以未加密数据的形式接受对象，然后在存储此类数据时进行加密。若采用客户端加密，工作负载应用程序需要负责在将数据发送到 Amazon S3 之前加密数据。这两种方式都让您可以使用 AWS Key Management Service（AWS KMS）创建并存储数据密钥，或者您也可以提供自己的密钥并自行对其负责。使用 AWS KMS，您可以通过 IAM 设置策略，决定谁可以、谁不可以访问数据密钥与解密数据。
针对 Amazon RDS，如果您已选择对数据库进行加密，那么备份也会被加密。DynamoDB 备份始终加密。使用 AWS Elastic Disaster Recovery 时，加密所有传输中数据和静态数据。借助弹性灾难恢复，可以使用默认的 Amazon EBS 加密“卷加密密钥”或自定义的客户自主管理型密钥来加密静态数据。
**网络弹性注意事项**
为了增强针对网络威胁的备份安全性，除了加密之外，还可以考虑实施这些额外的控制措施：
+ 使用 AWS Backup 保管库锁或 Amazon S3 对象锁定来实现不可变性，以防止备份数据在其保留期内遭到更改或删除，从而防范勒索软件和恶意删除。
+ 使用 AWS Backup 逻辑上受物理隔离的保管库为关键系统建立生产环境与备份环境之间的逻辑隔离，从而实现分离来协助防止这两个环境同时受到危害。
+ 定期使用 AWS Backup 还原测试来验证备份的完整性，以验证备份没有受损并且可以在发生网络事件后成功恢复。
+ 使用 AWS Backup 多方审批对关键的恢复操作实施多方审批，通过要求由多个指定批准者授权来防止未经授权或恶意的恢复尝试。
### 实施步骤
1. 对每个数据存储使用加密。如果源数据已加密，则备份也将被加密。
+ [在 Amazon RDS 中使用加密](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)。当您创建 RDS 实例时，可以使用 AWS Key Management Service 配置静态加密。
+ [在 Amazon EBS 卷上使用加密](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)。您可以配置默认加密或在创建卷时指定唯一密钥。
+ 使用所需的 [Amazon DynamoDB 加密](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)。DynamoDB 可加密所有静态数据。您可以使用 AWS 拥有的 AWS KMS 密钥或者 AWS 托管式 KMS 密钥，指定存储在账户中的密钥。
+ [加密 Amazon EFS 中存储的数据](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)。在创建文件系统时配置加密。
+ 在源和目标区域中配置加密。您可以使用 KMS 中存储的密钥在 Amazon S3 中配置静态加密，但这些密钥是区域特定密钥。您在配置复制时可以指定目标密钥。
+ 选择是为弹性灾难恢复使用默认还是自定义 [Amazon EBS 加密](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption)。使用此选项会加密暂存区域子网磁盘和复制磁盘上的已复制静态数据。
1. 实施用于访问备份的最低权限。请遵循最佳实践，根据[安全最佳实践](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)来限制对备份、快照和副本的访问。
1. 为关键备份配置不可变性。对于关键数据，实施 AWS Backup 保管库锁或 S3 对象锁定，以防止在指定的保留期内遭到删除或更改。有关实施详细信息，请参阅 [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)。
1. 为备份环境创建逻辑分离。为需要增强网络威胁防护的关键系统实施 AWS Backup 逻辑上受物理隔离的保管库。有关实施指南，请参阅 [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/)。
1. 实施备份验证流程。配置 AWS Backup 还原测试，以定期验证备份没有受损并且可以在发生网络事件后成功恢复。有关更多信息，请参阅 [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/)。
1. 为敏感的恢复操作配置多方审批。对于关键系统，实施 AWS Backup 多方审批，以便要求在继续恢复之前获得多个指定批准者的授权。有关实施详细信息，请参阅 [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/)。
## 资源
**相关文档：**
+ [AWS Marketplace：可用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS Encryption](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）创建的对象](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)
+ [Encrypting Data and Metadata in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Encryption for Backups in 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 Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [什么是 AWS Elastic Disaster Recovery？](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [FSISEC11: How are you protecting against ransomware?](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/fsisec11.html)
+ [Ransomware Risk Management on AWS Using the NIST Cyber Security Framework](https://docs.aws.amazon.com/whitepapers/latest/ransomware-risk-management-on-aws-using-nist-csf/welcome.html)
+ [Building cyber resiliency with AWS Backup logically air-gapped vault](https://aws.amazon.com/blogs/storage/building-cyber-resiliency-with-aws-backup-logically-air-gapped-vault/)
+ [Validate recovery readiness with AWS Backup restore testing](https://aws.amazon.com/blogs/storage/validate-recovery-readiness-with-aws-backup-restore-testing/)
+ [Improve recovery resilience with AWS Backup support for Multi-party approval](https://aws.amazon.com/blogs/storage/improve-recovery-resilience-with-aws-backup-support-for-multi-party-approval/)
**相关示例：**
+ [Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 自动执行数据备份
将备份配置为根据遵循恢复点目标（RPO）的定期计划自动备份，或者在数据集发生更改时自动备份。具有低数据丢失要求的关键数据集，需要频繁地自动备份；而可以接受一定丢失的较不关键的数据，备份频率可以更低。
**期望结果：**按照确定的节奏创建数据来源备份的自动流程。
**常见反模式：**
+ 手动执行备份。
+ 使用具有备份功能的资源，但不包括自动化中的备份。
**建立此最佳实践的好处：**自动化备份可以确保按照 RPO 定期执行备份，并在未备份时发出警报。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
AWS Backup 可用于创建各种 AWS 数据来源的自动数据备份。Amazon RDS 实例可以按照五分钟的频率进行几乎连续的备份，Amazon S3 对象可以按照十五分钟的频率进行几乎连续的备份，提供可恢复到备份历史记录中的特定时间点的时间点故障恢复（PITR）功能。对于其他 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 EBS 快照。
AWS Elastic Disaster Recovery 提供从源环境（本地或 AWS）到目标恢复区域的持续、块级复制。服务会自动创建和管理时间点 Amazon EBS 快照。
针对您的备份自动化和历史的集中式视图，AWS Backup 提供完全托管的基于策略的备份解决方案。它会使用 AWS Storage Gateway 将云端和本地的多项 AWS 服务的数据备份集中在一起并自动处理。
除了版本控制，Amazon S3 还具有复制功能。整个 S3 存储桶都可自动复制到相同或不同 AWS 区域 中的其他存储桶。
**实施步骤**
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。有关如何使用 AWS Backup 创建自动备份的动手实践指导，请参阅 [Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)。用于存储数据的大多数 AWS 服务提供了原生备份功能。例如，可以利用 RDS 来实现支持时间点故障恢复（PITR）的自动备份。
1. 对于自动备份解决方案或托管服务**不支持的数据来源**（如本地数据来源或消息队列），请考虑使用受信任的第三方解决方案来创建自动备份。或者，您可以使用 AWS CLI 或开发工具包创建自动化过程来完成此操作。您可以使用 AWS Lambda 函数或 AWS Step Functions 来定义创建数据备份中涉及的逻辑，并使用 Amazon EventBridge 按照基于 RPO 确定的频率来调用它。
**实施计划的工作量级别：**低
## 资源
**相关文档：**
+ [APN 合作伙伴：可帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule](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 Elastic Disaster Recovery？](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
**相关视频：**
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
# REL09-BP04 定期执行数据恢复以验证备份完整性和流程
通过执行恢复测试，验证备份流程实施是否满足恢复时间目标（RTO）和恢复点目标（RPO）要求。
**期望结果：**使用明确定义的机制定期从备份恢复数据，确认可以按照为工作负载确定的恢复时间目标（RTO）来恢复数据。验证从备份进行还原可以得到包含原始数据的资源，而不会造成数据损坏或无法访问数据，并且数据丢失在恢复点目标（RPO）之内。
**常见反模式：**
+ 还原备份，但未查询或检索任何数据以确认还原操作可用。
+ 假定备份存在。
+ 假定系统的备份完全正常运行，并且可从中恢复数据。
+ 假定从备份还原或恢复数据的时间满足工作负载的 RTO。
+ 假定备份中包含的数据符合工作负载的 RPO
+ 需要时进行还原，没有使用运行手册或者没有按照确定的自动程序执行。
**建立此最佳实践的好处：**测试备份的恢复过程可以确认在需要时能够将数据还原，不必担心数据可能丢失或损坏，可以按照工作负载要求的 RTO 还原和恢复，并且任何数据丢失都符合工作负载的 RPO。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
测试备份和还原功能可树立信心，确信能够在出现中断时执行这些操作。定期将备份还原到新的位置，并运行测试以验证数据的完整性。应该执行一些常见的测试，以核实所有数据是否均可用、未损坏、可访问且任何数据丢失都符合工作负载的 RPO。此类测试还可以帮助确定恢复机制是否足够快以满足工作负载的 RTO 要求。
使用 AWS，您可以构建一个测试环境，还原您的备份以评测 RTO 和 RPO 功能，并且对数据的内容和完整性执行测试。
此外，Amazon RDS 和 Amazon DynamoDB 还允许时间点故障恢复（PITR）。您可以使用持续备份将您的数据集还原到其在指定日期与时间所处的状态。
数据是否可用、没有损坏、是否可以访问并且任意数据丢失都符合工作负载的 RPO。此类测试还可以帮助确定恢复机制是否足够快以满足工作负载的 RTO 要求。
AWS Elastic Disaster Recovery 提供 Amazon EBS 卷的持续时间点恢复快照。复制源服务器时，根据配置的策略记录一段时间内的时间点状态。弹性灾难恢复可以启动实例用于测试和演练，而不重定向流量，从而帮助您验证这些快照的完整性。
**实施步骤**
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 韧性监测中心](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 Elastic Disaster Recovery，则可以[启动恢复演练](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)。
1. 根据您之前为数据验证确立的标准，从还原后的资源**验证数据恢复**。还原和恢复的数据是否包含备份时的最新记录或项目？ 此数据是否在工作负载的 RPO 之内？
1. **测量还原和恢复所需的时间**，并与确立的 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）等服务将推送通知（例如电子邮件或短信）发送给利益相关方。[这些消息还可以发布到消息传递应用程序，例如 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 Lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)提供动手实践体验，可用于练习针对此处的多个步骤实现自动化的方法。
![\[图中显示了自动化的备份和还原流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/automated-backup-restore-process.png)
**实施计划的工作量级别：**中到高，具体取决于验证标准的复杂性。
## 资源
**相关文档：**
+ [Automate data recovery validation with AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN 合作伙伴：可帮助进行备份的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace：可用于备份的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule](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 Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
# REL 10. 如何使用故障隔离来保护工作负载？
故障隔离可将组件或系统故障的影响限制在定义的界限内。通过适当的隔离，界限之外的组件不受故障影响。跨多个故障隔离界限运行工作负载，可以提高工作负载对故障的韧性。
**Topics**
+ [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 组件的自动恢复受限于单个位置](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 采用隔板架构来限制影响范围](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 将工作负载部署到多个位置
将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。
AWS 中服务设计的一个基本原则是避免单点故障，包括底层物理基础设施。AWS 在全球多个地理位置（称为 [Regions](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html)）提供云计算资源和服务。每个区域在物理和逻辑上都是独立的，由三个或更多 [Availability Zones (AZs)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) 组成。可用区在地理上彼此接近，但在物理上是分开和隔离的。当您将工作负载分布于各个可用区和区域之间时，可以降低火灾、洪水、与天气相关的灾难、地震和人为错误等威胁的风险。
制定位置策略，以提供适合您的工作负载的高可用性。
**期望结果：**生产工作负载分布于多个可用区（AZ）或区域之间，以实现容错和高可用性。
**常见反模式：**
+ 您的生产工作负载只存在于单个可用区中。
+ 您在多可用区架构满足业务要求时实施多区域架构。
+ 您的部署或数据变得不同步，这会导致配置偏差或数据复制不足。
+ 当应用程序组件之间的韧性和多位置要求不同时，您未考虑这些组件之间的依赖关系。
**建立此最佳实践的好处：**
+ 您的工作负载更能抵御意外事件，例如电源或环境控制故障、自然灾害、上游服务故障或影响可用区或整个区域的网络问题。
+ 在启动特定 EC2 实例类型时，您可以访问更广泛的 Amazon EC2 实例清单，并降低出现 InsufficientCapacityExceptions（ICE）的可能性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
在区域的至少两个可用区（AZ）中部署和运行所有生产工作负载。
**使用多个可用区**
可用区是资源托管位置，它们在物理上彼此分开，以避免由于火灾、洪水和龙卷风等风险而导致的相关故障。每个可用区都有独立的物理基础设施，包括市电连接、备用电源、机修服务和网络连接。这种安排方式可将其中任何组件的故障限制在受影响的可用区内。例如，如果可用区范围的事件导致 EC2 实例在受影响的可用区中不可用，则您在其它可用区的实例仍保持可用。
尽管同一 AWS 区域中的可用区在物理上是分开的，但它们之间的距离足够近，可以提供高吞吐量、低延迟（个位数毫秒）的联网。您可以在可用区之间同步复制大多数工作负载的数据，而不会显著影响用户体验。这样一来，您便能以主动/主动或主动/备用配置使用区域中的可用区。
与工作负载关联的所有计算均应分布于多个可用区中。这包括 [Amazon EC2](https://aws.amazon.com/ec2/) 实例、[AWS Fargate](https://aws.amazon.com/fargate/) 任务和 VPC 连接的 [AWS Lambda](https://aws.amazon.com/lambda/) 函数。AWS 计算服务，包括 [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)、[Amazon Elastic Container Service（ECS）](https://aws.amazon.com/ecs/)和 [Amazon Elastic Kubernetes Service（EKS）](https://aws.amazon.com/eks/)，为您提供了跨可用区启动和管理计算的方法。将它们配置为根据需要在不同的可用区中自动替换计算以保持可用性。要将流量定向到可用的可用区，请在计算前放置一个负载均衡器，例如应用程序负载均衡器或网络负载均衡器。如果某个可用区受到损害，AWS 负载均衡器可以将流量重新路由到可用的实例。
您还应该为工作负载复制数据，并使其在多个可用区中可用。某些 AWS 托管式数据服务，例如 [Amazon S3](https://aws.amazon.com/s3/)、[Amazon Elastic File Service（EFS）](https://aws.amazon.com/efs/)、[Amazon Aurora](https://aws.amazon.com/aurora/)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Queue Service（SQS）](https://aws.amazon.com/sqs/)和 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)，默认情况可在多个可用区中复制数据，并且可以抵御可用区损害。对于其它 AWS 托管式数据服务，例如 [Amazon Relational Database Service（RDS）](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/) 和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/)，您必须启用多可用区复制。启用后，这些服务会自动检测可用区损害，将请求重定向到可用的可用区，并在恢复后根据需要重新复制数据，而无需客户干预。熟悉您使用的每项 AWS 托管式数据服务的用户指南，以了解其多可用区的功能、行为和操作。
如果您使用的是自行管理的存储，例如 [Amazon Elastic Block Store（EBS）](https://aws.amazon.com/ebs/)卷或 Amazon EC2 实例存储，则必须自行管理多可用区复制。
![\[图中显示了跨三个可用区部署的多层架构。请注意，Amazon S3 和 Amazon DynamoDB 始终会自动部署到多个可用区。而 ELB 也会被部署到所有三个区。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/multi-tier-architecture.png)
**使用多个 AWS 区域**
如果工作负载需要极高的韧性（如关键基础设施、与运行状况相关的应用程序或具有严格的客户或强制可用性要求的服务），您可能需要超出单个 AWS 区域所能提供的额外可用性。在这种情况下，您应该在至少两个 AWS 区域中部署和运行工作负载（假设数据驻留要求支持这么做）。
AWS 区域位于世界各地和多个大洲的不同地理区域。AWS 区域与单独的可用区相比，其物理分离和隔离程度甚至更高。除了少数例外情况，AWS 服务利用这种设计在不同区域之间完全独立运行（也称为*区域服务*）。AWS 区域服务的故障设计为不影响其它区域中的服务。
当您在多个区域中运行工作负载时，应考虑其它要求。由于不同区域中的资源彼此分开且独立，因此必须在每个区域中复制工作负载的组件。除计算服务和数据服务外，这还包括基本的基础设施，例如 VPC。
**注意：**在考虑多区域设计时，请验证工作负载能够在单个区域中运行。如果您在区域之间创建依赖关系，其中一个区域中的组件依赖于另一个区域中的服务或组件，则可能会增加故障风险并显著削弱可靠性状况。
为了简化多区域部署并保持一致性，[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) 可以跨多个区域复制整个 AWS 基础设施。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 还可以检测配置偏差，并在某个区域中的 AWS 资源不同步时通知您。许多 AWS 服务为重要的工作负载资产提供多区域复制。例如，例如，[EC2 Image Builder](https://aws.amazon.com/image-builder/) 可以在每次构建后将 EC2 机器映像（AMI）发布到您使用的每个区域。[Amazon Elastic Container Registry（ECR）](https://aws.amazon.com/ecr/)可以将容器映像复制到选定的区域。
您还必须跨您所选的每个区域复制数据。许多 AWS 托管式数据服务提供跨区域复制功能，包括 Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache 和 Amazon EFS。[Amazon DynamoDB 全局表](https://aws.amazon.com/dynamodb/global-tables/)接受在任何受支持的区域中进行写入，并将在所有其它配置的区域间复制数据。对于其它服务，您必须指定一个主区域进行写入，因为其它区域包含只读副本。对于工作负载使用的每项 AWS 托管式数据服务，请参阅其用户指南和开发人员指南，以了解其多区域功能和局限性。请特别注意必须将写入定向到何处、事务处理功能和限制、如何执行复制以及如何监控区域之间的同步。
AWS 还能够非常灵活地将请求流量路由到区域部署。例如，可以使用 [Amazon Route 53](https://aws.amazon.com/route53/) 配置 DNS 记录，来将流量定向到离用户最近的可用区域。或者，可以在主动/备用配置中配置 DNS 记录，在这种配置中，您将一个区域指定为主区域，仅当主区域变得运行状况不正常时，才回退到区域副本。您可以配置 [Route 53 health checks](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) 来检测运行状况不正常的端点并执行自动失效转移，此外，还可以使用 [Amazon 应用程序恢复控制器（ARC）](https://aws.amazon.com/application-recovery-controller/)来提供高度可用的路由控制，以便根据需要手动重新路由流量。
即使您选择不在多个区域中运行来实现高可用性，也可以将多个区域视为灾难恢复（DR）策略的一部分。如果可能，请在辅助区域中以*热备用* 或*指示灯* 配置来复制工作负载的基础设施组件和数据。在此设计中，您从主区域复制基准基础设施，如 VPC、自动扩缩组、容器编排工具和其它组件，但您将备用区域中的可变大小组件（如 EC2 实例和数据库副本的数量）配置为最小可操作大小。您还可以安排从主区域到备用区域的连续数据复制。如果发生事件，则可以横向扩展或增加备用区域中的资源，然后将其提升为主区域。
### 实施步骤
1. 与业务利益相关者和数据驻留专家合作，来确定哪些 AWS 区域可用来托管您的资源和数据。
1. 与业务和技术利益相关者合作，来评估您的工作负载，并确定其韧性需求是否可以通过多可用区方法（单个 AWS 区域）来满足，或者是否需要多区域方法（如果允许多个区域）。使用多个区域可以提高可用性，但可能会增加复杂性和成本。评估时考虑以下因素：
1. **业务目标和客户要求**：如果在可用区或区域中发生影响工作负载的事件，允许有多少停机时间？ 评估恢复点目标，如 [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)中所述。
1. **灾难恢复（DR）要求**：您想要确保自行抵御哪种潜在灾难？ 考虑数据丢失或长期不可用的可能性，影响范围涉及单个可用区到整个区域。如果您跨可用区复制数据和资源，而单个可用区持续出现故障，则可以在另一个可用区中恢复服务。如果您跨区域复制数据和资源，则可以在另一个区域中恢复服务。
1. 将计算资源部署到多个可用区中。
1. 在 VPC 中，在不同的可用区中创建多个子网。将每个子网配置为足够大，以容纳处理工作负载所需的资源，即使在发生事件期间也是如此。有关更多详细信息，请参阅 [REL02-BP03 确保 IP 子网分配考虑扩展和可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)。
1. 如果您使用的是 Amazon EC2 实例，请使用 [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 来管理实例。在创建自动扩缩组时，指定在上一步中选择的子网。
1. 如果您正在对 [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) 或 [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) 使用 AWS Fargate 计算，请在创建 ECS 服务、启动 ECS 任务或为 EKS 创建 [Fargate 配置文件](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html)时，选择您在第一步中选择的子网。
1. 如果您使用的 AWS Lambda 函数需要在 VPC 中运行，请在创建 Lambda 函数时，选择您在第一步中选择的子网。对于任何没有 VPC 配置的函数，AWS Lambda 自动为您管理可用性。
1. 将流量定向器（例如负载均衡器）放在计算资源之前。如果启用了跨区域负载均衡，[AWS 应用程序负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)和[网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)会检测何时由于可用区受损而无法访问 EC2 实例和容器等目标，并将流量重新路由到正常运行的可用区中的目标。如果您禁用跨区域负载均衡，请使用 Amazon 应用程序恢复控制器（ARC）来提供可用区转移功能。如果您使用的是第三方负载均衡器或已实施了自己的负载均衡器，请为它们配置跨不同可用区的多个前端。
1. 跨多个可用区复制工作负载的数据。
1. 如果您使用的是 AWS 托管式数据服务，例如 Amazon RDS、Amazon ElastiCache 或 Amazon FSx，请研读其用户指南以了解其数据复制和韧性功能。必要时启用跨可用区复制和失效转移。
1. 如果您使用 AWS 托管式存储服务，例如 Amazon S3、Amazon EFS 和 Amazon FSx，请避免对需要高耐久性的数据使用单可用区或单区配置。对这些服务使用多可用区配置。查看相应服务的用户指南，以确定默认情况下是否启用了多可用区复制，或者是否必须启用它。
1. 如果您运行的是自行管理的数据库、队列或其它存储服务，请根据应用程序的说明或最佳实践安排进行多可用区复制。熟悉应用程序的失效转移过程。
1. 配置您的 DNS 服务以检测可用区受损，并将流量重新路由到运行状况正常的可用区。Amazon Route 53 与弹性负载均衡器结合使用时，可以自动执行此操作。还可以为 Route 53 配置失效转移记录，这些记录使用运行状况检查来响应仅具有正常运行的 IP 地址的查询。对于用于失效转移的任何 DNS 记录，请指定较短的生存时间（TTL）值（例如，60 秒或更短），以协助防止记录缓存阻碍恢复（Route 53 别名记录为您提供相应的 TTL）。
**使用多个 AWS 区域时的额外步骤**
1. 跨所选区域复制工作负载使用的所有操作系统（OS）和应用程序代码。如有必要，可以使用 Amazon EC2 Image Builder 等解决方案复制 EC2 实例使用的亚马逊机器映像（AMI）。使用 Amazon ECR 跨区域复制等解决方案复制存储在注册表中的容器映像。为用于存储应用程序资源的任何 Amazon S3 存储桶启用区域复制。
1. 将您的计算资源和配置元数据（例如，存储在 AWS Systems Manager Parameter Store 中的参数）部署到多个区域。使用前面步骤中介绍的相同过程，但请为您要用于工作负载的每个区域复制配置。使用 AWS CloudFormation 等基础设施即代码解决方案在区域之间统一复制配置。如果您在指示灯配置中使用辅助区域进行灾难恢复，您可以将计算资源的数量减少到最小值以节省成本，同时相应地增加恢复时间。
1. 将数据从主区域复制到辅助区域。
1. Amazon DynamoDB 全局表提供数据的全局副本，可以从任何支持的区域写入这些副本。对于其它 AWS 托管式数据服务，例如 Amazon RDS、Amazon Aurora 和 Amazon Elasticache，您可以指定主（读/写）区域和副本（只读）区域。有关区域复制的详细信息，请参阅相应服务的用户和开发人员指南。
1. 如果您运行的是自行管理的数据库，请根据应用程序的说明或最佳实践安排进行多区域复制。熟悉应用程序的失效转移过程。
1. 如果工作负载使用 AWS EventBridge，则可能需要将选定的事件从主区域转发到辅助区域。为此，请将辅助区域中的事件总线指定为主区域中匹配事件的目标。
1. 考虑是否以及在多大程度上希望跨区域使用相同的加密密钥。平衡安全性和易用性的典型方法是使用区域范围的密钥来处理区域本地数据和身份验证，并使用全球范围的密钥来对在不同区域间复制的数据进行加密。[AWS Key Management Service（KMS）](https://aws.amazon.com/kms/)支持 [multi-region keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)，以便安全地分发和保护跨区域共享的密钥。
1. 考虑使用 AWS Global Accelerator，通过将流量定向到包含正常运行的端点的区域，来提高应用程序的可用性。
## 资源
**相关最佳实践：**
+ [REL02-BP03 确保 IP 子网分配考虑扩展和可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 使用静态稳定性来防止双模态行为](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**相关文档：**
+ [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure)
+ [White paper: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Resilience in Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: Example: Distribute instances across Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [How EC2 Image Builder works](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Amazon ECS 如何将任务放置在容器实例上（包括 Fargate）](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [AWS Lambda 中的故障恢复能力](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3：复制对象概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon ECR 中的私有映像复制](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [全局表：使用 DynamoDB 的多区域复制](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Elasticache for Redis OSS: Replication across AWS 区域 using global datastores](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Amazon RDS 中的弹性](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [使用 Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [AWS Global Accelerator Developer Guide](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Multi-Region keys in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: Configuring DNS failover](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Amazon Application Recovery Controller (ARC) Developer Guide](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Sending and receiving Amazon EventBridge events between AWS 区域](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 系列博客文章
+ [开启 AWS 灾难恢复（DR）架构，第一部分：云端恢复策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**相关视频：**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 组件的自动恢复受限于单个位置
如果工作负载的组件只能在单个可用区或本地数据中心内运行，则必须利用相关功能在定义的恢复目标内彻底重建工作负载。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
如果由于技术约束无法使用将工作负载部署到多个位置的最佳实践，则必须实施其他的韧性路径。在这种情况下，必须让重建必要基础设施、重新部署应用程序和重建必要数据的操作实现自动化。
例如，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 区域内随机选择可用区，然后对其中的集群进行预置。所有集群节点在同一区域中配置。
对于部署到本地数据中心基于服务器的有状态工作负载，您可以使用 AWS Elastic Disaster Recovery 来保护 AWS 中的工作负载。如果已经在 AWS 托管中，则可以使用弹性灾难恢复将工作负载保护到其他可用区或区域。弹性灾难恢复在轻量级暂存区域中使用持续的块级复制，以便快速可靠地恢复本地应用程序和基于云的应用程序。
**实施步骤**
1. 实施自我修复。尽可能使用自动扩缩部署实例或容器。如果不能使用自动扩缩，则使用 EC2 实例的自动恢复功能，或者基于 Amazon EC2 或 ECS 容器生命周期事件实现自我修复自动化。
+ 将 [Amazon EC2 Auto Scaling 组](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)用于对单个实例 IP 地址、私有 IP 地址、弹性 IP 地址和实例元数据没有要求的实例和容器工作负载。
+ 启动模板用户数据可以用于实现自动化，让大多数工作负载可以自我修复。
+ 将 [Amazon EC2 实例的自动恢复功能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)用于需要单个实例 ID 地址、私有 IP 地址、弹性 IP 地址和实例元数据的工作负载。
+ 自动恢复功能会在检测到实例故障时，向 SNS 主题发送恢复状态提醒。
+ 在无法使用自动扩缩或 EC2 恢复的情况下，请使用[Amazon EC2 实例生命周期事件](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)实现自我修复自动化。
+ 使用这些事件调用自动化，该自动化将根据您需要的流程逻辑来修复组件。
+ 使用 [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 保护仅限于单个位置的有状态工作负载。
## 资源
**相关文档：**
+ [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Amazon 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)
+ [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 采用隔板架构来限制影响范围
实施隔板架构（也称为基于单元的架构），将工作负载中故障的影响限制于有限数量的组件。
**期望结果：**基于单元的架构使用多个独立的工作负载实例，其中每个实例称为单元。单元彼此独立，不与其他单元共享状态，并且处理整个工作负载请求的子集。这样减少了故障（例如，错误的软件更新）对单个单元及其正在处理的请求的潜在影响。如果某个工作负载使用 10 个单元来服务 100 个请求，则在发生故障时，总请求中有 90% 不会受故障的影响。
**常见反模式：**
+ 让单元无限制地发展。
+ 同时将代码更新或部署到所有单元。
+ 在不同单元之间共享状态或组件（路由器层除外）。
+ 向路由器层添加复杂的业务或路由逻辑。
+ 没有尽量减少跨单元交互。
**建立此最佳实践的好处：**借助基于单元的架构，许多常见类型的故障控制在单元本身，从而实现了额外的故障隔离。若出现难以控制的故障类型（例如不成功的代码部署，或者是受损或调用特定故障模式的请求，也称为*毒丸*请求），这些故障边界可以提供韧性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
在船舶上，隔板确保船体裂口控制在船体的一个区段内。在复杂的系统中，通常会复制此模式以实现故障隔离。故障隔离边界可将一个工作负载内的故障影响限制于有限数量的组件。边界之外的组件不受故障影响。通过使用多个故障隔离边界，您可以限制对工作负载的影响。在 AWS 中，客户可以使用多个可用区和区域来实现故障隔离，但故障隔离的概念也可以扩展到工作负载的架构。
整个工作负载是分区的单元，按分区键进行划分。这个键需要与服务的*粒度*，或者与使用最少的跨单元交互来细分服务工作负载的自然方式保持一致。分区键的示例包括客户 ID、资源 ID 或可以在大多数 API 调用中轻松访问的任何其他参数。单元路由层根据分区键将请求分发到单个单元，并向客户端提供单个端点。
![\[图中显示了基于单元的架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/cell-based-architecture.png)
**实施步骤**
在设计基于单元的架构时，需要考虑几个设计注意事项：
1. **分区键**：选择分区键时应考虑一些特别事项。
+ 分区键应与服务的粒度，或者与使用最少的跨单元交互来细分服务工作负载的自然方式保持一致。示例包括 `customer ID` 或 `resource ID`。
+ 在所有请求中都必须提供分区键，要么直接提供，要么通过很容易由其他参数确定地推断出来的方式提供。
1. **持久单元映射**：上游服务在其资源的生命周期内应只与单个单元交互。
+ 根据工作负载，可能需要使用单元迁移策略将数据从一个单元迁移到另一个单元。可能需要进行单元迁移的一种情况是：工作负载中的一个特定用户或资源变得太大，要求它具有专用的单元。
+ 单元之间不应该共享状态或组件。
+ 因此，应该避免或尽量减少跨单元交互，因为这些交互会在单元之间产生依赖关系，从而削弱故障隔离的改进。
1. **路由器层**：路由层是单元之间的共享组件，因此无法遵循与单元相同的分隔策略。
+ 建议路由器层使用分区映射算法以一种计算效率高的方式将请求分发到各个单元，例如结合加密哈希函数和模块化算法，将分区键映射到单元。
+ 为避免产生多单元影响，路由层必须尽可能保持简单和可横向扩展，这就需要在此层中避免出现复杂的业务逻辑。这还有一个额外的好处，即始终可以轻松地理解其预期行为，从而实现彻底的可测试性。正如 Colm MacCárthaigh 在《[Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)》一文中所说，简单的设计和持续工作模式可产生可靠的系统并降低抗脆弱性。
1. **单元大小**：单元大小应具有上限，不得发展到超过这个值。
+ 应通过执行彻底的测试来确定大小上限，直至达到临界点并建立安全的运营边际。有关如何实施测试实践的更多详细信息，请参阅 [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md)
+ 总体工作负载增长时应增加额外的单元，使得工作负载能够随着需求的增加而扩展。
1. **多可用区或多区域策略**：应利用多层韧性来防止出现不同的故障域。
+ 要实现韧性，应使用可构建防御层的方法。其中一层使用多可用区，通过构建高度可用的架构，防止出现较小规模、更常见的中断。另一个防御层用于防御很少发生的事件，例如大范围的自然灾害和区域级别的中断。这个第二层涉及到设计应用程序的架构来跨越多个 AWS 区域。为工作负载实施多区域策略，有助于防御影响到某个国家/地区中较大地理面积的大范围自然灾害，或者区域范围的技术故障。请注意，实施多区域架构会有很高的复杂性，对于大部分工作负载通常来说都是不必要的。有关更多详细信息，请参阅[REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)。
1. **代码部署**：交错的代码部署策略应该优于同时将代码更改部署到所有单元。
+ 这有助于最大限度地减少因部署不当或人为错误而导致多个单元出现故障。有关更多详细信息，请参阅[自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。
## 资源
**相关最佳实践：**
+ [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)
**相关文档：**
+ [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [使用随机分区进行工作负载隔离](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**相关视频：**
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience](https://www.youtube.com/watch?v=wUzSeSfu1XA)
# 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/)
# 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_non_functional.md)
+ [REL12-BP04 使用混沌工程测试韧性](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP05 定期进行 GameDay 活动](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 执行事后分析
审核影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，限制或防止再次发生同类事件。制定程序，以便迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。如果需要，可将这些原因告知他人。
评测为什么现有测试找不到问题。如果还没有，为此案例增设测试。
**期望结果：**您的团队采用一致且一致的方法来处理事后分析。一种机制是[错误更正（COE）流程](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)。COE 流程有助于您的团队识别、理解和解决事件的根本原因，同时还可以建立防护机制，以限制同一事件再次发生的可能性。
**常见反模式：**
+ 查找事件成因，但不继续深入探究其他潜在问题和缓解问题的方法。
+ 只找出人为错误原因，但不提供任何培训或可防止人为错误的自动化功能。
+ 只注重追究责任，而不去了解根本原因，营造恐惧文化，阻碍开诚布公的交流
+ 见解分享不畅，事件分析结果仅限于一小群人知道，其他人无法从中吸取经验教训
+ 没有收集制度性知识的机制，因此无法以最新最佳实践的形式保存经验教训，从而失去宝贵见解，导致根本原因相同或相似的事件反复发生
**建立此最佳实践的好处：**如果其他工作负载实施了相同的成因，执行事后分析并共享分析结果可帮助缓解这些工作负载的故障风险，让它们能够在事件发生之前实施缓解或自动恢复措施。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
有效的事后分析让您有机会针对系统中其他地方使用的架构模式存在的问题，提出常见的解决方案。
COE 流程的基础是记录和解决问题。建议定义一种标准化的方法来记录关键的根本原因，并确保其得到分析和处理。为事后分析流程分配明确的责任人。指派负责的团队或个人来监督事件调查和后续行动。
鼓励注重学习和改进而不是互相推脱责任的文化。强调目标是防止将来发生事件，而不是惩罚某些人。
为执行事后分析制定明确定义的程序。这些程序应概述要采取的步骤、要收集的信息以及在分析期间要解决的关键问题。彻底调查事件，除直接原因外，还要找出根本原因和成因。使用诸如*[五个为什么](https://en.wikipedia.org/wiki/Five_whys)*之类的技巧来深入研究潜在问题。
维护从事件分析中吸取的经验教训的存储库。这些制度性知识可以作为未来的事件和预防工作的参考。分享在事后分析中发现的结果和洞察，并考虑召开公开的事后审查会议，讨论经验教训。
### 实施步骤
+ 在执行事后分析时，确保整个过程不是以追究责任为目的。这使事件中涉及到的人员能够冷静地看待建议的纠正措施，并促进诚实的自我评测和团队间的协作。
+ 定义记录关键问题的标准化方法。此类文档的示例结构如下所示：
+ 发生了什么？
+ 客户和您的业务受到了什么影响？
+ 根本原因是什么？
+ 您有哪些数据来支持这一点？
+ 例如，指标和图表
+ 对关键支柱有什么影响，特别是在安全方面？
+ 在构造工作负载时，您需要基于业务环境在各个支柱之间做出权衡。这些业务决策可以推动您的工程优先事务。在开发环境中，您可能会通过降低可靠性来降低成本；而对于任务关键型解决方案，您可能会通过增加成本来提高可靠性。安全始终是头等大事，因为您必须保护您的客户。
+ 您获得了哪些经验教训？
+ 您采取了哪些纠正措施？
+ 操作项
+ 相关术语
+ 为执行事后分析制定明确定义的标准操作程序。
+ 设置标准化事件报告流程。全面记录所有事件，包括最初的事件报告、日志、通信和事件期间采取的行动。
+ 请记住，并不是发生了停机才叫做事件。这可能是未遂事件，也可能是系统能够履行其业务功能，但以意外的方式运行。
+ 根据反馈和经验教训，持续改进事后分析流程。
+ 在知识管理系统中记录关键调查发现，并考虑应添加到开发人员指南或部署前清单中的任何模式。
## 资源
**相关文档：**
+ [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
**相关视频：**
+ [Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders' Library: Operational Excellence at Amazon](https://www.youtube.com/watch?v=7MrD4VSLC_w)
# REL12-BP03 测试可扩展性和性能要求
使用负载测试等技术来验证工作负载是否满足扩展和性能要求。
在云中，可以按需为工作负载创建生产规模测试环境。可以使用云来预置一个与预期生产环境非常接近的测试环境，而不是依赖于缩减的测试环境（这可能会导致对生产行为的预测不准确）。此环境有助于您更准确地模拟应用程序面临的现实世界条件来进行测试。
除了性能测试工作外，还务必验证基础资源、扩展设置、服务配额和韧性设计在负载之下是否按预期运行。这种整体方法验证应用程序可根据需要可靠地扩展和执行，即使在最苛刻的条件下也不例外。
**期望结果：**即使在峰值负载下，工作负载也会保持其预期的行为。您可以主动解决随着应用程序发展和演变而可能出现的任何与性能有关的问题。
**常见反模式：**
+ 您使用的测试环境与生产环境不太匹配。
+ 您将负载测试视为单独的一次性活动，而不是部署持续集成（CI）管道不可或缺的部分。
+ 您没有定义明确且可衡量的性能要求，例如响应时间、吞吐量和可扩展性目标。
+ 您在不切实际或负载不足的情况下执行测试，并且无法针对峰值负载、突然激增和持续高负载进行测试。
+ 您没有通过超出预期的负载限制来对工作负载进行压力测试。
+ 您使用了不充分或不适当的负载测试和性能分析工具。
+ 您缺乏全面的监控和警报系统来跟踪性能指标和检测异常情况。
**建立此最佳实践的好处：**
+ 负载测试有助于您在系统投入生产之前识别其潜在的性能瓶颈。在模拟生产级流量和工作负载时，您可以确定系统可能难以处理负载的领域，例如响应时间慢、资源限制或系统故障。
+ 当您在各种负载条件下测试系统时，可以更好地了解支持工作负载所需的资源需求。这些信息有助于您在资源分配方面做出明智的决策，并防止资源过度配置或配置不足。
+ 要识别潜在的故障点，您可以观察工作负载在高负载条件下的性能。这些信息有助于您通过酌情实施容错机制、失效转移策略和冗余措施，来提高工作负载的可靠性和韧性。
+ 您可以尽早发现并解决性能问题，这有助于避免系统中断、响应时间缓慢和用户不满意所带来的代价高昂的后果。
+ 在测试期间收集的详细性能数据和分析信息有助于您排查生产环境中可能出现的与性能相关的问题。这可以加快事件响应和解决速度，从而减少对用户和组织运营的影响。
+ 在某些行业，主动性能测试有助于工作负载达到合规标准，从而降低受处罚或出现法律问题的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
第一步是定义全面的测试策略，该策略涵盖扩展和性能要求的各个方面。首先，根据业务需求（例如吞吐量、延迟直方图和错误率），明确定义工作负载的服务级别目标（SLO）。接下来，设计一套测试来模拟各种负载场景，范围涵盖从平均使用量到突然激增和持续的峰值负载，并验证工作负载的行为是否符合 SLO。这些测试应自动执行，并集成到持续集成和部署管道中，以便在开发过程的早期阶段发现性能回归情况。
要有效地测试扩展和性能，请投资购买正确的工具和基础设施。这包括可以生成真实用户流量的负载测试工具、用于识别瓶颈的性能分析工具以及用于跟踪关键指标的监控解决方案。重要的是，您应该验证测试环境在基础设施和环境条件方面是否与生产环境紧密匹配，以使您的测试结果尽可能准确。为了更轻松且可靠地复制和扩展类似于生产环境的设置，请使用基础设施即代码和基于容器的应用程序。
扩展和性能测试是一个持续的过程，而不是一次性活动。实施全面的监控和警报来跟踪应用程序在生产环境中的性能，并使用这些数据来不断完善测试策略和优化工作。定期分析性能数据来识别新出现的问题，测试新的扩展策略，并实施优化以提高应用程序的效率和可靠性。当您采用迭代方法并不断从生产数据中学习时，可以验证应用程序是否能够适应不断变化的用户需求，并随着时间的推移保持韧性和最佳性能。
### 实施步骤
1. 制定明确且可衡量的性能要求，例如响应时间、吞吐量和可扩展性目标。这些要求应基于工作负载的使用规律、用户预期和业务需求。
1. 选择并配置负载测试工具，该工具可以准确地模仿生产环境中的负载规律和用户行为。
1. 设置与生产环境（包括基础设施和环境条件）紧密匹配的测试环境，来提高测试结果的准确性。
1. 创建涵盖各种场景的测试套件，范围从平均使用规律到峰值负载、快速激增和持续的高负载。将测试集成到持续集成和部署管道中，以便在开发过程的早期阶段发现性能回归情况。
1. 开展负载测试来模拟真实的用户流量，并了解应用程序在不同负载条件下的行为。要对应用程序进行压力测试，请超出预期负载并观察其行为，例如响应时间降级、资源耗尽或系统故障，这有助于确定应用程序的突破点并为扩展策略提供信息。通过逐步增加负载来评估工作负载的可扩展性，并衡量性能影响，来确定扩展限制并规划未来的容量需求。
1. 实施全面的监控和警报，来跟踪性能指标，检测异常，并在超过阈值时启动扩展操作或通知。
1. 持续监控和分析性能数据，来确定需要改进的领域。对测试策略和优化工作进行迭代。
## 资源
**相关最佳实践：**
+ [REL01-BP04 监控和管理配额](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 发送通知（实时处理和报警）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
**相关文档：**
+ [加载测试应用程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)
+ [AWS 上的分布式负载测试](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
+ [应用程序性能监控](https://aws.amazon.com/what-is/application-performance-monitoring/)
+ [Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/)
**相关示例：**
+ [Distributed Load Testing on AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws)
**相关工具：**
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Apache JMeter](https://jmeter.apache.org/)
+ [K6](https://k6.io/)
+ [Vegeta](https://github.com/tsenart/vegeta)
+ [Hey](https://github.com/rakyll/hey)
+ [ab](https://httpd.apache.org/docs/2.4/programs/ab.html)
+ [wrk](https://github.com/wg/wrk)
+ [AWS 上的分布式负载测试](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# REL12-BP04 使用混沌工程测试韧性
在生产环境中或尽可能接近生产的环境中定期运行混沌试验，了解系统如何应对不利条件。
**期望结果：**
除了在事件期间验证已知预期工作负载行为的韧性测试之外，还可以通过以故障注入实验或注入意外负载的形式应用混沌工程，定期验证工作负载的韧性。将混沌工程和韧性测试结合起来，这可以让您提升信心，相信工作负载能够经受组件故障，并可从意外中断中恢复，而影响极小甚至没有影响。
**常见反模式：**
+ 进行韧性设计，但不验证故障发生时工作负载如何作为一个整体运行。
+ 从不在真实环境和预期负载下进行试验。
+ 不将实验视为代码，也不在整个开发周期中维护实验。
+ 不将混沌实验作为 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 是在混沌工程 GameDay 活动期间使用的一个不错选择。该服务支持在不同类型的资源中同时引入故障，包括 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/latest/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 故障对容器组的 CPU 运行压力测试，同时使用 AWS FIS 故障操作终止随机选择的集群节点百分比。
## 实施步骤
1. 确定哪些故障要用于实验。
评测工作负载的设计是否具有韧性。这种设计使用 [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) 的最佳实践创建，考虑到了基于关键依赖项、以往事件、已知问题以及合规性要求的风险。列出每个旨在保持韧性的设计元素及其旨在缓解的故障。有关创建此类列表的更多信息，请参阅《[Operational Readiness Review](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。
1. 为每个故障指定一个优先级。
先进行粗略的分类，如高、中或低。要评测优先级，请考虑故障的频率和故障对整体工作负载的影响。
考虑给定故障的频率时，请分析此工作负载的以往数据（如有）。如果没有以往数据，则使用在类似环境中运行的其他工作负载的数据。
考虑给定故障的影响时，故障的范围越大，影响通常也越大。还要考虑工作负载设计和目的。例如，访问源数据存储的能力对于进行数据转换和分析的工作负载至关重要。在这种情况下，您要确定访问故障以及节流访问和延迟插入等实验的优先级。
事件后分析是了解故障模式的频率和影响的良好数据来源。
使用指定的优先级来确定首先对哪些故障进行实验，以及开发新的故障注入实验的顺序。
1. 对于执行的每项实验，请遵循下图中的混沌工程和持续韧性飞轮。
![\[混沌工程和持续韧性飞轮图，显示了“改进”、“稳定状态”、“假设”、“进行实验”和“验证”阶段。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/chaos-engineering-flywheel.png)
1. 将稳定状态定义为指示正常行为的工作负载的一些可测量输出。
如果工作负载运行可靠且符合预期，则显示为稳定状态。因此，定义稳定状态之前，请验证工作负载是否运行状况良好。稳定状态并不一定意味着故障发生时对工作负载没有影响，因为一定百分比的故障可能在可接受的范围内。稳定状态是您将在实验期间观察到的基线，如果下一步中定义的假设结果不符合预期，则会突出显示异常。
例如，可以将某个支付系统的稳定状态定义为处理 300 TPS，成功率为 99%，且往返时间为 500 毫秒。
1. 形成一个关于工作负载如何应对故障的假设。
一个好的假设是基于工作负载预计如何缓解故障来保持稳定状态。该假设指出，如果发生特定类型的故障，系统或工作负载将继续保持稳定状态，因为该工作负载在设计时就有特定缓解措施。应在假设中具体说明特定的故障类型和缓解措施。
假设可以使用以下模板（但其他措辞也可以接受）：
**注意**
如果发生*具体故障*，则*工作负载名称*工作负载将*描述缓解控制措施*，以此维持*业务或技术指标影响*。
例如：
+ 如果 Amazon EKS 节点组中 20% 的节点出现故障，则 Transaction Create API 将在不到 100 毫秒的时间内继续处理 99% 的请求（稳定状态）。Amazon EKS 节点将在五分钟内恢复，容器组将在实验开始后八分钟内得到调度并处理流量。警报将在三分钟内发出。
+ 如果单个 Amazon EC2 实例发生故障，订单系统的弹性负载均衡运行状况检查会让弹性负载均衡仅向剩余的运行状况良好的实例发送请求，而 Amazon EC2 Auto Scaling 将替换故障实例，从而保持服务器端（5xx）错误增长率低于 0.01%（稳定状态）。
+ 如果主 Amazon RDS 数据库实例发生故障，则供应链数据收集工作负载将失效转移并连接到备用 Amazon RDS 数据库实例，以保持不到 1 分钟的数据库读写错误（稳定状态）。
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 的实验，另请参阅 [Resilient and Well-Architected Apps with Chaos Engineering 实验室](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)在生产环境中进行实验，尽可能同时启动控制和实验系统部署。在非高峰时间进行实验是一种很好的做法，可以减小首次在生产环境中试验时的潜在影响。此外，如果使用实际的客户流量会带来太大的风险，您可以在生产基础设施上针对控制和实验部署使用合成流量进行实验。当不能使用生产环境时，在尽可能接近生产环境的预生产环境中进行实验。
您必须建立和监控防护机制，确保实验对生产流量或其他系统的影响不会超过可接受的限度。建立停止条件，以便在实验达到您定义的防护机制指标的阈值时停止实验。这应该包括工作负载的稳定状态指标，以及针对您要注入故障的组件的指标。[综合监控](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）还是手动执行，这些后期操作都应包含在描述如何检测和处理故障的行动手册中。
1. 验证假设。
[混沌工程原则](https://principlesofchaos.org/)为如何验证工作负载的稳定状态提供了以下指导：
关注系统的可测量输出，而不是系统的内部属性。短时间内对该输出的测量构成了系统稳态的代理。整个系统的吞吐量、错误率和延迟百分比都可以是代表稳态行为的相关指标。通过关注实验过程中的系统行为模式，混沌工程验证系统确实在工作，而不是试图验证它如何工作。
在之前的两个示例中，我们包括了服务器端（5xx）错误增长率低于 0.01% 和数据库读写错误持续时间不到 1 分钟的稳态指标。
5xx 错误是一个很好的指标，因为此类错误是工作负载客户端会直接经历的故障模式的结果。数据库错误测量适合作为故障的直接结果，但是还应补充一个客户端影响测量，例如失败的客户请求或向客户端显示的错误。此外，在工作负载客户端直接访问的任何 API 或 URI 上包含一个综合监控（也称为用户金丝雀）。
1. 改进工作负载设计，提高韧性。
如果未保持稳定状态，则调查如何改进工作负载设计来缓解故障，并应用 [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/)的文章，等等。
实施这些更改后，再次进行实验（如混沌工程飞轮中的虚线所示），确定更改的效果。如果验证步骤表明假设成立，则工作负载将处于稳定状态，循环将继续。
1. 定期进行实验。
混沌实验是一个循环，作为混沌工程的一部分，应定期进行实验。在工作负载满足实验的假设后，实验应实现自动化，作为 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)的实验室让您能够动手实践。
故障注入实验也是 GameDay 活动的一部分（请参阅 [REL12-BP05 定期进行 GameDay 活动](rel_testing_resiliency_game_days_resiliency.md)）。GameDay 活动会模拟故障或事件，以便验证系统、流程和团队的响应。其目的是实际执行团队在发生意外事件时会执行的操作。
1. 捕获和存储实验结果。
必须捕获并持久保存故障注入实验的结果。包括所有必要的数据（如时间、工作负载和条件），以便以后能够分析实验结果和趋势。结果示例可能包括控制面板的屏幕截图、从指标数据库进行的 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/)
+ [Chaos Engineering: Planning your first experiment](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure](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: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**相关工具：**
+ [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-BP05 定期进行 GameDay 活动
安排 GameDay 来定期练习旨在应对影响工作负载的事件和损害的过程。让负责处理生产场景的团队参与进来。这些练习有助于强制实施相关措施，来防止生产事件对用户造成影响。当您在现实条件下实践响应过程时，可以在实际事件发生之前发现并解决任何差距或弱点。
GameDay 活动会模拟类似于生产的环境中的事件，以便测试系统、流程和团队的响应。其目的是执行团队在实际发生事件时会执行的相同操作。这些练习有助于您了解可以从哪些方面作出改进，并有助于培养组织在处理各种事件和损害方面的经验。这些练习应该定期开展，这样，团队就知道如何建立根深蒂固的应对习惯。
GameDay 可让团队做好准备，以便更充满信心地处理生产事件。经过良好练习的团队更有能力快速检测和应对各种场景。这可以显著改善就绪状态和韧性态势。
**期望结果：**您在一致、有计划的基础上运行韧性 GameDay。这些 GameDay 被视为业务运营中正常和预期的组成部分。您的组织已经建立了备灾文化，当出现生产问题时，团队已经做好了充分的准备，可以有效地做出响应，高效地解决问题并减轻对客户的影响。
**常见反模式：**
+ 您记录过程，但从不练习这些过程。
+ 您不让业务决策者参与测试练习。
+ 您开展了 GameDay，但没有通知所有相关的利益相关者。
+ 您只关注技术故障，但不涉及业务利益相关者。
+ 您未将从 GameDay 中吸取的经验教训纳入恢复过程。
+ 您将失败或错误归咎于团队。
**建立此最佳实践的好处：**
+ 增强响应技能：在 GameDay，团队在模拟的事件中练习其职责并测试其沟通机制，从而在生产环境中做出更加协调和高效的响应。
+ 识别和解决依赖关系：复杂的环境通常涉及各种系统、服务和组件之间错综复杂的依赖关系。GameDay 有助于您识别和解决这些依赖关系，并验证运行手册过程是否正确涵盖了关键系统和服务，以及是否可以及时纵向扩展或恢复这类系统和服务。
+ 培养韧性文化：GameDay 有助于培养组织内部的韧性思维。当您让跨职能团队和利益相关者参与时，这些练习可以提高整个组织对韧性重要性的认识、协作和共同理解。
+ 持续改进和适应：定期的 GameDay 有助于您不断评测和调整韧性策略，从而使这些策略在不断变化的环境中保持相关性和有效性。
+ 增强对系统的信心：成功的 GameDay 有助于您树立信心，确信系统能够承受中断并从中恢复。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
设计并实施了必要的韧性措施后，请开展 GameDay 来验证生产中的一切是否按计划进行。GameDay，尤其是第一个 GameDay，应让所有团队成员都参与，并应事先向所有利益相关者和参与者告知日期、时间和模拟场景。
在 GameDay 期间，参与的团队会根据规定的过程模拟各种事件和潜在的场景。参与者密切监控和评测这些模拟事件的影响。如果系统按设计运行，则应激活自动检测、扩展和自我修复机制，且对用户几乎没有影响。如果团队观察到任何负面影响，他们就会回滚测试，并通过相应运行手册中记载的自动手段或手动干预来纠正已发现的问题。
要持续提高韧性，记录和吸取经验教训至关重要。该过程是一个*反馈循环*，它系统化地从 GameDay 捕获见解，并使用这些见解来增强系统、流程和团队能力。
为协助您重现系统组件或服务可能意外出现故障的现实场景，请将模拟故障作为 GameDay 练习注入。团队可以在受控的环境中测试其系统的韧性和容错能力，并模拟其事件响应和恢复流程。
借助 AWS，可以使用基础设施即代码，通过生产环境的副本来开展 GameDay。通过此过程，可以在与生产环境非常相似的安全环境中进行测试。考虑使用 [AWS Fault Injection Service](https://aws.amazon.com/fis/)来创建不同的故障场景。使用诸如 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 之类的服务来监控 GameDay 期间的系统行为。使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 来管理和运行行动手册，并使用 [AWS Step Functions](https://aws.amazon.com/step-functions/) 来编排重复出现的 GameDay 工作流程。
### 实施步骤
+ **制定 GameDay 计划：**制定结构化计划来定义 GameDay 的频率、范围和目标。让关键利益相关者和主题专家参与规划和实施这些练习。
+ **为 GameDay 做好准备：**
1. 确定主要的业务关键服务，这些服务是 GameDay 的重点。对支持这些服务的人员、流程和技术进行编目和映射。
1. 制定 GameDay 的日程，让相关团队做好参与事件的准备。准备好自动化服务来模拟计划的场景并运行相应的恢复流程。诸如 [AWS Fault Injection Service](https://aws.amazon.com/fis/)、[AWS Step Functions](https://aws.amazon.com/step-functions/) 和 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 等 AWS 服务有助于您自动实施 GameDay 的各个方面，例如注入故障和启动恢复操作。
+ **运行模拟：**在 GameDay，运行计划的场景。观察并记录人员、流程和技术对模拟事件的反应。
+ **开展练习后回顾：**GameDay 结束后，召开回顾会议来回顾所吸取的教训。确定需要改进的领域以及改善运营韧性所需的任何措施。记录您的调查发现，并跟踪任何必要的更改，来增强韧性策略和完成准备工作。
## 资源
**相关最佳实践：**
+ [REL12-BP01 使用行动手册调查故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL12-BP04 使用混沌工程测试韧性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
+ [OPS04-BP01 确定关键绩效指标](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
**相关文档：**
+ [什么是 AWS GameDay？](https://aws.amazon.com/gameday/)
**相关视频：**
+ [AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s)
**相关示例：**
+ [AWS Workshop - Navigate the storm: Unleashing controlled chaos for resilient systems](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97)
+ [Build Your Own Game Day to Support Operational Resilience](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)
# REL 13. 如何规划灾难恢复（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 管理灾难恢复站点或区域的配置偏差](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 自动执行恢复](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 定义停机和数据丢失的恢复目标
故障可通过多种方式影响您的业务。首先，故障可能导致服务中断（停机时间）。其次，故障可能导致数据丢失、不一致或过时。为了指导您如何应对故障和从故障中恢复，请为每个工作负载定义恢复时间目标（RTO）和恢复点目标（RPO）。*恢复时间目标（RTO）*是指服务中断和恢复服务之间可接受的最大延迟。*恢复点目标（RPO）*是指在上一个数据恢复点之后可接受的最长时间。
**期望结果：**根据技术考虑和业务影响，每个工作负载都有指定的 RTO 和 RPO。
**常见反模式：**
+ 您尚未指定恢复目标。
+ 您选择任意的恢复目标。
+ 您选择的恢复目标过于宽松并且不符合业务目标。
+ 您尚未评估停机时间和数据丢失的影响。
+ 您选择不切实际的恢复目标，如零恢复时间或零数据丢失，这对工作负载配置而言可能无法实现。
+ 您选择的恢复目标比实际业务目标更苛刻。这会迫使实施恢复的成本和复杂度超出工作负载所需。
+ 您选择的恢复目标与相关工作负载的恢复目标不兼容。
+ 您没有考虑监管和合规要求。
**建立此最佳实践的好处：**在为工作负载设置 RTO 和 RPO 时，可以根据业务需求制定明确且可衡量的恢复目标。一旦设定了这些目标，就可以创建专为实现这些目标而量身定制的灾难恢复（DR）计划。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
构造一个矩阵或工作表，来协助指导灾难恢复规划。在矩阵中，创建不同的工作负载类别或层级，所依据的是这些类别或层级的业务影响（例如严重、高、中和低），以及每个工作负载类别或层级关联的目标 RTO 和 RPO。以下矩阵提供了您可以遵循的示例（请注意，RTO 和 RPO 值可能有所不同）：
![\[图中显示了灾难恢复矩阵\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)
对于每个工作负载，调查和了解停机时间和数据丢失对业务的影响。影响通常会随着停机时间和数据丢失而增加，但影响的形式可能会因工作负载类型而异。例如，长达一小时的停机时间可能影响很小，但在一小时之后，影响可能会迅速加剧。影响可能以多种形式呈现，包括财务影响（如收入损失）、声誉影响（包括失去客户信任）、运营影响（如错过工资发放或生产率下降）和监管风险。完成后，将工作负载分配到相应的层级。
分析故障所产生的影响时，请考虑以下问题：
1. 在对业务产生不可接受的影响之前，工作负载可以保持不可用的最长时间是多少？
1. 工作负载中断将对业务产生多大影响以及会产生什么样的影响？ 考虑各种影响，包括财务、声誉、运营和监管。
1. 在对业务造成不可接受的影响之前，可以丢失或无法恢复的最大数据量是多少？
1. 能否从其它来源重新创建丢失的数据（也称为*派生的* 数据）？ 如果是，还要考虑用于重新创建工作负载数据的所有源数据的 RPO。
1. 此工作负载所依赖的工作负载（下游）的恢复目标和可用性期望是什么？ 根据工作负载下游依赖关系的恢复能力，工作负载的目标必须是可实现的。考虑可能的下游依赖关系解决办法或缓解措施，以提高此工作负载的恢复能力。
1. 依赖于此工作负载的工作负载（上游）的恢复目标和可用性期望是什么？ 上游工作负载目标可能要求此工作负载具有比最初看起来更严格的恢复能力。
1. 根据事件的类型，是否有不同的恢复目标？ 例如，根据事件影响的是一个可用区还是整个区域，您可能有不同的 RTO 和 RPO。
1. 恢复目标在一年中的某些事件或时期是否会发生变化？ 例如，在假日购物季、体育赛事、特别促销和新产品发布期间，您可能有不同的 RTO 和 RPO。
1. 恢复目标如何与您可能拥有的任何业务线和组织灾难恢复策略保持一致？
1. 是否需要考虑法律或合同后果？ 例如，根据合同，您是否有义务提供具有给定 RTO 或 RPO 的服务？ 不履行这些义务会受到什么处罚？
1. 您是否需要维护数据完整性来满足监管或合规性要求？
以下工作表有助于您评估每项工作负载。您可以修改此工作表来满足具体的需求，例如添加附加问题。
![\[工作表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/worksheet.png)
### 实施步骤
1. 确定业务利益相关方和负责每个工作负载的技术团队，并与他们互动。
1. 对组织中的工作负载影响创建严重性类别或层级。类别示例包括：严重、高、中和低。对于每个类别，请选择反映您的业务目标和要求的 RTO 和 RPO。
1. 将您在上一步创建的影响类别之一分配给每个工作负载。要决定工作负载如何映射到某个类别，请考虑工作负载对业务的重要性，以及中断或数据丢失的影响，并使用上述问题来提供指导。这将为每个工作负载生成一个 RTO 和 RPO。
1. 考虑上一步中确定的每个工作负载的 RTO 和 RPO。让工作负载的业务和技术团队参与进来，以确定是否应调整目标。例如，业务利益相关者可能确定需要更严格的目标。或者，技术团队可能决定应修改目标，以使这些目标能够在可用的资源和技术限制下得以实现。
## 资源
**相关最佳实践：**
+ [REL09-BP04 定期执行数据恢复以验证备份完整性和流程](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 使用行动手册调查故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**相关文档：**
+ [AWS Architecture Blog: Disaster Recovery](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)
+ [Managing resiliency policies with AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 合作伙伴：可帮助进行灾难恢复的合作伙伴](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: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [ 上工作负载的灾难恢复AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 使用定义的恢复策略来实现恢复目标
定义可满足工作负载恢复目标的灾难恢复（DR）策略。选择一种策略，例如备份和还原、备用（主动/被动）或主动/主动。
**期望结果：**每个工作负载都有已定义且实施的灾难恢复策略，可让该工作负载实现灾难恢复目标。工作负载之间的灾难恢复策略利用可重用模式（例如前面所述的策略）。
**常见反模式：**
+ 为具有类似灾难恢复目标的工作负载实施不一致的恢复过程。
+ 在发生灾难时临时实施灾难恢复策略。
+ 没有针对灾难恢复的计划。
+ 恢复期间依赖于控制面板操作。
**建立此最佳实践的好处：**
+ 通过定义恢复策略，您可以使用常用工具和测试步骤。
+ 使用定义的恢复策略可改善团队之间的知识共享情况，并在他们自己的工作负载上实施灾难恢复。
**在未建立这种最佳实践的情况下暴露的风险等级：**高。若没有经过计划、实施和测试的灾难恢复策略，发生灾难时就不太可能实现恢复目标。
## 实施指导
灾难恢复策略依赖于在主位置无法运行工作负载的情况下，在恢复站点中支持工作负载的能力。最常见的恢复目标是 RTO 和 RPO，如 [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md)中所述。
跨单个 AWS 区域内的多个可用区（AZ）的灾难恢复策略可以缓解火灾、洪水和重大停电等灾难事件造成的影响。如果需要实施保护措施，为工作负载无法在给定 AWS 区域中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的灾难恢复策略。
在跨多个区域构建灾难恢复策略时，您应该选择以下某个策略。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。*恢复区域*指的是 AWS 区域，而不是用于工作负载的主要区域。
![\[图中显示了灾难恢复策略\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/disaster-recovery-strategies.png)
+ **备份和还原**（RPO 以小时为单位，RTO 为 24 小时或更短时间为单位）：将数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复（PITR），在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。
+ **指示灯**（RPO 以分钟为单位，RTO 以数十分钟为单位）：在恢复区域中预置核心工作负载基础设施的副本。将数据复制到恢复区域并在其中创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。
+ **温备用**（RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速纵向扩展来处理生产负载。温备用的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为*热备用*。
+ **多区域（多站点）主动-主动**（RPO 接近于零，RTO 可能为零）：工作负载部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，因为这种情况很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。
**注意**
指示灯和温备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而温备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而温备用只需要您纵向扩展（所有内容都已部署并运行）。根据 RTO 和 RPO 需求在两者之间进行选择。
如果需要考虑成本，并且希望实现与温备用策略中定义的类似 RPO 和 RTO 目标时，您可以考虑云原生解决方案（例如 AWS Elastic Disaster Recovery），此类解决方案会采用指示灯方法并提供改进的 RPO 和 RTO 目标。
**实施步骤**
1. **确定可满足此工作负载恢复要求的灾难恢复策略。**
选择灾难恢复策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。
例如，在下图中，企业已经确定了自己允许的最大 RTO 以及可在服务恢复策略上花费的费用限额。考虑到企业目标，指示灯或温备用这样的灾难恢复策略将同时满足 RTO 和成本标准。
![\[图中显示了根据 RTO 和成本选择灾难恢复策略\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/choosing-a-dr-strategy.png)
如需了解更多信息，请参阅[业务连续性计划（BCP）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。
1. **查看如何实施所选灾难恢复策略的模式。**
这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为灾难恢复策略，这将利用多个策略的元素。
在后续步骤中，您可以对特定的工作负载应用策略。
**备份和还原**
*备份和还原*是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（例如另一个 AWS 区域）。
![\[图中显示了备份和还原架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/backup-restore-architecture.png)
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](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/latest/framework/images/pilot-light-architecture.png)
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](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/latest/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)可以提供运行时环境，以便这些环境准备好立即响应函数的调用。
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)》。
**多站点主动/主动**
作为*多站点主动/主动*策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于灾难恢复以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）时使用此策略。作为一种灾难恢复策略，如果工作负载在部署此策略的某个 AWS 区域中不能得到支持，那么该区域将被撤出，使用其余区域维持可用性。多站点主动/主动策略是灾难恢复策略中操作最复杂的策略，只有在业务要求需要时才应选择它。
![\[图中显示了多站点主动/主动架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/multi-site-active-active-architecture.png)
有关此策略的更多详细信息，请参阅《[Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)》。
**AWS Elastic Disaster Recovery**
如果您正考虑为灾难恢复使用指示灯或温备用策略，AWS Elastic Disaster Recovery 可以提供一种带来更多好处的替代方法。弹性灾难恢复可以提供类似于温备用方法的 RPO 和 RTO 目标，同时保持指示灯方法的低成本。弹性灾难恢复将数据从主区域复制到恢复区域，使用持续数据保护来实现以秒为单位的 RPO 和以分钟为单位的 RTO。在恢复区域中仅部署复制数据所需的资源，从而降低成本，类似于指示灯策略。使用弹性灾难恢复时，如果在失效转移或演练过程中启动，则服务会协调并编排计算资源的恢复。
![\[架构图说明了 AWS Elastic Disaster Recovery 的运作方式。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/drs-architecture.png)
**其他保护数据的实践**
对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。
**使用单个 AWS 区域内的多个可用区（AZ）**
使用单个区域内的多个可用区时，实施灾难恢复会用到上述策略的多个元素。首先，您必须使用多个可用区创建一个高可用性（HA）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 [Amazon EC2 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)和[弹性负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones)在多个可用区中部署了资源，主动处理请求。此架构还演示了热备用方法，如果主 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 实例出现故障（或可用区本身出现故障），则备用实例将提升为主实例。
![\[图中显示了多可用区架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/multi-az-architecture2.png)
除了这种高可用性架构，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 [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)。如果一个可用区发生故障，您需要将这些数据恢复到另一个可用区。如果可能，您还应该将数据备份复制到另一个 AWS 区域，提供另一层保护。
下面的博客文章中介绍了一种不太常见的单区域多可用区灾难恢复的替代方法：[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/)。这里的策略是尽可能保持可用区之间的隔离，就像区域的运作方式一样。使用这种替代策略，您可以选择主动/主动或主动/被动方法。
**注意**
某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 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)，您可以通过[单个模板](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)控制部署的堆栈处于活动状态还是备用状态。使用弹性灾难恢复时，服务会复制并编排应用程序配置和计算资源的还原。
所有灾难恢复策略都要求在 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 服务如何跨区域运行的信息，请参阅博客系列文章《[Creating a Multi-Region Application with AWS Services](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 应用程序恢复控制器](https://aws.amazon.com/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 Global Database](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 全局数据库的现有复制拓扑。因此，主区域中以前的读/写实例将成为副本，并从恢复区域接收更新。
如果这不是自动执行的，则需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。
失效转移后，如果可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。
失效转移和失效自动恢复所需的所有步骤都应保存在行动手册中且可供所有团队成员使用，并定期接受审查。
使用弹性灾难恢复时，服务会协助编排并自动执行失效自动恢复流程。有关更多详细信息，请参阅 [Performing a failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html)。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [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 Architecture Blog: Disaster Recovery](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)
+ [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded](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: Configuring DNS Failover](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)
+ [What is Amazon 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: Get Started - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN 合作伙伴：可帮助进行灾难恢复的合作伙伴](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: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
# REL13-BP03 测试灾难恢复实施以验证实施效果
定期测试到恢复站点的失效转移，验证是否在正常运作，以及是否满足 RTO 和 RPO。
**常见反模式：**
+ 从不在生产环境中进行失效转移演练。
**建立此最佳实践的好处：**定期测试灾难恢复计划，验证计划在需要时能否正常发挥作用，以及团队是否知道如何执行策略。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要避免的模式是制定了恢复路径但很少测试。例如，您可能有一个用于只读查询的辅助数据存储。在写入某个数据存储，却发现主存储故障时，您可能希望失效转移到辅助数据存储。如果不经常测试此失效转移，您可能会发现自己关于辅助数据存储容量的假设是错误的。辅助数据存储容量在上次测试时可能是足够的，但可能无法再容纳这次情况下的负载。根据我们的经验，唯一有效的错误恢复路径是您经常测试的路径。因此，最好只制定几条恢复路径。您可以建立恢复模式并定期对其进行测试。如果恢复路径比较复杂或至关重要，您仍需定期在生产环境中测试该故障，确保恢复路径有效。在我们刚才讨论的示例中，您应该定期将故障转移到备用存储，无论是否有需要。
**实施步骤**
1. 为灾难恢复设计工作负载。定期测试恢复路径。面向恢复的计算可识别系统中能够增强恢复功能的特性：隔离和冗余，系统范围回滚更改的能力，监控并确定运行状况的能力，提供诊断、自动恢复、模块化设计的能力，以及重启的能力。对恢复路径进行演练，确认可以在指定时间内恢复到指定状态。在此恢复过程中使用运行手册来记录问题，并在下一次测试之前找到问题的解决方案。
1. 对于基于 Amazon EC2 的工作负载，使用 [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 为灾难恢复策略实施和启动演练实例。AWS Elastic Disaster Recovery 可以高效地运行演练，帮助您为失效转移事件做好准备。您还可以使用弹性灾难恢复频繁地启动实例进行测试和演练，无需重定向流量。
## 资源
**相关文档：**
+ [APN 合作伙伴：可帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Architecture Blog: Disaster Recovery](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 系列博客文章
+ [AWS Marketplace：可用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Elastic Disaster Recovery 为失效转移做准备](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [The Berkeley/Stanford recovery-oriented computing project](http://roc.cs.berkeley.edu/)
+ [What is AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相关视频：**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 管理灾难恢复站点或区域的配置偏差
为了成功执行灾难恢复（DR）过程，一旦灾难恢复环境上线，工作负载就必须能够及时恢复正常操作，而不会丢失相关的功能或数据。要实现这一目标，务必在灾难恢复环境和主环境之间保持一致的基础设施、数据和配置。
**期望结果：**灾难恢复站点的配置和数据与主站点相当，这有助于在需要时进行快速而完整的恢复。
**常见反模式：**
+ 当对主位置进行更改时，您未能更新恢复位置，这导致配置过时，从而阻碍恢复工作。
+ 您未考虑潜在的限制，例如主位置和恢复位置之间的服务差异，这些限制可能会在失效转移期间导致意外故障。
+ 您依赖手动流程来更新和同步灾难恢复环境，这会增加人为错误和不一致的风险。
+ 您未能检测到配置偏差，这会导致在事件发生之前错误地感知灾难恢复站点就绪状态。
**建立此最佳实践的好处：**灾难恢复环境和主环境之间的一致性可显著提高事件发生后成功恢复的可能性，并降低恢复过程失败的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
全面的配置管理和失效转移就绪方法有助于您验证灾难恢复站点是否持续更新，并准备好在主站点出现故障时进行接管。
要实现主环境和灾难恢复（DR）环境之间的一致性，请验证您的交付管道是否同时将应用程序分发到主站点和灾难恢复站点。在适当的评估期后推出对灾难恢复站点的更改（也称为*错开部署*），以检测主站点的问题，并在问题蔓延之前停止部署。实施监控以检测配置偏差，并跟踪环境中的更改和合规性。在灾难恢复站点中执行自动修复，以使其保持完全一致，并做好准备在发生事件时立即接管。
### 实施步骤
1. 验证灾难恢复区域包含成功执行灾难恢复计划所需的 AWS 服务和功能。
1. 使用基础设施即代码（IaC）。保持生产基础设施和应用程序配置模板的准确性，并定期将其应用于灾难恢复环境。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 可以检测 CloudFormation 模板指定的内容与实际部署内容之间的偏差。
1. 配置 CI/CD 管道来将应用程序和基础设施更新部署到所有环境，包括主站点和灾难恢复站点。诸如 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 等 CI/CD 解决方案可以自动执行部署过程，从而降低配置偏差的风险。
1. 在主环境和灾难恢复环境之间错开部署。这种方法支持在主环境中对更新进行初始部署和测试，这样可以在问题传播到灾难恢复站点之前，将其隔离在主站点中。这种方法可以防止同时将缺陷推送到生产和灾难恢复站点，并保持灾难恢复环境的完整性。
1. 持续监控主环境和灾难恢复环境中的资源配置。诸如 [AWS Config](https://aws.amazon.com/config/) 之类的解决方案有助于强制实施配置合规性并检测偏差，这有助于在不同环境中保持一致的配置。
1. 实施警报机制，以跟踪和通知任何配置偏差或数据复制中断或滞后。
1. 自动修复检测到的配置偏差。
1. 安排定期审计和合规性检查，以验证主配置和灾难恢复配置之间的持续一致性。定期审核可帮助您保持对既定规则的遵守，并确定需要解决的任何差异。
1. 检查 AWS 预置容量、服务配额、节流限制以及配置和版本差异是否存在不匹配。
## 资源
**相关最佳实践：**
+ [REL01-BP01 了解服务配额和约束](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 跨多个账户和区域管理服务配额](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 监控和管理配额](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**相关文档：**
+ [按照 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：检测堆栈和资源的非托管配置更改](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [AWS CloudFormation：在整个 CloudFormation 堆栈上检测偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [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: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
**相关示例：**
+ [CloudFormation 注册表](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [适用于 AWS 的配额监控程序](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Implement automatic drift remediation for AWS CloudFormation using Amazon CloudWatch and AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Architecture Blog: Disaster Recovery](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 系列博客文章
+ [AWS Marketplace：可用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 自动执行恢复
实施可靠、可观测、可重复且经过测试的自动化恢复机制，来降低故障的风险和业务影响。
**期望结果：**您已经为恢复流程实施了有据可查、标准化且经过全面测试的自动化工作流程。恢复自动化功能会自动纠正导致数据丢失或不可用（低风险）的小问题。您可以针对严重事件快速调用恢复流程，在恢复流程运行时观察补救行为，并在观测到危险情况或故障时结束这些流程。
**常见反模式：**
+ 您依赖于处于故障或已降级状态的组件或机制，作为恢复计划的一部分。
+ 恢复流程需要手动干预，例如控制台访问（也称为*单击操作*）。
+ 您在存在数据丢失或不可用高风险的情况下自动启动恢复过程。
+ 您没有包含一个机制来中止不起作用或带来额外风险的恢复过程（如*暗灯* 或*红色的大型停止按钮*）。
**建立此最佳实践的好处：**
+ 提高了恢复操作的可靠性、可预测性和一致性。
+ 能够实现要求更高的恢复目标，包括恢复时间目标（RTO）和恢复点目标（RPO）。
+ 降低了事件期间恢复失败的可能性。
+ 降低了与容易出现人为错误的手动恢复过程相关的故障风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
要实施自动恢复，您需要一种使用 AWS 服务和最佳实践的全面方法。首先，请确定工作负载中的关键组件和潜在故障点。开发自动化流程，无需人工干预即可从故障中恢复工作负载和数据。
使用基础设施即代码（IaC）原则开发恢复自动化功能。这使您的恢复环境与源环境保持一致，并支持对恢复过程进行版本控制。要编排复杂的恢复工作流程，可以考虑诸如 [AWS Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)或 [AWS Step Functions](https://aws.amazon.com/step-functions/) 等解决方案。
恢复过程自动化可带来显著的好处，有助于您更轻松地实现恢复时间目标（RTO）和恢复点目标（RPO）。但是，此类功能可能会遇到意外情况，而可能会导致失败或造成新的风险，例如额外的停机时间和数据丢失。要降低这种风险，请提供快速停止正在进行的恢复自动化的功能。一旦停止，您就可以进行调查并采取纠正措施。
对于支持的工作负载，可以考虑使用 AWS 弹性灾难恢复（AWS DRS）等解决方案来提供自动失效转移。AWSDRS 会持续将计算机（包括操作系统、系统状态配置、数据库、应用程序和文件）复制到目标 AWS 账户和首选区域中的暂存区。如果发生事件，AWS DRS 会自动将复制的服务器转换为 AWS 上恢复区域中完全预置的工作负载。
维护和改进自动恢复是一个持续的过程。根据经验教训不断测试和完善恢复过程，并随时了解可以增强恢复能力的新 AWS 服务和功能。
### 实施步骤
1. **规划自动恢复**
1. 对您的工作负载架构、组件和依赖关系进行全面审核，来确定和规划自动恢复机制。将工作负载的依赖关系分类为*硬* 依赖关系和*软* 依赖关系。硬依赖关系是指工作负载运行所必须具备且无法替代的依赖关系。软依赖关系是工作负载通常使用的依赖关系，但此类依赖关系可以用临时替代系统或流程替换，或者可以通过[优雅降级](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation)进行处理。
1. 建立识别和恢复丢失或已损坏数据的流程。
1. 定义在完成恢复操作后确认已恢复的稳定状态的步骤。
1. 考虑为使恢复的系统准备好提供全面服务所需的任何操作，例如预热和填充缓存。
1. 考虑在恢复过程中可能遇到的问题以及如何检测和修复这些问题。
1. 考虑无法访问主站点及其控制面板的场景。验证可以在不依赖主站点的情况下独立执行恢复操作。考虑使用诸如 [Amazon 应用程序恢复控制器（ARC）](https://aws.amazon.com/application-recovery-controller/)之类的解决方案来重定向流量，而无需手动更改 DNS 记录。
1. **开发自动恢复流程**
1. 实施自动化的故障检测和失效转移机制，来实现免手动恢复。构建控制面板（例如使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)）来报告自动恢复过程的进度和运行状况。包括验证成功恢复的过程。提供一种机制来中止正在进行的恢复。
1. 对于无法自动恢复的故障，编写[行动手册](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency)作为后备流程，并考虑制定[灾难恢复计划](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts)。
1. 测试恢复过程，如 [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html) 中所述。
1. **为恢复做好准备**
1. 评估恢复站点的状态并提前为其部署关键组件。有关更多详细信息，请参阅 [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)。
1. 为恢复操作定义明确的角色、职责和决策过程，涉及整个组织的有关利益相关者和团队。
1. 定义启动恢复过程的条件。
1. 制定计划来还原恢复过程，需要时或在认为安全之后回退到主站点。
## 资源
**相关最佳实践：**
+ [REL07-BP01 在获取或扩展资源时利用自动化](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 监控工作负载的所有组件以检测故障](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 管理灾难恢复站点或区域的配置偏差](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**相关文档：**
+ [AWS Architecture Blog: Disaster Recovery](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)
+ [Orchestrate Disaster Recovery Automation using Amazon Route 53 ARC and AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Build AWS Systems Manager Automation runbooks using AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [AWS Marketplace: Products That Can Be Used for Disaster Recovery](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 弹性灾难恢复](https://aws.amazon.com/disaster-recovery/)
+ [使用弹性灾难恢复进行失效转移和失效自动恢复](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [AWS 弹性灾难恢复资源](https://aws.amazon.com/disaster-recovery/resources/)
+ [APN 合作伙伴：有助于进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**相关视频：**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)