可用性对照表：90% 到 99.999% 各允许多少宕机时间
99.9% 可用性到底允许宕机多久？本文给出 90% 到 99.999% 各级可用性对应的年/月/周/日最大宕机时间对照表，并解释"几个 9"对 SLA 承诺和系统架构的实际意义。
**可用性（Availability/Uptime）指服务在给定时间段内正常可用的比例。**例如一个月要达到 99.9% 可用性，允许的最大宕机时间是 43.2 分钟。下面的对照表列出各级可用性允许的全部宕机时间，签 SLA、定 SLO 时直接查表即可。
可用性-宕机时间对照表
| 可用性 | 每年允许宕机 | 每月允许宕机 | 每周允许宕机 | 每天允许宕机 |
|---|---|---|---|---|
| 90%（一个 9） | 36.5 天 | 3 天 | 16.8 小时 | 2.4 小时 |
| 99%（两个 9） | 3.65 天 | 7.2 小时 | 1.68 小时 | 14.4 分钟 |
| 99.5% | 1.83 天 | 3.6 小时 | 50.4 分钟 | 7.2 分钟 |
| 99.9%（三个 9） | 8.76 小时 | 43.2 分钟 | 10.1 分钟 | 1.44 分钟 |
| 99.95% | 4.38 小时 | 21.6 分钟 | 5.04 分钟 | 43.2 秒 |
| 99.99%（四个 9） | 52.6 分钟 | 4.32 分钟 | 1.01 分钟 | 8.64 秒 |
| 99.999%（五个 9） | 5.26 分钟 | 25.9 秒 | 6.05 秒 | 0.86 秒 |
（按月 30 天、年 365 天计算）
怎么读这张表
"9"的个数每加一个，允许的宕机时间缩小 10 倍，工程成本却往往是指数级上升。
- 99.9%（三个 9）：多数 SaaS 的 SLA 基线。每月 43 分钟的预算，足够应对常规发布和偶发故障，合理的架构冗余即可达成；
- 99.99%（四个 9）：每月只有 4 分多钟。意味着一次 10 分钟的故障就会花光两个多月的预算，需要多可用区部署、自动化故障转移；
- 99.999%（五个 9）：全年只允许 5 分钟。通常只有电信运营商级或金融核心系统才敢承诺，成本极高。
三个容易踩的坑
- 可用性 ≠ 性能：接口能返回但耗时 30 秒，按严格定义算"可用"，用户体验却是不可用。成熟度高的团队会把响应时间也写进 SLO；
- 计划维护算不算宕机：要在 SLA 里写清楚。多数厂商把提前公告的维护窗口排除在宕机统计外，客户签合同时务必看清这一条；
- 平均值的陷阱：一个月 43 分钟预算，一次全花完（单次 43 分钟大故障）和分 43 次每次 1 分钟，数字一样，用户感受天差地别。看可用性的同时要看故障次数和单次时长分布。
如何测量真实可用性
可用性数据必须来自用户视角的外部测量，而不是服务器自检——服务器觉得自己活着，用户可能根本连不上。观测云的**可用性监测（云拨测）**从全球多个拨测节点按分钟级频率探测你的站点和 API，自动统计可用率、故障时长和地域分布，达标与违约一目了然，可直接作为 SLA/SLO 的数据凭证。 1 结合监控器告警，故障发生的第一时间即可启动响应，把宕机时间压在预算之内。 2
常见问题（FAQ）
Q：我们应该承诺几个 9？
看客户付多少钱、宕机一分钟损失多大。内部工具 99% 可能够，面向客户的 SaaS 主流是 99.9%，涉及资金交易的再往上走。承诺超出实际能力的"9"，等于签了一张迟早兑现的赔偿单。
Q：99.9% 和 99.99% 的成本差多少？
行业经验法则：每多一个 9，成本约增加一个数量级。因为要靠多可用区冗余、自动故障转移、更严格的变更管理来支撑，这些都是真金白银。
Q：宕机预算（Error Budget）是什么？
就是这张表的另一面：100% 减可用性目标得到的"允许不可靠额度"。SRE 实践中用它平衡稳定性与新功能发布速度——预算没花完就大胆发布，花完了就冻结发布专注稳定性。
