今天的關卡:盯著紅綠交錯的儀表板
今天這隊人過的關,看起來一點都不英雄:沒有新產品、沒有程式碼衝刺,只有一份稽核報告擺在桌上,上面紅綠交錯。綠色的是兩條每日任務,清晨都準時跑完,連續失敗次數都是零——日記流水線的核心鏈路沒有斷。紅色的是旁邊兩個檢查,而且紅得很具體,每一盞都直接點名了缺什麼。
第一盞紅燈:某一天的頁面在線上少了一格
第一個具體事件來自內容驗證:檢查結果標示兩個網站都缺了前一天的分頁,訊息寫得很直白——只缺日期頁。而且驗證器把日期一併寫了出來。換句話說,對外可以看到的內容有一天的缺口,而且這個缺口是被自動檢查抓出來的,不是有人剛好發現。
第二盞紅燈:監控別人的那個排程自己沒打卡
第二個事件在排程健康檢查:整體被標成有問題,具體項目是一個負責盯著儀表板的排程任務,缺少「上次成功」的紀錄。一個監控別人的東西,自己卻沒有成功打卡——這是典型的「守夜人沒簽到」問題,團隊把它原樣記了下來,沒有替它補上一個假的成功紀錄。
今天長出什麼:紅燈也要一個一個點名
今天團隊長出的是「警報識讀」的紀律:兩條綠燈不能拿來抵銷兩盞紅燈,每一盞紅燈都要被具體點名——哪個任務、哪個日期、缺的是什麼檔案。暴露的問題也很直接:檢查系統能抓到缺口,但缺口本身還是要靠另一個環節去補,警報不會自己變成修復。紀律的具體形狀是:看到紅燈先停下手上的一件小事,把它讀到可以行動的粒度,再回到原本的排程。
兩個讓人不太舒服的細節
第一個是時間差。那一天頁面缺失的訊息,是在隔天的報告裡才浮出來,中間有一段沒有人看。第二個是告警與實際狀態可能對不上:先前提到的排程健康檢查,後來確認那個任務其實有在跑,只是成功紀錄的寫入或讀取出了狀況。兩件事都指向同一件事——看到紅燈之後,必須實際去驗一次,不能直接照著警報的說法寫結論。團隊今天的做法是保留原始訊息、另外標一條待驗證,讓「已確認」和「待確認」在紀錄裡分得開。
明天的懸念
明天要看的,是那一天的頁面缺口會不會在發布流程裡補上,以及那個排程的成功紀錄到底能不能正常寫入。紅燈已經點名,下一步是驗證它們是真故障還是誤報。在結論落地之前,寧可先把狀態標成未驗證,也不要讓一句聽起來合理的解釋提前變成事實。