可用性几个 9 是什么
可用性用“几个 9”表示，指服务在统计周期内可用的时间比例。它流行起来，是因为把抽象的可靠性翻译成了停机时长：99.9% 对应 30 天约 43 分 12 秒，99.99% 对应约 4 分 19 秒。每提高一个 9，架构复杂度与运维投入会成倍上升，因此目标应按业务影响分级设定，而不是对所有系统统一喊高标准。可用性还要写清统计窗口与排除项，否则数字无法对齐。
基本信息
| 定义 | 可用时间 ÷ 统计周期总时间 |
|---|---|
| 常见窗口 | 月度或年度，须在 SLA 中写明 |
| 99.9% | 30 天约 43 分 12 秒 |
| 99.99% | 30 天约 4 分 19 秒 |
| 关键限定 | 可用性沿依赖链相乘，短板决定整体 |
| 相关指标 | MTTR、MTBF、错误预算、RTO/RPO |
典型使用场景
- 新服务定目标：按业务影响与停机损失推算，而不是照抄行业口号
- 供应商谈判：云厂商的可用性承诺要与自身 SLA 对齐并留出缓冲
- 架构评审：识别单点，判断是否需要多可用区或双活设计
- 预算论证：把提高一个 9 所需的成本折成金额，与停机损失比较
- 事后复盘：用实际停机时长反推达成情况，验证目标是否现实
- 变更窗口：计划维护若不计入可用性，必须在 SLA 中明确写出
可用性与停机时长对照
| 可用性 | 月停机（约） | 年停机（约） |
|---|---|---|
| 99% | 7 小时 12 分 | 3.65 天 |
| 99.5% | 3 小时 36 分 | 1.83 天 |
| 99.9% | 43 分 12 秒 | 8 小时 46 分 |
| 99.95% | 21 分 36 秒 | 4 小时 23 分 |
| 99.99% | 4 分 19 秒 | 52 分 34 秒 |
| 99.999% | 26 秒 | 5 分 16 秒 |
目标选择思路
目标选择思路
先问业务：一年中断多久才不可接受？
再评估：达到目标所需的架构与运维投入
沿依赖链核算：整体可用性 ≈ 各级可用性相乘
避免给所有系统同一个目标：按业务链路分级
写清统计窗口与排除项，例如计划维护是否计入每提升一个 9 投入通常成倍增加：目标要与业务损失匹配，把所有系统都定成 99.99% 往往意味着哪个都保不住。
可用性是乘出来的：入口网关 99.99%、应用 99.99%、数据库 99.9% 的链路，整体上限约 99.88%，单点优化的收益有限。
服务“活着”不等于可用：正确率下降、延迟翻倍同样构成业务中断，可用性目标最好与 SLI 一起看，避免指标打架。
降低停机时间的常见手段
- 消除单点：入口、数据库、认证等关键环节做冗余，避免一处故障全链路停摆
- 多可用区部署：把故障域限制在局部，配合流量摘除自动切换
- 健康检查与自动摘除：让异常实例先停止接流量，而不是等用户报障
- 灰度与快速回滚：把故障影响限制在少量流量与较短时间窗内
- 容量与预案：预留峰值余量，对已知风险准备降级方案
- 演练与故障注入：定期验证切换与恢复流程，暴露文档与权限缺口
与 RTO/RPO 的分工
可用性衡量日常运行的稳定程度，RTO 与 RPO 描述灾难场景下的恢复能力，两者合起来才覆盖完整。日常可用性很高的系统，也可能因为缺少灾备而在机房级故障中停机数天，因此指标要成对使用。
计划维护与不可抗力是否计入可用性，必须在 SLA 里写清；不写明时，双方会各自按对自己有利的口径统计。
可用性统计要区分“系统层”与“业务层”：网关存活率好看，但订单成功率下降时，业务视角的不可用已经开始计时。