一个看似正常的空队列

连续三周，无人值守的流水线一直报告队列深度健康。每次检查都是零待处理项，仪表盘上那个数字没人细看，因为零正是你想要的结果。零意味着工作正在被完成。

直到下游消费者发问：为什么九天来什么都没收到。

两个真相拼成一个谎言

队列是空的，因为根本没有东西进入队列。生产端在模式不匹配时静默失败，捕获异常后只记录调试级别日志，然后干净地返回。消费端轮询空队列，一无所获，于是报告一切正常。系统两半都在说真话，两个真相组合起来却是一个谎言。

这是一种特定的故障模式：某个指标的健康状态和死亡状态产生相同读数。队列深度是最明显的例子，错误计数也一样——零错误可能意味着什么都没坏，也可能意味着什么都没运行。

缓存命中率百分之百也可能是陷阱

缓存命中率达到100%可能很优秀，也可能意味着你在给每个请求提供一份冻结的快照。延迟骤降通常不是性能胜利，而往往是你开始返回比正确答案更廉价的东西。

这种模式有固定形状：任何衡量“坏事缺席”的指标，无论坏事是被阻止了，还是测量从未发生，读数都一模一样。你无法用一个只在失败时递增的计数器来区分成功与沉默。

修复不是调阈值，而是换测量对象

真正有效的做法不是设置更好的阈值，而是去测量“好事的存在”。不问“有多少项在等待”，而是问“过去一小时处理了多少项，这个数字是否与本周同一天同一时段应有的水平一致”。不问“有没有错误”，而是问“运行是否完成，并发出携带负载计数的心跳”。

心跳必须携带信息。一个光秃秃的存活信号只能证明进程还活着，不能证明它做了任何事。

代理会说自己成功了，而且技术上没错

最难接受的一个版本是：你的代理会报告成功，它在技术上是正确的，但你想要的结果并不存在。一个被要求发布草稿的代理，发现没有草稿，于是报告“无可发布，干净退出”，它完全按指令行事。它也制造了一整天的零产出，在日志里看起来和正确跳过发布的那天一模一样。

代理和日志都不知道区别。只有掌握“本应发生什么”背景信息的人类才知道，而无人值守的全部意义恰恰在于没有这样的人在场。

把预期写进仪表，而不是靠人盯着

因此，仪表必须编码预期。某处需要存在这样一条声明：在工作日，这个时段应当恰好产出一个工件；如果产出为零，无论退出码多干净，都算事故。这条声明不是指标，而是一份契约，它存在于被测量系统之外，因为系统无法自己验证自己是否做了该做的事。