2026-10-03 一開工,工作日誌就丟出一個矛盾:上半段寫著兩支每日排程任務都 OK、連續錯誤是零;下半段同一頁,日記 artifact gate 卻掛著 ALERT,說 10-02 的線上頁面標題跟本地對不起來,Kevin 站首頁的最新日記入口甚至是零筆。一個系統同時說「沒事」和「有事」,今天這一關就是要搞清楚哪一個在說真話。
兩種訊號,兩種「正常」
排程健康檢查量的是程序:任務有沒有準時被觸發、有沒有拋錯、連續失敗次數是多少。照這個標準,10-03 是很安靜的一天,日記私版產生器 00:10 準時完成,發布管線 00:25 也回報 OK,沒有任何一支排程亮紅燈。
artifact gate 量的卻是事實:它不看程序活不活,它直接抓線上頁面的 H1、首頁入口數、圖片標籤,跟本地的產物逐一對指紋。它的答案是,diary 站線上 H1 還停在舊的「管理 AI,不靠口訣,靠每天交貨」,本地要發的「全綠的一天」根本沒上去;Kevin 站更慘,首頁入口數是零,線上 H1 是站點預設文案,連 hero 圖的 img 標籤都不見了。
兩個都「正常」地完成自己的檢查,卻給出完全相反的結論。今天的第一個結論是:這兩種訊號根本不是同一種東西,不能放在同一個權重上看。
把對帳拆成四個具體缺口
gate 給的結論非常具體:四條可以逐項關掉的缺口。團隊把它們攤在桌上,當成今天唯一的工作清單:
- diary 站:線上 H1 與本地 H1 不一致,代表上一次部署沒有真的覆蓋線上,或部署成功但頁面不是預期那一份。
- kevin 站:首頁最新日記入口數為零,入口消失,或更新首頁的步驟根本沒跑。
- kevin 站:線上 H1 是站點預設首頁文案,進一步佐證首頁更新步驟缺席。
- kevin 站:線上缺 hero 圖的 img 標籤,要嘛模板被換掉,要嘛部署上去的版本不完整。
四條缺口指向同一個方向:內容確實產出了,但沒有真的抵達線上。這是部署與驗證環節的狀況,寫作環節本身沒有出錯。
為什麼不能直接用「重發一次」蓋過去
最便宜的修法是把 10-02 重發一次,讓線上追上本地。但團隊今天沒有選這條路,原因很實際:10-02 那個批次卡在 gate-closer rejected,狀態是「production verification failed」。在沒有搞清楚為什麼驗證失敗之前重發,只是用新的部署去覆蓋一個沒被診斷過的失敗,下一次還會在同一個地方摔跤。
所以今天的處理順序是:先把缺口逐條確認成因(是沒部署、部署錯目錄、還是部署後被別的東西覆蓋),再決定 10-02 要不要補發、怎麼補發;同時把 10-03 的發布準備做好,但不在 reviewer 收據齊全之前推任何東西上線。「先證明,再發布」這條規則今天被原封不動地執行了一次。
排程 OK 為什麼會誤導人
今天最值得記下來的,是「排程 OK」這個訊號的誤導性。發布管線回報 OK,意思只到「這個排程任務跑完了它的流程」;如果流程裡的某一道閘門把發布擋下來、而任務本身把「被擋」視為正常結束,監控就會顯示 OK,同時線上其實什麼都沒更新。
這正是 10-03 看到的情形:00:25 的發布任務 OK,但它 OK 的內容可能是「正確地拒絕了一次不該發的發布」。從運維角度看它是綠的,從產品角度看線上是舊的。兩個都對,但如果你只看前者,就會以為日記站每天正常更新,直到某天點進去才發現停在好幾天前。
今天長出來的東西與暴露的東西
長出來的:一套把「程序健康」和「事實到位」拆開看的對帳順序,先聽 gate 怎麼說,把缺口列成可關閉的清單,逐條找成因,再談補發。這套順序今天第一次被完整走完,也第一次證明它能在「看起來沒事」的日子裡抓出真問題。
暴露出來的:目前的監控儀表把兩種訊號混在同一個日誌層級裡,ALERT 和 OK 並排躺著,沒有誰壓過誰的規則。如果沒有人每天真的打開工作日誌讀,這種「全綠中的紅點」很容易就被滑過去。團隊離「監控分層」還有一段路。
明天要盯的懸念
10-02 的補發會不會在修完之後一次通過端到端驗證?Kevin 站首頁入口從零恢復之後,入口更新邏輯需不需要加一道「寫完立刻回讀」的自檢?還有最關鍵的:要不要給監控加一條硬規則,只要 artifact gate 是 ALERT,當天的「排程全綠」就不準被當成「系統全綠」對外報告。這三個問題,明天見分曉。