报告每天准时出,数据停在 13 天前

我有一套自动跑的期权日报:每个交易日 17:00,定时任务生成一份带波动率、 风险溢价、期限结构的报告,推到我手机上。

跑了两周,每天准时,格式完美,没有一次报错。

直到某天我为了复盘一次大行情去翻原始数据,才发现:数据层最后一次更新是 13 天前。

失败长什么样

定时任务里配的是"生成报告"那个脚本。而更新研究数据层的是另一个脚本, 从来没被加进定时任务。数据层是建库那天的一次性快照。

于是这 13 天里,报告每天都在用同一份两周前的数据,重新算出一套"今天的"指标。 其中风险溢价那一段,因为新旧数据的时间错位,符号是反的——报告告诉我的方向, 和市场实际的方向相反。

没有任何一个环节报错。日志全绿。推送成功。

为什么这类故障特别难发现

崩溃是响亮的:进程死了,你收不到报告,十分钟内就知道出事了。

数据冻结是安静的:你照常收到报告,它照常有数字,数字照常在小数点后两位波动 (因为公式里还有别的输入项在变)。你的注意力被"我收到了报告"这件事满足了, 不会再去问"这些数字是从哪天的原料算出来的"。

更糟的是,人对熟悉的输出会降低审视强度。第一天你会仔细看,第十天你只扫一眼标题。 输出的稳定性反而成了掩护。

我改了什么

三件事,按重要性排序:

1. 每一个产物都必须自带数据时点。 不是脚本的运行时间,是原始数据的最后日期。 两者必须都显示,而且并排显示。运行时间是"我什么时候算的",数据时点是"我用的是什么时候的原料"—— 这两个东西不一样,长得也不该一样。

2. 陈旧就报警,而且报警要挡在结论前面。 数据超过 N 天没更新,报告顶部直接挂一条 醒目的告警,不是写在末尾的小字。如果超过阈值更多,宁可不出那几段结论, 也不要出一段基于陈旧数据的判断。一份缺了两段的报告是有用的; 一份全须全尾但方向反了的报告是有害的。

3. 分叉检测。 我的站点会比较"源文件的修改时间"和"上次同步进库的时间"—— 源比库新,就说明数据分叉了,页面上明确标 stale。宁可让页面难看, 不能让它安静地展示旧数据。

一条更通用的原则

任何自动化产物,都必须能回答一个问题:你用的是哪一天的原料?

回答不了这个问题的报告,不该被信任;能回答但你从没检查过的,等于没回答。

这条对交易系统尤其致命:一个指标的数值可以陈旧但看起来合理,而你会照着它下单。 报错会让你停下来,陈旧数据不会。

本文描述的是我自己的个人研究系统,涉及的都是公开市场数据。修复方案已落地, 问题记录在案。