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

# 容錯和故障隔離
<a name="fault-tolerance-and-fault-isolation"></a>

 當我們考慮可用性時，這是兩個重要的概念。容錯能力是[承受子系統故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)並維持可用性的能力（在已建立的 SLA 內做正確的事情）。若要實作容錯，工作負載會使用備用 (或備援) 子系統。當冗餘集合中的其中一個子系統發生故障時，另一個子系統會取得其工作，通常幾乎無縫。在這種情況下，備用零件是真正的備用容量；它們可以承擔故障子系統 100% 的工作。使用真正的備援裝置時，需要多個子系統故障，才能對工作負載產生不利影響。

 故障隔離可最大限度地減少發生故障時的影響範圍。這通常是通過模塊化實現的。工作負載會分解成小型子系統，這些子系統會獨立故障，而且可以單獨修復。模塊的故障[不會傳播到模塊之外](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html)。這個想法橫跨工作負載中的不同功能，以及橫向跨越提供相同功能的多個子系統。這些模組充當錯誤容器，可限制事件期間的影響範圍。

 控制平面、資料平面和靜態穩定性的架構模式直接支援實作容錯和容錯隔離。Amazon Builder Library 文章[使用可用區域的靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)為這些術語提供了良好的定義，以及它們如何適用於建置彈性、高可用性的工作負載。本白皮書在 [[設計上的高可用性分散式系統] 一節中使用了這些模式AWS，](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title)我們也在此總結它們的定義。
+  **控制平面** — 進行變更所涉及的工作負載部分：新增資源、刪除資源、修改資源，以及將這些變更傳播到需要的位置。控制平面通常比資料平面更複雜，而且具有更多的移動零件，因此在統計學上更容易發生故障並具有較低的可用性。
+  **資料平面** — 提供 day-to-day 業務功能的工作負載部分。數據平面往往比控制面更簡單，並且以更高的體積運行，從而導致更高的可用性。
+  **靜態穩定性** — 儘管相依性受損，工作負載仍能繼續正確操作的能力。實現的一種方法是從數據平面中刪除控制平面依賴關係。另一種方法是鬆散耦合工作負載相依性。也許工作負載沒有看到任何更新的信息（例如新事物，刪除的東西或修改的東西），它的依賴項應該已經交付。但是，在依賴關係受損之前它所做的一切都繼續起作用。

 當我們考慮工作負載的損害時，我們可以考慮兩種高層次的方法進行恢復。第一種方法是在損害發生後對該損害做出反應，也許使用AWS Auto Scaling來添加新的容量。第二種方法是在這些損壞發生之前做好準備，也許是通過過度佈建工作負載的基礎結構，以便它可以繼續正確運行，而不需要額外的資源。

 靜態穩定的系統使用後一種方法。它預先佈建了故障期間可用的備用容量。此方法可避免在工作負載復原路徑中建立控制平面的相依性，以便佈建新容量以從故障中復原。此外，為各種資源佈建新容量需要時間。在等待新容量時，您的工作負載可能會因現有需求而超載，並經歷進一步降級的情況，進而導致「中斷」或完全可用性損失。但是，您也應該考慮將預先佈建的容量用於可用性目標的成本影響。

 靜態穩定性為高可用性工作負載提供接下來的兩個規則。

**規則第 7 條**  
 請勿依賴資料平面中的控制平面，尤其是在復原期間。

**規則第 8 條**  
 鬆散地耦合相依性，因此您的工作負載可以在可能的情況下正確運作，儘管依賴