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

# 套用架構
<a name="applying-framework"></a>

套用彈性分析架構的最佳方法是從標準問題集開始，依失敗類別組織，您應該詢問您正在分析的使用者案例中的每個元件。如果有些問題不適用於工作負載中的每個元件，請使用最適用的問題。

您可以從兩個角度思考失敗模式：
+ 失敗如何影響元件支援使用者案例的能力？
+ 失敗如何影響元件與其他元件的互動？

例如，當您考慮資料存放區和過度載入時，您可能會考慮資料庫處於過度載入和查詢逾時下的失敗模式。您也可以考慮資料庫用戶端如何透過重試或無法關閉資料庫連線來造成資料庫負擔，以耗盡連線集區。另一個範例是身分驗證程序，其中可能包含數個步驟。您需要考慮多重要素驗證 (MFA) 應用程式或第三方身分提供者 (IdP) 的故障會如何影響此身分驗證系統中的使用者案例。

當您回答下列問題時，應考慮失敗的來源。例如，過載是由客戶激增或人工運算子在維護活動期間使太多節點停止服務所造成？ 您可能可以在每個問題中識別多個失敗來源，這可能需要不同的緩解措施。當您提出問題時，請記錄您發現的潛在故障模式、它們適用的元件，以及每個故障的來源。

**單一故障點**
+ 元件是否針對備援進行架構？
+ 如果元件故障，會發生什麼情況？
+ 您的應用程式是否可以容忍單一可用區域的部分或全部損失？

**過度延遲**
+ 如果此元件的延遲增加，或是與其互動的元件的延遲增加 （或 TCP 重設等網路中斷），會發生什麼情況？
+ 您是否已使用重試策略適當設定逾時？
+ 您是否快速或緩慢失敗？ 是否有層疊效果，例如因為快速失敗而意外將所有流量傳送到受損的資源？
+ 對此元件提出的最昂貴請求是什麼？

**負載過多**
+ 哪些因素會讓此元件不堪負荷？ 此元件如何超過其他元件？
+ 如何避免在永遠不會成功的工作上浪費資源？
+ 您是否有為元件設定的斷路器？
+ 某個項目可以建立不可覆寫的積壓項目嗎？
+ 此元件可以在哪裡體驗雙模式行為？
+ 可以超過哪些限制或服務配額 （包括儲存容量）？
+ 元件如何在負載下擴展？

**設定錯誤和錯誤**
+ 如何防止錯誤設定和錯誤部署到生產環境？
+ 您能否自動復原錯誤的部署，或從部署更新或變更的故障容器轉移流量？
+ 您有哪些防護機制可以防止操作員錯誤？
+ 哪些項目 （例如登入資料或憑證） 可能會過期？

**共享命運**
+ 您的故障隔離界限是什麼？
+ 部署單位的變更是否至少與您預期的[故障隔離界限](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)一樣小，但理想上更小，例如單箱環境 （故障隔離界限內的單一執行個體）？
+ 此元件是否在使用者案例或其他工作負載之間共用？
+ 哪些其他元件與此元件緊密耦合？
+ 如果此元件或其相依性發生部分或灰色故障，會發生什麼情況？

詢問這些問題後，您也可以使用 SEEMS 來開發工作負載和每個元件特有的其他問題。SEEMS 最適合做為結構化方式來考慮故障模式，並在執行恢復能力分析時做為啟發來源。它不是剛性分類。不要花時間擔心特定失敗模式適合哪個類別，這並不重要。*重要的是*，您考慮了失敗並將其寫下來。答案沒有錯誤；在盒外保持創造性和思考是有益的。此外，請勿假設故障模式已緩解；包括您可以考慮的所有潛在故障模式。

您不太可能在第一次練習中預期所有潛在的失敗模式。架構的多次反覆運算可協助您產生更完整的模型，因此您不需要在第一次傳遞時嘗試解決所有問題。您可以定期、每週或每兩週定期執行分析。在每個工作階段中，專注於特定的失敗模式或元件。這有助於在改善工作負載彈性方面取得穩定、增量的進展。收集使用者案例的潛在失敗模式清單後，您可以決定如何處理它們。