SLA正常运行时间计算器

概述

可用性目标都以百分比给出，而百分比很不擅长传达量级。99% 和 99.9% 看着紧挨在一起， 每年却差出三天多。这个计算器把百分比换算成时间，也就是这个数字真正有用的形态。

填入一个可用性数值，就能得到一年、一个月、一周和一天各自允许的不可用时长。

使用方法

1. 输入一个可用性百分比，或者点击某个预设。
2. 读出四个窗口下允许的不可用时长。

预设覆盖了真实协议里会出现的档位：90、95、99、99.9、99.95、99.99 和 99.999。

速查表

有两点值得注意。第一，「每天」这一列就是一次糟糕发布必须塞进去的额度。第二，在大约 99.99% 以下，一天允许的不可用时长已经短于一个人注意到告警、打开看板、想清楚该做 什么所需的时间——这就是可靠性从运维问题变成架构问题的实际分界线。

怎么定目标

从后果倒推，不要从雄心正推。

先问故障期间会发生什么。如果只是批处理跑晚了、随后补上来，目标可以定低。如果客户 无法完成一笔购买，目标就跟着收入走。如果有紧急服务依赖它，那你要问的其实不是这个 问题。

然后拿目标去对照你的依赖。串联路径上的可用性是乘法叠加的：一个需要三个组件的服务， 每个组件 99.9%，在它自己还什么都没做错之前，上限就已经只有约 99.7%。你不可能承诺 超出关键路径允许的水平，而加一层重试并不会改变这个算术——除非各次失败之间相互独立。

最后拿它对照你的恢复流程。99.99% 的目标配上人工切换、外加一个靠邮件呼叫的值班轮班， 那不是目标，是愿望。数字本身就隐含了机制。

SLO 与 SLA 是两个数字

要让内部 SLO 比合同 SLA 更紧。这段差额就是你的运营余量：在这个区间里你已经没达成 自己的目标、已经开始处置，但还没触发赔偿。

99.9% 的内部 SLO 配 99.5% 的合同 SLA，在第一个信号（43 分钟）与第一笔服务额度返还 （3.6 小时）之间，每月大约留出 2.9 小时的缓冲。如果两个数字相等，那么你察觉的那一 刻同时就是你开始欠钱的那一刻，也就彻底没有机会安静地把问题处理掉。

另外一定要读免责条款。大多数 SLA 不计入已公告的维护、客户自身配置导致的故障，以及 不可抗力事件。这些排除项意味着：在用户确实经历了真实不可用的那个月里，服务依然可以 「达成 SLA」——那是一个法律结论，不是工程结论。

怎么算「不可用」

百分比只是算术；难的是它所适用的那个定义。两个团队可以对同一个月报出不同的可用性， 而双方都没有说谎。

从哪里测？ 从你自己网络内部发起的探测，会跳过 CDN、跳过 DNS、跳过互联网路径—— 而恰恰有很大一部分用户可感知的故障就发生在那里。从外部测，得到的数字更接近用户的 实际体验，也比你看板上那个更难看。

多久测一次？ 每五分钟一次的探针无法发现短于五分钟的中断，而对一次 30 秒的中断， 它会根据时机把它记成零分钟或者五分钟。粗粒度探测不会让你更可靠，只会让你的测量更 看不见东西。

测哪个接口？ 一个只要进程还活着就返回 200 的健康检查，会在所有真实请求都失败的 故障期间报告完全可用。检查必须真的去调用那些要紧的依赖。

部分失效。 如果二十个接口里坏了一个，服务算「可用」吗？基于时间的定义通常说算。 用那个接口的用户说不算。这正是应当把可用性定义为成功请求的比例、而不是定义为一段段 在线区间的首要原因——那套框架见 错误预算计算器。

在你把这个数字承诺出去之前，先把定义写下来，因为日后的争执正是发生在定义上。

示例

• 为冗余找依据。 99.9% 允许每月 43 分钟；单区域部署加人工切换，一次故障就经常 超出这个额度。
• 规划维护窗口。 如果维护算作不可用，那么四小时的窗口对任何 99.9% 及以上的目标 都是超支的。要么按合同它不算，要么你需要一次零停机迁移。
• 审视厂商的承诺。 一份声称 99.99%、却在整套文档里都找不到任何自动切换描述的 承诺，是营销数字。
• 设定告警阈值。 在 99.95% 下，每周一分钟的不可用就是周预算的五分之一。这就是 你的告警必须能分辨的尺度。

说明

这里一年按 365 天、一个月按 30 天。闰年和日历月会让数字略有偏移；如果一份合同的 结论取决于这个差别，就用合同里写明的定义。

这个工具回答的是「这个百分比允许多少不可用时长」。如果你还想知道预算里能装下多少 次单独失败的请求、以及已经花掉了多少，用 错误预算计算器——那是同样的算术，只是作用在请求量上而不是时间上。