上一篇研究完混沌工程，決定了自動化先讓 AI 理解實驗情境、產生 Chaos Mesh YAML，目標檢查與實際執行則交給程式控制。

接下來把時間拉回 gpt-4o 剛出現的時候，看看當時怎麼實作這流程。

那時候大家整天在討論 Prompt Engineering，想著怎麼透過 LangChain、LangGraph 或 n8n，把 LLM、Prompt 與外部工具串成一套執行流程，或是乾脆自己寫 Python 程式碼來控制工作流。雖然現在的 AI 已經強到你可以躺著看它表演，但當時我為了清楚掌握流程，還是得替 AI 把每個步驟安排好。

用程式碼固定 AI 的執行範圍

流程先讀取使用者輸入的實驗條件，再交給 LLM 解析故障類型與目標。程式取得目標後，會先查詢 Kubernetes，確認這些資源真的存在。

目標確認完成，LLM 才會產生 Chaos Mesh YAML。程式接著驗證 YAML 格式與 CRD，通過後才建立實驗資源。如果驗證失敗，就把錯誤交回 LLM 修正。

把這些步驟串起來後，完整流程如下：

這個流程保留兩個停止條件：

1. 只要有目標不存在，程式就回報錯誤並結束，不會繼續產生或套用 YAML。
2. YAML 達到 MAX_RETRY 仍未通過驗證，程式就停止流程並回報錯誤。

透過 Azure DevOps Pipeline 執行

我把這套程式透過 Azure DevOps Pipeline 啟動，讓工程師可以從原本熟悉的 CI/CD 介面輸入實驗條件並啟動流程。

Step 1：輸入實驗條件

啟動 Pipeline 時，需要填入三個變數：

下圖是啟動 Azure DevOps Pipeline 時的輸入畫面：

Step 2：產生並注入 Chaos Mesh YAML

Pipeline 啟動後，程式會讀取 FAULT_SITUATION、DURATION 與 NAMESPACE，再把實驗情境交給 LLM 解析。

從 Pipeline log 可以看到，程式先完成 targets in K8s 檢查，接著由 LLM 產生 Chaos Mesh YAML。YAML 通過驗證後，程式才把實驗資源建立到 Kubernetes。

下圖是 Pipeline 產生並注入 Chaos Mesh YAML 的執行結果：

Step 3：確認實驗執行與影響

建立實驗資源後，先到 Chaos Mesh Dashboard 確認執行狀態。

下圖可以看到 sock-shop-frontend-to-catalogue-delay-chaos-agent 這個 NetworkChaos 正在執行，故障類型是 Delay，持續時間為一分鐘。這張圖只能確認程式已經建立實驗，而且 Chaos Mesh 正在執行；實際影響仍要回到 Grafana 查看。

從 Grafana Dashboard 可以看到，約在 14:14 注入故障後，Frontend Latency 明顯上升，QPS 同時下降。這表示網路延遲確實影響到 Frontend，而且影響可以從 metrics 中觀察到。原本的韌性假設有沒有成立，還要再對照預先設定的門檻與錯誤率。

結論

這一版由程式控制執行順序與安全檢查，LLM 只負責理解情境與產生 YAML。好處是每一步都很明確，缺點是流程只要調整，程式碼就要跟著修改。

後來 MCP 出現，我開始嘗試讓 AI Agent 自己選擇工具並完成流程。下一篇就來看看，改用 MCP 與 n8n 後，整套混沌工程自動化會變成什麼樣子。