SLA 错误预算计算器

百分比掩盖真相，分钟数才说明问题。选择一个 SLA 目标和一个周期，把允许的停机时间看成一个可以据此做计划的数字——再输入你实际经历过的停机时间（或实际测得的可用率），看还剩多少预算、消耗速度有多快。纯粹的算术，在你的浏览器中完成。

如果两个观测字段都填了，以停机分钟数为准——那是更直接的度量。

参考：按目标和周期列出的允许停机时间

SLA 目标28 天30 天365 天
99%6h 43m7h 12m3d 15h
99.9%40m 19s43m 12s8h 45m
99.95%20m 10s21m 36s4h 22m
99.99%4m 2s4m 19s52m 34s

为什么分钟数会改变讨论方式

SLA 百分比是一个谁也想象不出画面的承诺。“三个九”在销售演示里听起来很严谨，而它准确的含义是每月 43 分 12 秒的允许停机时间——一次糟糕的发布加上一次缓慢的回滚就用完了。只谈百分比的团队，往往是在事故进行中才第一次发现分钟数，而那是学习算术最糟糕的时机。预算这个框架解决了这个问题：它把额度变成一种有余额的资源——出故障时余额减少，余额健康时可以有意识地把预算花在一次高风险迁移上，余额耗尽时，约定——无论写没写下来——就是功能开发暂停，直到可靠性恢复。这就是错误预算的全部管理价值：它把工程界最古老的争论——发布还是稳定——变成一个双方同意以同一种方式解读的数字。

消耗百分比是同一个想法的预警形式。预算被突破不是在它用完的那一刻，而是在几周之前、在消耗速度已使耗尽成为必然却无人行动的那一刻。月初第一周就用掉一半预算，是一个最高级别的警报信号，此时还有时间冻结变更、回滚那个不稳定的东西并安排人手修复——同样的 50% 出现在月中，则只是正好按节奏推进。跟踪速度，而不只是余额，预算就不再是事后复盘的统计数字，而会成为它原本该成为的东西：在决定还能改变结果时就被拉响的决策触发器。

相关工具：值班排班器规划凌晨 3 点由谁来守护这份预算，备份保留计算器规划当防御失败时，恢复能回溯到多远。

延伸阅读：一套可靠性例行做法——轮班、备份保留和错误预算如何作为一个整体的规划习惯协同工作。

常见问题

什么是错误预算？

你的 SLA 已经允许的故障量，用时间来表示。30 天内 99.9% 的目标允许该周期 0.1% 的停机时间——43 分 12 秒——超过之后目标即被突破。把它框定为预算，是把一个抽象的百分比变成团队可以有意识地花销的东西：发布、迁移和维护都从同 43 分钟里支出。

为什么 99.99% 感觉比 99.9% 严格得多？

因为每多一个九，额度就除以十。同样是 30 天：99% 允许 7 小时 12 分钟，99.9% 允许 43 分钟，99.95% 允许 21 分 36 秒，99.99% 允许 4 分 19 秒——还不够一次重启。选择目标，就是选择你的运维实际上能承受多少事故，这也是为什么诚实的目标应由实测能力决定，而不是由愿望决定。

什么是消耗速率？

相对于整个周期，你花掉预算的速度有多快。本页面的消耗百分比是简化形式：迄今的停机时间除以总额度。周期过半时恰好消耗了 50%，你正好在节奏上；在第一周就消耗了 50%，你正走向突破，而冻结高风险变更的时机就是现在、选项还存在的时候，而不是等到 99%。

周期应该用 28、30 还是 365 天？

让周期与承诺相匹配。面向客户的 SLA 通常按日历月书写，一个月有 28 到 31 天不等——30 是标准的规划数字，28 是最严苛的二月情形。365 天的视角适合年度目标，能显示一份合同真正承诺的全年总量。如果供应商给你报的是年度数字、报告的却是月度数字，比较之前先把两者互相换算。

计划内维护算进预算吗？

这取决于合同，而且是 SLA 起草中最常争论的条款之一。许多 SLA 排除预先公告的维护窗口；许多 SLO（内部目标）则把一切都算在内，原则是用户体验到的计划内和计划外停机并没有区别。明确作出决定、把它写下来，并确保你跟踪的数字与你们约定的定义一致。