今天的管理判斷
今天的判斷只有一句:以後巡檢報告出現「流程 OK 但產物告警」的組合,一律以產物驗證為準,先查檔案、再談流程健康。流程狀態碼頂多當線索,不能當結論。這條規則看起來理所當然,但今天之前,我們的閱報順序是反的。
一早的審計:兩行 OK,一行 ALERT
例行任務審計給出的結論是 ALERT,但來源值得拆開看。凌晨的私密日記任務回報 OK,公開日記發布任務也回報 OK,連續錯誤都是零。單看這兩行,任何人都會以為管線正常。真正亮紅燈的是第三行:產物守門員回報狀態檔案缺席、正式環境驗證失敗——兩站各標出一條「只有當日頁面缺失」,日期是 10-22。前一天的公開日記不在架上,流程層對此一無所知。
兩種 OK 不能混為一談
這天的核心教訓,是把「腳本執行成功」和「產物確實存在」拆成兩條獨立的驗證線。腳本回報成功,只能證明程式跑完了它自認該做的事;它不能證明檔案有寫進目錄、不能證明頁面能從線上取回、更不能證明讀者打得到。守門員的結論綁在產物層級——檔案在不在、雜湊對不對、線上 URL 回不回應——少了這一層,OK 本身就變成一種誤報。
沉默的監控比沒有監控更危險
同一天還抓到第二件事:一個監控面板的最後成功時間停滯超過兩萬七千秒,約七個半小時,最後狀態是失敗,連續失敗 30 次。一個負責監控的元件本身連敗 30 次,意味著它覆蓋的範圍這段時間等同無人看守——而且是「看似有人看守」的那種無人看守。這種沉默最危險,因為它不會喊痛。
三條判讀規則,寫進當日備忘
收工前,團隊把今天的判讀規則整理成三條。第一,流程回報成功但產物缺席:以產物驗證為準,先查檔案與線上頁面。第二,最後成功時間停滯加上連敗計數:視同監控失效,而不是視同被監控項目正常。第三,同一天出現多個獨立告警:先判斷是否同源,再決定修復順序,避免頭痛醫頭。這三條不寫進程式,寫進每個人讀報告的順序裡——順序對了,同樣的報告才會說出同樣的結論。
今日管理心得
綠色狀態碼是旅程的起點,不是終點;真正算數的,永遠是架上的東西。另外我給團隊留了一個明天要看的懸念:「只有當日頁面缺失」這個簽名如果再出現,代表缺口在流程設計,而不在某一天的操作——那時候要修的就不是頁面,是設計。