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

# 了解權衡和風險
<a name="tradeoffs"></a>

彈性架構應使用少數經過良好測試、簡單且可靠的機制來回應故障。為了實現最高等級的彈性，工作負載應該自動偵測並盡可能從失敗模式復原。這樣做需要大量投資來執行彈性分析。這表示實現更高層級的彈性需要做出權衡。不過，隨著您繼續做出權衡，您會達到相對於恢復能力目標減少回報的點。以下是最典型的權衡：
+ **成本** – 備援元件、增強的可觀測性、其他工具或增加的資源使用率將導致成本增加。
+ **系統複雜性** – 偵測和回應故障模式，包括緩解解決方案，且可能不使用受管服務會導致系統複雜性提高。
+ **工程工作** – 需要額外的開發人員時數來建置解決方案，以偵測和回應故障模式。
+ **營運開銷** – 監控和操作處理更多故障模式的系統可能會增加營運開銷，尤其是當您無法使用 受管服務來緩解特定故障模式時。
+ **延遲和一致性** – 建立有利於可用性的分散式系統需要一致性和延遲的權衡，如 [PACELC 理論](http://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf)中所述。



![\[根據所做出的權衡達成彈性目標的機率，您會在其中達到降低回報的點\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/resilience-analysis-framework/images/tradeoffs.png)


當您考慮使用者案例中所識別失敗模式的緩解措施時，請考慮您需要進行的權衡。與安全性一樣，彈性是一個最佳化問題。您必須決定是否要避免、緩解、轉移或接受已識別失敗所帶來的風險。您可以避免某些失敗模式、您接受的集合，以及一些您可以轉移的模式。您可以選擇減輕您識別的許多失敗模式。若要決定採取哪種方法，請提出兩個問題來執行評估：失敗發生的可能性為何？ 如果工作負載確實發生，會對工作負載造成什麼影響？

**可能性**是事件發生的可信度。例如，如果使用者案例的元件在單一 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上運作，則元件可能會在系統操作期間的某個時間點中斷，可能是因為修補程序或作業系統錯誤。或者，由 Amazon Relational Database Service (Amazon RDS) 管理的資料庫，可同步其主要和次要執行個體之間的資料，其完全無法使用的合理性較低。

**影響**是事件可能造成之傷害的預估值。它應該從財務和評價角度評估，並且相對於它影響的使用者故事的價值。例如，不堪負荷的資料庫可能會對電子商務系統接受新訂單的能力產生重大影響。不過，在負載平衡器後方 20 個執行個體的機群中遺失單一執行個體，影響很小。

您可以將這些問題的答案與為了降低風險而必須進行的權衡成本進行比較。當您考量風險閾值和彈性目標時，這些資訊會通知您計劃主動緩解哪些失敗模式的決策。