REL11-BP04 恢复期间依赖于数据面板而不是控制面板

控制面板提供用于创建、读取、描述、更新、删除和列出（CRUDL）资源的管理 API，而数据面板则处理日常服务流量。在对可能影响韧性的事件实施恢复或缓解响应时，着眼于使用最少数量的控制面板操作，实现对服务的恢复、重新扩缩、恢复、修复或失效转移。在这些降级事件期间，数据面板操作应凌驾于任何活动之上。

例如，以下是所有控制面板操作：启动新的计算实例、创建数据块存储和描述队列服务。启动计算实例时，控制面板必须执行多项任务，例如查找具有容量的物理主机、分配网络接口、准备本地数据块存储卷、生成凭证以及添加安全规则。控制面板往往是复杂的编排。

期望结果：当资源进入受损状态时，将流量从受损资源转移到运行状况良好的资源，能够自动或手动恢复系统。

常见反模式：

建立此最佳实践的好处：提高自动修复的成功率可以缩短平均恢复时间，并提高工作负载的可用性。

在未建立这种最佳实践的情况下暴露的风险等级：中。对于某些类型的服务降级，控制面板会受到影响。依赖于大量使用控制面板进行修复，可能会增加恢复时间（RTO）和平均恢复时间（MTTR）。

实施指导

要限制数据面板操作，请评测每项服务，了解恢复服务所需的操作。

利用 Amazon 应用程序恢复控制器来转移 DNS 流量。这些功能会持续监控应用程序从故障中恢复的能力，让您能够跨多个 AWS 区域、可用区和本地部署控制应用程序恢复。

Route 53 路由策略使用控制面板，因此不要依赖控制面板进行恢复。Route 53 数据面板会回复 DNS 查询，并执行和评估运行状况检查。它们分布在全球各地，专为 100% 可用性的服务水平协议（SLA）而设计。

用于创建、更新和删除 Route 53 资源的 Route 53 管理 API 和控制台是在控制面板上运行，而这些控制面板设计用于优先考虑在管理 DNS 时所需的强一致性和持久性。为了实现这一点，控制面板位于单个区域“美国东部（弗吉尼亚州北部）”中。虽然这两个系统都非常可靠，但控制面板不包含在 SLA 中。在极少数情况下，数据面板的韧性设计允许自身保持可用性，而控制面板做不到。对于灾难恢复和失效转移机制，使用数据面板功能可提供尽可能高的可靠性。

将计算基础设施设计为静态稳定，以避免在事故发生期间使用控制面板。例如，如果您使用的是 Amazon EC2 实例，请避免手动配置新实例或指示自动扩缩组添加实例作为响应。要获得最高级别的韧性，请在集群中预置足够的容量用于失效转移。如果必须限制此容量阈值，请在整个端到端系统上设置限制，安全地限制到达有限资源集的总流量。

对于诸如 Amazon DynamoDB、Amazon API Gateway、负载均衡器和 AWS Lambda 无服务器之类的服务，使用这些服务时可以利用数据面板。但是，创建新函数、负载均衡器、API Gateway 或 DynamoDB 表是一项控制面板操作，应在降级之前完成，以便为事件和演练失效转移操作做准备。对于 Amazon RDS，数据面板操作允许访问数据。

有关数据面板、控制面板以及 AWS 如何构建服务来满足高可用性目标的更多信息，请参阅使用可用区的静态稳定性。

了解哪些操作位于数据面板，哪些位于控制面板。

实施步骤

对于降级事件后需要恢复的每个工作负载，请评估失效转移运行手册、高可用性设计、自动修复设计或高可用性（HA）资源恢复计划。确定可能被视为控制面板操作的每个操作。

考虑将控制面板操作更改为数据面板操作：

考虑允许数据面板操作影响相同修复措施的其他方法。

如果是任务关键型服务，可考虑使用辅助区域中的某些服务，以便在不受影响的区域内进行更多控制面板和数据面板操作。

资源

相关最佳实践：

相关文档：

相关视频：

相关示例：

相关工具：