可用性几个 9 是什么意思？SLA、SLO、SLI 有什么区别？

简化版

几个 9 表示系统在统计周期内可用时间占比，比如 99.9% 年不可用时间约 8.76 小时，99.99% 约 52.56 分钟。SLI 是实际衡量指标，SLO 是内部目标，SLA 是对外承诺和违约责任。

详细版

三者关系可以这样理解：

概念	含义	例子
SLI	服务水平指标，衡量现实表现	请求成功率、P99 延迟、错误率
SLO	服务水平目标，内部要达到的目标	月成功率 ≥ 99.95%
SLA	服务水平协议，对客户的承诺	未达 99.9% 赔偿服务费

可用性通常按公式计算：

可用性 = 可用时间 / 总时间

常见年度不可用时间大致为：

可用性	年不可用时间
99%	约 3.65 天
99.9%	约 8.76 小时
99.99%	约 52.56 分钟
99.999%	约 5.26 分钟

面试时要补充：可用性不能只看机器是否存活，还要看用户请求是否成功、延迟是否可接受、核心功能是否可用。

完整版教学

一、几个 9 是把故障时间量化

“高可用”如果只停留在口号上，很难评估。几个 9 的意义，就是把可用性换算成允许故障时间。99.9% 听起来很高，但按一年计算，仍然允许大约 8.76 小时不可用。对普通后台系统可能可以接受，对支付、交易、核心登录就可能太长。

换算方法并不复杂。一年按 365 天计算，总分钟数是：

365 × 24 × 60 = 525600 分钟

如果可用性是 99.99%，不可用比例是 0.01%，也就是 0.0001：

525600 × 0.0001 = 52.56 分钟

这能帮助团队理解目标的严肃性。每多一个 9，成本通常不是线性增加，而是明显上升，因为你需要更强的冗余、更快的故障检测、更完善的容灾和更成熟的运维体系。

二、SLI 是仪表盘上的真实数字

SLI 是用来衡量服务表现的指标。常见 SLI 有请求成功率、错误率、P95/P99 延迟、可用实例比例、消息堆积时间、数据同步延迟等。

设计 SLI 时要贴近用户体验。进程存活率 100% 没有意义，如果用户请求大量超时，服务在用户眼里就是不可用。对接口服务来说，成功率和延迟通常比 CPU 使用率更直接；对消息系统来说，消息是否及时消费、是否丢失、是否重复更关键；对数据库来说，主从延迟、连接耗尽、慢查询比例也很重要。

好的 SLI 应该可测量、可报警、能反映用户体验，并且能驱动行动。指标太多会让人麻木，指标太少又看不到问题。

三、SLO 是内部工程目标

SLO 是团队给自己的目标，比如“订单创建接口月成功率 99.95%，P99 延迟低于 500ms”。它通常比 SLA 更严格，因为内部要给自己留缓冲。假设对外 SLA 是 99.9%，内部 SLO 可能设置为 99.95% 或 99.99%。

SLO 的一个重要作用是指导工程投入。如果某服务已经长期超过目标很多，也许不需要继续堆高可用成本；如果经常低于目标，就要投入治理。SLO 让团队在“可靠性”和“研发速度”之间有共同语言。

还有一个概念叫错误预算。比如 SLO 允许一个月 0.1% 的失败请求，这个 0.1% 就是错误预算。如果预算消耗太快，就要暂停高风险发布，优先修稳定性问题。

四、SLA 是对外承诺，带有商业后果

SLA 是服务提供方和客户之间的协议，通常会写明可用性承诺、统计口径、排除项、赔偿方式。比如云服务承诺月可用性不低于 99.95%，否则按一定比例退还服务费。

SLA 要谨慎，因为它不只是技术目标，还涉及合同、客户预期和赔偿责任。很多公司内部会有 SLO，但未必把同样高的目标写进 SLA。对外承诺越高，背后的工程成本、值班成本和容灾成本越高。

面试时提到 SLA，不要只说“几个 9”，最好补一句统计口径。比如是按全站、按接口、按地域还是按客户统计；是按请求成功率还是按服务不可达时间统计；计划维护窗口算不算不可用。这些口径会极大影响结果。

五、可用性要和延迟一起看

