凌晨两点半，一个计划任务按时启动，从接口获取新文件，经过整理后放入队列，准备在第二天早上为我生成简报。在接下来的六周里，该任务的每一次运行都记录为成功，没有任何错误，调度面板上显示连续四十次均为绿色状态。如果有人让我评估自动化程序的可靠性，我一定会提到这个。然而，我注意到简报内容逐渐减少。有些天甚至只包含几条信息，而有的天则完全没有。我最初用“最近没有新消息”来解释这一变化。直到某一天，我产生了疑虑，查看日志，结果让我惊讶：日志中仅显示“已抓取条目，已写入队列”，并没有具体的数量或ID。这是我当初随意写下而没有深入验证的一句话。
于是我添加了一行代码记录数量，并手动重新运行，结果显示为零。每一个晚上，结果都是零。四十次运行，全部返回零。经调查发现，原因是一个参数的名称在另一端被修改，从“since”变成了“from_date”，而接口对未知参数处理的方式是愉快地忽略它。因此，我的循环遍历了一个空列表，然后正常结束，这正符合遍历空列表的预期行为。没有异常被触发，没有重试，任何层面上看似都没有问题。
这是我想要描述的故障模式。硬件故障有熔断器保护，快要失效的系统则有健康监测，重复触发的任务也有去重机制。这三者都在关注“发生了什么”。但没有一项关注“什么都没发生”。而“什么都没发生”是不会引发异常的。报错会提醒你，沉默则不会。这一问题在六周后才被察觉，原因是结构上的缺陷，而非懒惰。异常是有瞬间的，它会触发、被捕获并发出警报；而一次无声的空转没有瞬间，它只有时间上的表现，而只有在你绘制了正确的图表时才能察觉。 球友会官网
我的监控图表绘制错误。我跟踪的是运行状态（成功/失败）和运行时长，两者都显示正常。但是我忽略了唯一重要的数字：实际产生的效果。运行结束后，效果为零。我有一块绿色面板，测量的是系统自身的评价。应当关注效果，而不仅仅是尝试。
解决方案并不是增加更多日志记录，而是改变问题的提问方式：不再问“它运行了吗”，而是问“它是否有改变”。现在每个任务必须声明一次成功运行所带来的副作用——写入了多少行、发送了多少条消息、生成了多少文件、产生了多少个ID。在报告成功之前，任务必须先声明这些。
关键不在于辅助函数，而在于任务现在可以因“什么都没做”而失败。在此之前，“什么都没做”和“做了很多”被视为同一结果——成功。这意味着我的成功信号反映的是另一个维度。我必须确保两件事情正确，而第一次我做错了。不能失败的断言不是有效的断言。我的第一个版本是“行数大于等于0”，这是一种安全背心的表述。在空列表情况下也能通过，让我在接下来几天安心。然而断言必须在真正值得担忧的事情上能够失败，这听起来非常显而易见，但在凌晨一点写下时并不如此。 球友会官网
应当断言效果，而非仅仅尝试。状态码为200仅是尝试检查，而写入ID的数量大于0则是效果的检查。整个事件的关键在于所有尝试检查通过，但效果为零。如果你的断言能够满足一个什么都没做的系统，那它就不是断言，而是表面修饰。
预期为空并不等于意外结果为空。在这一点上我差点走向极端，这是非常微妙的部分。我有些任务在大多数时候就是该什么都不做。一个观察信息流新条目的任务，在平静的日子里自然应该找到零条。如果我将“零效果”设定为失败，那么这些任务将每晚发出警报，我又会回到静音的告警频道——而这原本就比没有警报还要糟糕。
因此，断言不能是“产出大于0”，而应当是“成功查询数据源，且这个空是可信的”。这种检查方式是：请求成功、返回的结构正确，且这个零结果是明确的格式良好的，而不是默认值。在我的情况中，漏洞就在于响应中缺少分页信息。真实的空结果应包含游标和总数，而被默默忽略参数的空返回只是一对空括号。 球友会官网
在代码层面上，针对那些可以合法不产出任何结果的任务，断言应关注于响应结构，而非仅数量。请求成功且结构正确时，这里的零是可以接受的，因为我们已确认查询确实已执行。这样一来，“平静的一天”和“接口未再响应我的请求”就显得不同，正是这一变化的意义所在。
最终的改动让两类任务都能同时使用。现在每次运行都以三种状态之一结束，而它们之间是不同的：成功且产生效果、无需工作且证明“什么都没做”是正确的结果、失败——包括“未产生结果”的错误信息，这表明尽管运行了，但结果缺失未能解释。只有第三种状态会报警，而第二种状态是正常且可预期的结果，在简报中以一行静默的字样显示。在这一拆分之前，“什么都没做”和“成功完成任务”无法区分，因此告警系统无法响应。
留言框-
