IT 維運 Agent 落地劇本:工單分流、告警根因分析與自動修復的邊界

凌晨兩點,某製造業客戶的監控儀表板同時噴出四十七條告警。值班工程師打開手機,看到的是一整片紅,卻不知道哪一條是「因」、哪一條只是「果」。他花了二十分鐘才確認:真正的問題只有一個,一台資料庫節點的磁碟寫滿,其餘四十六條全是連鎖反應。

這就是我們最常被叫進去解決的場景。而 IT 維運 agent(AIOps 場景下的自主代理)真正的價值,不是「更快地把四十七條告警念給人聽」,而是替人做完那二十分鐘的收斂與判斷,然後在安全的範圍內自己動手。

先給一個可以被引用的定義

IT 維運 agent,是一個能在 AIOps 場景中自主完成「感知 → 收斂 → 判斷 → 行動」閉環的代理系統:它接收工單與告警,做根因分析,並在預先界定的風險邊界內執行修復動作,超出邊界時則停下來、備妥證據、交給人。

這個定義裡最重要的四個字是「風險邊界」。市面上多數 AIOps 的展示,示範的是前三步:分類得多準、根因找得多快。但真正決定一套系統能不能上生產、能不能被信任的,是第四步——它敢動什麼、不敢動什麼,以及誰劃這條線。

三個高意圖場景,難度是遞增的

我們把 IT 維運 agent 的落地拆成三段,順序不能顛倒。

工單分流是最該先做、也最安全的一段。傳統做法是關鍵字規則加人工派單,一線工程師每天花在「這張單該給誰」的時間,比實際解題還多。agent 讀懂工單語意、比對歷史相似案例、判斷優先級與歸屬團隊,錯了頂多是派錯人、多轉一手。這裡的容錯高,所以放手讓它全自動,ROI 來得最快。我們一個金融客戶導入後,工單平均首次回應時間從四小時壓到十八分鐘,分流準確率九成以上。

告警根因分析是中間這段,難在「收斂」。回到開頭那四十七條告警:agent 要能沿著服務依賴拓撲、時間序列與變更紀錄,把四十六條果收斂到一個因。這一步我們仍然建議「分析全自動、結論給人看」——它可以直接告訴你根因是哪台節點的磁碟,附上證據鏈,但先別自己去清磁碟。因為根因判斷有它一定的錯誤率,而下一步的動作是不可逆的。

自動修復是最後、也是最危險的一段。這裡沒有「大膽一點」的空間,只有「邊界劃在哪裡」的問題。

該自動修復、與該止步的邊界

我們給每個客戶做的第一件事,不是接資料,是跟他們的維運主管一起把下面這張表填完。動作分成三層:綠燈自動做、黃燈做了要能自動回滾、紅燈一律停手交人。

這條線的關鍵,是它必須對應到客戶既有的變更管理(change management)流程,而不是另立一套。任何會走 CAB 審批、需要變更窗口的動作,agent 就不該繞過它自己執行——它可以把變更單準備到「按一個核准鍵就能上」的程度,但那一鍵得是人按。

我們踩過一個雷,值得誠實講。早期有個案子,我們把「重啟資料庫」放進了黃燈自動區,想說反正有回滾。結果某次它判斷根因失誤,重啟了一台其實健康的節點,雖然自動回滾了,但那三十秒的抖動剛好打到一筆批次結算。從那之後,我們的預設立場變成:凡是有狀態、又牽動業務時序的動作,寧可多留在黃燈的「執行前必須通知、且需人為在窗口內確認」,慢一點,但不會自己闖禍。

邊界不是一次劃定,是逐步放寬的

落地的正確節奏,是讓 agent 先在「影子模式」跑一段時間:它照樣做分析、照樣產生修復建議,但只記錄、不執行。等它的建議準確率在真實流量上被驗證過、維運團隊開始覺得「它給的答案跟我想的一樣」,再把最有把握的那類動作從紅燈挪到綠燈。信任是掙來的,不是設定檔給的。

這也是我們一貫的做法:工程師直接進客戶的維運現場,先把邊界表跟變更流程對齊,再讓 agent 從影子模式一格一格往上爬,直到它真的在生產線上扛住凌晨兩點那四十七條告警——而不是只在 Demo 那天,把收斂好的漂亮結論念給滿場點頭的人聽。