本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 常見的緩解策略
<a name="mitigation-strategies"></a>

若要開始，請考慮使用*預防性*緩解措施，以防止失敗模式影響使用者案例。然後，您應該考慮*修正*緩解措施。更正緩解措施有助於系統自我修復或適應不斷變化的條件。以下是符合彈性屬性之每個失敗類別的常見緩解措施清單。


| 
| 
| **失敗類別** | **所需的彈性屬性** | **緩解措施** | 
| --- |--- |--- |
| 單點故障 (SPOFs) | 備援和容錯能力 |   實作[備援](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)：例如，使用 Elastic Load Balancing (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://en.wikipedia.org/wiki/Multipath_TCP](https://en.wikipedia.org/wiki/Multipath_TCP)時，使用抖動、對沖等技術實作[指數退避和重試](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)，使用[與鬆耦合系統的非同步互動](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/)、[Canary 部署](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 繫結以暫停工作流程，並停止接受新工作，以避免進一步傷害。在這些情況下，您應該考慮所需的操作工具和護欄。

最後，您應該一律假設在制定緩解策略時，人類會犯錯。雖然現代 DevOps 實務會尋求自動化操作，但人類仍須因各種原因而與您的工作負載互動。不正確的人為動作可能會在任何 SEEMS 類別中造成故障，例如在維護期間移除太多節點並導致過載，或錯誤設定功能旗標。這些案例實際上是預防性護欄的失敗。根本原因分析不應以「人類犯錯」的結論結束。相反地，它應該解決一開始可能發生錯誤的原因。因此，您的緩解策略應考慮人工運算子如何與工作負載元件互動，以及如何透過安全防護機制防止或最小化人工運算子錯誤的影響。