流水线一直报告成功，为什么数据还在落后？

设想一个采集任务遇到上游接口新增的记录格式：客户端解析不了，就把记录退回队列；退回这一步成功了，任务便报告成功。仪表板一直亮着绿灯，数据却越来越落后。

没有次数上限的重试，会让这种故障一直持续下去。同一个请求重复再多遍，解析器也学不会新格式。永久性的不兼容，需要单独的错误状态和修复流程。

一个重试循环，能把隔壁的流水线一起拖垮

几条数据源如果共用同一个服务商配额，故障数据源的重试就可能挤掉正常数据源所需的容量。给每个来源单独的预算，再在共享出口统一限流，故障就不会扩散。

修好解析器之后，要逐步重放积压记录。对照来源数量和入库数量，检查重复记录，并观察服务商的限流响应。部署成功，几乎说明不了缺失的记录是否真的补上了。

让助手看到数据的缺口

数据不完整，助手照样能写出一份很有把握的解释。问它业务活跃度为何下降，它可能先猜一个业务原因，而没去查采集是不是出了错。检索结果要附带覆盖范围和更新时间，助手才能指出缺口，拒绝做没有依据的比较。

数据采集需要单独的验收标准：哪些来源必须到齐，最多允许晚多久，用什么核对办法证明完整。应用就算从索引里找对了文档，只要索引本身缺了一块，业务问题照样可能答错。

给重试设上限，再核对结果

重试这条路径，既要有上限，也要有办法把缺失的记录找回来。

每个重试循环都要有上限，达到上限的条目进入死信队列，并且真的有人去看。条目里要带上来源、失败类别和最后一次尝试的时间，负责人才好排查。

保留具体的错误类别，以及足够定位问题的脱敏细节。光有「unable to parse」不够，还要有对应的字段、格式版本和追踪编号，同时别把机密载荷复制进日志。

告警除了盯错误，还要盯处理量和等待时长。与可比时段相比明显下降，即使每个任务都报告成功，也值得调查。队列等待阈值要按交付承诺来定，并把计划内的低流量时段考虑进去。

遇到有限流的服务商，每个数据源各有自己的预算，一个出故障的数据源就没法把其他数据源饿死。

留一份业务动作的历史

解释数字变化，往往还需要一份业务动作的历史记录。在 Bilibili 演讲中，Zara Zhang 讲到一位分析师，他的代理会从获准读取的聊天、文档和会议纪要里收集业务动作。这样，暂停一次投放就能和指标变化放在一起考虑。不过这只是一条值得追查的线索，证明不了因果关系。

缓存又加了一道时效边界。一个数字写入时可能是对的，来源变化之后就可能误导人。每个对外报告的数值都要标明来源更新时间和新鲜度，过期的值要让人一眼看出来。

两项指标，还得有人负责

给报表或助手供数的流水线，可以先加两项指标：最老的待处理记录等了多久，以及实际接收的记录数与预期基线相差多少。和这条数据源的负责人一起定阈值，触发一次测试告警，并指定谁来响应。否则新图表也会和原来的绿灯一样，摆在那里没人注意。