我們使用AI作為受控探針來測試警報文件

我們運營著一小批裸金屬伺服器，用於驗證Glassmkr在真實硬體多樣性下的表現。七臺機器來自四個供應商、三種作業系統家族，時間跨度從2017到2024年。隨著時間的推移，這些機器積累了大量警報。上週，儀表盤上活躍警報多達35個，大多是常規的漂移問題：核心更新待處理、安全補丁可用、自動更新未配置。儀表盤已告知我們數週該做什麼，而我們一直未行動。

我們決定利用這個積壓做點有用的事。與其親自修復警報，不如進行一個實驗：讓一個編碼代理嘗試修復所有警報，但附加一個關鍵約束。

約束條件

代理只能使用：每個警報規則在/docs/alerts頁面中的部分；警報證據JSON中的fix_commands欄位；我們自己的文件中連結的任何文本；警報指向的日誌輸出。它不能使用：來自訓練資料的一般Linux管理知識；我們未連結的外部供應商文件的網頁搜尋；未經我們建議的常識性運維操作。

這個約束的目的是測試我們的文件，而不是模型的能力。沒有約束，代理會依賴訓練資料解決問題，我們無法瞭解文件的不足。有了約束，我們指南中的每一個缺口都會顯現出來。

我們對九臺機器上的35個活躍警報進行了測試。去重後，共有10種不同的規則型別，涵蓋核心更新、防火牆配置、SSH加固、安全補丁、自動更新、systemd服務故障、IPMI SEL事件、介面錯誤、SMART故障和核心漏洞。

我們的發現

大多數規則沒問題。代理嘗試解決了三種風險最高的型別（應用修復有實際後果），並審查了其他型別的指南質量。十種規則型別中有四種沒有可操作的缺口。三種可以透過Forge記錄的簡單命令解決。剩下的三種在證據格式或文件中存在特定的、可修復的缺口。

這三種值得詳細描述，因為每種代表不同的失敗模式。

模式1：警報與證據不一致

在一臺機器上，smart_failing觸發嚴重級別警報。代理讀取證據發現health: "PASSED"。從客戶角度看，警報說驅動器故障，而證據說健康檢查透過。沒有第三個欄位解釋矛盾。該規則實際上基於多個獨立的SMART閾值觸發：重分配扇區數超過廠商閾值、待定扇區數增長、離線不可修復計數。任何一個都可能觸發規則。證據形狀根本沒有指明哪個條件觸發了。

修復是一行的求值器改動：發射一個triggering_signals陣列，顯式命名每個觸發條件。修復後，同一臺機器上警報清晰顯示："triggering_signals": [{ "attribute": "reallocated_sectors", "observed": 1, "expected": 0 }]。一個扇區在Crucial MX300上重對映。真實訊號，低嚴重性，立即清晰。

模式2：警報基於歷史記錄觸發

在我們的生產services-1主機上，ipmi_sel_critical因2024年11月的電源供應AC事件觸發。這些事件是成對的Asserted/Deasserted條目，意味著BMC觀察到供電跌落和恢復。到2026年5月，電源已平穩執行15個月。而警報一直在觸發。該規則沒有時間視窗機制。一旦關鍵事件進入系統事件日誌，規則永久觸發，即使是一年前的瞬時事件。證據未暴露事件時間戳，因此儀表盤上的客戶無法知道事件是當前還是歷史，除非透過shell檢視。

修復是雙重的：將時間戳新增到critical_events[]證據陣列中的每個事件；為規則本身新增可配置的時間視窗，預設30天，並可針對噪聲主機進行覆蓋。修復釋出後，services-1警報在下一次採集週期自動解決：一年前的事件落在新視窗外。無需客戶操作。

模式3：警報指向問題但未指向修復

在第三臺機器上，systemd_service_failed因fail2ban觸發。代理按照我們的四步指南：檢查狀態、讀取日誌、嘗試重啟、再次檢查狀態。前三步有效。日誌顯示實際問題：Have not found any log file for sshd jail。第四步（重啟）失敗，因為底層配置問題未改變。我們的文件在此處結束，建議“檢查配置和依賴項”。這恰恰是客戶自助服務中斷的地方。日誌說了實話。我們需要從日誌輸出到修復之間搭建橋樑。

修復是操作性的，而非文件性的：我們更改了Crucible，將失敗單元的最後幾行日誌直接包含在警報證據中。客戶無需SSH即可看到失敗原因。該機器上的警報證據現在直接顯示Have not found any log file for sshd jail錯誤。到修復的路徑更短了。

交叉發現

這三個缺口看似不同，但共享一個形狀：每種情況下，規則已經可以訪問的證據比客戶看到的證據更豐富。所有三個修復都是暴露我們已經掌握的資訊。這是持續存在的缺口模式。我們的/docs/alerts頁面以一般性術語告訴客戶警報的含義，而證據JSON具體告訴客戶規則觀察到了什麼。兩者正在偏離。檢視我們儀表盤中警報證據的客戶比閱讀我們文件頁面的客戶獲得了更好的指導。

我們在代理成功解決警報的規則中也注意到相同的更溫和版本。對於interface_errors，我們的fix_commands欄位包括防火牆與網絡卡的歧義檢查，而我們的/docs/alerts頁面未提及。對於ssh_root_password，我們的fix_commands欄位包括金鑰訪問驗證探測，而文件頁面未提及。更豐富的指導隱藏在警報本身中。

我們交付了什麼

同一周內我們交付了三個求值器更改和一次文件審計。證據形狀改進首先落地，因為槓桿更高：每個閱讀任何警報的客戶立即受益。文件審計隨後落地，以縮小/docs/alerts與fix_commands之間的差距。我們沒有為每個規則新增“可操作步驟”部分，因為fix_commands已服務於該目的。錯誤在於/docs/alerts沒有反映它。

方法論，單獨說明

使實驗成功的約束值得提取出來。沒有它，實驗將衡量LLM的一般Linux能力，這並不有趣，因為答案是“對大多數事情足夠高”。有了它，實驗衡量了我們自己的指南對於自助服務是否足夠完整，這正是對客戶重要的關鍵問題。

任何在自己的基礎設施上執行類似練習的人都應採用相同的約束。禁止代理使用其在領域上的訓練資料。強制它僅使用你產品記錄的指南。每個失敗點都是真實客戶也會遇到的缺口。透過AI執行的優勢在於速度：實驗大約需要一小時時鐘時間。使用自己產品的優勢在於誠實：每個暴露的缺口都是真實的。

關於工具的一個說明：我們為此實驗使用了外部編碼代理（Claude Code），因為禁止訓練資料使用對於外部代理比對我們自己的生產部署更易執行。實驗執行在我們的驗證叢集上，而不是任何客戶基礎設施。來自Glassmkr賬戶的客戶遙測繼續由我們專用L4 GPU上的Gemma 4 26B分析，從未離開Glassmkr棧。

我們一個月後還會再做一次。剩餘工作列表尚未清空。