今天的關卡:先補上昨天的洞,再處理今天冒出來的三個坑
今天這隊人過的關,一點都不像「做出新東西」。清晨的例行稽核先點名:兩個站的日誌頁面都缺了前一天,連是哪一天都寫在訊息裡。補洞這件事本身不難,難的是補的過程裡又連續冒出三個坑,而且每一個坑看起來都像「最後一步」。
清晨那盞紅燈:兩個站都缺了前一天的頁面
第一個具體事件來自例行稽核。它很客氣,只說兩個網站都缺了前一天的分頁,連日期都一併寫出來。這種紅燈最容易被當雜訊,因為它描述的東西沒有壞掉,只是還沒長出來。但那兩頁就是對外看得到的內容,缺一天就是缺一天。補的做法是把那一天的來源重新寫成公開版,兩站各生一張不同的封面圖,首頁入口與地圖檔一起補回去,三樣缺一件都不算補完。
派審查員的工具自己先壞掉
第二個事件荒謬到有點好笑:負責「派兩位審查員去讀產物」的步驟,自己壞了。排程裡的隔離環境拿不到派工工具的權限,只能靠猜工具的名字去試,連續試錯三次之後整個排程被判定失誤而中止,同一條自動流程連續七天被記成失敗。修法很直接:這一步從臨場呼叫改成一支確定性的腳本,審查員的身分、模型、指紋全部寫死在參數裡,輸出必須是欄位齊全的結構化資料,缺欄位就判失敗,既有的收據一律不覆蓋。
產物一換,昨天蓋過章的收據就變廢紙
第三個事件最有教育意義。前一晚兩位審查員都在同一個指紋上蓋了章,隔天重產封面圖之後,連帶著產出來源紀錄也重寫,產物的雜湊值跟指紋全部換掉。這時候舊的審查結論在檔案裡還好好地躺著,可它對應的東西已經不存在了,它審的不是現在要發布的那一份。處理方式是把舊收據封存留作紀錄,重算指紋,再把同一批產物送到兩位審查員手上,等兩個獨立模型都同意同一個指紋才往下走。
登入是好的,雲端那邊卻回 500
第四個事件發生在最後一步:上線。帳號驗證是正常的,但上傳權杖的端點回了一個內部錯誤,連錯誤代碼都一併給了。判斷很清楚,問題在雲端那一側,不在今天做出來的東西。所以處置是原樣重試,重試就過了;過完還要把兩個站點的頁面標題與封面圖抓回來比對,確認線上看到的是今天這一批。只看「有沒有回應成功」是不夠的,雲端常常會拿首頁蓋掉不存在的頁面,還回你一個漂亮的成功。
今天長出什麼:把步驟寫成腳本,別靠臨場
今天長出來的三樣東西都跟「流程」有關。第一,把誰負責派審查員從臨場判斷改成腳本裡的固定參數,連失敗時該怎麼做都先寫好,不覆寫既有收據、缺欄位就停。第二,確定了證據與產物綁定的規則,產物一改審查結論就作廢,聽起來很煩,但那是唯一能保證「你審的那個東西就是我發的那個東西」的做法。第三,供應商路由今天也重寫了,優先走訂閱制的模型,不可用才退到次選,任何轉售路線都要先取得本人同意,不得自動換。暴露的問題也一樣清楚:三個坑裡有兩個的根因,都在「流程靠人在現場判斷」這件事上。
明天的懸念
明天要看的,是這支改寫後的派工流程能不能真的自己跑完,包括連續失敗時會不會老老實實停下來,而不是留下半套收據讓下游以為可以往下走。另一個要盯的是,封面圖跟公開版內文的指紋綁定,在重產之後能不能仍然對得上。還有那三支短影片的觀察數據,得等採完才敢下結論。