positions.updated_at 陈旧 = 数据通道断？健康扫描误报的澄清实录与正确判据三选一

巡检大屏突然飙红，报警信息直指持仓价格滞后了整整四个月。
系统提示 positions.updated_at 停留在六月，距离今天已经跨越了四个自然月。
任何盯着这条告警的人，都会本能地认为底层数据管道已经彻底瘫痪。
实际跑了一遍端到端链路，价格通道却流着正常的血液。

通道其实一直在跑

凌晨两点半，我们手动拉取了六只持仓的最新快照。
对比源直接指向 ReShare 最新收盘行情。
517520 的 AQ 报价显示为 1.88，ReShare 九月三十日收盘价定格在 1.876。
600900 的 28.54 与源端数据严丝合缝。
601318 的 53.29 同样精准对齐。
161226 的 1.83 对比 ReShare 的 1.832，波动微乎其微。
000737 的 13.44 与源端完全一致。
512000 的 0.49 对比 ReShare 的 0.492，链路通畅无阻。

六组数据逐一比对，全部打上了对勾。
价格通道不仅没断，反而在安静地吞吐最新行情。
ReShare 的 stock_data 全表扫描显示，MAX(date) 锁定在最新交易日。
健康扫描的 29 个端点全部返回 OK 状态。
数据管道的工作节奏非常平稳，没有任何卡顿迹象。
这条验证记录直接推翻了四个月前滞后的荒谬结论。

警报是如何被误读的

10 月 7 号的 devlog 里，那条警告标着醒目的三角形符号。
核心诉求是确认 ReShare 价格源是否宕机。
排查脚本的逻辑非常直接，直接抓取了 positions.updated_at 字段做时效性校验。
这个字段记录的是持仓实体的最后修改时间。
只要持仓列表里没有发生新增或卖出，这个时间戳就会原地踏步。
六月之后我们确实没动过仓位，更新停摆属于完全正常的业务状态。
脚本把交易变动时间硬塞进了价格时效判定公式里。
拿错字段的检查逻辑，直接制造了一场系统性的误报。

data_fetcher.py 并没有停止运行，它依然在后台拉取行情。
价格更新机制完全独立于持仓表的修改记录。
运维人员看到陈旧的时间戳，第一反应是去查调度任务。
这种基于静态字段的阈值告警，缺乏对业务语义的理解。
数值再大也只是数字噪音，语义对齐才是监控的底线。
误报产生的根因，往往藏在字段定义的夹缝里。

怎么才算通道真活着

静态时间戳会骗人，我们需要更硬核的判据来锚定健康度。
第一种判据看日涨跌幅。
day_change_pct 当前值为 1.68%，计算逻辑是九月三十日与九月二十九日的价差对比（以 517520 为例：(1.876-1.845)/1.845）。
只要这个百分比不为零，就说明价格数据源在持续刷新。
aq-health-scan.py 的 4a 节点早就部署了这套校验机制。
第二种判据直接查数据库水位。
ReShare 的 stock_data 全表扫描显示，MAX(date) 锁定在最新交易日。
健康扫描的 29 个端点全部返回 OK 状态。
数据源没有滞后，管道运转节奏正常。
第三种判据回归端到端比对。
定期请求 ReShare 的 /api/v1/history/get?days=5 接口。
拿返回的最新日期与业务侧持仓报价做交叉验证。
三者任选其一，都能避开静态字段的陷阱。

判据的设计必须遵循数据流动的客观规律。
价格通道是动态更新的，校验逻辑也必须保持动态视角。
固定时间戳只能反映业务变更，无法反映市场数据。
把波动率和接口返回日期作为核心指标，能大幅降低误报概率。
团队内部已经统一了这套三选一的标准。
后续的健康扫描任务将全面替换旧的校验逻辑。

拿错字段的代价

10 月 8 号的 git 提交 f132061 里，补上了 .devlog/2026-10-08.md。
这篇记录正式推翻了 7 号的误判结论。
ReShare 服务在 0.6 秒内完成全量健康检查。
服务稳定运行在 v0.29.7 版本，资源占用曲线平滑。
这场虚惊暴露出监控体系的一个致命盲区。
告警触发时，运维人员往往直奔数值看阈值。
忽略了字段背后的业务语义，数值再大也只是数字噪音。
系统误报一次，团队就需要花数小时去自证清白。

漏报固然会引发资损，但误报会悄悄透支操作人员的信任账户。
信任一旦见底，下次真出故障时，告警只会变成背景板。
SRE 团队最怕的不是系统沉默，而是系统乱叫。
把字段语义对齐业务动作，才是健康扫描的底线。
下次巡检遇到陈旧时间戳，先问这是交易记录还是行情记录。
看清语义再动鼠标，能省下大半的排查精力。