4、接口高可用目标：可用性指标（SLA、SLO）、故障容忍度与设计目标
做高可用架构之前，你得先想清楚一件事——「到底要多高才算高？」
有人说四个9（99.99%），有人说三个9就够。我自己刚带项目那会儿，也拍过脑袋定目标。后来线上出过一次故障，才发现目标定得太高，成本兜不住；定得太低，业务又受不了。说白了，可用性不是拍出来的，是算清楚SLA、SLO和故障容忍度之后，一步一步设计出来的。
4.1 三个核心指标：SLI、SLO、SLA
很多团队把这三个概念搞混。我简单说一下它们的区别——
| 指标 | 全称 | 一句话解释 | 典型例子 |
|---|---|---|---|
| SLI | Service Level Indicator | 你实际测出来的指标值 | 过去30天接口平均延迟95ms |
| SLO | Service Level Objective | 你对自己承诺的目标值 | 接口延迟P99 ≤ 200ms |
| SLA | Service Level Agreement | 你跟客户签的合同条款 | 可用性≥99.9%，否则赔偿5%费用 |
4.2 SLA与可用性计算公式
可用性的标准公式不复杂：
可用性 = (总时间 - 故障时间) / 总时间 × 100%但实际计算时要注意——总时间按什么粒度？是按年、月还是分钟？
我建议你直接用分钟算。举个例子：
- 一个月（30天）总分钟数 = 43200分钟
- 99.9% 可用性允许故障时长 = 43200 × 0.1% ≈ 43.2分钟
- 99.99% 可用性允许故障时长 ≈ 4.32分钟
核心要点：99.99%看起来只比99.9%多了一个9，但允许的故障时间缩了10倍。你要为这个差距付出多大的架构成本？心里得有数。
4.3 故障容忍度：你能扛住几重故障？
定完SLA，下一步就是设计故障容忍度。说白了，就是问自己一个问题：
「如果某个节点挂了，系统还能正常服务吗？如果两个节点同时挂呢？」
我以前在电商公司遇到过这种事：活动大促，两个数据库节点先后宕机——一个因为硬盘写满，另一个因为机房网络波动。我们当时设计的是N+1冗余，理论上扛得住单节点故障，但两个同时挂就直接跪了。那一次SLA跌破99%，赔了不少钱。
4.3.1 常见故障容忍模型
| 模型 | 说明 | 适用场景 |
|---|---|---|
| N+1 | 需要N个节点工作，额外多部署1个备节点 | 单点故障风险较低，成本有限 |
| 2N | 完全双倍冗余，两个集群同时在线 | 关键业务，SLA要求99.99%以上 |
| N+2 | 除了N个主节点，额外2个备用 | 故障率较高或运维响应较慢的环境 |
| 故障转移（Failover） | 主节点故障时,自动切换到备用节点 | 所有高可用架构的基础能力 |
| 降级（Degradation） | 部分功能不可用，核心功能保持 | 资源不足或后端系统故障时的保底策略 |
| 限流（Rate Limiting） | 控制单位时间内请求量，防止雪崩 | 应对突发流量，保护后端 |
个人建议：不要追求「100%不会挂」的系统——那是不可能的。我的经验是，先分析业务场景里最常见的那种故障模式（比如单节点磁盘满、网络闪断），先搞定它。把80%的精力花在应对20%的高频故障上，比一把抓靠谱得多。
4.4 设计目标：把你的SLA翻译成架构决策
好了，现在你知道自己要的是几个9，也知道自己打算承受几重故障。下一步——怎么落地？
我个人习惯用下面这张表来映射可用性目标 → 架构方案：
4.4.1 故障容忍度设计清单
你可以在设计阶段逐项检查——
- 单点故障：每个关键组件（数据库、缓存、网关）是否都有备用？
- 机房级别故障：如果整个机房断电，流量能否自动切到另一个机房？
- 网络超时：调用下游接口超时后，是重试还是快速失败？要避免重试放大。
- 雪崩：限流+熔断+隔离，这三个缺一不可。
- 数据一致性：主从同步延迟是否在SLO范围内？
我曾经踩过的坑：在设计数据分级接口时，我过于关注N+1的故障转移，却忽略了降级策略。结果有一次缓存集群挂了，接口直接返回500。其实完全可以降级成全量查库——虽然慢点，但至少可用。从那以后，我把降级写进了每个接口的设计文档里，作为必选项。
4.5 一个小技巧：用错误预算来动态调整
你还记得Google SRE里的错误预算吗？其实很简单——
错误预算 = 1 - SLO
比如SLO是99.9%，错误预算就是0.1%。你的团队每个月只有43.2分钟的「犯错额度」。用完了，这个月就不能再发新版本了。
我为什么提这个？因为很多团队定完SLA就忘了，到故障时才想起指标。而错误预算能让你主动管理风险。我用过一个Dashboard，每天展示当前已消耗的错误预算百分比。一旦接近80%，我们就会收紧发布节奏，多做一轮review。
| SLO | 每月错误预算（分钟） | 典型策略 |
|---|---|---|
| 99.9% | 43.2 | 可接受少量计划外故障，快速恢复即可 |
| 99.99% | 4.32 | 需要自动化故障转移，降低MTTR |
| 99.999% | 0.432 | 多活+混沌工程，故障响应时间以秒计 |
4.6 总结几步定目标
老规矩，我给你一个可以照着做的步骤清单——
- 第一步：跟业务方对齐核心访问链路，找出哪些接口的可用性直接影响收入或用户体验。
- 第二步：基于历史故障数据（如果你有的话），估算当前可用性水平。没有数据？先按99.9%起步。
- 第三步：计算达到目标所需的SLO与错误预算，并评估成本上限。
- 第四步：按故障容忍度模型，画出架构冗余方案（N+1还是2N）。
- 第五步：加入降级、限流、熔断等保底策略，确保极端情况下核心功能可用。
额外提醒：别把SLA定得比你能做到的还高一个数量级。我有朋友为了投标写了99.999%的SLA，实际连99.99%都没达到，结果每个季度都要赔钱。还不如老老实实定99.9%，然后靠稳定性建设慢慢提升。
好了，可用性指标的坑和设计方法，基本就这些。你下次再被问到「你的接口几个9」，别只甩一个数字出来。拿出SLI、SLO、SLA的分层数据，再配上你的故障容忍度设计——这才是专业的态度。