本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
故障注入是藉由建立破壞性事件,例如伺服器中斷或 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 的停止條件。