重试预算如何从你的仪表板中隐藏了供应商的真实错误率

周会汇报的幻灯片上写着 99.9%。发票则显示账单翻了三倍。这两个数字在相邻的仪表盘上共存了数月，却没人发现它们衡量的是不同的世界。可靠性数值是重试后的结果——每一个最终返回 200 的调用都被计为成功——而成本数值则是客户端进行的每一次尝试，按 Token 计费。在两者之间，是一个慷慨的五次重试循环，以及一个尾部延迟正在悄悄恶化的供应商。第一次有人同时观察这两个数字是在一次故障期间，当时成本异常告警在可用性告警之前就触发了。

这就是整个模式。一个看起来像是可靠性机制的重试预算，本质上也是一个成本-质量调节旋钮，而那些只关注其中一面的团队，正在为一个发票最终会修正的可用性数字买单。

渐行渐远的两种“调用”定义

重试循环是分布式系统中最古老的模式之一。十多年来，AWS Builders' Library 一直主张，对于任何与远程服务通信的客户端来说，带有抖动的指数退避（exponential backoff with jitter）是不可或缺的。《SRE 实践手册》（The SRE Workbook）则从另一个角度提出了同样的观点：重试会将低错误率放大为更高水平的流量，一个跨越三个重试层的单一用户操作可能会对数据库产生 64 次尝试。标准的建议是为重试设置预算，以便为这种放大效应设定上限。

建议是对的。问题在于预算所隐藏的指标。

在重试循环下游计算的成功率 SLO 衡量的是客户端是否 最终 得到了答案。在任何重试发生前计算的成功率 SLO 衡量的是 供应商 是否在第一次尝试时就给了客户端答案。这是关于不同层面的不同问题，多年来它们足够接近，以至于没人需要去区分它们。但 LLM 工作负载让它们产生了分歧。

原因是重试的成本不再可以忽略不计。在微服务中重试一个 GET /healthz 几乎是免费的——几个字节，几毫秒，以及自动扩容组件根本察觉不到的 CPU 周期。但在使用工具（tool-using）的 LLM 调用中，重试意味着重新序列化系统提示词（system prompt）、对话历史、检索到的 Payload 以及用户消息——两万个输入 Token，每一次尝试都要全额计费。Anthropic 和 OpenAI 的 SDK 在遇到 429 和 5xx 错误时默认都会重试两次，这意味着一个性能略有波动的供应商可以将你的输入 Token 账单增加 1.5 倍，而你的重试后成功率指标甚至连一个基点（basis point）都不会改变。

CloudZero 的可观测性文章将这种差距描述为买单者缺失的一层。工程师看到的是可用性数字，财务看到的是发票，而双方没有一个共同的指标来解释为什么一个平稳而另一个在攀升。成本是领先指标。可用性是滞后指标。

99.9% 成功率背后隐藏了什么

想象一个供应商，其首试成功率在六周内从 99% 线性下降到 95%。由于有五次重试预算和相对独立的失败概率，重试后的成功率在整个窗口期内都保持在 99.99% 以上。仪表盘纹丝不动。周会汇报显示一切正常。

与此同时，每次成功调用所需的平均尝试次数从 1.01 次上升到 1.20 次。在一个每月运行一千万次调用、每次调用包含两万个输入 Token 的工作负载中，这意味着多出了 400 亿个计费输入 Token，这大约相当于按之前的尝试率计算的整个输入 Token 预算。发票翻倍并不是因为业务量增长，而是因为同样的业务量现在每次成功的成本更高了。

第一次有人将这两个数字联系起来通常是在故障期间。供应商的首试成功率掉下悬崖——一小时内从 95% 降至 60%——重试预算再也无法吸收失败，重试后的数字终于产生了波动。成本异常告警比可用性告警早触发四个小时，因为成本信号是尝试次数的连续积分，而可用性信号是跨越预算上限的阶跃函数。

这正是《SRE 实践手册》在告警指南中讨论的模式：告警必须对你真正关心的症状敏感，而重试后的成功率并不是那个症状。它是重试层为了平滑症状而设计的重度平滑后的转换结果。平滑后的指标是你放在状态页（Status Page）上的。它们不是你用来告警的。

重试前和重试后是两种不同的 SLO

修复方法在概念上很简单，但在操作上很复杂：将重试前成功率和重试后成功率作为独立的指标公开，每个指标都有自己的阈值和告警。

重试前成功率是客户端看到的供应商真实错误率。当它恶化时，这个数字应该驱动你与供应商的沟通。当它超过阈值时，这个数字应该触发模型或区域的故障切换（failover）。SRE 团队应该将这个数字视为依赖项的 真实 可用性，因为它每损失一个基点，你的重试预算就必须在成本上吸收一个基点。

重试后成功率是用户感知到的产品可用性。这个数字应该驱动你与领导层的 SLO 对话。它是衡量你的错误预算（error budget）是否被消耗的指标。它是状态页应该反映的数字。

加载中…