做运维、做架构、写SLA绕不开一个词可用性。前阵子有朋友问我合同上写可用性99.99%一年到底能挂多久我说52分钟出头。他又问那要是99.999%呢我说一年只能挂5分钟多点。他愣了一下就差一个9怎么差这么多这个问题其实特别典型。很多人对几个九的概念就停留在数字越大多越好但真要回答按年、按月、按周、按天分别允许停机多久能立刻算清楚的人并不多。今天这篇文章不聊架构也不讲监控工具就专门把各个九对应停机时间这笔账彻底算明白。我会把从99%到99.99999%这六七个常见档位分别按年、月、周、天四个粒度拆开告诉你每个档位到底允许系统挂多久。这些数值不是用来背的是用来直接落地到SLA制定、告警阈值设计和故障复盘里的。写SLA、做容量规划、定应急预案的人建议把这篇收藏起来当工具表用。1. 几个九到底在说什么先把公式吃透很多新人会把99.99%可用理解成系统特别稳定这句话没错但不够精确。可用性的定义不是不出故障而是在单位时间内正常服务的时间占比。严格一点它的计算口径通常是可用性 正常运行时间 / (正常运行时间 停机时间)如果只谈百分比那它的反面叫不可用率不可用率 1 - 可用性所以四个九等于99.99%对应的不可用率是0.01%也就是0.0001。记住不可用率这个概念后面所有的停机时间计算全靠它。1.1 可用性不是稳定而是故障时间的占比上限举个生活化的例子。小区门口有家便利店承诺每天营业12小时一年365天都开门。如果这个店一年里因为进货、盘库、断电累计关了4.38小时那它的年度可用性大约就是99.9%——因为一年8760小时里它只关了4.38小时。这个店不能说我从来没坏过但客户基本感知不到问题。换成你的业务系统也一样可用性只约束挂多久并不约束挂几次。很多刚入行的朋友会混淆可用性和可靠性。可靠性指两次故障之间的平均间隔也就是MTBF可用性则是MTBF和MTTR平均修复时间共同决定的。公式是MTBF/(MTBFMTTR)。一个系统可能经常抖但每次几十秒就恢复那它的可用性不一定差反过来一个系统一年只挂一次但一次挂两小时可用性可能只有99.9%左右。所以优化可用性不光要减少故障次数还要缩短每次故障的恢复时间。这一点在后面按天算预算的时候会体现得特别明显。1.2 每多一个九不是多一点点而是严格十倍这里有个最容易忽略的地方99%和99.9%差多少不是字面上差0.9个百分点而是不可用率从1%降到了0.1%停机时间预算直接缩到十分之一。同理99.99%比99.9%严格10倍99.999%比99.99%又严格10倍。用大白话说四个九是一年挂52分钟多五个九是一年挂5分钟出头。每加一个九允许挂的时间直接砍掉一个数量级。我见过不少团队定目标时很随意张嘴就是我们要做到99.999%。等我把对应的时间预算摊出来他们才意识到一年只能挂5分钟出头一个月预算才25秒。所以选可用性等级不能凭感觉要先用时间预算倒推看你的故障恢复水平能不能兜住。各档位的不可用率差异看下面这张表可用性等级不可用率对应含义99%两个九1%每年有1%的时间不可用99.9%三个九0.1%比两个九严格10倍99.99%四个九0.01%比三个九严格10倍99.999%五个九0.001%比四个九严格10倍99.9999%六个九0.0001%比五个九严格10倍这10倍的差距是理解所有停机时间对照表的基础。下面开始看具体数字。2. 按年算停机时间签合同、写SLA最常用的口径先看最常用的年度口径。这里以365天作为一年也就是8760小时。网上很多SLA模板里写99.99%对应每年不超过52.6分钟就是这么算出来的。2.1 全年可用性对照表一年到底能挂多久按365天一整年算各档位允许的停机时间如下可用性等级一年不可用时间换成更直观的单位99%两个九87.6小时约3天15小时36分99.9%三个九8.76小时约8小时45分36秒99.99%四个九52.56分钟约52分33秒99.999%五个九5.256分钟约5分15秒99.9999%六个九31.536秒约31.5秒99.99999%七个九3.154秒约3.2秒这张表建议直接贴在监控大屏旁边。不是因为好看而是因为它能把抽象目标量化到一年最多挂多久。比如运营告诉你上个季度挂了2次每次20分钟加起来40分钟一对比发现已经超过99.99%的年度预算了可这个季度还有一个月没走完后面再出一次事故全年就守不住。这种预算快用完的紧迫感只有量化之后才出得来。2.2 年度口径的局限性它是个秋后算账的指标年度可用性适合签合同、做年度总结但它有一个明显问题粒度太大反应太慢。等你在年度面板上看到可用性跌破目标往往事故已经过去很久预算早就超支了。所以工程上的做法是把它拆成更小的窗口来盯季度、月度、周、甚至天。把年、月、周、天四个维度都列出来就是为了适配不同场景下的管理粒度。另一个容易踩的坑是一年按多少天算的口径问题。有的协议按365天有的按365.25天甚至有人图省事按360天。举个例子99.99%在365天口径下是52.56分钟按365.25天算是52.60分钟差异不到1秒但如果你用360天算出来就是51.84分钟能差出40多秒。SLA合同里这类口径差异一旦较真对账时会很麻烦。我自己早期做合同评审时没注意分母口径事后核对数据才发现定义不一致后来凡是涉及可用性的条款第一件事就是确认周期基准。3. 按月、按周算SLO预算怎么分才合理年口径是秋后算账那平时看什么看月和周。月和周的粒度正好匹配大多数团队的发布节奏和SLO考核周期。3.1 自然月口径别忽略30天和31天的差别先看按月算。为了方便很多工具和文档会统一按30天即720小时来算这样得出的值是一个平均月的预算。实际自然月有28/29/30/31天预算会差几个百分点但对大多数业务来说用30天口径做估算已经足够了。按月计算各档位对应关系如下按30天一月的口径可用性等级一月不可用时间换成更直观的单位99%两个九7.2小时7小时12分钟99.9%三个九43.2分钟43分12秒99.99%四个九4.32分钟4分19秒99.999%五个九25.92秒约26秒99.9999%六个九2.592秒约2.6秒99.99999%七个九0.2592秒约0.26秒这个维度的核心用途是跟月度SLO挂钩。比如你和客户签的SLA是月度99.9%那你这个月所有发布、变更、故障导致的不可用时间加起来预算就是43.2分钟。很多人没有月度预算意识月初一个功能上线灰度发布卡了半小时月底再出个小故障20分钟回头一看这个月可用性已经不到99.9%了。等月底复盘才发现问题不是一次重大事故导致的而是一个个看似可接受的变更把预算吃光了。3.2 周维度发布窗口和维护窗口是预算消耗大户把窗口再缩小到一周7天168小时各档位对应关系如下可用性等级一周不可用时间换成更直观的单位99%两个九100.8分钟1小时40分48秒99.9%三个九10.08分钟10分4.8秒99.99%四个九60.48秒约1分钟99.999%五个九6.048秒约6秒99.9999%六个九0.6048秒约0.6秒99.99999%七个九0.06048秒约60毫秒周预算的实战意义主要在发布和维护。举个例子你承诺99.99%可用性一周总预算只有60秒。一次常规发布如果涉及滚动重启假设每台机器重启要10秒你有8台机器只要不是真正的无缝滚动每台停机10秒就已经80秒这一周还没等流量高峰到来可用性预算就已经超了。所以团队做发布方案时一定要先算这轮变更会吃掉多少停机预算再决定要不要选在低峰期、要不要用蓝绿发布或金丝雀发布来规避传统重启。这在追求高可用性系统的团队里是发布评审的必答题。4. 按天算监控频率与告警阈值的一场博弈日维度是最好理解的一天就是24小时、1440分钟、86400秒。但也是最能让人清醒的维度因为你会发现很多看起来很高的可用性目标折成一天根本没剩多少容错空间。4.1 日维度对照表一天能挂几秒按24小时一天计算各档位对应关系如下可用性等级一天不可用时间换成更直观的单位99%两个九14.4分钟14分24秒99.9%三个九86.4秒1分26秒99.99%四个九8.64秒接近9秒99.999%五个九0.864秒不到1秒99.9999%六个九0.0864秒约86毫秒99.99999%七个九0.00864秒约8.6毫秒很多团队看到99.999%一天只能挂0.864秒时第一反应是这不可能。确实如果你还在用每隔60秒探活一次、连续失败2次才告警的监控方案探测周期本身就已经远超日预算了。这也是为什么真正的五个九系统必须有非常强的冗余和自动故障转移能力而不是靠人去扛。人肉值班的极限和五个九的预算根本不在一个量级。4.2 用日预算倒推监控频率和告警阈值这里有个实操技巧拿日预算去倒推监控频率。假设你的目标是99.99%一天只能挂8.64秒那你的探活周期至少要小于8.64秒否则一次故障从发生到被探活发现时间就已经用掉一大半。更进一步告警链路本身也有延迟Prometheus拉取一次要几秒、告警规则评估要几十秒、值班人看到通知再登录服务器这几个环节走完十分钟就过去了。如果你的系统不具备自动恢复或自愈能力单靠探活人工想守住四个九以上基本是白日梦。正因为这样很多高可用性系统在设计时会把无人干预的故障转移时间当成关键指标。数据库主从切换、负载均衡摘流、多可用区调度要的就是把RTO恢复时间目标压缩到分钟级甚至秒级。我见过一个支付类业务对外宣称99.99%但他们做数据库切换演练时RTO目标压在30秒内。为什么因为一天只有8.64秒预算但报警发现、人员确认、决策切换这些环节还要占时间只能靠自动切换把核心恢复动作压到极致才有希望在预算内兜住故障。5. 从表格到SLO管理这套数值怎么落地上面这些表如果你只当知识看看价值不大。真正的用法是把它落成SLO、监控策略和流程规范。5.1 先选SLI再谈SLO可用性到底按什么算可用性到底按什么算在工程上必须先定清楚。我见过团队把SLO写成系统可用性99.9%但没人规定这个可用性是用HTTP探活成功率、请求错误率、还是核心接口的延迟达标率来测量。结果就是事故复盘时研发说服务没挂只是部分请求超时了测试说探活一直是通的两边各说各话。先定义SLI服务等级指标再定义SLO服务等级目标顺序一定不能反。三种最常见的SLI口径请求成功率成功请求数除以总请求数适合对外API和Web应用。探活可用性按固定周期探测目标服务是否可访问适合网络设备和基础组件。延迟达标率例如P99延迟小于200毫秒的请求占比适合对性能敏感的业务。不同口径算出来的可用性可能差很多。比如一个服务有1%的请求会超时但探活点只探测首页探活结果可能一直是200你的可用性看起来是99.9%实际上用户体验已经很差了。所以定SLI时要选最贴近用户真实感受的指标而不是选最容易测的指标。5.2 错误预算告警别等超了再报警SLO定下来之后错误预算Error Budget就是允许出错的额度也就是前面算的那些停机时间或不可用比例。团队里最常见的错误是只放一个本月可用性曲线等到它跌破目标线才告警。但这个指标是滞后指标等你看到的时候事故已经造成损失了。我建议的错误预算告警方式分三级第一级预算消耗速率告警。如果按当前消耗速度推算月底会超过可用性目标就提前告警。这能在故障发生早期介入而不是月底秋后算账。第二级瞬时可用性告警。5分钟或10分钟窗口内的可用性跌破某个应急预案门槛立刻触发高优告警不管本月总预算还剩多少。第三级单一事件消耗告警。任何一次故障把月度预算消耗超过一定比例比如10%就立刻触发复盘不用等到月底。这里给一个计算示例月度目标99.9%月预算43.2分钟。某次故障时长6分钟那它已经消耗了当月预算的6除以43.2约等于13.9%。如果这个月出现7次同样规模的故障月度目标铁定保不住。用这个比例作为故障严重度的判定依据比单纯按持续时间长短定性要更贴近实际用户影响也更方便向非技术同事解释。6. 常见误解与排查技巧实录从事稳定性和架构工作久了会发现同样的错误反复出现。这里列几个我踩过的坑基本都是真实发生过的事。6.1 四个高频误解误解一把99.999%理解成一年只能挂5分钟出头平均每天能挂几十秒。实际上按日口径算五九只有0.864秒年度和日度是两个完全不同的量纲不能简单除以365就完事。误解二以为99.99%比99.9%只是多了0.09个百分点。错这0.09个百分点对应的是不可用率缩到十分之一。所以从三个九提到四个九投入的资源和付出的努力往往要翻好几倍。误解三只盯着停机时间而忽略降级服务。比如你把首页缓存开了用户能看到页面但下单接口超时严格来说系统不可用了吗这取决于SLI定义。如果SLI只统计HTTP 200那降级可能完全不可见用户却已经在骂了。误解四用年目标倒推日常告警。这样导致事故发生后两三个月才意识到预算超支再想补救已经晚了。正确的做法是把预算切到月度、周度甚至用滚动窗口来管理。6.2 排查问题时我会逐条核对每次做完故障复盘我习惯拿这几条检查方案故障持续时间是多少换算成对应的月度或年度预算消耗百分比。监控系统是多久后发现异常的这个发现延迟对后续处理影响有多大自动恢复机制有没有生效如果没有人工介入花了多久当前可用性目标下的日预算是多少故障恢复时间RTO有没有超出预算SLI口径是不是足够贴近用户真实体验这些核对项能帮你在事故后快速定位到底是稳定性问题还是监控灵敏度问题或者是流程协作问题。很多时候你以为是在治理技术债实际需要治理的是发现链路和响应链路。比如有一次故障持续了15分钟正好卡在99.99%的日预算边缘复盘时发现其中11分钟都耗在告警发出但没人确认上真正的修复操作只花了4分钟。那这次事故的核心问题不是代码而是告警触达和值班机制。7. 一点落地的个人体会先算账再定架构目标这些年做稳定性治理我最大的体会是很多团队不是没有技术能力而是没有先做算术题。定99.9%还是99.99%不应该靠拍脑袋而要看业务能接受多久不服务以及团队有没有能力把故障恢复时间压到那个量级。算清楚年、月、周、天四个维度的停机预算是聊高可用性系统所有话题的起点。没有预算概念的高可用性设计就像没有上限的信用卡刷爆是迟早的事。我还养成了一个习惯每接一个新系统第一周就把它的SLO拆成一张表贴到团队空间里——季度预算多少分钟、月度多少、单周多少、单日多少秒然后在监控系统里加上本月已消耗错误预算这个指标。有这个数字在每次有人提要不要临时加个变更的时候先看一眼预算剩余很多事情自然就有了结论。预算充足时快速试错是合理的预算告急时一切变更都要走更重的评审流程。最后再分享一个小技巧不要把可用性目标只写成一年X个九而是在团队内部把目标拆成本月错误预算剩余X分钟。目标太抽象团队没有体感预算太具体每个人都能理解还剩多少容错空间。这一张对照表加一个预算面板可能是我做稳定性治理以来觉得投入产出比最高的两样东西。