今天的管理判斷很直接:當儀表板全部轉綠,管理者的工作才剛開始——要問的是「這片綠是怎麼來的」,鬆一口氣還太早。10/1 的審計五項全 OK,包括前兩天還在發 ALERT 的日記 artifact gate——9/28 的缺頁終於補上了。但從警報響起到傷口闔上,花了超過 48 小時。
為什麼在意這件事
因為 48 小時這個數字,量的不是技術難度,是流程缺口。缺頁的修法一點都不神祕:產出公開版、過 gate、部署、驗證,每一步都有現成腳本。真正花時間的是「沒有人把 ALERT 認領成自己的任務」——警報每天出現在審計裡,但出現和被處理之間,隔著一個沒有明確 owner 的真空。
看到的進步
進步很具體:缺口最終是被流程自己消化的,不是靠臨時救火。gate 從缺頁回報轉成 published_gate_closer,deploy=yes,整條鏈路走完沒有跳步。這代表九月初搭建的那套雙站發布管線,在真實故障面前是能用的,不需要每次都靠人盯。
看到的問題
問題也一樣具體:從 ALERT 出現到有人動手,中間隔了兩天以上。如果這是一個面向讀者的產品表面破洞,兩天就是兩天的讀者體驗損失。工具正常、審計正常、健康檢查正常——唯獨「把警報變任務」這一段,還停留在靠人記得。這種真空在忙亂期看不出來,只有在安靜期才看得清楚。
今天教 AI 什麼
教的重點只有一條:安靜不是結案。系統全綠的時候,團隊的預設動作不該是「今天沒事」,而是「今天適合回頭檢查那些剛闔上的傷口,是不是真的縫好了」。這包括:缺頁補上了,那個讓它缺頁的根因呢?補頁的流程跑完了,那個讓 ALERT 掛兩天的 owner 真空呢?
今天的管理心得
- 系統的價值要看警報響起之後發生什麼,安靜期的全綠什麼都證明不了。
- 流程債比技術債更隱蔽:工具全正常,問題在沒人認領警報。
- 修復完成後的第一個安靜日,正是安排 retrospective 的最好時機。
明天還要看的點
還不敢放手的地方很明確:下一次 artifact gate 或健康檢查發出 ALERT,從警報到動手的延遲是多少。如果又超過 24 小時,那就得把它視為常態,在排程層加一條「ALERT 自動建任務」的規則。系統自律的下一步,不是自己修復,是自己認領。