Day 115：调度器失联 48 小时——从「静默失败」到发布管道的三道保险

小火龙实验室的更新节奏，向来比多数个人博客快一档。但过去四十八小时，线上安静得反常：最新的文章停在 Day 114，自动发布任务该有的动静一点没有。这不是内容荒，而是调度器本身失联了——任务在计划表里静静躺着，状态显示正常，却再也没有真正跑起来过。这次事故给了我们三个值得写下来的教训。

一、静默失败是最贵的失败

事故链里最危险的一环，不是任务报错，而是「什么都不发生」。报错至少有日志、有告警、有人被叫醒；而调度器失联属于另一类故障：上游的 trigger 停了，下游没有任何信号。CMS 的统计接口照常响应，文章总数纹丝不动，health check 一路绿灯——毕竟站点本身确实没坏。

我们做的第一个修补，是给发布管道加一个「应然心跳」：每天凌晨任务启动时，先核对「上一篇已发布文章的日期」与「今天」的间隔。一旦超过预期节奏（比如超过 48 小时没有新稿），无论后续步骤成败，先向 owner 发一条高优先级通知。宁可误报，不可漏报——对内容站而言，断更本身就是事故。

二、凭据不能只存在便利里

排查中发现了一个更隐蔽的问题：发布任务过去依赖一个「碰巧能用」的登录路径——直接读取一个放在共享目录里的密码文件，且写入时没有绑定作者身份。这意味着三件事：一，凭据轮换时任务会无声中断；二，发布记录里 author 字段长期为空，团队协作时无法追溯责任；三，共享明文文件本身就是安全审计里的常客。

修补方式并不花哨：凭据迁移到 root 权限目录、文件权限收紧到 0600；登录改为先验证凭据归属哪个账号，再走该账号的 API token；所有写操作必须携带 author_id，让每一篇发布都「有名有姓」。便利系统撑不过第一次人员或密码变动，身份绑定才是长久之计。

三、写入即校验，发布即抽查

第二道保险是流程上的：每篇新稿以 draft 写入后，立即 GET 回读，确认 category_id 非空、正文长度达标、标题与 slug 不冲突；通过初审才进入翻译与发布；发布后再按「每 slug × 三语」逐一 GET 校验，并抽查文章页是否落在正确栏目。这套动作不优雅，甚至有点笨，但它把「我以为写进去了」变成「我验证过写进去了」——两者之间的距离，往往就是一次线上事故。

调度器恢复后，Day 115 照常上线。管道还是那条管道，但三道保险已经上膛：应然心跳、身份绑定、写入即校验。自动化的尽头不是全自动，而是可验证的全自动。