SLA 数学 — 99.91% 可用性实际上为你带来的停机时长成本

想象一下：你正在和客户开会，客户要求“99.99%的可用性”，你点点头，双方就这么过去了。六个月后，你盯着SLA信用条款，困惑自己是怎么走到这一步的。你随意同意的那个承诺，每年允许52分钟的停机时间——而其中大部分都会在一次糟糕的部署中消失无踪。

这是每个开发者在签署SLA或在提案中承诺可用性数字之前都应该掌握的数学知识。

公式

可用性百分比通过一个简单的公式转换为停机时间：

停机时间 = (1 - 可用性) × 周期

对于99.9%的可用性：1 - 0.999 = 0.001。乘以一年中的分钟数（525,960），得到525.96分钟——即每年允许8.77小时的停机时间。这并不是灾难性的故障。这是一次普通的周二下午部署，持续数小时，一次数据库故障切换耗时超出预期，以及一次深夜依赖服务更新导致认证服务中断。八小时过得很快。

参考表

收藏这个表格。其中每个数字都是用同样的方式计算的——(1 - 可用性) × 周期长度（分钟），然后转换为最易读的单位。

可用性	每日停机时间	每周停机时间	每月停机时间	每年停机时间
99%	14.4分钟	1.68小时	7.3小时	87.6小时
99.5%	7.2分钟	50.4分钟	3.65小时	43.8小时
99.9%	1.44分钟	10.08分钟	43.83分钟	8.77小时
99.95%	43.2秒	5.04分钟	21.92分钟	4.38小时
99.99%	8.64秒	1.01分钟	4.38分钟	52.6分钟
99.999%（五九）	0.864秒	6.05秒	26.3秒	5.26分钟

重新阅读99.999%这一行。每年允许5分26秒的停机时间。总计，包括计划维护、健康检查失败，以及你的负载均衡器发现死节点需要的30秒。你可以计算一下这对大多数团队来说是否现实。

五九实际上需要的内容

五九（99.999%）不仅仅是“良好的基础设施”。它是一种不同的工程方法。要达到这个水平，你需要：

• 每一层都具备完整的冗余 ——在堆栈的任何地方都不能存在单点故障，包括DNS、CDN、数据库和应用层
• 具备亚秒级检测的自动故障切换 ——人类无法响应得足够快；你的监控和故障切换必须在无需人工干预的情况下运行
• 零停机部署 ——采用蓝绿或金丝雀部署，并具备自动回滚。任何需要重启的部署都会消耗你的5分钟预算
• 多区域主动-主动配置 ——单个区域宕机不会导致整个系统中断
• 计划外的维护工作在SLA窗口之外 ——大多数99.9%的SLA明确排除计划内维护，但99.999%的SLA通常没有空间容纳这类维护

真正达到99.999%的公司——如AWS S3、Google Cloud Storage——拥有专门的可靠性工程团队，多年混沌工程数据，以及基础设施投入，足以让大多数SaaS创始人望而却步。这是可以实现的，但绝非偶然，也绝非廉价。

你可以使用 可用性/服务等级协议计算器 来为任何可用性百分比和你正在处理的时间窗口运行这些转换。

SLA信用问题

这里正是大多数人感到意外的地方：云服务商提供的SLA信用，并不会补偿你实际的损失。它们只补偿你服务费用的一部分。

AWS、GCP和Azure通常在SLA违约时提供10至30%的月服务费用作为信用。如果你每月支付$500用于EC2，而发生2小时的中断违反了SLA，你可能会获得$50至150的信用。然而，你可能已经损失了数千收入，耗费了大量工程师时间应对事故，并损害了客户信任。

当你为自己的客户起草SLA时，请理解这是一套标准模式——信用是与服务费用挂钩的善意行为，而非全额赔偿。务必仔细阅读赔偿条款。许多企业客户会试图协商实际损失的表述；这是一场需要律师参与的另类对话，而非SRE团队的职责。

月度与年度窗口的差异

SLA是基于特定时间段计算的，而这个时间段比大多数人意识到的更重要。一个年度99.9%的SLA，意味着你每年总共8.77小时的停机时间，分布在12个月中。而一个月度99.9%的SLA，每月仅允许43.83分钟的停机时间——但这个时间每月都会重置。

客户几乎总是希望采用月度测量——听起来更严格，而且在你有一个糟糕月份时，他们可以借此获得优势。但他们往往没有意识到的是，月度测量实际上可能提供更少的总缓冲时间：43.83分钟 × 12个月 = 每年525.96分钟，这与年度计算结果完全相同。区别在于，月度SLA下，只要有一个糟糕的月份，即使全年其他时间表现完美，也可能触发违约。

在谈判时，尽可能争取采用年度测量窗口。当客户坚持要求月度测量时，确保你的基础设施能够每月都达到99.9%，而不仅仅是全年平均表现。

你应该实际承诺的内容

以下建议是真正实用的：

个人项目和早期产品

99.%是诚实且合适的。每月9小时的停机时间对没有专职运维的小团队来说是现实的。不要承诺你无法持续交付的内容——错过SLA的声誉成本，远高于提前设定较低期望。

基于标准云基础设施的B2B SaaS产品

99.9%是合适的指标。通过完善的监控、自动扩展、托管数据库以及无需停机即可部署的CI/CD流水线，这在AWS、GCP或Azure上是真正可实现的，无需付出英雄般的努力。每月43分钟的预算虽然紧张，但只要部署自动化到位，是完全可以实现的。

99.99%及以上

这需要真正的投入：跨多个可用区的负载均衡器、多区域故障切换、数据库自动复制与主备切换，以及一位将可靠性作为首要职责的负责人。如果客户要求99.99%，而你目前尚未具备相应基础设施，诚实的回答是协商降至99.9%，并将其作为未来迈向99.99%的路线图，同时在定价中反映相应的基础设施成本增加。

99.999%是亚马逊和谷歌的领域。除非你运营的是金融基础设施、医疗系统或电信级服务，并配备专职SRE团队，否则这并不是一个现实的承诺。

为你的具体情况运行计算

这里的数学公式适用于任何时间窗口和任何可用性目标。如果你处理的是非标准SLA周期——例如90天滚动窗口、财政季度或自定义测量周期——公式依然相同：将停机百分比乘以该窗口内的分钟数。

这 IO Tools上的可用性/SLA计算器 可处理所有这些内容——输入任意可用性百分比和时间周期，即可获得精确的停机时间允许值，这在起草SLA条款或回应客户关于可用性的要求时，提供一个现实的反提案。

总结：对于大多数没有专门可靠性投入的团队来说，99.9%是实际的上限。高于此水平的成本是真实存在的，并需要真正的流程变革。在合同签署前，必须清楚自己承诺的内容。

你可能也会喜欢