周二下午，你刚发完部署，下游API开始超时，重试逻辑把一次失败变成四十次。一个代码路径坏了，现在热循环里疯狂抛异常。等你回滚完，九十分钟里已经产生了两百万条错误事件。

你的错误监控工具照单全收，干得漂亮。

打开网易新闻 查看精彩图片

几天后，第二起"事故"来了：账单。你签的26美元月费计划，悄悄变成了390美元。你超了包含的事件量，计价器按每事件几分之一美分继续跑。没人问你，也没人能问你——事件来得比任何人类审批都快。

打开网易新闻 查看精彩图片

这就是按用量计费监控最让我费解的地方：定价和你的处境成反比。工具在你最惨的那天收你最多钱。流量 spike、糟糕发布、吵闹依赖、重试风暴——每个都是运维紧急事件，同时又是计费事件。本该帮你渡劫的产品，正在计量你的"特权"。

我在做一款叫 ErrSight 的错误追踪工具，早期就决定不这么干。没有超额费用。不是"低超额费"，不是"带慷慨缓冲的超额费"。完全没有。套餐上限是真上限，不是惊喜账单的起点。

这比听起来更有工程挑战，下面说说怎么实现的。

超额计费是选择，不是物理定律。先诚实说说为什么超额定价这么普遍。不是因为别无选择，是因为这是最省事、最赚钱的方式。

最省事：实现 trivial——数进来的量，乘个费率，月底发总额。你不必在热路径做决策，不必对客户说"不"，照单全收月底算账就行。

打开网易新闻 查看精彩图片

最赚钱：计价器在账单前就跑起来了。等客户看到数字，钱已经花了，无法拒绝。这种不对称就是整个商业模式。

看清这点，"无超额"就不是定价噱头，而是设计约束。意味着把决策前移，放到请求路径里，在客户还能被保护的时候。具体我定了三条规则：

一，账户配额用尽时，停止接收并明确告知。别默默收数据再开票。

二，架构上确保不可能突破上限，哪怕并发请求突发——因为突发时最需要保护。

三，客户真需要更多容量时，让扩容……