错误预算只有0.1次请求，还能部署吗？

一句话总结

错误预算不是面板装饰，而是用经过验证的观测和商定策略决定是否变更的输入。数据缺失时，仅因错误数为 0 就批准部署，不是安全判断，而是没有证据的判断。

为什么需要它

假设平台目标为 30 天发放可用性 99.9%、快速成功率 99%。当前窗口有 10000 次有效尝试、9995 次可用成功、9850 次快速成功。可用性 99.95% 达标，快速成功 98.5% 却不足。只看可用性就上线新功能，可能让已有延迟体验更糟。

这些数字用于学习策略判断，并非所有平台的正确目标。过松或用户无法感知的极端目标都会扭曲成本与优先级，必须先说明要保护哪种用户体验。

工作原理

请求型预算的四个数字

同一窗口中 N 为有效尝试，G 为好事件，T 为目标。允许失败量是 N × (1 − T)，实际失败为 N − G，剩余预算是允许量减实际量，消耗比是实际量除以允许量。练习把 sli、consumed 显示到六位小数，但边界比较时不把允许失败量先舍入为整数。

N=10000、T=0.999 时允许失败 10 次。失败 5 次，剩余 5、消耗一半；失败 10 次，剩余正好 0；失败 20 次，剩余 -10、消耗比 2。把负数截成 0 会丢失超额量。

N=100 时允许量为 0.1。这不是存在 0.1 次事件，而是比例目标的算术量；一次失败就消耗十倍。若先把 0.1 舍入成 0，分母和策略解释都会错误。必须同时说明小样本敏感性和代表性窗口。

预算耗尽与变更策略需协商

Google SRE 错误预算策略示例展示如何把预算状态与变更优先级、责任和例外连接。本练习策略：剩余预算不高于 0 时 freeze 普通功能变更，有剩余则 ship。freeze 不等于禁止所有工作，事故恢复和紧急安全修复需另行判断、评审。函数只返回练习结论，不调用真实部署系统。

观测有缺口或有效尝试为 0 时返回 investigate，并把成功率、预算留为 null，明确没有计算依据。还需调查窗口是否真无请求、采集器是否停止、路由是否改变。covered 只是观测范围证据的摘要标志，代码写 true 并不能证明真实完整性。

不混用不同窗口

steady、slow、gap 是独立的 30 天虚拟窗口，不是连续三天。每个窗口内要匹配分子分母，不能用昨天分母除今天失败，也不能把 30 天预算和 5 分钟失败直接称为同一消耗率。短窗口 burn rate 告警需要单独定义时间段和比例。

合并可用性与延迟结论时，优先级依次为 investigate、freeze、ship，避免一项缺证据却因另一项良好而获批。这是练习契约，真实策略还可考虑服务重要度、依赖和变更风险。

现场表现

steady 的 available=9995/10000、fast=9950/10000 且覆盖完整，两项预算都有剩余。slow 可用性相同，但 fast=9850，因此 freeze。gap 即使收集数字显示 100%，covered=False，也应 investigate。除状态字符串外，还要保存各 SLI、允许量、剩余量、消耗比，供他人复算。

这也是岗位能力的一部分。2026-09-11 查看过的 Supabase SRE 职位把用户体验 SLI/SLO、错误预算策略与运营准备评审连接起来。本练习只覆盖其中小型计算与验证循环，不代表满足全部岗位要求。

下一步

后续练习先确保 HTTP 失败不会从分母遗漏，再用真实请求验证，随后实现汇总、预算、报告和反例。最后用五种错误实现检查案例：正确实现必须通过，只拒绝错误实现。