3. SLA 计算公式与模型：可用性计算公式、月度/年度 SLA 计算、复合 SLA 模型
聊完了 SLA 的定义和监控指标，咱们得动真格的了——怎么算？
说实话，我见过不少团队，SLA 写得天花乱坠，一到算账的时候就懵了。要么公式用错，要么时间窗口没对齐，最后跟业务方扯皮扯到天亮。这一章，咱们就把计算这件事彻底掰扯清楚。
3.1 可用性计算公式：别小看这个除法
可用性的核心公式，说白了就一个除法：
可用性 = (总时间 - 不可用时间) / 总时间 × 100%举个例子：一个月 30 天，总共 43200 分钟。你的服务宕了 43.2 分钟，那可用性就是 (43200 - 43.2) / 43200 × 100% = 99.9%。
嗯，这里有个坑——“不可用时间”怎么定义？
我个人习惯把“不可用”分成两类：
- 完全不可用：用户完全访问不了，比如 5xx 错误持续超过阈值
- 部分不可用：响应变慢、功能降级，但还能用
我在项目中遇到过，业务方非要把部分不可用也算成完全不可用，结果可用性直接掉到 99% 以下。后来我们约定：响应时间超过 3 秒算 0.5 倍不可用时间，超过 10 秒算 1 倍。这样双方都能接受。
3.2 月度与年度 SLA 计算：时间窗口的陷阱
月度 SLA 和年度 SLA，用的公式一样，但时间窗口不同，结果可能差很多。
月度 SLA 计算：
月度可用性 = (当月总分钟数 - 当月不可用分钟数) / 当月总分钟数 × 100%注意，每个月的总分钟数不一样。1 月是 44640 分钟，2 月平年只有 40320 分钟。同样的 43.2 分钟宕机，在 2 月算出来是 99.89%，在 1 月是 99.90%。
年度 SLA 计算：
年度可用性 = (全年总分钟数 - 全年不可用分钟数) / 全年总分钟数 × 100%全年总分钟数 = 365 × 24 × 60 = 525600 分钟（闰年 527040 分钟）。
这里有个常见的误区：有人把 12 个月的月度可用性直接平均，当成年度可用性。 这是错的！
为什么？因为每个月的总时间不一样，加权平均才对。正确的做法是：把全年的不可用时间加起来，除以全年的总时间。
| 时间窗口 | 总分钟数 | 99.9% 允许宕机 | 99.99% 允许宕机 |
|---|---|---|---|
| 1 天 | 1440 | 1.44 分钟 | 8.64 秒 |
| 1 月（30 天） | 43200 | 43.2 分钟 | 4.32 分钟 |
| 1 年（365 天） | 525600 | 8.76 小时 | 52.56 分钟 |
3.3 复合 SLA 模型：链式服务的噩梦
单个服务的 SLA 好算，但现实中的系统往往是链式的——用户请求经过网关、认证、业务逻辑、数据库、缓存……任何一个环节出问题，整个请求就挂了。
复合 SLA 的核心公式：
SLA_总 = SLA_1 × SLA_2 × SLA_3 × ... × SLA_n举个例子：你的系统有 4 个服务，每个都是 99.9% 可用性：
SLA_总 = 0.999 × 0.999 × 0.999 × 0.999 = 0.996 = 99.6%你看，4 个 99.9% 串起来，直接掉到 99.6%。年度宕机时间从 8.76 小时变成了 35 小时——多了 4 倍！
这就是为什么我常说：别只看单个服务的 SLA，要看端到端的 SLA。
我在项目中遇到过，业务方承诺客户 99.99% 的可用性，结果后端有 6 个服务串在一起，每个都是 99.99%。算下来总可用性只有 99.94%，根本达不到承诺。最后只能加钱上冗余，或者拆成并行架构。
- 串联模型： 所有服务必须都可用，整体才可用。公式是乘法，结果比任何一个单点都低。
- 并联模型： 只要有一个服务可用，整体就可用（比如多活部署）。公式是 1 - (1 - SLA_1) × (1 - SLA_2) × ...，结果比任何一个单点都高。
实际系统中，往往是串并联混合。比如：
- 网关层是并联（多活）
- 业务逻辑层是串联（必须经过认证、订单、支付）
- 数据层是并联（主从切换）
算的时候，先算并联组的等效 SLA，再算串联组的等效 SLA，一层层往上推。
3.4 复合 SLA 计算示例：一个真实场景
假设一个电商系统的核心链路：
- 负载均衡（并联双活，每个 99.99%）
- API 网关（单点，99.95%）
- 认证服务（单点，99.99%）
- 订单服务（单点，99.99%）
- 数据库（主从切换，并联，主 99.99%，从 99.95%）
第一步：算并联组
负载均衡等效 SLA = 1 - (1 - 0.9999) × (1 - 0.9999) = 1 - 0.0001 × 0.0001 = 0.99999999 ≈ 99.999999%
数据库等效 SLA = 1 - (1 - 0.9999) × (1 - 0.9995) = 1 - 0.0001 × 0.0005 = 0.99999995 ≈ 99.999995%第二步：算串联组
总 SLA = 0.99999999 × 0.9995 × 0.9999 × 0.9999 × 0.99999995
≈ 0.9993 = 99.93%你看，即使负载均衡和数据库做了高可用，网关的 99.95% 还是把整体拉到了 99.93%。年度宕机时间约 6.13 小时。
这就是复合 SLA 的残酷现实——短板效应非常明显。想提升整体可用性，先盯着最弱的那个环节。
3.5 避坑指南：计算 SLA 时常见的 5 个错误
- 忽略维护窗口：计划内维护算不算不可用？我建议在 SLA 里明确写清楚，比如“计划内维护提前 72 小时通知，不计入不可用时间”。
- 采样粒度太粗：用 5 分钟粒度采样，可能漏掉 30 秒的短暂故障。我个人习惯用 1 分钟粒度，关键服务用 10 秒。
- 把平均值当承诺：99.9% 是下限，不是平均值。你承诺 99.9%，就得保证每个月都达到，而不是年底平均一下。
- 忽略复合效应：前面讲过了，串联服务越多，整体 SLA 越低。设计架构时就要算清楚。
- 不区分全局与局部：某个地域的故障算不算全局不可用？建议按地域分维度计算，别混在一起。