如果接口没有返回 500，但 P99 延迟达到 30 秒，用户仍然认为不可用。因此现代可用性指标经常把成功率和延迟结合起来，例如“请求在 1 秒内成功返回才算可用”。

这就是用户视角的可用性。系统内部可能觉得服务没挂，但用户等待超时、页面打不开、支付一直转圈，这些都应该算进可靠性治理。高可用不是服务进程活着，而是用户关键动作能顺利完成。

六、可用性统计口径会直接影响结果

几个 9 看起来是数学问题，实际落地最容易争议的是统计口径。按接口统计还是按服务统计，按请求量加权还是按时间窗口统计，错误码算不算失败，超时算不算失败，依赖第三方导致的失败算不算，计划维护是否排除，这些都会改变可用性数字。

例如某接口 1 分钟内 100 万次请求失败，和一个低频接口 1 小时完全不可用，按请求量和按时间算出的影响不同。对用户来说，核心接口失败比边缘接口失败严重得多。因此 SLI 应该围绕用户关键旅程设计，比如登录成功率、下单成功率、支付成功率、订单查询可用率，而不是只看服务进程存活。

还要把延迟纳入口径。一个请求 30 秒后成功返回，技术上不是 500，但用户已经放弃。很多团队会定义“在指定延迟阈值内成功返回才算可用”，这比单纯成功率更贴近体验。

七、错误预算能指导发布和稳定性投入

SLO 的价值不只是写在文档里，它可以形成错误预算。比如月度 SLO 是 99.9%，意味着这个月有 0.1% 的不可用预算。预算充足时，团队可以正常迭代；预算消耗过快时，就应该收紧发布、优先修稳定性、减少高风险变更。

错误预算让研发和运维不再互相拉扯。研发希望快，稳定性团队希望稳，SLO 给双方一个共同刻度：只要可靠性在预算内，可以保持迭代；一旦预算透支，系统稳定性优先。

面试追问“怎么提升几个 9”时，不能只说加机器。要先看错误预算花在哪里：是发布事故、容量不足、依赖超时、数据库故障、网络问题还是人工误操作。不同原因对应不同治理：灰度发布、容量压测、熔断降级、主从切换、容灾演练、权限管控。几个 9 的背后是系统性治理，而不是单个优化。

八、常见误区与追问

这道题要紧扣「可用性 SLA」本身回答，不能把它混成泛泛的高可用套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明故障域、冗余、健康检查、切换流程、RPO/RTO 和演练结果。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	SLA 用可用时间比例衡量服务稳定性，关键是把几个 9 转成允许故障时间并倒推架构和运维要求	不要停在名词解释
流程机制	定义服务口径 -> 计算允许不可用时间 -> 拆分依赖 SLA -> 设计冗余和降级 -> 监控错误预算 -> 复盘消耗原因	要说清触发点、状态变化、确认点和失败兜底
工程取舍	99.9% 每月约允许 43.2 分钟不可用，99.99% 每月约 4.32 分钟，差一个 9 成本差很多	高可用不是永不故障，而是用冗余、隔离、自动切换和演练降低故障影响

可用性 SLA 面试拆解：
1. 定义服务口径
2. 计算允许不可用时间
3. 拆分依赖 SLA
4. 设计冗余和降级
5. 监控错误预算
6. 复盘消耗原因

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「可用性 SLA」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

误区：SLA 越高越好。 更高 SLA 需要更多冗余、自动化和成本，要和业务价值匹配。
误区：服务部署多副本就等于高 SLA。 依赖、发布、容量、故障切换和人为操作都会影响 SLA。
误区：平均延迟好就可用性高。 可用性还要看错误率、超时率和核心功能成功率。
追问：四个 9 每月能挂多久？ 大约 4.32 分钟，按 30 天粗算。
追问：错误预算有什么用？ 把可用性目标转成可消耗额度，指导发布速度和稳定性投入。
追问：依赖 SLA 如何影响整体？ 串联依赖会相乘，一个弱依赖可能拉低整体可用性。

九、加强记忆

SLI 是“测什么”，SLO 是“想做到多少”，SLA 是“对外承诺多少”。几个 9 是把高可用从口号变成故障时间预算。可用性目标越高，越要用真实用户视角定义指标，而不是只看机器是否还活着。

简化版

详细版