停机 12 天后：三处没人发现的丢失

机器停了 12 天。开机之后，调度器把错过的任务一次性铺开补跑，五分钟里 6 个任务被模型服务商以请求过于频繁拒掉。4 个后来补上了，2 个再也没有跑起来，那一天的产出是零。没有一条报警。

崩溃会喊，停止不会

那两件没有产出的事，一件是每天 19:00 跑的战略雷达，一件是每 8 小时跑一次的内容引擎。我们是在第二天早上看到有人在频道里问「昨天怎么没有报告」，才知道它们断了。

原因是这两件事的失败方式正好落在监控的盲区里。告警系统的默认判据是进程还在不在、退出码是不是 0，而一个静默停止的任务在这两项上都正常，它只是没有结果。也就是说，监视器在看你有没有跑，没有看你有没有产出。这两件事绝大多数时候一致，一旦不一致，屏幕上一切正常，实际产出为零。

我们的判断是：自动运行的系统里，最贵的故障不是崩溃，是没有报错的停止。崩溃会留下退出码、堆栈和一条告警；停止什么都不留，只留下一个空的时间格。判断一个任务是不是真的在跑，唯一的硬证据是它今天的产物在不在。

第二处：前提条件消失，脚本安静退出

每周一早上刷新关注列表的任务连续失败了三周。它要连一台既登录着平台、又开着远程调试端口的浏览器，而这台机器上已经没有这样的浏览器。脚本连不上就退出，什么都不写。

三周之后翻到那份关注列表，还是 9 月 21 日那一版：45 个账号。三周里没有一个人、没有任何一份报告提到过它。真正的问题是它的失败条件不是代码缺陷，而是环境前提：没有浏览器可连，对脚本来说就等于这次没有事情可做。

这类任务在健康检查里永远是健康的，因为失败长得像成功。修法很具体：把外部依赖写成显式检查（登录态在不在、端口通不通、配额还剩多少），前提不成立时留下一条记录再退出。一行检查加一行记录，成本远低于三周的静默。

第三处：过期被当成不成立

同一天，8 张中等优先级的卡在同一秒被系统以挂得太久为由自动取消。按证据，至少两张底下的问题没有修：一张是交给智能体的指令文件超过了上下文上限，被静默截断，任务跑完了，但读到的是半份规则；另一张是分钟级行情的标的名单不包含观察名单，止损引擎的相似日模拟覆盖率被锁死，它的下游卡至今还挂着。

取消记录上写的是自动取消。四个字读起来像已经处置。

我们的判断是：过期规则解决的是队列太长，用的是时间这个替身变量；时间戳只能说明没人动过它，不能说明问题消失。把两者等同，等于让系统替你宣布一个它没有证据支持的结论。自动关闭应该区分处理完了和没人看：前者要有证据，例如下游引用清零、验证通过；后者只能标记为待复核。

三处丢失指向同一个缺口

三处的共性是一个缺口：任务有跑过没有的记录，没有产出在哪的记录。判据挂在过程上，结果层面的丢失就永远查不出来。

把判据从过程换成产物

这套改法不需要新系统，五件事按顺序做完就够：

外部证据指向同一条线。IBM 商业价值研究院 2026 年 6 月对 2,000 位技术高管的调查里，70% 说业务团队部署技术的速度快过 IT 的追踪能力；Salesforce 2026 年 5 月对 2,025 位决策者的调查说，多数部署者上线时只带了一部分监督，其余是上线之后补的。两句话说的是同一件事：正在运行的东西比有主的东西多。产物清点是让两者重新对上的最便宜的方式。

这套做法的边界

边界一：有的任务天然不落盘，比如只往频道里发一条消息。这时候至少要把发过这件事写成记录，否则它和没跑没有区别。

边界二：产物在不在，证明的是跑过，不是跑对。产出正确需要另一套东西：评估集、抽检、发布前的回归闸门。把两者混在一起，会得到一个看着很忙的账本。

边界三：巡检自己也会坏，所以巡检也要落产物。我们的巡检每天写一行字，说它查了多少个任务、有几个缺产物；它断掉的那天，这一行会消失，那就是信号。

