Agent 自愈系統實戰：從崩潰恢復到無人值守

許多團隊把「高可用」理解為多機部署與負載平衡，但真正的無人值守系統還需要最後一塊拼圖：自愈（self-healing）。它不是玄學，而是一套工程化的閉環：偵測、診斷、修復、驗證、留痕。

為什麼傳統監控不夠

Prometheus 加上告警群是多數團隊的標配，但它解決的是「讓人知道」，而不是「讓系統恢復」。凌晨三點的告警意味著：人是系統可靠性的瓶頸。自愈系統的目標是把已知故障的處理從人身上移走，只把未知故障升級給人。

1. 偵測（Detect）：除了指標閾值，還需要心跳與「金絲雀請求」。一個服務進程活著但執行緒池耗盡，CPU 曲線完全正常，只有端到端探測能發現。關鍵是縮短「故障發生→被感知」的視窗，從分鐘級壓到秒級。

2. 診斷（Diagnose）：自動收集上下文——最近一次部署、錯誤日誌尾部、相依服務狀態、系統資源水位。沒有診斷的自愈是瞎猜，會把偶發問題放大成雪崩。診斷輸出應該是結構化的「嫌疑清單」，按信賴度排序。

3. 修復（Repair）：從低風險到高風險分級操作：重啟單個實例 → 摘除流量 → 回滾最近部署 → 擴容。每一級都要有熔斷條件，例如同節點 10 分鐘內自愈超過 3 次就停止並升級人工。

4. 驗證（Verify）：修復動作完成不等於故障恢復。必須讓偵測階段的同一組探測重新通過，才算自愈成功。很多「重啟大法」失敗的根源是修復後沒有驗證，壞節點被重新放回流量池。

5. 留痕（Record）：每次自愈都要寫結構化日誌：時間、故障簽名、採取的動作、結果、耗時。這是後續改進的唯一原料。沒有留痕的自愈系統是黑箱，你甚至不知道它今天救了你有幾次。

先窄後寬。 不要一上來就做通用自愈框架。選一個最高頻、模式最固定的故障（磁碟寫滿、連線池耗盡），寫死它的診斷與修復路徑，跑通閉環後再泛化。

冪等是底線。 自愈動作可能被重複觸發——網路抖動導致偵測誤判、上一輪修復還在進行。每個修復動作必須冪等，並有分散式鎖或租約機制防止並行操作。

給自愈系統本身做監控。 誰來監控監控者？自愈迴圈卡死、鎖洩漏、診斷邏輯 bug，都可能讓系統表面平靜實則腐爛。最簡單的方法：每天定時彙總自愈次數，突然歸零和突然飆升同樣可疑。

自愈不是取代 SRE，而是把 SRE 從重複勞動中解放出來，去做真正需要判斷力的架構工作。衡量標準很樸素：凌晨被叫醒的次數。如果你的告警群裡 80% 的訊息其實只需要「重啟並觀察」，那正是自愈系統該吃掉的負載。從小閉環開始，讓它慢慢學會更多故障的處理套路——無人值守的未來，是這樣一步步練出來的。