使用 mirrord 在預發佈集羣上驗證 AI-SRE 修復

本文是系列的第二部分，展示瞭如何將 mirrord 集成到 AI-SRE（人工智能站點可靠性工程師）中，使其能夠在真實集羣上自主測試修復方案。我們使用了 HolmesGPT（唯一可自託管的開源 AI-SRE）進行端到端演示，並植入了兩個錯誤來測試通過（PASS）和拒絕（REJECT）兩種結果。

整個流程如下：HolmesGPT 調查警報並生成 Markdown 報告，然後一個小型 Claude 封裝器將報告轉化為代碼補丁。驗證器使用 mirrord exec 在真實集羣中運行該補丁，並與未修補的基線進行比較，最後根據警報的實際服務等級目標（SLO）返回 verdict。

演示集羣包含一個 Python 結算服務（checkout）、一個定價服務（pricing）和一個負載生成器。Prometheus 收集指標，Alertmanager 在違反 SLO 時觸發警報。HolmesGPT 作為 Pod 運行在集羣中，訂閲 Alertmanager。當警報觸發時，HolmesGPT 進行調查並將報告傳遞給驗證器 Pod，驗證器運行橋接（調用 Claude 生成補丁），然後使用 mirrord exec 在驗證器 Pod 中以目標部署的網絡身份、環境和掛載運行修補後的代碼。

場景一：錯誤率警報（通過）。一個錯誤導致約 10% 的請求返回 500 錯誤，觸發 CheckoutErrorRateHigh 警報。HolmesGPT 快速定位到根因（ValueError），橋接步驟生成補丁（處理 item-3 情況）。驗證器運行基線（10% 錯誤率）和修補後（0% 錯誤率）各 100 次請求，SLO 條件不再滿足，且迴歸監控列表乾淨， verdict 為 PASS。

場景二：延遲警報（拒絕）。定價服務存在長尾延遲，1/10 的調用耗時約 1.5 秒，導致 p99 延遲超過 300 毫秒的 SLO。HolmesGPT 建議實施緩存，橋接步驟生成了內存緩存補丁。驗證結果：基線 p99 為 2162 毫秒，修補後為 2010 毫秒，仍違反 SLO。雖然 p50 下降了 99.8%，但緩存未命中的請求仍然存在。Verdict 為 REJECT。正確的修復應該是添加客户端超時，修補後 p99 降至約 330 毫秒，通過驗證。

這兩個場景表明，通過驗證循環可以阻止看似合理但實際無效的修復。mirrord 的優勢在於無需構建和部署，即可在真實集羣中快速、並行地驗證多個候選補丁。相關代碼已開源在 GitHub，歡迎嘗試。