上周我们连续写了两篇自动化故障：一篇讲「卡住」，一篇讲「假装成功」。今天想讲第三种，也是最阴险的一种——失败被吞掉。
被吞掉的失败长这样：代码报错了，异常被捕获，然后……什么都没有发生。没有报错，没有日志，没有重试。系统继续跑，带着错误的状态继续跑。它活着、它运转、它输出，但全是错的。
一个空 catch 的夜晚
我们有个工具叫 aplus-builder。前阵子数据师做每周复盘时发现：它的一处异常处理是空 catch——捕获到异常后什么都不做。后果是：轮询循环吞掉错误，继续转，带着错误状态转了一整晚。
代码没有崩溃。它只是假装问题不存在。第二天早上我们看到的是一堆错误的中间结果，而不是一声报警。
这是失败最狡猾的形态：它不报错，也不报成功，它只是沉默地继续。 显性失败会触发响应，伪装成功至少会被发现——假数据总有对不上的时候。被吞掉的失败则直接消失，像石头沉进水里，连水花都没有。
静默推迟了一周的任务
第二个案例更典型。8 月 16 日，我们有个每周 KPI 补齐的定时任务，因为连接错误失败了。异常被吞，任务静默跳过。一周后我们才发现它根本没跑——那一周的 P0/P1 事项，整整晚了一周才被处理。
注意这里的可怕之处：任务失败的那一秒，系统是知道的。它只是选择了不告诉我们。而在这整整一周里，所有依赖这份 KPI 的后续工作，都在一个「上周已经补齐了」的错误前提上继续推进。
连失败检测器也会失败
8 月 23 日我们博客断更，看门狗触发补发，补发卡住，看门狗自己 exit 1。更早的 8 月 18 日，看门狗脚本首跑直接 Script not found——安全网从未生效过。
这引出了我们最近一周最重要的领悟：失败是会传染的，每一层安全网都可能成为下一个沉默点。
- 任务失败 → 看门狗检测 → 看门狗自己的路径配错了
- 看门狗触发补发 → 补发和原任务用同一个模型，模型卡住，补发跟着死
- 上传返回 200 → 我们写 runlog 标记成功 → runlog 是假的
失败不是线性的。一个失败可以藏在另一个失败里，而监控层本身的失败，通常最晚被发现——因为它没有监控。
失败会扎堆：坏窗口
我们最近还观察到一个现象：凌晨 2 点到 3 点，多个任务接连失败——连接错误、超时、卡死，一晚上能坏三四个。单独看每个任务都像偶发故障，放一起看就是环境问题：那个时段网络和模型服务本身就不稳定。
所以我们的排查顺序变了：多个任务在同一时段失败，先查环境，再查代码。 8 月 10 日的全灭事件、8 月 23 日的断更，证据链都指向环境抖动，而不是任务本身写错了。
营销上的对应坑：所有渠道数据在同一时段集体异常时，先怀疑平台故障或政策变动，别急着改策略——你改策略的那晚，平台可能只是打了个喷嚏。
营销自动化里的僵尸系统
说到营销，被吞掉的失败在营销自动化里比比皆是：
- 投放系统：素材审核失败，系统自动暂停，后台报表却显示花费正常——预算停了，数据还在假装
- 邮件自动化：送达率 98%，实际大量进了垃圾箱，打开率统计的是「送达但没被看见」
- AI 客服：会话标记「已解决」，用户转头去投诉了，工单系统毫无波澜
这些场景的共同点：系统带着错误状态继续跑，而它输出的数据看起来一切正常。 营销决策是链条式的——假数据会一路传导：复盘结论错了、方法论错了、预算加错了。链条越长，被吞掉的失败越贵。
更隐蔽的代价是组织层面：当系统永远报成功，人就停止怀疑了。最危险的状态不是「总出问题」，而是「一直很顺利」——那往往意味着失败已经被吞了很久。
让失败必须发声的四条规则
这三周我们踩了足够多的坑，沉淀出四条规则，现在每个自动化任务都过一遍：
规则一：空 catch 是犯罪。 catch 块里必须做三件事之一：重试、降级、报警。什么都不做的 catch，等于亲手把失败埋起来。写代码时多写一行日志，排查时能省一夜。
规则二：独立验证。 不信接口的返回值，换一条完全独立的路径去问结果。上传 → curl 请求 URL；发布 → git log 看远程 commit；发送 → 抽查真实收件箱。接口说成功不算，独立验证说成功才算。
规则三：监控的监控。 定期体检你的看门狗：它上次真正触发是什么时候？告警还连着吗？双份部署的脚本两边同步了吗？给监控做体检，比给业务做体检更重要——业务出错有人看见，监控出错没人看见。
规则四：失败扎堆先查环境。 多个任务同一时段失败，先怀疑环境（网络、模型服务、平台策略），再怀疑代码。建一个时段健康记录，让「坏窗口」可以被看见。
写这篇的时候，我翻到了 8 月 23 日那篇的结尾：「失败不可怕，可怕的是失败得无声无息。」今天想补一句：
失败从来不会消失，它只会被吞掉。而被吞掉的失败，会变成系统的一部分，继续运转。 所以别只盯着成功率和告警——偶尔去翻翻那些「一直很顺利」的环节，那里可能埋着最贵的失败。
