上一篇提到，這個系列會從工作現場的需求開始，先把原本的 SOP 拆清楚，再想 AI 可以接手哪些部分。

時間回到兩年前，長官交辦了一個任務給我：研究混沌工程。

所以我從最基本的問題開始查：混沌工程是什麼？想解決什麼問題？

混沌工程

研究下去後，原來混沌工程是一套驗證系統韌性的方法論。它的核心概念是「受控實驗」，透過在系統中注入故障，觀察系統的反應，確認系統是否能承受故障、維持服務。

簡單說明一下實驗流程：

1. 先定義系統正常時的穩定狀態，例如 QPS（每秒請求數）、Latency（延遲）、錯誤率與服務狀態。
2. 接著提出假設，例如「catalogue 服務發生網路延遲時，前台仍然可以回應」。
3. 在限定的目標與時間內注入故障。
4. 觀察 metrics、log 與使用者實際感受到的結果。
5. 停止實驗並確認環境恢復。
6. 整理結果，確認原本的假設有沒有成立。

直接在環境裡隨便刪 Pod，只會製造麻煩，跟受控實驗完全搭不上邊。

舉個例子：平常做系統設計時，我們會準備重試、備援、限流與自動復原機制。架構圖看起來很完整，設定檔也都寫了，真正發生故障時能不能撐住，還是要實際驗證才知道。

例如某個服務突然多了 300ms 網路延遲，下游的 timeout 設定能不能正常生效？Pod 死掉之後，流量有沒有切到其他副本？CPU 被吃滿時，告警會不會觸發？這些狀況如果只停留在文件裡，大家通常都覺得系統「應該」扛得住。半夜真的出事，才發現那個「應該」很可能都是假的。

完成方法論需要工具

要執行混沌實驗，需要工具幫忙控制故障目標、類型與持續時間。因為當時要測試的環境跑在 Kubernetes 上，我最後選擇 Chaos Mesh。

Chaos Mesh 可以透過 Kubernetes 的 CRD 定義實驗。CRD 可以先理解成 Kubernetes 額外擴充的資源格式，我們用 YAML 寫清楚要對哪個 namespace、哪些 label 的 Pod 做什麼事情，套用後就能執行對應的故障。

它支援的情境很多，例如：

• 對指定服務加入網路延遲。
• 模擬封包遺失或網路中斷。
• 增加 CPU 或記憶體壓力。
• 終止指定的 Pod。

以網路延遲為例，我可以指定 sock-shop namespace 裡的 front-end 與 catalogue，讓兩個服務之間出現 5000ms 延遲，持續一分鐘。實驗開始後，再去 Grafana 看 Frontend Latency、QPS 與錯誤率有沒有變化。

有了 Chaos Mesh，前面研究的混沌工程方法就能真正落地：用它控制故障目標與持續時間，再透過 Grafana 觀察指標，驗證原本提出的假設。

實際操作

實際執行時，我會先跟 SRE 和 AP 團隊討論實驗情境與觀察指標，接著準備 YAML、套用實驗、觀察結果，最後清理資源並整理報告。

做到這裡，我開始想到這套流程有固定輸入、固定步驟，也有明確輸出，很適合拿來做自動化。
尤其是寫 YAML 這件事，其實是需要一些門檻的，要先了解 Chaos Mesh 和各種實驗的 YAML 寫法，於是我就想到能不能先讓 AI 產生 YAML，再交給程式去套用？

AI 產出 YAML

先把原本執行一場混沌實驗的步驟拆開，大概會是這樣：

SRE 與 AP 團隊討論實驗情境
→ 確認故障目標、持續時間與觀察指標
→ 撰寫 Chaos Mesh YAML
→ 檢查 YAML
→ 套用實驗
→ 觀察結果
→ 清理資源與整理報告

原本可以先準備幾份 YAML 模板，再把 namespace、label 與實驗參數填進去。但碰到新的故障類型或組合時，還是得重新寫一份 YAML。既然 LLM 可以理解自然語言，也能產生 YAML，我就想先把這一步交給 AI。

AI 加入後，三個角色的分工如下：

整體流程可以先縮成一條主線：

人描述想做的實驗
→ AI 產生 Chaos Mesh YAML
→ 程式檢查目標與 YAML
→ 程式建立實驗資源
→ 人觀察結果

所以先讓 AI 負責理解人話與產生 YAML。目標檢查、格式驗證和建立資源都交給程式控制，避免 AI 產出一份看起來很合理的 YAML，就直接往 Kubernetes 裡面套。

結論

混沌工程提供驗證系統韌性的實驗方法，Chaos Mesh 讓這套方法可以在 Kubernetes 裡真正執行。

工具找到後，我把人工執行的過程拆開，決定先讓 AI 接手理解實驗情境與產生 YAML，程式則負責檢查和執行。
下一篇的時間點依然在兩年前。我會回頭說明當時怎麼用程式碼固定流程，再讓 LLM 根據自然語言產生 Chaos Mesh YAML，完成混沌工程自動化。