本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 持續混沌工程實驗生命週期
如[上一節](implementation.md)所述，您可以採用不同的方式實作混沌工程實驗。在所有情況下，建置有意義的混沌實驗的關鍵在於了解應用程式、歷史事件和實作的修補，以及清楚了解要調查的領域，例如彈性或安全性。您對應用程式的了解可協助您制定應用程式潛在弱點的假設，並了解它在注入錯誤時如何偵測、修復和復原。
混沌實驗生命週期包含下列步驟：
1. 定義實驗的目標。
1. 選取目標應用程式。
1. 對齊心智圖。
1. 解決應用程式的已知問題。
1. 定義假設和實驗。
1. 確保實驗的操作準備度。
1. 執行受控案例和實驗。
1. 從 學習並微調實驗。
這些步驟會在圖表中說明，並在下列各節中討論。
## 定義目標並設定期望
在每次實驗之前，請確保您的目標和期望是具體的、可衡量的、可實現的、相關的和有時間限制的。明確定義下列項目：
+ **識別**系統和服務的可能故障或弱點，以了解它們如何影響使用者。這包括識別可能的故障模式，例如伺服器當機、網路故障或軟體錯誤，以及評估其對系統整體效能和可靠性的潛在影響。
+ 透過定義關鍵風險指標 (KRIs) 來**量化**故障對系統和服務的影響。這包括當延遲、輸送量和錯誤率等指標偏離其穩定狀態時，測量失敗的影響。透過了解此類偏差的影響，您可以根據業務風險來排定緩解失敗的優先順序。
+ **制定**和**驗證**緩解或防止失敗的策略。這包括識別潛在的解決方案，例如備援、錯誤修正或備用策略，以及在受控環境中測試其有效性。透過驗證這些策略，您可以確保有效防止或緩解故障，並可以放心地在生產系統中部署它們。
+ **改善**事件回應和災難復原程序。透過在受控環境中重播失敗，您可以測試事件回應程序、識別潛在的瓶頸或差距，以及精簡災難復原程序。這有助於確保您準備好在發生意外故障時快速有效地做出回應。
## 選取目標應用程式
混沌工程是一項強大的技術，但需要考慮優先順序才能最大化價值。決定將混沌工程工作重點放在何處時，請先考慮您業務的關鍵服務。要求您的團隊逐一完成軟體開發生命週期階段，並開始先在測試環境中注入錯誤。業務關鍵型應用程式直接與營收、客戶體驗和核心操作相關。這些服務的混沌實驗可以發現可能對組織造成嚴重影響的漏洞，如果未解決，則可能整個市場。例如，專注於面向客戶的服務，例如交易系統或訂單系統。排定這些中央服務的優先順序可為每個時間投資提供最大的保護。
在關鍵服務之後，請查看資料庫、訊息佇列、網路和共用服務 APIs 等基本元件。這些可能會用作整個組織的共用元件或服務，因此它們的故障會導致廣泛的問題。確認基礎設施服務的彈性可確信它們不會打亂其上方的相依應用程式。例如，關閉 Kafka 叢集的混沌工程實驗顯示許多下游應用程式的容錯能力。雖然系統基礎設施不是直接面對客戶，但它是主要的混沌工程目標。
請不要忘記映射人員、程序、設施資訊和第三方相依性的心理差距，因為如果不符合組織的影響承受能力目標，可能會導致重大中斷。如需測量混沌工程投資報酬率的詳細資訊，請參閱策略文件中[將混沌工程投資混沌工程投資的 ROI 量化](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-chaos-engineering-journey/roi-chaos-engineering.html)*為策略必要*性。
下圖顯示在不同服務層上執行混沌實驗的投資報酬率。
## 對齊心智圖 （應用程式探索）
當您執行臨機操作實驗或遊戲日時，您將透過保留專注於映射應用程式詳細資訊的白板工作階段，開始應用程式探索程序。（如果您在混沌管道中執行實驗，您已透過定義目標應用程式來對齊該心智圖。) 了解心理差距的好方法是讓最資淺的團隊成員先繪製應用程式的圖表，然後要求更資深的工作人員逐步新增至圖表。這將發現跨體驗層級理解的任何差距。
圖表應描述應用程式的直接上游和下游相依性，以及任何重要的第三方整合。請確定透過應用程式請求的預期流程相符。規劃關鍵工作流程和使用者旅程，以釐清客戶如何使用應用程式。考慮使用[序列圖](https://en.wikipedia.org/wiki/Sequence_diagram)來擷取此資訊。
在此協作工作階段之後，團隊應該擁有應用程式的共同心理模型、其關鍵相依性及其監控功能，並了解做出明智決策以繼續進行或取消潛在混沌實驗的風險。
## 解決應用程式的已知問題
混沌工程實驗旨在主動找出應用程式中的瑕疵。透過注入延遲增加、伺服器重新啟動或可用區域電源受損等故障，您可以驗證應用程式容忍逼真的中斷的能力。不過，此程序會假設目標應用程式中的基本穩定性和運作狀態層級。在已經有問題的應用程式上執行混沌實驗，可能會掩蓋更深層次的問題。
在進行混沌工程之前，團隊應該解決應用程式中任何已知的瑕疵、錯誤和效能問題。
## 定義假設和實驗
過去導致應用程式或組織內其他應用程式中斷的事件，可作為混沌實驗想法的絕佳來源。例如，先前的中斷是由組態錯誤或缺少彈性模式所觸發？ 透過混沌實驗檢閱事件歷史記錄並重播這些真實世界失敗的根本原因，是在未來針對類似問題開發彈性的有效方法。
另一個寶貴的實驗概念來源可以直接來自最熟悉 應用程式的工程師、架構師和操作員。允許團隊成員提交他們認為可能會嚴重中斷應用程式的假設失敗案例，讓您能夠根據內部知識收集想法。然後，應用程式團隊可以評估哪些提議的案例可能具有最大的潛在影響，或公開最大的未知風險。針對此類高風險、較不了解的案例進行混沌實驗，可以產生重要的學習並防止未來發生問題。
第三個想法來源是執行彈性建模，以預測會導致已識別業務損失的條件。有些彈性建模練習具有以元件為基礎的方法來建置彈性模型，而有些則具有以系統為基礎的方法。以元件為基礎的方法詢問問題：「當元件 *x* 處於極端負載或失敗時會發生什麼情況？」 然後，開發彈性模型的團隊推測此類案例對更廣泛的應用程式的影響，並識別目前實施的監控和預防性控制，以偵測和緩解案例的影響。或者，系統型方法遵循由上而下的程序，以反白顯示應用程式的不良狀態，例如「Web Storefront 顯示過時的庫存層級」，並邀請應用程式團隊預測哪些條件或條件會導致應用程式以這種方式運作。
## 確保實驗的操作準備度
您需要可量化的指標來衡量不利條件對應用程式及其行為的影響，如先前有關[可觀測性](getting-started.md#observability)一節中所述。能夠測量應用程式的行為可讓您判斷不利條件是否會影響應用程式，以及影響程度。
了解應用程式是否有影響的最佳方法是測量其穩定狀態。穩定狀態會測量正常操作的外觀，通常符合特定應用程式的業務和客戶體驗指標。在進行下一個步驟之前，請確定您已備妥可觀測性來了解影響，並在實驗未如預期進行時準備好回復機制。
## 執行受控實驗和案例
在 AWS，我們不建議在生產環境中的應用程式上執行初始混沌實驗。混沌實驗的目的是了解應用程式在壓力條件下如何運作的新知識。應用程式的行為在實驗期間可能無法預測，因此第一次在生產環境中執行實驗可能會對客戶造成影響。因此，您應該一律在影響真實世界使用者的可能性最低的較低層級環境中執行初始混沌實驗，然後在驗證並確信您的應用程式可以吸收、調整並從注入的動作中復原之後，反覆瀏覽您的環境。
使用擷取金鑰詳細資訊的文件徹底規劃每個實驗，類似於附錄中提供的[實驗規劃文件](sample-planning.md)。要包含的一些關鍵欄位是穩定狀態定義、假設和失敗注入方法。混沌實驗的規劃、執行和分析可以在單一成品中涵蓋。
在您完成實驗的寫入計畫後，請準備任何必要的程式碼，以注入文件中概述的計劃中斷。
若要擷取實驗期間的潛在影響，請確定有可觀測性機制。如果您還沒有自動擷取實驗結果的方法，例如 AWS FIS 實驗報告、識別將在執行期間做筆記的團隊成員、擷取儀表板螢幕擷取畫面，以及帶領團隊完成實驗。
## 學習和微調
在每次實驗之後，以團隊身分一起檢閱和思考混沌實驗。有意識地努力維持無責的思維。您的目標是要有開放、具建設性的對話，完全專注於獲得最大的學習，而不是指派責任。
首先檢閱實驗的穩定狀態定義和假設。應用程式的行為是否如預期？ 是否有任何使假設失效的意外？ 討論應用程式在實驗期間如何反應的觀察，包括好與壞。收集的資料 ― 指標、日誌、螢幕擷取畫面等 ― 應該說明發生的情況。
以好奇而非判斷的方式進行此資料檢閱，並根據學習，找出可改善應用程式設計、文件、監控或其他功能的領域。這些動作項目會擷取為後續專案，讓應用程式更具彈性。
透過這種無責方法，您可以坦率地討論發生了什麼問題以及如何修正它。假設來自參與的每個人的正面意圖，並信任他們正在努力實現良好的成果。您的共同目標是透過持續學習和調整來實現組織成長和進展。以具建設性、無責的方式執行的混沌實驗審查為您的團隊提供安全空間，以取得寶貴的洞見，讓您的應用程式和組織長期更可靠且更具彈性。重點在於學習，而不是人員。若要將學習內容分散到您的團隊，請將[實驗結果報告](sample-result.md)發佈到中央位置，並公告調查結果，以便其他人可以從中學習。