混沌工程：在 AI 時代重建系統韌性

by
目錄

🌏 Read this article in English

綠燈不是平安。

是延遲被吸進長尾，沒人看見。

這在 AI 系統中並不罕見。傳統監控依賴「服務仍在運行」的假設，但當 LLM 推理延遲飆升、向量資料庫出現索引更新延遲或召回結果暫時不一致時，核心路徑可能已經部分退化。用戶流失往往發生在「系統未死」的灰色地帶。

這讓我們意識到：高可用仍重要，但在 AI 系統的長尾故障面前，它需要補上「韌性驗證」。

傳統監控的核心邏輯是「偵測已發生的異常」。這在微服務架構中運作良好，因為服務邊界清晰，依賴關係可預測。但當系統引入 AI 元件時，變數呈指數級增加。

偵測已發生的異常，等於承認失效邊界已被觀測到。這裡的關鍵不在於偵測，而在於量化。監控只能告訴你「系統不可用」，卻無法告訴你「系統在什麼條件下會超出可接受服務水準」。

閾值警報在二元狀態（開/關）下仍是必要的第一層，但在 AI 的連續退化曲線上，它容易漏掉那段灰色地帶。我們需要在「異常偵測」之外，再補上「韌性驗證」。

混沌工程：從預防到韌性驗證

Chaos Monkey 不是教你怎麼搞壞系統。

是逼你承認——你以為的高可用，從來沒被驗證過。

混沌工程常被誤解為「故意搞壞系統」。這種觀點忽略了其核心價值：在受控環境中，量化系統的失效邊界。

Netflix 的 Chaos Monkey 啟發了整個業界，但 AI 系統的混沌工程需要更細緻的設計。我們不隨機殺死容器，我們注入「情境性故障」。

韌性不是「不故障」。

而是「在故障發生時，系統仍能維持核心業務價值」。

這意味著我們需要定義「可接受的退化」。

例如，當向量資料庫延遲超過 500ms 時，系統是否仍能透過快取提供基礎搜尋？當 LLM API 限流時，系統是否仍能透過本地小模型提供簡化回應？

這些取捨沒有單一標準答案，取決於你的業務優先級。

在 AI 導入期建立故障注入框架

在功能優先的戰場上，韌性驗證常被安排到較後期，這是資源分配下的理性取捨。但當系統進入生產環境前，我們必須補上這塊拼圖。

以下是三個可執行的步驟：

1. 定義故障場景矩陣

不要隨機注入故障。建立一個矩陣，涵蓋以下維度：

  • 依賴層：資料庫、快取、外部 API、模型服務
  • 故障類型：延遲、丟包、限流、權限錯誤
  • 影響範圍：單節點、區域、全域

但矩陣最大的價值不是覆蓋率，而是逼團隊把「可接受的退化」寫成文字。

例如，測試 LLM API 限流時，模擬 10% 的請求返回 429 錯誤，比模擬 100% 的宕機更具價值。因為它揭示了系統在部分失效時的行為。

2. 建立自動化注入管道

使用 Chaos Mesh 或 LitmusChaos 等工具，將故障注入自動化。

這兩者在 Kubernetes 故障注入、CRD/實驗編排上具有工程價值，能幫助團隊在複雜的叢集環境中精確控制變數。

關鍵在於「可重複性」。每次測試應保持相同注入參數與觀測口徑，讓退化曲線可以比較。

# 注意：以下為概念範例，正式使用請依當前 Chaos Mesh NetworkChaos schema 驗證
apiVersion: chaos.mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-latency-llm-api
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - ai-inference
  delay:
    latency: "200ms"
    correlation: "100"

這段 YAML 定義了對 ai-inference 命名空間的所有 Pod 注入 200ms 的網路延遲。透過自動化，我們可以定期執行測試，觀察系統行為。

3. 量化韌性指標

傳統 SLA（服務等級協議）關注可用性。韌性 SLA 關注「退化曲線」。

這裡需要先釐清一個常見誤區：RTO（恢復時間目標）與 RPO（恢復點目標）適合狀態恢復場景。但在純推理延遲場景，這些指標往往失靈。

應優先使用 p95/p99 latency、成功率、fallback hit rate、品質分數。

這些指標必須與業務價值掛鉤。例如，搜尋功能的退化曲線可能比推薦功能的退化曲線更陡峭，因為搜尋是核心路徑。

韌性與開發速度：怎麼分配投資組合

建立混沌工程框架需要投入資源。

這意味著更多的測試時間、更多的工具維護、更多的工程師培訓。

在資源有限的情况下，這是一個合理的取捨。

我自己的習慣是——先看這個依賴掛了，業務會不會在 SLA 內被客戶感知。

決策框架：

  • 如果系統是核心業務路徑（如支付、搜尋）：投資混沌工程，因為故障成本極高。
  • 如果系統是實驗性功能（如新穎的 AI 功能）：採用輕量級監控，因為開發速度優先。
  • 如果系統依賴外部不可控服務（如第三方 API）：重點放在退化和重試策略，因為無法控制上游。

這不是「全有或全無」的選擇。它是根據風險調整的投資組合。

市場訊號：韌性工程的未來

AI 系統的韌性邊界，目前仍由各家團隊的 incident 學費在一筆筆畫出來。

市場訊號尚未明朗，但已有跡象可循：CNCF Landscape 上 Chaos 相關專案數量在過去兩年明顯擴張，Chaos Mesh、LitmusChaos 在大型 SaaS 與 fintech 的採用案例陸續浮上來。

對核心業務路徑而言，退化曲線正在慢慢補進 SLA 的對話裡，而不只是 99.9%。

等三年回頭看，這條曲線可能會比可用率，更早被寫進值班交接的第一頁。

下一步：從最小可行韌性開始

可以從一個高風險依賴開始，注入 500ms 延遲，觀察系統反應。

若已有 staging 環境與基本觀測資料，通常可從半天內的手動演練開始。它會給你一個直觀的理解：系統在故障時如何行為。

故障是必然，但退化可以優雅。

下次 staging 升級時，你願意花十分鐘，看看系統在邊緣狀況下的樣子嗎？

Sources