跑得稳：不盯也能跑

第 1 篇文章里,我反思过「把跑得稳的复杂度提前了」:任务表、webhook、备份恢复,这些是「万一」的保险,不该在能跑阶段出现。现在到了跑得稳,这些当初被砍掉的东西,到了该引入的时候。原则还是那一条:按真实痛点逐个引入,不是一次全上。

任务表:跑批第一次有了记录

之前的 pipeline 是手动跑,跑的过程只在终端里,失败只能看屏幕。跑得稳做的第一件事是任务表:每次运行记一条——类型、状态、参数、日志路径、起止时间、退出码、错误信息。用的 SQLite,Python 内置,零新依赖。

再配上日志落盘,每次运行的完整输出写到 data/logs 下,任务表和日志用路径关联。从此跑批可追溯:哪天跑的、跑成什么样、失败在哪一步,翻表就知道。

调度:写进代码,不依赖宿主 cron

盘后自动跑,最传统的做法是 cron,一行配置。但我不想用——将来系统要 docker 部署或本地代码部署,cron 是宿主环境的依赖:容器里不一定有,本机还要单独配。调度这种每天都发生的事,最好就在代码里。

所以调度器是一个常驻进程:每天工作日 17:03 检查一次,到点直接调用 pipeline 的函数,不经过 shell。加一个 --now 参数,首次启动立即执行一次。docker 部署时跑一个 scheduler 进程,本地部署也跑同一个进程,逻辑完全同构;手动跑就用 CLI,和调度器走的是同一个执行体,行为一致。

这个决策也顺带被环境验证了一次:运行环境里没有 cron、没有 sudo,装不了系统级调度——那就把调度本身写进代码,反而更干净。

备份和告警:一个先做,一个克制

备份便宜,先做:每次拉数后把数据文件按日期存一份,保留最近 14 份。数据 1MB 出头,重拉一次也就两三分钟,但「数据被搞坏了能回滚」是验证信号里的硬要求,成本低就先上。

告警克制:失败时发通知的能力做成可配置,默认关——因为「失败没发现」这个痛点还没真实出现,等手动跑几周真的漏过事,再把 webhook 地址配上。如果现在就接一堆通知渠道,就是重复第 1 篇的错误。

验证:机制就绪,一周观察待部署

跑得稳的验证信号是「一周不盯也能跑」:数据最新、失败有告警、数据有备份。机制层面我都验证了:任务表三种状态记录正确、失败模拟能写错误信息、备份正常生成。

但有一条必须诚实:真正的一周自动运行,需要部署到实际环境跑一周才能确认——本机验证的是机制,不是持续运行。机制就绪不等于验证完成,这一步留给部署。

跑得稳做完,系统从「手动跑」变成了「可以自己跑」。任务表把每次运行变成可追溯的记录,调度让数据每天自动更新,备份兜底,告警待痛点触发。当初设计稿里被砍掉的东西,在对应痛点出现时,一件一件回来了。