对四种角色的含义不一样。AI 应用负责人拿到的是一个今天就能写完的巡检脚本；数字转型负责人拿到的是一条新的验收判据，看今天的产物而不是平台开通数；C 层拿到的是日报里该出现的数，产物数而不是任务数；合规负责人拿到的是缺口记录，没有产出的那些天必须有人写下原因，否则事后无法解释。

我们的判断

让停止发出声音的成本，比让系统不出故障低一个数量级。我们把这套做法写进了自己的运行规则：任务开工前先声明产物，收尾时核对产物是不是真的在磁盘上，对不上就不算完成。规则起作用的地方不是故障变少了，而是故障不再需要被人偶然发现。

今天早上打开你的定时任务清单，逐个问一句：昨天它的产出在哪？答不上来的那些，就是下一次停机时会消失的部分。

为什么普通监控抓不到这三类停止

监控指标通常分三层：心跳、退出码、日志量。三层各有一个失效方式。心跳回答不了跑了但没有结果；退出码回答不了脚本认为无事可做；日志量回答不了日志写满了、里面全是重试失败。三类停止分别打在其中的一层上，所以任何单独一层的监视都看不见它们。

这意味着加一个告警不是解法。解法是把判据从过程层移到结果层：不问这次运行成不成功，问今天该有的东西在不在。我们后来改的就是这个方向。同样的停机再发生一次时，缺产物的清单会直接出现在早报里，而不是等人来问。

补跑是一个物理问题

12 天的工作要在 5 分钟里补完，撞上的是服务商按分钟计的请求上限。这类上限不会因为你是老客户而消失，也不会因为任务重要而让步。所以补跑必须有排队和优先级：先补会阻塞别人的任务，比如数据刷新和状态同步；再补只影响自己的任务，比如日报和摘要。

我们的选择是给补跑加两道闸：一是并发上限，二是把被拒的请求写进一份未完成清单，清单进第二天的巡检。代价是有些事会晚一天，收益是没有事会悄悄消失。对多数团队来说，晚一天比没有要好接受得多。

可以照抄的巡检清单

把它当成一张每天跑一遍的表，五列：

这张表的价值不在漂亮，在于它能在没有任何外部信号的情况下，把今天少了什么说出来。我们自己的版本每天输出一行汇总：查了多少个任务，几个缺产物，几个前提不成立。

和事后解释的关系

没有产出的那些天，如果没有记录，事后是无法解释的。你只能说明系统当时在运行，说明不了它为什么没有结果。复盘和审计要的是可复现的时间线，而时间线是一行一行记录拼出来的，不是靠回忆拼出来的。

静默停止的代价经常被低估的地方在这里：它不会造成一次事故，但它会让一段时间变成空白，而空白事后会被填上猜测，猜测通常落在当时在场的人身上。

三个常见的反驳

这三条我们都在内部遇到过，最后落到同一个判断上：把产物的定义写得足够小，一条记录也算，清单就能覆盖全部任务。

一天空白损失了什么

这一天没有产出，损失不是可以按小时折算的工作量，而是时间锚点。战略雷达按天扫，缺一天，第二天看到的是拼在一起的两天信号，判断只能按更晚的窗口去读；内容引擎缺一天，第二天要么补一批，要么少一批。两种处理都会改变后面的节奏。

更贵的是没人知道缺口存在。我们是由人在第二天早上问出来的。如果那天的频道恰好安静，缺口会一直挂着，挂到某个下游动作用到它为止。这是我们把巡检放进流程的原因：它负责让缺口早一天被人看见，而不是等缺口自己浮上来。

参考来源：本文第一部分的三处运维事实来自 OOMeta 自有运行记录；外部证据见下列来源。IBM Institute for Business Value《CIOs and CTOs Face Growing AI Control Gap》，2026-06-08，newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales ；Salesforce《State of Agentic AI in the Enterprise》，2,025 位受访者，2026 年 5 月，www.salesforce.com/news/stories/agentic-ai-leaders-survey-on-roi 。