今天的管理判斷先講在前面:零決策日不等於零管理。10/13 沒有升級戰、沒有 ALERT、沒有需要我拍板的取捨——表面上看,這是閘門替我上班的一天。但我真正在意的是:當系統安靜運轉時,管理者該做什麼?我的答案是,做那些事故日永遠排不進日程的事。
為什麼我在意「安靜」這件事
因為安靜有兩種。一種是系統健康的安靜,一種是沒人看儀表板的安靜,從外面看一模一樣。10/12 凌晨的 artifact gate ALERT 才剛教過我們:發布鏈路可以「安靜失敗」——status.json 沒寫,gate-closer 整輪跳過,紅燈亮一整夜沒人處理。所以今天看到全綠,我的第一反應不是放心,是翻收據:兩班 cron 的執行時間、連續錯誤計數、昨天發布的線上驗證,每一項都要有證據,而不是「看起來沒事」。
三個不性感的動作
第一,確認 10/12 發布的收據鏈完整:雙審 APPROVE、deploy 記錄、線上驗證全綠,全部歸檔。發布完成不等於管理完成,收據能在一週後被翻出來才算。第二,把昨天三條教訓固化:簡體字檢查、sitemap root lastmod 的 regex 缺陷、dHash 全域窗口比對——每一條都從「踩過的坑」升級成「可檢查的規則」。教訓不寫成規則,下次就還是眼淚。第三,刻意不修那顆已知的雷:builder 的 root regex 和 10/11 缺頁,我選擇記下來、不動手,因為補頁會重算整個 dHash 窗口,在沒有完整檢查計畫前動它,期望收益是負的。
我今天教 AI 的事:無聊是系統的目標狀態
團隊在事故日表現很好,但今天我刻意示範另一種工作方式:兩班準時、連續錯誤為零的「無聊日」的正確用法,是把昨天的戰場清理乾淨、把教訓釘成規則、把已知的風險寫在明處。我告訴團隊:管理者的成就感不能來自救火,否則你會無意識地縱火。系統的目標狀態是無聊,管理者的功課是學會在無聊裡工作。
我還不敢放手的地方
那顆 sitemap 的雷還在地上。它已經咬過兩次(10/11 與 10/12 的 stale_root_lastmod),按「同一個錯不犯第三次」的規則,它必須在第三次之前被修掉。明天我要看的點很具體:builder regex 與 sitemap 格式的對齊修好,以及 10/11 補頁的 dHash 窗口重算方案。安靜的日子會過去,雷不會自己消失。