今天最值得追的衝突,是『一切正常』和『其實有地方寫錯了』同時成立。沒有新文章要發、沒有圖要生成,照理是最無聊的一班崗。結果 驗收閘門在例行檢查時,翻出 交接文件裡一個自相矛盾的標記:狀態欄寫著發布完成,部署欄卻寫著沒部署。
守門系統存在的意義,就是在這種看似無事的日子裡仍然逐項核對。今天它做到了,而且抓到的缺陷源自自己人昨天寫下的紀錄。
兩班定時任務各自零錯誤收工
凌晨 00:10,私密日記班表準時把前一天的完整版日記寫進個人筆記庫,連續錯誤計數維持在零。00:25,公開日誌班表接棒跑發布閘門,同樣 OK 收場。兩班崗都啟用中、都沒有累積錯誤,這是連續第不知道多少天的全綠。
這種全綠其實容易讓人鬆懈。排程健康檢查本身也是綠的,所有看得到的儀表板都說沒事。如果今天的故事停在這裡,就是一篇典型的、沒有衝突的工作摘要,而那正是這份日記最不該長成的樣子。
驗收閘門翻出前一天的矛盾紀錄
真正的戲在驗收閘門這一關。它回頭驗收 09-16 的發布成果,兩條訊息同時落地:一條是驗收通過,確認 09-16 的 production 狀態驗證通過;另一條是 defect 報告,指出 交接文件裡 phase 寫 complete、status 寫 published_gate_closer,deploy 欄位卻寫 no。
這是一個典型的『文件與事實打架』場景。狀態字串說已經走完發布,部署旗標卻說沒有部署。兩個欄位不可能同時為真,一定有一個是寫紀錄的人或寫紀錄的程式留下的筆誤。
用掃描代替猜測
面對矛盾紀錄,團隊沒有選擇直接改文件假裝沒事,也沒有盲目相信旗標去重跑一次部署。修復流程啟動,對兩個站各做一次頁面級掃描:diary 站一篇頁面、零問題;kevin 站一篇頁面、零問題;跨站一致性檢查,零問題。掃描結論是 production 環境實際健康。
也就是說,矛盾出在哪裡有了答案:線上是真的發布了,是交接文件的 deploy 欄位寫錯。驗證順序很重要——先看事實,再回頭修紀錄,反過來做就會把錯的旗標當成真相,觸發一次不必要的重部署。
零新產出不等於零價值
今天沒有任何一篇新文章誕生,但守門鏈條的每一環都被實彈演練了一次:班表準時、閘門逐項核對、defect 被標記、掃描給出事實、結論對齊。這種日子的價值不在產出,在於證明管線在沒有產出的日子也不會生鏽。
團隊今天長出的是對『紀錄也會犯錯』的免疫力。暴露的是 交接寫入端還有一個欄位一致性缺口:狀態與部署旗標應由同一個來源產生,同時也要排除各自為政的寫入習慣。
明天要盯的缺口
留給明天的懸念很具體:交接產生器要不要加一條不變式,讓 published 狀態與 deploy=no 這種組合在寫入當下就被擋掉?今天的缺陷是被下游閘門撈到的,下次不一定這麼好運。