值班台上先看哪些信号
某球队数据台的值班位，屏幕分成三块：一块是篮球比分捷报的推送流，一块是原始数据源的时间戳，一块是值班人自己的记录表。夜里的比赛密集，值班人通常不会盯着比分本身，而是盯着几个更容易出问题的信号：推送时间戳与源时间戳的差值、同一场比赛在不同来源上的比分是否一致、以及推送频率是否突然变密或变稀。
这些信号背后是一个朴素的约束：篮球比分捷报的价值不在于“快一秒”，而在于“可核对”。如果一条推送无法回溯到源时间戳，那它在值班台上就只是一个孤立的数字，出了问题也没法定位。
- 看时间戳差值：源时间戳与推送时间戳的间隔是否稳定。
- 看一致性：同一场比赛在两个来源上的比分是否同步。
- 看频率：推送间隔是否出现异常的密集或稀疏。
- 看字段完整性：比赛状态、节次、剩余时间是否齐全。
篮球比分捷报最常见的断点
值班记录里反复出现的断点，大致可以归成几类。它们往往不是同时发生，而是沿着链路一层层往下走。
- 源站限流：请求频率过高，源站返回空数据或延迟响应。
- 字段缺失：比分有更新，但节次或剩余时间没跟上，导致展示错位。
- 时区错位：跨时区赛事的时间戳被按本地时间解读，值班人误判为延迟。
- 缓存过期：中间层缓存没有及时刷新，推送流里出现重复的旧比分。
- 网络抖动：推送通道短暂中断，恢复后一次性补发多条，造成“突然变密”的假象。
值班时最容易误判的一种情况：推送频率突然变密，值班人第一反应是“比赛节奏快”，但实际往往是通道恢复后的补发。先看时间戳，再下结论。
按顺序推演一次排查
排查顺序比排查工具更重要。值班台上的推演通常从最靠近源的一端开始，逐层往推送端走，避免在中间层反复试错。
- 先确认源时间戳是否在更新。如果源本身没动，问题不在推送链路。
- 再看中间层缓存的时间戳。如果源更新了但缓存没动，问题在缓存刷新。
- 接着看推送流的时间戳与源时间戳的差值。如果差值突然拉大，问题在推送通道。
- 最后看展示层的字段完整性。如果时间戳都对，但节次或剩余时间错位，问题在字段映射。
这个顺序的边界在于：它假设源是可信的。如果源本身出现异常，比如同一场比赛在两个源上比分不一致，那就需要先判断哪个源更接近现场，而不是继续往下推。 篮球比分捷报
什么时候该回滚
回滚不是失败，而是值班台上的一个正常动作。判断是否回滚，通常看两个条件：一是错误是否已经影响到展示层的可读性，二是修复路径是否比回滚更慢。
- 如果推送流里出现连续多条错误比分，且无法快速定位到单条，回滚到上一个稳定版本。
- 如果只是个别字段缺失，且能在展示层做降级处理，可以先不回滚。
- 如果回滚成本高于等待修复，比如回滚会丢失已确认的比分，那就先记录、再修复。
回滚之后，值班人通常会在记录表上留一行：回滚时间、回滚原因、回滚后的观察窗口。这行记录不是为了追责，而是为了让下一个值班人知道这条链路刚刚动过。
收尾时留下的核对清单
值班结束前，核对清单是留给下一个人的交接。它不需要很长，但需要覆盖刚刚动过的每一个环节。
- 源时间戳是否仍在正常更新。
- 中间层缓存是否已恢复到稳定刷新频率。
- 推送流的时间戳差值是否回到正常区间。
- 展示层的字段是否完整，节次与剩余时间是否对齐。
- 回滚记录是否已写入值班表，观察窗口是否已标注。
这张清单的边界是：它只覆盖值班人刚刚接触过的链路。如果链路本身发生了变化，比如换了源或改了推送通道，清单需要重新推演，而不是直接沿用。