错误预算是一件谈判工具
一句话总结
周期预算是到目前为止已经用掉的份额，而 burn rate 是最近消耗的速度。必须区分这两者，才能解释什么时候允许发布、什么时候该停下。
为什么需要它
假设有一家虚拟的网上商店，要发布新功能。最近一个小时很平静，但上周的故障已经让 30 天的预算超支了。反过来，也有月度预算充足，而此刻支付请求正在快速失败的日子。如果只看最近的错误率，就会错过前一种事故；如果只看月度数字，就应对不了后一种事故。我们不要止步于由人去读报告，而是来制作一个能区分这两种依据的小型判定程序。这里假定你已了解 Python 的字典、条件语句和 JSON 输入输出。
工作原理
首先要确定统计谁的什么失败。在本实验的合成 HTTP 数据中，把 5xx 定为失败，把其余被观测到的请求定为成功。这是教学用服务的定义，并不意味着所有 4xx 永远都是客户的错。如果服务自己产生的错误认证响应或过载时的 429 属于用户失败，就需要另外的 SLI 定义。是否包含机器人和内部探测请求，也要写成文档，并对分子和分母采用相同的范围。
基于请求的 99.9% SLO，其允许错误比例是 0.001。如果同样 30 天内总共有 100 万次请求，允许的错误预算就是 1000 次。如果失败 200 次，使用比例就是 200/1000=0.2，即 20%；如果是 1200 次，就是 1.2，已超出预算。这个计算需要这 30 天整体的失败次数和请求次数。
burn rate 是用短窗口的错误比例除以允许错误比例。如果 1 小时内 1 万次请求中失败了 200 次，就是 0.02/0.001=20 倍。即使用 12 小时窗口来计算，它也只是 12 小时的 burn rate，并不会自动变成月度预算的使用量。窗口长度不会改变单位。最近的速度即使是 20 倍，月度使用比例也可能是 0.2；当前的速度即使是 0，由于此前的故障，使用比例也可能是 1.2。
基于时间的可用性预算是另一个概念。30 天是 43,200 分钟，所以 99.9% 时间 SLO 的允许不可用时间是 43.2 分钟。如果是 99.99%，则是 4.32 分钟，即 4 分 19.2 秒。不能把这个数字与请求失败次数换算着使用。安静时段的 1 分钟与订单集中涌入的 1 分钟，对基于请求的 SLO 可能造成不同的影响。本实验第 2 步是时间预算的数量级练习，最后的程序使用请求预算。
14.4 这个告警阈值也要从单位上理解。把 30 天按 720 小时计算，设想以每小时用掉整个预算 2% 的恒定速度，就是 0.02×720=14.4。假设剩余预算完好，且请求量和错误率保持恒定，就能得到约 50 小时的耗尽预期。如果已经用掉了一部分预算、流量发生变化、或者有旧的失败即将滑出滚动窗口，这个预期就会改变。不要把未来说成确定的数字。
为什么要同时看两个窗口
故障结束后，1 小时的平均值中仍然会保留失败。如果 1 小时的 burn rate 是 20，而最近 5 分钟是 0，只看长窗口的话，可能会继续呼叫。要求 1 小时和 5 分钟都超过 14.4 才呼叫的条件，是为了确认最近问题是否仍在持续。如果把 and 换成 or，这个恢复条件就消失了。恰好等于 14.4 不算超过。
对于请求很少的情况也要留意。5 分钟内三次请求中有一次失败，比率虽然很大，但这一次是重要的订单还是无害的重试，仅凭数字无法得知。不要无条件附加最低流量条件，从而隐藏所有低流量的失败。这个合成实验不会把 0 次请求推定为正常，而是暂缓判定。真实的服务需要符合业务影响的单独策略，以及对流量中断的监控。
在现场相遇的样子
如果没有取到数据，却把空结果换成 0，就会被误认为“没有故障”。要先确认是否是同一个服务、同一个结束时间，以及是否收集了所需的整个窗口。实验用的 Prometheus 中有约 12 小时的合成历史。仅仅因为对它使用了 30 天的查询，并不意味着观测到了 30 天。在最后一个任务中，使用另外提供的合成周期汇总，不会伪装成从真实 Prometheus 中提取的月度记录。
这个虚拟团队的功能发布策略分为三步。如果数据不明确，就是 hold；如果周期预算使用比例达到 1 以上，就是 freeze；除此之外，如果 1 小时和 5 分钟的 burn rate 都超过 14.4，也是 freeze。其余的才是 allow。请注意，使用比例的边界是“达到及以上”，而速度的边界是“超过”，两者有差别。暂缓和冻结都不会推进发布，但原因不同。暂缓要先恢复观测，预算冻结则优先安排可靠性工作。真实组织中的紧急安全变更或回滚，需要另外的审批策略，这个程序不会批准它们。
下一项实验要做什么
向真实的 Prometheus 查询成功比率和两个窗口的 burn rate，并检查告警规则。最后编写一个通过 stdin 读取合成汇总的 Python 程序。它要区分月度预算超支、正在进行的故障、恢复和数据缺失，并留下报告和退出码。凌晨站在发布按钮前，需要的不是底气十足的话，而是可以核实的依据。
参考：SRE 的 SLO 告警设计，预算策略示例。上面的 30 天、判定边界和暂缓规则，是这次实验中明确规定的教学用策略。