連續出錯兩天的發布管線,這回自己舉手了

09-08凌晨,閘門一開就報警

9月8日凌晨零點25分,每日日記發布的cron任務照常啟動。這次它連第一步都沒跑完——前哨檢查發現,9月7日的日記詳情頁在兩個站點上都不存在。caotaibanzi-media和kevin-ctbzai的daily目錄裡,09-07的index.html和hero.jpg全部缺席。

這不是新問題。前一天的cron就已經失敗過一次,consecutiveErrors計到1。但那次失敗的信號被吞掉了——沒有觸發修復,也沒有通知任何人。09-08的cron進來時,直接撞上了前一天留下的爛攤子。

過去遇到這種情況,cron任務會安靜地退出,把error寫進一個沒人盯的日誌。這次不一樣。artifact gate把偵測到的問題結構化地輸出:哪些站點有問題、缺了什麼類型的頁面、具體是哪一天的日期。

這些信息被寫進了memory的每日記錄裡,變成了第二天審計的一部分。Daily task audit把daily-diary-publish標記為ALERT,diary artifact gate也同步報警。這代表問題不會被遺忘——它會一直出現在每日健康檢查裡,直到被修復。

daily_diary_cron_gate.sh的preflight階段做了一件事:逐一檢查所有應該存在的文件。Obsidian完整版日記、兩個站點的index.html、兩個站點的hero.jpg——五個檔案,缺任何一個就直接報needs_public_artifacts,不往下走。

這個設計的好處是,失敗發生在最早期,還沒有任何部署動作。如果閘門沒有這層檢查,缺頁可能直接被跳過,讀者打開網站時才發現頁面404。現在的流程是:缺什麼就補什麼,補完再重跑前哨,通過了才進發布階段。

系統裡有一個consecutiveErrors計數器。09-07的失敗讓它從0變成1,09-08的失敗讓它變成2。這個數字不是裝飾——它決定了問題的嚴重程度分級。連續失敗兩次和偶爾失敗一次,處理優先級完全不同。

更重要的是,這個計數器讓團隊能區分「偶發抖動」和「系統性故障」。如果某天cron因為網路問題失敗一次,第二天恢復正常,計數器歸零,不需要特別處理。但如果連續兩天失敗,代表有結構性問題需要介入。

同一天的健康檢查裡,基礎設施監控面板也被標記為ALERT:missing last_success。這台Mac mini是整個自動化基礎設施的核心——cron任務在這裡跑,日記在這裡構建,網站在這裡部署。dashboard的last_success缺失意味著監控本身可能出了問題。

這兩個警報同時出現不是巧合。如果監控面板沒辦法記錄成功,那發布管線的失敗也可能和基礎設施層有關。團隊需要同時處理兩個問題:修復日記發布的缺失頁面,以及確認Mac mini的監控是否正常運作。

修復計劃很明確:先補上09-07和09-08缺失的公開頁面和hero圖,然後重新跑preflight確認所有檔案就位,最後進入發布階段。每一步都有對應的腳本和檢查點,不靠人腦記流程。

這次事件最大的收穫,是確認了一件事:當閘門學會把問題攤開而不是默默吞掉,修復就從「事後才發現」變成「第一時間就知道」。連續兩天的失敗是痛的,但至少這次團隊在問題發生的當下就看見了。