错误预算计算器

概述

SLO 是用比例表达的承诺：这么大一部分请求会成功。它真正有用的推论是余下那一部分， 也就是 错误预算——在你违背承诺之前，被允许发生的失败量。

把可靠性表述成一份预算，会改变整场对话的性质。「什么都不许弄坏」不能算工程目标， 因为它等于把风险定价为无穷大，而定价无穷大的结果就是禁止交付任何东西。相反， 「这个月你有 43 分钟不可用额度，其中已经花掉了 12 分钟」是一个能拿来排期、能拿来 权衡取舍的目标。

这个计算器把一个 SLO 换算成三个数字：以百分比表示的预算、你所选窗口内允许的不可用 时长，以及——如果你填了请求量——这段预算里能装下多少次单独的失败。

使用方法

1. 填入你要承诺的 SLO，用百分比表示。
2. 用天数设置窗口。30 是常见的滚动月；7 能带来更快的反馈循环；90 对应季度复盘。
3. 可选：填入该窗口的请求量，得到失败次数。

怎么读这几个数字

错误预算 就是 100% − SLO。它跟 SLO 摆在一起显得小到可以忽略，而这正是重点： 99.9% 与 99.99% 的差别，是允许你花掉的量缩小到十分之一——这就是每多一个 9 都比 前一个贵得多的原因。

允许的不可用时长 是把这份预算按挂钟时间折算到整个窗口上。这个数字最适合拿去跟 团队之外的人讲，因为「大约每月 43 分钟」是一件具体的事，而「99.9%」不是。

允许失败的请求数 是同一份预算折算到请求量上的结果。这才是应当据此排期和做计划的 那个数字，因为它直接对应你在监控里真正观测得到的东西——5xx 响应的计数，或者超过你那 条延迟阈值的请求数。

时间预算和请求预算不是一回事

两次故障可以消耗完全相同的时间预算，而请求预算相差极大，反过来也一样。

凌晨 3 点整体中断五分钟，代价是五分钟的不可用时长，以及极少量的失败请求。而一整天里 持续有 0.5% 的请求失败，按朴素的定义几乎不产生任何「不可用时长」，却足以把一个月的 请求预算耗干。

用户真正体验到的是第二种。如果你只用时间来度量可用性，就会系统性地少算那些最让人 恼火的失败，因为部分失效在这种度量方式下根本不会被记成不可用时长。

所以这两种预算必须分开来看：它们衡量的是同一份承诺在两个不同维度上被消耗的程度，而 同一次事件在这两个维度上的读数可以完全不相称。

通常的解法是把 SLI 定义成「好事件 / 有效事件」的比例——成功请求除以总请求，或者 足够快的请求除以总请求——只在需要对外沟通时才导出一个基于时间的数字。

预算实际花在了什么上面

常见的误解是把预算当成留给故障的余量。实践中它要跟一切会让请求失败的事情共享：

• 发布。 除非每一层都正确地做了连接排空，否则即使一次完全干净的滚动发布，也会 在切换的瞬间掉掉一些连接。
• 计划内维护。 只要用户能感知到，它就算在内——无论你有没有提前公告过。
• 依赖方故障。 你的预算会被上游服务商的故障花掉，而这件事你连投票权都没有。
• 长尾。 零星的超时、重试次数耗尽、某一个状态不好的节点。这些几乎不会升级成一次 正式故障，但它们会一点一点累加起来。

这就是为什么按「把错误预算 100% 花完」来规划的团队一定会超支。计划里只把其中一 小部分留给故障，其余留给日常运营的固有成本。

示例

• 99.9%，30 天窗口 —— 大约 43 分钟。一次糟糕的发布加上回滚缓慢，就能花掉一个 月的大半。
• 99.95%，30 天窗口 —— 大约 22 分钟。到这个量级，人工回滚已经不够快，必须上 自动化。
• 99.99%，30 天窗口 —— 大约 4 分钟。只有在无人介入即可完成的多区域切换下才可 能做到。
• 99.999%，30 天窗口 —— 大约 26 秒。仅仅是发现问题通常就比这更久，所以架构必须 能容忍故障，而不是响应故障。

每上一档，允许的失败量大致缩小到十分之一，成本则是一次台阶式跃升。SLO 要从用户 真正需要什么来定，而不是从「几个 9 听起来更体面」来定——一条内部批处理流水线做到 99.99%，是花钱而没人受益。

说明

窗口就按你填入的天数精确计算，因此 30 天的月份等于 2,592,000 秒。日历月之间最多 相差三天，如果你要跟合同对账，这个差别是要紧的；而滚动 30 天窗口是运营上更常见的 选择，也顺手绕开了这个问题。

失败请求数是截断而非四舍五入，因为「半次失败」不是能花掉的东西。

如果可用性是写进合同、带违约赔偿档位的数字，用 SLA 计算器。它回答的是相邻的那个问题——一个给定的可用性 承诺允许多少不可用时长——不涉及请求量这一侧。