本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
常见的缓解策略
首先,请考虑使用预防性缓解措施来防止故障模式影响用户情景。然后你应该考虑纠正性的缓解措施。纠正性缓解措施可帮助系统自我修复或适应不断变化的条件。以下是每个故障类别的常见缓解措施列表,这些缓解措施与弹性属性一致。
失败类别 |
所需的弹性特性 |
缓解措施 |
---|---|---|
单点故障 (SPOFs) |
冗余和容错 |
|
负荷过大 |
足够的容量 |
|
延迟过长 |
及时输出 |
|
配置错误和错误 |
正确输出 |
|
共同的命运 |
故障隔离 |
|
尽管其中一些缓解措施只需很少的精力即可实施,但其他缓解措施(例如采用基于单元的架构以实现可预测的故障隔离和最大限度地减少共同命运故障)可能需要重新设计整个工作负载,而不仅仅是特定用户故事的组成部分。如前所述,重要的是要权衡故障模式的可能性和影响,以及为缓解故障模式所做的权衡取舍。
除了适用于每种故障模式类别的缓解技术外,您还应该考虑恢复用户情景或整个系统所需的缓解措施。例如,故障可能会暂停工作流程并阻止将数据写入预定目的地。在这种情况下,您可能需要操作工具来重新推动工作流程或手动修复数据。您可能还需要在工作负载中构建检查点机制,以帮助防止在发生故障时丢失数据。或者,你可能需要建立一根 andon cord 来暂停工作流程并停止接受新工作以防止进一步的伤害。在这些情况下,您应该考虑所需的操作工具和护栏。
最后,你应该始终假设人类在制定缓解策略时会犯错误。尽管现代 DevOps 实践试图实现操作自动化,但由于各种原因,人类仍然必须与您的工作负载进行交互。不正确的人为操作可能会导致任何 SEES 类别的故障,例如在维护期间移除太多节点并导致过载,或者错误地设置了功能标志。这些情况确实是预防性护栏的失败。根本原因分析永远不应该以 “人类犯了错误” 的结论而告终。相反,它应该从一开始就解决可能出错的原因。因此,您的缓解策略应考虑人类操作员如何与工作负载组件进行交互,以及如何通过安全护栏防止或最大限度地减少人为操作员错误造成的影响。