除錯復盤：一個「靜默鏈路」讓高價值檢測視窗滑過去的兩週

上個月我們在一條識別鏈路裡花了一整週排查「模型在特定品類上變差」。最後定位到的根本原因和模型評分本身關係不大——是上游一條時間視窗滑移的鏈路事件，把檢測任務的可用數據拉長了，再疊加一個只有部分團隊知道的離峰運行改動，導致高價值樣本的比對視窗整體向後滑了一段。

把過程拆開看，有四個動作是真正起作用的那部分。

我們當時看到的現象

業務側連續兩天回饋「高價值類別的異常件，第一次被抓到已經是入庫後 8 小時」。監控儀表板上沒有紅字——檢測模型評分正常，吞吐量正常，佇列沒有堆積。這個組合很危險：一切數字看起來都健康，但交付時間已經被吃掉了。

第一步：先查交付時間戳記，而不是先查模型分數

我們將批次的「模型分數交付時間」和「數據鏈路交付時間」分開記錄了一整週。結果是模型分數交付時間幾乎沒動，但數據鏈路因為一次調度離峰，把每天 03:00 的高價值批次壓到了 04:40 才開始檢測。業務側的 8 小時感知，就是從 04:40 算起的。

這一步的教訓：排查「某段視窗變差」時，第一步應該是將時間軸對齊，而不是直接去調模型。分數沒動但交付滑了，十之八九是鏈路上的事。

第二步：給鏈路加一個「下一批就緒」探針

我們加了一個輕量級探針：不檢測業務異常，只確認「上一批數據在 T+15 分鐘內完成了寫入磁碟和分片」。它產生不了任何分數，但輸出了一個過去沒人看的時間戳記。第二週上線後，再做同類問題排查只需要看一條數字，而不是翻三份不同系統的日誌。

第三步：把「離峰運行」寫進變更單而不是群組訊息

那次把 03:00 批次挪到 04:40 的調度改動，是一次為了離峰運行的大促壓力測試準備，只在一個維運群組裡同步過。檢測團隊和模型平台都不知道自己的上游時間軸變了。兩個月後我們補了一條規矩：任何會改動交付時間窗的調度變更，必須寫進當天的變更單，並在變更單裡列出受影響的下游任務負責人。當週就有兩批次差點撞上，提前發現提前改。

第四步：告警閾值跟著交付時間走，而不是跟分數走

最後的事故收斂機制是把告警對象換掉：原來告警盯的是「模型分數低於閾值」，現在同時盯「交付時間戳記晚於計畫 30 分鐘」。分數那條線保留做第二層。因為業務側真正的在意點是「我在什麼時間能拿到判斷」，不是「這個判斷的分數是多少」。

復盤的數字

- 問題佔用排查時間：1 週（其中 6 天在和「為什麼分數沒動」搏鬥）

- 交付視窗滑移實際幅度：約 100 分鐘/天，持續 2 天未被發現

- 交付探針上線後，同類型「遲發現」事件從每月 2 次降到 0

- 告警從分數獨改 → 分數 + 時間戳記雙軌後，第一週內多捕獲 1 次鏈路滑移

值班的一句話

看到「分數正常但有人回饋變慢/變晚」，先查數據進入鏈路的時間戳記，再看模型。大多數時候答案在前者。