做高可用性系统的同学几乎都会被问到同一个问题“我们系统要做到几个九”问的人往往以为这只是个数字答的人却知道背后压着一整座关于停机时间、架构冗余和运维成本的大山。“99.9%”和“99.99%”听起来只差一个9实际落到年停机时间上一个大约允许8.76小时另一个只允许52.56分钟差了十倍。如果你还没把这层关系想透今天这篇文章就帮你把“可用性各个九的年、月、周、天停机时间”彻底盘明白。无论你是SRE、架构师、后端开发还是被领导追着要SLA指标的负责人这组换算都是一个绕不开的基础工具。会用很简单但能用对、能把目标拆成团队能执行的动作才是真正有价值的地方。我会从计算公式、标准换算表、错误预算一路聊到实际选档时容易踩的坑尽量把这张表背后的逻辑讲透。1. 先搞懂公式可用性不是“能连上就算”很多同学第一次接触可用性以为“系统还能访问”就是可用。实际上在SRE和运维体系里可用性是一个有明确时间分母的比率。只有把定义和计算口径统一了后面所有报表、告警、SLA才站得住脚。1.1 可用性的数学定义和常见口径可用性的标准公式不长可用性 实际可用时间 / 承诺总时间 × 100%也可以反过来表达停机时间停机时间 承诺总时间 × (1 - 可用性)这里的核心是“承诺总时间”。你是不是7x24小时对外提供服务是否包含凌晨维护窗口是否包含业务低峰期的计划内停机这些都必须事先说清楚。同一个99.9%如果分母按全年8760小时算年停机是8.76小时如果分母只按工作日9:00-18:00算年停机就会急剧缩小。不是数学变了是大家说的根本不是同一个“九”。日常交流中可用性一般按“9”的个数来分档。99%俗称“两个九”99.9%是“三个九”99.99%是“四个九”以此类推。每个档位对应的不可用比例分别是1%、0.1%、0.01%。别看比例只是小数点在移动换算成停机时间就是量级上的差距。1.2 SLA、SLO、SLI三个词背后的目标对齐谈可用性之前要先分清三个概念SLIService Level Indicator衡量服务好坏的具体指标比如请求成功率、延迟P99、可用时长。SLOService Level Objective你给SLI设的目标值比如“月度请求成功率不低于99.9%”。SLAService Level Agreement对外的服务协议达不到会有赔偿和商业后果。很多人把SLA和SLO混着说但实际落地时差别很大。SLO是内部承诺可以动态调整SLA是对外契约签了就要有赔付成本。我见过团队对外承诺四个九内部SLO却还是按三个九在跑结果一个故障就把整年利润赔进去。所以聊“几个九”之前先确认这是SLO还是SLA。前者关乎团队节奏后者关乎真金白银。1.3 计算实例一个0.1%的故障预算怎么算出来的举一个最简单的计算帮你建立直觉。假设我们承诺99.9%可用性一个月按30天算总时间 30 × 24 × 60 43200 分钟 停机预算 43200 × (1 - 0.999) 43200 × 0.001 43.2 分钟这意味着这个月里所有故障累计不能超过43.2分钟。一次发布回滚花了20分钟那这个月就只剩23.2分钟可以“挥霍”。如果再来一次持续30分钟的雪崩这个月已经超支。这种“预算”视角比单纯看百分比要直观得多也是后面错误预算方法论的起点。2. 一张表看懂年、月、周、天停机时间现在咱们进入正题把“可用性各个九的年、月、周、天停机时间”一次性列清楚。以下表格按年365天、月30天、周7天、日24小时计算保证纵向口径一致。2.1 标准换算表所有九级别的年/月/周/天停机时间可用性年停机月停机按30天周停机日停机99%两个九3.65 天 / 5256 分钟7.2 小时 / 432 分钟1.68 小时 / 100.8 分钟14.4 分钟99.9%三个九8.76 小时 / 525.6 分钟43.2 分钟10.08 分钟1.44 分钟99.95%三个九半4.38 小时 / 262.8 分钟21.6 分钟5.04 分钟43.2 秒99.99%四个九52.56 分钟4.32 分钟60.48 秒8.64 秒99.999%五个九5.256 分钟25.92 秒6.048 秒0.864 秒99.9999%六个九31.536 秒2.592 秒0.6048 秒0.0864 秒99.99999%七个九3.1536 秒0.2592 秒0.06048 秒0.00864 秒这张表在不少运维文档里见过简化版但很多简化版把“月”直接按“年/12”算导致月停机时间是43.8分钟而不是43.2分钟差出来的0.6分钟就是自然月平均天数的误差。所以你在引用任何一张表之前先确认它用的分母是什么。我这边统一按30天方便和月度错误预算对接。2.2 怎么从这张表快速估出任意时间窗口不需要把整张表背下来只需要记一个口诀先求不可用比例再乘以总分钟数。比如要算某个系统99.95%在季度90天内允许停机多久总分钟数 90 × 1440 129600 分钟 不可用比例 1 - 0.9995 0.0005 季度停机预算 129600 × 0.0005 64.8 分钟这种方式比查表更灵活。尤其当你面对非标准窗口比如“这次活动持续12小时要求可用性不低于99.99%”直接算12小时 720分钟停机预算 720 × 0.0001 0.072分钟 4.32秒听到“四个九”直觉上会觉得“12小时只允许挂4.32秒”很苛刻但这就是真实的预算。活动期间任何一次紧急发布导致的闪断都可能直接击穿这个目标。2.3 为什么很多人会把99.99%的日停机时间算错我见过不少团队在日维度算错因为他们直接把小数点挪一下就完事。比如有人问99.99%一天允许多久回答说“0.01%乘以1440分钟等于1.44分钟”。这个答案错得离谱1.44分钟对应的是99.9%。0.01%乘以1440应该是0.144分钟也就是8.64秒。这类错误很典型因为“0.01%”在百分比语境下看起来很小但放大到一天里依旧有实际量级。类似的还有“99.999%的月停机”不应该是“4.32分钟去掉一个零”吗并不是99.999%对应0.001%的不可用比例月停机是43200乘以0.00001等于0.432分钟也就是25.92秒。每多一个九日停机时间就再除以10这张表按行读下来就是这个规律。3. 多一个九系统要承担什么表上的数字看着很轻巧但落到真实系统里每多一个九都不是“再优化一点”的问题而是架构和运维模式的整体升级。3.1 停机预算的“体感”从一次15分钟故障看差距拿一次常见的15分钟故障来看不同档位的承受力。99.9%月度预算43.2分钟15分钟故障占比约为34.7%这个月还剩28.2分钟可用。99.95%月度预算21.6分钟15分钟故障直接消耗69.4%剩6.6分钟后面基本要提心吊胆。99.99%月度预算4.32分钟15分钟故障已经是预算的3.47倍意味着这个月的目标已经无法完成。同样的故障在三个九的指标下可能只是“疼一下”在四个九的指标下就是“目标击穿”。这就是为什么很多高可用团队会对线上故障等级保持极度敏感——不是小题大做而是预算真的经不起折腾。3.2 从架构复杂度看每多一个九的代价可用性目标越高你可能要付出非线性增长的架构成本。三个九的系统单机加上基本重启脚本也许还能撑四个九的系统需要负载均衡、多副本、故障自动切换五个九往往要跨可用区部署、数据多活、混沌演练、容量冗余。每多一个九对恢复时间的要求也高一个量级。举个例子如果你的系统恢复一次要10分钟那么打四个九的日预算8.64秒就没意义因为任何一次真故障都会直接击穿。要达到四个九你不仅需要故障次数少还要单次恢复足够快最好做到自动化秒级切换。所以高可用目标本质上是“少挂 快恢复”的组合要求而不是单纯“上多几台机器”。3.3 业务场景决定档位不是追求越高越好我见过一些内部系统明明月活跃用户几百人也要定四个九。结果就是运维同学为了一个没人用的报表接口天天熬夜业务却感知不到差别。可用性目标应该跟着业务影响走用户直接操作、涉及支付交易的核心链路至少四个九甚至更高。主流程的中台接口、订单查询、账号服务三个九到三个九半比较合理。后台离线计算、内部管理平台、日志分析两个九到三个九足够。别把“可用性越高越好”当成信仰高可用是有代价的。定一个让业务能接受、团队能兑现、成本不失控的目标远比写一个漂亮但做不到的数字更有价值。4. 怎么定目标用错误预算反推集群该设几个九“错误预算”这套方法论最早来自Google SRE实践核心思想很简单既然可用性不是100%那自然就存在一个允许出错的空间。把这个空间显式地算出来作为团队可以消耗的“预算”当预算快用完时就必须放缓发布、优先搞稳定性。4.1 错误预算把SLO变成团队能用的日常指标SLO如果只是纸面百分比很难指导日常工作。比如“月度可用性不低于99.95%”团队每个人都知道吗知道以后能做什么吗错误预算把目标转换成“这个月还有多少分钟可以挂”就非常直观了。计算公式错误预算 (1 - SLO目标) × 周期总时间以月度30天、SLO99.95%为例错误预算 0.0005 × 43200 分钟 21.6 分钟这21.6分钟就是全月所有故障和延迟超时的总消耗。每次线上故障、每次慢请求、每次发布回滚都会消耗这个池子。池子清零说明本月SLO已经不可能达成这时候最理性的动作不是继续发布功能而是停下来做稳定性工作。4.2 月度与季度错误预算计算示例我习惯同时看月度预算和季度预算因为单看一个月容易因为一次大故障就“破罐子破摔”季度预算能帮助团队保持更长周期的节奏。SLO 99.9%月度错误预算43.2分钟季度预算约129.6分钟。SLO 99.95%月度错误预算21.6分钟季度预算约64.8分钟。SLO 99.99%月度错误预算4.32分钟季度预算约12.96分钟。落地时可以用一个简单的错误预算剩余比例来驱动决策剩余比例 (总预算 - 已消耗预算) / 总预算当剩余比例低于50%时本周不再做高风险发布低于20%时进入“冻结发布 只修关键故障”模式。这里的关键是让错误预算成为团队共识而不是某个监控页面里没人看的数字。4.3 用错误预算决定“能不能发布”我所在团队之前有一个规则核心服务发布前先看错误预算剩余量。剩余充足正常发布剩余不多禁止发布已经透支只能回滚修复。这个规则一开始遭了不少开发同学吐槽但跑了一个季度后大家都承认稳定性变好了。原因不复杂。发布是导致故障的最常见诱因之一而错误预算给了团队一个客观的、不带人情味的判断依据。不需要争论“这次改动风险大不大”直接看预算还剩多少。预算多你可以做更多探索预算少一切以保命优先。这也是高可用性系统里技术和流程互相配合的典型场景。5. 算停机时间最容易踩的三个坑反复用停机时间表时会发现很多团队对出来的数字完全对不上不是一个人算错而是口径不统一。下面这三个坑是我在实际工作中见过最多的。5.1 自然月 vs 平均月口径不同结论不同前面提过年停机时间除以12得到的是“平均月”45天? 这里写错了我重新算一下严谨点是年停机525.6分钟除以12等于43.8分钟而按30天算月停机是43.2分钟。0.6分钟的差距虽然不大但如果你的SLO是99.99%这0.6分钟已经占到月度预算4.32分钟的14%不能忽略。所以无论是写监控报表还是对账都要明确自己用的是“自然月天数”还是“固定30天”。自然月更贴近业务固定30天更便于自动化计算。我建议内部报表统一用固定30天外部SLA按自然月但提前在合同里写清楚计算规则。5.2 分母取业务时间还是7x24结果相差几倍如果一个系统只在工作日9:00-18:00开放分母应该按业务时间来算。这时99.9%的月停机预算就不是43.2分钟而是大概11.88分钟因为一个月业务分钟数只有22个工作日 × 9小时 × 60分钟 11880分钟 11880 × 0.001 11.88分钟分母一换结果差了3.6倍。很多团队对外报可用性时喜欢用业务时间分母因为数字更好看但对用户而言他们只关心自己想用的时候能不能用。两边都有道理前提是提前说清楚。否则两个团队各拿各的数字开会永远对不齐。5.3 监控上报的可用性不等于用户感受到的可用性这是最隐蔽的一个坑。你在监控系统里看请求成功率99.99%但用户可能在弱网环境下、在边缘节点上、在特定运营商链路上反复失败。监控探针的数据是基于机房间网络和内部链路用户侧的失败未必能完全反映出来。因此在做可用性统计时最好把SLI定义成“用户可感知维度”。比如核心接口的端到端成功率、登录接口的P99延迟、支付回调的成功率。如果只盯着服务器内部指标很容易出现“监控里一片绿客诉电话响不停”的情况。6. 高可用性系统设计时按什么档位来配最后聊一聊和“高可用性系统”直接相关的落地问题。到底哪些系统配几个九多可用区部署是不是一定更安全回答这些问题没有标准答案但有一些判断原则可以参考。6.1 核心链路、普通链路、离线任务分别怎么选档我通常把系统分成三档来配核心链路支付、登录、购物车、订单状态变更这类直接决定用户能否完成核心动作的系统SLO定在99.99%或更高配套必须有多副本、自动切换、全链路监控。普通链路商品详情、评价、消息中心用户能接受偶尔刷不出来SLO定在99.9%到99.95%即可重点保证高峰期稳定。离线与内部任务报表生成、数据同步、批处理作业SLO可以放到99%甚至更低只要能在SLA截止时间前跑完就行。在“高可用性系统”语境里我见过不少团队把普通链路的SLO也抬到四个九导致所有服务都得按最高标准做冗余成本和维护压力成倍上升。好的架构师应该敢于对不同系统开不同档位的药方而不是一刀切。6.2 多可用区部署不会让可用性“自动变高”经常有人跟我说“我们做了多可用区部署可用性肯定是N个九吧。”现实没有这么简单。多可用区只是降低了“所有机器同时挂”的概率但如果你的切换依赖人工、数据复制存在延迟、流量调度不够自动化故障发生时该停多久还是停多久。从概率上算两个独立可用区同时故障的概率确实很低。假设单可用区可用性是99.9%故障概率0.001如果两个可用区完全独立且能无缝切换理论可用性可以做到1 - (0.001 × 0.001) 99.9999%但这里有两个前提一是故障真的相互独立二是切换时间能够忽略不计。现实中共享的基础组件、依赖的下游服务、错误配置都可能让两个可用区同时出事。所以多可用区是必要不充分条件最终能不能兑现高可用要看故障切换是否经过演练、是否足够快。6.3 我的经验从故障盲点反推目标最靠谱每次聊到“几个九”要怎么定我都会建议团队先做一个动作把过去一年所有真实故障列出来包括故障时长、影响范围、恢复时间再对照上面那张停机时间表看自己能落在哪个档位。如果去年已经发生了三次超过30分钟的故障那月度SLO就不应该定到四个九因为按四个九算预算只有4.32分钟这个目标从一开始就是空中楼阁。反过来如果业务确实需要高可用性就先解决恢复时间问题。把单次故障恢复RTO从30分钟压到5分钟再压到1分钟每一次缩短都会让目标更接近可实现。比起努力增加“机器数量”不如努力减少“恢复时间”。很多高可用团队的真正突破点不是买更多机器而是把故障恢复从“人肉发现手工操作”变成“自动发现秒级切换”。我和不同团队聊下来感觉真正能稳定兑现四个九的团队靠的不是在监控页面上把目标写得很高而是用一次次故障演练、发布管控和错误预算透支后的复盘喂出来的。数字只是结果流程和架构才是支撑那张表格里每一秒的底气。希望这篇关于“可用性各个九的年、月、周、天停机时间”的整理能让你在下次被问到“做的到几个九”时可以不慌不忙地拿出表格说出真实可执行的答案。