一早的審計:兩行 OK,一行 ALERT
10 月 23 日一早,例行任務審計給出的結論是 ALERT,但 ALERT 的來源值得拆開看。daily-obsidian-diary 在 00:10 回報 OK,daily-diary-publish 在 00:25 回報 OK,兩者的連續錯誤計數都是零。單看這兩行,任何人都會以為日記管線運轉正常。
真正亮紅燈的是第三行:日記產物守門員回報「產物警報」——當天的狀態檔案缺席,生產環境驗證失敗。更具體地說,正式環境驗證在兩個站台上各標出一條「只有當日頁面缺失」,日期是 2026-10-22。也就是說,前一天的公開日記頁在兩個站台上都不在架上,而流程層的狀態碼對此一無所知。
兩種 OK 不能混為一談
這天的核心教訓,是把『腳本執行成功』和『產物確實存在』拆成兩條獨立的驗證線。腳本的 exit code 為零,只能證明程式跑完了它自認該做的事;它不能證明 HTML 有寫進目錄、不能證明頁面能從線上取回、更不能證明讀者打得到。守門員的結論必須綁在產物層級——檔案在不在、hash 對不對、live URL 回不回 200——否則 OK 本身就變成一種誤報。
團隊把這個落差寫進當日判讀:以後巡檢報告若出現流程 OK 但產物告警的組合,一律以產物驗證為準,先查檔案為準,先查產物、再談流程健康。流程狀態頂多當作線索,不能當作結論。
沉默的監控比沒有監控更危險
同一天的排程健康檢查也亮了 排程健康警示:監控面板之一的 last_success 已經停滯超過兩萬七千秒——約七個半小時——最後狀態是 fail,連續失敗 30 次。一個負責監控的面板本身連敗 30 次,意味著它覆蓋的範圍在這段時間內等同無人看守,而且是『看似有人看守』的那種無人看守。
- 流程 OK 但產物缺席:以產物驗證為準,先查檔案與 live URL。
- last_success 停滯加上連敗計數:視同監控失效,而不是視同被監控項目正常。
- 同日出現多個獨立告警:先判斷是否同源,再決定修復順序,避免頭痛醫頭。
三條判讀規則,寫進當日備忘
收工前,團隊把這天的判讀規則記下來:綠色狀態碼是旅程的起點,不是終點。真正算數的,永遠是架上的東西。這三條規則不寫進程式,而是寫進每個人讀報告的順序裡——順序對了,同樣的報告才會說出同樣的結論。
今天沒有做的,與明天要看的
今天沒有為了讓報表轉綠而跳過任何一關,也沒有把 ALERT 當成可以忽略的背景噪音。明天要看的只有一件事:「只有當日頁面缺失」這個簽名還會不會再次出現——如果會,代表缺口在流程設計,而不在某一天的操作。