排障复盘：一个「静默链路」让高价值检测窗口滑过去的两周

上个月我们在一条识别链路里花了一整周排查「模型在特定品类上变差」。最后定位到的根因和模型评分本身关系不大——是上游一条时间窗口滑移的链路事件，把检测任务的可用数据拖长了，再叠加一个只有部分团队知道的错峰运行改动，导致高价值样本的比对窗口整体向后滑了一段。

把过程拆开看，有四个动作是真正起作用的那部分。

我们当时看到的现象

业务侧连续两天反馈「高价值类别的异常件，第一次被抓到已经是入库后 8 小时」。监控面板上没有红——检测模型评分正常，吞吐正常，队列没有堆积。这个组合很危险：一切数字看起来都健康，但交付时间已经被吃掉了。

第一步：先查交付时间戳，而不是先查模型分

我们把批次的"模型分交付时间"和"数据链路交付时间"分开记录了一整周。结果是模型分交付时间几乎没动，但数据链路因为一次调度错峰，把每天 03:00 的高价值批次压到了 04:40 才开始检测。业务侧的 8 小时感知，就是从 04:40 算起的。

这一步的教训：排查"某段窗口变差"时，第一步应该是把时间线对齐，而不是直接去调模型。分数没动但交付滑了，十有八九是链路上的事。

第二步：给链路加一个「下一批就绪」探针

我们加了一个轻量探针：不检测业务异常，只确认「上一批数据在 T+15 分钟内完成了落盘和分片」。它产生不了任何分数，但输出了一个过去没人看的时间戳。第二周上线后，再做同类问题排查只需要看一条数字，而不是翻三份不同系统的日志。

第三步：把"错峰运行"写进变更单而不是群消息

那次把 03:00 批次挪到 04:40 的调度改动，是一次为了错峰运行的大促压测准备，只在一个运维群里同步过。检测团队和模型平台都不知道自己的上游时间线变了。两个月后我们补了一条规矩：任何会改动交付时间窗的调度变更，必须写进当天的变更单，并在变更单里列出受影响的下游任务 owner。当周就有两批次差点撞上，提前发现提前改。

第四步：告警阈值跟着交付时间走，而不是跟分数走

最后的事故收敛机制是把告警对象换掉：原来告警盯的是"模型分低于阈值"，现在同时盯"交付时间戳晚于计划 30 分钟"。分数那条线保留做第二层。因为业务侧的真实同意是「我在什么时间能拿到判断」，不是「这个判断的分数是多少」。

复盘的数字

- 问题占用排查时间：1 周（其中 6 天在和"为什么分数没动"搏斗）

- 交付窗口滑移实际幅度：约 100 分钟/天，持续 2 天未被发现

- 交付探针上线后，同类型"迟发现"事件从每月 2 次降到 0

- 告警从分数独改 → 分数 + 时间戳双轨后，第一周内多捕获 1 次链路滑移

值班的一句话

看到"分数正常但有人反馈变慢/变晚"，先查数据进链路的时间戳，再看模型。大多数时候答案在前者。