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

# 常见缓解策略
<a name="mitigation-strategies"></a>

首先，考虑使用*预防性*缓解措施来防止故障模式影响用户故事。然后，应考虑*纠正性*缓解措施。纠正性缓解措施有助于系统自我修复或适应不断变化的条件。以下是每个故障类别的常见缓解措施列表，这些措施与韧性属性保持一致。


| 
| 
| **故障类别** | **所需韧性属性** | **缓解措施** | 
| --- |--- |--- |
| 单点故障（SPOF） | 冗余和容错能力 |   实施[冗余](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)：例如，通过在弹性负载均衡（ELB）背后使用多个 EC2 实例。   移除对 [AWS 全局服务控制面板](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services)的依赖，仅依赖全局服务数据面板。   当资源不可用时，使用[优雅降级](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html)，以使您的系统在出现单点故障时仍保持静态稳定。   | 
| 负载过高 | 充足容量 |   关键缓解策略包括[速率限制](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)、[卸除负载](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)和工作优先级排序、[持续工作](https://aws.amazon.com/builders-library/reliability-and-constant-work)、[指数回退和使用抖动重试](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)（或根本不重试）、[控制较小的服务](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control)、[管理队列深度](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)、[自动扩展](https://aws.amazon.com/autoscaling/)、[避免冷缓存](https://aws.amazon.com/builders-library/caching-challenges-and-strategies)和[断路器](https://brooker.co.za/blog/2022/02/16/circuit-breakers.html)。   您还应考虑自己的容量计划，并思考未来可能达到的容量和扩展限制，两者均与 AWS 资源和系统内的限制有关。   | 
| 延迟过长 | 及时输出 |   实施适当配置的[超时](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)或自适应超时（根据当前和预测的延迟条件更改超时值，以使缓慢的依赖项仍有可能取得进展，而不是放弃缓慢的请求）。   在从本地环境连接到云服务时，如果在特定路由上遇到延迟，则实施[指数回退和使用抖动重试](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)、对冲、使用[多路径 TCP](https://en.wikipedia.org/wiki/Multipath_TCP) 等技术、使用[与松耦合系统的异步交互](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html)、[缓存](https://aws.amazon.com/builders-library/caching-challenges-and-strategies)并且[不要丢弃工作](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)。   | 
| 配置错误和错误 | 正确的输出 |   捕捉软件中可重复出现的功能性错误的主要方法是通过[静态分析](https://en.wikipedia.org/wiki/Static_program_analysis)、[单元测试](https://en.wikipedia.org/wiki/Unit_testing)、[集成测试](https://en.wikipedia.org/wiki/Integration_testing)、[回归测试](https://en.wikipedia.org/wiki/Regression_testing)、[负载测试](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)和[韧性测试](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)等机制进行严格的测试。   实施[基础设施即代码（IaC）](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)以及[持续集成和持续交付（CI/CD）自动化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments)等策略，以帮助缓解配置错误的威胁。   使用[单箱](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)、[金丝雀部署](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html)、与故障隔离边界一致的部分部署或[蓝绿部署](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html)等部署技术，以减少错误配置和错误。   | 
| 故障共担 | 故障隔离 |   在您的系统中实施[容错能力](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems)，并使用逻辑和物理故障隔离边界，例如多个计算或容器集群、多个 AWS 账户、多个 AWS Identity and Access Management（IAM）主体、多个可用区以及可能的多个 AWS 区域。   [基于单元的架构](https://youtu.be/swQbA4zub20)和[随机分片](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding)等技术也可改善故障隔离。   考虑[松耦合](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html)和[优雅降级](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html)等模式，以防止级联故障。确定用户故事的优先级时，您还可以使用该优先级排序来区分对主要业务功能至关重要的用户故事和可以优雅降级的用户故事。例如，在电子商务网站中，您不希望网站上的促销小部件出现故障影响到处理新订单的能力。   | 

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

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

最后，在制定缓解策略时，您应该始终假设人为错误不可避免。尽管现代化 DevOps 实践力求实现自动化运营，但由于各种原因，人类仍然必须与工作负载进行交互。错误的人为操作可能会引起任何 SEEMS 类别的故障，例如在维护期间移除过多的节点并导致过载，或者错误地设置功能标志。这些场景实际上是预防性护栏的失效。根本原因分析绝不能止步于“人为失误”的结论，而应探究错误最初之所以发生的原因。因此，您的缓解策略应考虑人类运营人员如何与工作负载组件进行交互，以及如何通过安全护栏防止或最大限度地减少人为运营人员错误造成的影响。