本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
規劃您的 AWS FIS 實驗
故障注入是藉由建立破壞性事件，例如伺服器中斷或 API 限流，在測試或生產環境中對應用程式施加壓力的程序。透過觀察系統回應的方式，您可以實作改善。當您在系統上執行實驗時，它可協助您以受控方式識別系統性弱點，以免這些弱點影響依賴您系統的客戶。然後，您可以主動解決問題，以協助防止無法預測的結果。
開始使用 AWS FIS 執行故障注入實驗之前，建議您先熟悉下列原則和準則。
重要
AWS FIS 會對系統中的真實 AWS 資源執行實際動作。因此，在您開始使用 AWS FIS 執行實驗之前，強烈建議您先在生產前或測試環境中完成規劃階段和測試。
基本原則和指導方針
開始使用 AWS FIS 進行實驗之前，請執行下列步驟：
-
識別實驗的目標部署 — 首先識別目標部署。如果這是您的第一個實驗，我們建議您從生產前或測試環境中開始。
-
檢閱應用程式架構：您必須確定已識別每個元件的所有應用程式元件、相依性和復原程序。從檢閱應用程式架構開始。視應用程式而定，請參閱 AWS Well-Architected Framework。
-
定義穩定狀態行為：根據重要的技術和業務指標來定義系統的穩定狀態行為，例如延遲、CPU 負載、每分鐘登入失敗、重試次數或頁面載入速度。
-
形成假設 — 形成您預期系統行為在實驗期間如何變更的假設。假設定義遵循以下格式：
如果執行
錯誤注入動作，則業務或技術指標影響不應超過值。例如，身分驗證服務的假設可能會如下讀取：「如果網路延遲增加 10%，則登入失敗增加少於 1%。」 實驗完成後，您會評估應用程式彈性是否符合您的業務和技術預期。
在使用 AWS FIS 時，我們也建議遵循這些準則：
-
一律在測試環境中開始試驗 AWS FIS。永遠不要從生產環境開始。隨著您進行故障注入實驗，您可以在測試環境以外的其他受控環境中進行實驗。
-
從小型、簡單的實驗開始，例如在一個目標上執行 aws：ec2：stop-instances 動作，以建立您團隊對應用程式彈性的信心。
-
錯誤注入可能會導致實際問題。請謹慎進行，並確保您的第一次故障注入是在測試執行個體上，這樣客戶就不會受到影響。
-
測試、測試和測試更多。故障注入旨在透過妥善規劃的實驗在受控環境中實作。這可讓您對應用程式和工具的能力建立信心，以承受動盪的環境。
-
我們強烈建議您在開始之前，先備妥卓越的監控和提醒計畫。如果沒有它，您就無法了解或測量實驗的影響，這對於持續的故障注入實務至關重要。
實驗規劃準則
使用 AWS FIS，您可以在 AWS 資源上執行實驗，以測試應用程式或系統在故障條件下如何執行的理論。
以下是規劃 AWS FIS 實驗的建議準則。
-
檢閱中斷歷史記錄 — 檢閱您系統的先前中斷和事件。這可協助您建立系統整體運作狀態和彈性的概觀。開始在系統上執行實驗之前，您應該解決系統中的已知問題和弱點。
-
識別具有最大影響的服務 — 檢閱您的服務，並識別那些對最終使用者或客戶有最大影響的服務。
-
識別目標系統 — 目標系統是您執行實驗的系統。如果您初次使用 AWS FIS，或從未執行過故障注入實驗，建議您先在生產前或測試系統上執行實驗。
-
諮詢您的團隊：詢問他們擔心什麼。您可以建立假設來證明或拒絕他們的疑慮。您也可以詢問您的團隊他們不擔心什麼。此問題可以顯示兩個常見的缺點： 沉降成本和確認偏差缺失。根據團隊的答案形成假設，有助於提供有關系統狀態現實的詳細資訊。
-
檢閱您的應用程式架構：對您的系統或應用程式進行檢閱，並確保您已識別每個元件的所有應用程式元件、相依性和復原程序。
建議您檢閱 AWS Well-Architected 架構。該架構可協助您為應用程式和工作負載建置安全、高效能、彈性且高效率的基礎設施。如需詳細資訊，請參閱 AWS Well-Architected
。 -
識別適用的指標 — 您可以使用 Amazon CloudWatch 指標來監控實驗對 AWS 資源的影響。您可以使用這些指標來判斷應用程式以最佳方式執行時的基準或「穩定狀態」。然後，您可以在實驗期間或之後監控這些指標，以判斷影響。如需詳細資訊，請參閱使用 Amazon CloudWatch 監控 AWS FIS 用量指標。
-
為您的系統定義可接受的效能閾值 — 識別代表系統可接受、穩定狀態的指標。您將使用此指標來建立一或多個 CloudWatch 警示，其代表實驗的停止條件。如果觸發警示，實驗會自動停止。如需詳細資訊，請參閱AWS FIS 的停止條件。
