Netflix chaos 實踐的核心責任是驗證「服務在失效條件下是否仍維持 steady state」。重點是注入後能否用明確訊號證明系統仍可服務，故障注入數量是次要考量。

問題場景

許多團隊會做壓測與演練，但演練設計常停在工具層：kill instance、斷連線、延遲注入。這些動作本身不會自動產生可靠性結論。若沒有 steady state 與停止條件，演練只會留下「有做過 chaos」的紀錄。

Netflix 的價值在於把 chaos 轉成科學化驗證循環：先定義穩態，再設計可證偽的假設。

決策機制

一輪有效的 chaos 驗證要同時具備四個元素。

元素核心問題交付結果
Steady state服務正常時應維持什麼行為穩態指標
Hypothesis失效發生後仍應維持什麼可證偽假設
Blast radius實驗範圍怎麼限制實驗邊界
Abort condition何時立即停止風險切斷條件

FIT（Failure Injection Testing）把注入粒度推進到 request path，讓測試更接近真實依賴路徑。這讓團隊能在不擴大範圍的前提下，驗證高價值路徑的容錯能力。

可觀測訊號

訊號判讀重點對應章節
steady-state SLI注入後是否維持服務承諾6.22
abort trigger count停止條件是否可執行6.20
fallback success ratio降級與替代路徑是否有效8.3
trace degradation pattern退化是否集中於預期依賴4.3

常見陷阱

最常見錯誤是把 chaos 視為「故障越大越好」。這會把演練從驗證流程變成壓力展示，增加真實風險卻不提升可學習性。有效做法是用最小 blast radius 驗證最高價值假設，然後逐步放大。

下一步路由

若要把本案例落地，先寫 6.22 的穩態欄位，再在 6.20 定義停止條件。案例輸出的證據交給 6.23 與 8.22。