常见的缓解策略 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

常见的缓解策略

首先,请考虑使用预防性缓解措施来防止故障模式影响用户情景。然后你应该考虑纠正性的缓解措施。纠正性缓解措施可帮助系统自我修复或适应不断变化的条件。以下是每个故障类别的常见缓解措施列表,这些缓解措施与弹性属性一致。

失败类别

所需的弹性特性

缓解措施

单点故障 (SPOFs)

冗余和容错

  • 实现冗余 ——例如,通过使用 Elastic Load Balancing (ELB) 背后的多个 EC2 实例。

  • 移除对AWS 全局服务控制平面的依赖关系,只依赖于全局服务数据平面。

  • 当资源不可用时,使用优雅降级,这样您的系统就可以静态稳定到单点故障。

负荷过大

足够的容量

延迟过长

及时输出

配置错误和错误

正确输出

共同的命运

故障隔离

  • 在您的系统中实现容错能力,并使用逻辑和物理故障隔离边界,例如多个计算或容器集群、多个 AWS 账户、多个 AWS Identity and Access Management (IAM) 委托人、多个可用区,可能还有多个 AWS 区域。

  • 基于单元的架构随机分片等技术也可以改善故障隔离。

  • 考虑松散耦合优雅退化等模式,以防止级联故障。当你优先考虑用户故事时,你还可以使用该优先级来区分对主要业务功能至关重要的用户故事和可以优雅降级的用户故事。例如,在电子商务网站中,您不希望网站上的促销小工具受到损害,从而影响处理新订单的能力。

尽管其中一些缓解措施只需很少的精力即可实施,但其他缓解措施(例如采用基于单元的架构以实现可预测的故障隔离和最大限度地减少共同命运故障)可能需要重新设计整个工作负载,而不仅仅是特定用户故事的组成部分。如前所述,重要的是要权衡故障模式的可能性和影响,以及为缓解故障模式所做的权衡取舍。

除了适用于每种故障模式类别的缓解技术外,您还应该考虑恢复用户情景或整个系统所需的缓解措施。例如,故障可能会暂停工作流程并阻止将数据写入预定目的地。在这种情况下,您可能需要操作工具来重新推动工作流程或手动修复数据。您可能还需要在工作负载中构建检查点机制,以帮助防止在发生故障时丢失数据。或者,你可能需要建立一根 andon cord 来暂停工作流程并停止接受新工作以防止进一步的伤害。在这些情况下,您应该考虑所需的操作工具和护栏。

最后,你应该始终假设人类在制定缓解策略时会犯错误。尽管现代 DevOps 实践试图实现操作自动化,但由于各种原因,人类仍然必须与您的工作负载进行交互。不正确的人为操作可能会导致任何 SEES 类别的故障,例如在维护期间移除太多节点并导致过载,或者错误地设置了功能标志。这些情况确实是预防性护栏的失败。根本原因分析永远不应该以 “人类犯了错误” 的结论而告终。相反,它应该从一开始就解决可能出错的原因。因此,您的缓解策略应考虑人类操作员如何与工作负载组件进行交互,以及如何通过安全护栏防止或最大限度地减少人为操作员错误造成的影响。