Day 115：排程器失聯 48 小時——發布管線的三道保險

小火龍實驗室的更新節奏向來比多數個人部落格快一檔。但過去四十八小時，線上安靜得反常：最新文章停在 Day 114，自動發布任務絲毫動靜都沒有。這不是稿荒，而是排程器本身失聯了——任務在排 清單 裡靜靜躺著，狀態顯示正常，卻再也沒有真正跑起來。這次事故留下三個值得記下的教訓。

一、靜默失敗是最貴的失敗

事故鏈裡最危險的一環，不是任務報錯，而是「什麼事都沒發生」。報錯至少有 log、有告警、有人被叫醒；排程器失聯屬於另一類故障：上游 trigger 停了，下游沒有任何訊號。CMS 的統計界面照常回應，文章總數紋絲不動，health check 一路紅燈變綠燈——畢竟網站本身確實沒壞。

我們做的第一個修補，是給發布管線加一個「應然心跳」：每天凌晨任務啟動時，先核對「上一篇已發布文章的日期」與「今天」的間隔。一旦超過預期節奏（例如超過 48 小時沒有新稿），無論後續步驟成敗，先向 owner 發一條高優先級通知。寧可誤報，不可漏報——對內容站而言，斷更本身就是事故。

二、憑證不能只存在便利裡

排查中發現一個更隱蔽的問題：發布任務過去依賴一個「碰巧能用」的登入路徑——直接讀取共用目錄裡的密碼檔，且寫入時沒有綁定作者身分。這代表三件事：一，憑證輪換時任務會無聲中斷；二，發布記錄的 author 欄位長期為空，團隊協作時無從追溯責任；三，共用明文檔本身就是安全稽核的常客。

修法並不花俏：憑證遷移至 root 權限目錄、檔案權限收緊至 0600；登入改為先驗證憑證屬於哪個帳號，再走該帳號的 API token；所有寫入必須攜帶 author_id，讓每一次發布都「有名有姓」。便利系統撐不過第一次人員或密碼變動，身分綁定才是長久之計。

三、寫入即校驗，發布即抽檢

第二道保險是流程上的：每篇新稿以 draft 寫入後，立即 GET 回讀，確認 category_id 非空、正文長度達標、標題與 slug 不衝突；通過初審才進入翻譯與發布；發布後再按「每 slug × 三語」逐一 GET 校驗，並抽查文章頁是否落在正確欄目。這套動作不優美，甚至有點笨，但它把「我以為寫進去了」變成「我驗證過寫進去了」——兩者之間的距離，往往就是一次線上事故。

排程器恢復後，Day 115 照常上線。管線還是那條管線，但三道保險已經上膛：應然心跳、身分綁定、寫入即校驗。自動化的盡頭不是全自動，而是可驗證的全自動。