REL13-BP05 自动执行恢复
实施可靠、可观测、可重复且经过测试的自动化恢复机制，来降低故障的风险和业务影响。
期望结果：您已经为恢复流程实施了有据可查、标准化且经过全面测试的自动化工作流程。恢复自动化功能会自动纠正导致数据丢失或不可用（低风险）的小问题。您可以针对严重事件快速调用恢复流程，在恢复流程运行时观察补救行为，并在观测到危险情况或故障时结束这些流程。
常见反模式：
-
您依赖于处于故障或已降级状态的组件或机制，作为恢复计划的一部分。
-
恢复流程需要手动干预，例如控制台访问（也称为单击操作）。
-
您在存在数据丢失或不可用高风险的情况下自动启动恢复过程。
-
您没有包含一个机制来中止不起作用或带来额外风险的恢复过程（如暗灯 或红色的大型停止按钮）。
建立此最佳实践的好处：
-
提高了恢复操作的可靠性、可预测性和一致性。
-
能够实现要求更高的恢复目标，包括恢复时间目标（RTO）和恢复点目标（RPO）。
-
降低了事件期间恢复失败的可能性。
-
降低了与容易出现人为错误的手动恢复过程相关的故障风险。
在未建立这种最佳实践的情况下暴露的风险等级：中
实施指导
要实施自动恢复，您需要一种使用 AWS 服务和最佳实践的全面方法。首先，请确定工作负载中的关键组件和潜在故障点。开发自动化流程，无需人工干预即可从故障中恢复工作负载和数据。
使用基础设施即代码（IaC）原则开发恢复自动化功能。这使您的恢复环境与源环境保持一致，并支持对恢复过程进行版本控制。要编排复杂的恢复工作流程，可以考虑诸如 AWS Systems Manager 自动化或 AWS Step Functions
恢复过程自动化可带来显著的好处，有助于您更轻松地实现恢复时间目标（RTO）和恢复点目标（RPO）。但是，此类功能可能会遇到意外情况，而可能会导致失败或造成新的风险，例如额外的停机时间和数据丢失。要降低这种风险，请提供快速停止正在进行的恢复自动化的功能。一旦停止，您就可以进行调查并采取纠正措施。
对于支持的工作负载，可以考虑使用 AWS 弹性灾难恢复（AWS DRS）等解决方案来提供自动失效转移。AWSDRS 会持续将计算机（包括操作系统、系统状态配置、数据库、应用程序和文件）复制到目标 AWS 账户和首选区域中的暂存区。如果发生事件，AWS DRS 会自动将复制的服务器转换为 AWS 上恢复区域中完全预置的工作负载。
维护和改进自动恢复是一个持续的过程。根据经验教训不断测试和完善恢复过程，并随时了解可以增强恢复能力的新 AWS 服务和功能。
实施步骤
-
规划自动恢复
-
对您的工作负载架构、组件和依赖关系进行全面审核，来确定和规划自动恢复机制。将工作负载的依赖关系分类为硬 依赖关系和软 依赖关系。硬依赖关系是指工作负载运行所必须具备且无法替代的依赖关系。软依赖关系是工作负载通常使用的依赖关系，但此类依赖关系可以用临时替代系统或流程替换，或者可以通过优雅降级进行处理。
-
建立识别和恢复丢失或已损坏数据的流程。
-
定义在完成恢复操作后确认已恢复的稳定状态的步骤。
-
考虑为使恢复的系统准备好提供全面服务所需的任何操作，例如预热和填充缓存。
-
考虑在恢复过程中可能遇到的问题以及如何检测和修复这些问题。
-
考虑无法访问主站点及其控制面板的场景。验证可以在不依赖主站点的情况下独立执行恢复操作。考虑使用诸如 Amazon 应用程序恢复控制器（ARC）
之类的解决方案来重定向流量，而无需手动更改 DNS 记录。
-
-
开发自动恢复流程
-
实施自动化的故障检测和失效转移机制，来实现免手动恢复。构建控制面板（例如使用 Amazon CloudWatch
）来报告自动恢复过程的进度和运行状况。包括验证成功恢复的过程。提供一种机制来中止正在进行的恢复。 -
测试恢复过程，如 REL13-BP03 中所述。
-
-
为恢复做好准备
-
评估恢复站点的状态并提前为其部署关键组件。有关更多详细信息，请参阅 REL13-BP04。
-
为恢复操作定义明确的角色、职责和决策过程，涉及整个组织的有关利益相关者和团队。
-
定义启动恢复过程的条件。
-
制定计划来还原恢复过程，需要时或在认为安全之后回退到主站点。
-
资源
相关最佳实践：
相关文档：
相关视频：
