说要 99.9% 之前先换成分钟：SLO 和错误预算怎么决定你要买几台服务器

先把它换成分钟，再讨论要不要这个数字

开口要 99.9% 之前，先把它换成分钟：一个季度 43 分钟。43 分钟够不够你做一次定位加回滚？如果不够，这个目标就不是给你定的。

这句反问不是抬杠。绝大多数团队定可用率目标的方式是拍脑袋——同行都写 99.9%，那我们也写 99.9%；老板觉得四个 9 听起来更专业，那就 99.99%。可这两个数字背后是两套完全不同的机器摆法、两套完全不同的值班制度和两套完全不同的账单。差 0.09 个百分点，容错时间差 10 倍。

先补一个口径说明，免得后面算错账：上面那个 43 分钟，是 99.9% 在一个月（按 30.44 天折算）窗口下的容错时间，很多服务合同用的就是月度口径；如果严格按一个自然季度（91.3 天）算，99.9% 是约 131 分钟。两个数字差 3 倍，不是谁算错了，是统计窗口没说清楚。这正是本文想讲的第一件事：讨论可用率之前，先把"多长时间内"定下来，否则所有数字都是自说自话。

本文要落地的判断只有一条：SLO 不是挂在墙上的口号，它能直接换算成"每个季度允许不可用什么数量级的分钟"，而这个分钟数反过来决定你要几台机器、要不要跨机房、还能不能在业务时间发版。先算分钟，再定目标，最后才谈配置。顺序反了，钱一定花错地方。

• 99% 和 99.9% 是两档工程，99.9% 和 99.99% 又是两档工程：前者靠"备份 + 人能修"，后者靠"冗余 + 机器自动切"，成本不是加一点，是换一档。
• 切换时间会被算漏：检测 + 决策 + 执行三段加起来，主备架构动辄吃掉 3 到 10 分钟，99.99% 一个月的全部预算才 4 分钟多。
• 你的 SLO 上限被最弱的依赖卡死：自己做到 99.99%，支付接口只有 99.9%，端到端就是 99.89%，多花的钱一分都没兑现成用户体验。
• SLI 选错比 SLO 定错更致命：用平均延迟掩盖长尾，会出现"监控全绿、用户在骂"，而这份绿还是你自己骗自己的。
• 预算烧完不等于不能发版：冻结的应该是"非必要变更"，安全补丁和可靠性修复反而要走绿色通道。

四个常见可用率对应的时间账：按小时、按月、按季度各是多少

换算本身没有技术含量，就是一个乘法：允许不可用时长 = 窗口总时长 ×（1 − SLO）。真正容易出错的是窗口怎么取、按什么单位记、哪些时间算进去。

按自然时间口径（1 年 = 365 天 = 525600 分钟，1 月按平均 30.44 天 = 43800 分钟，1 季度按 91.3 天 = 131472 分钟）算出来是下面这本账：

99%（两个 9）：每小时允许 36 秒；每天 14.4 分钟；每月约 7 小时 18 分；每季度约 21 小时 54 分；每年约 87.6 小时，也就是 3.65 天。这个量级意味着"出事了重装一台机器"完全来得及，甚至允许你把数据从备份里拉回来重建。

99.9%（三个 9）：每小时 3.6 秒；每天 1.44 分钟（86 秒）；每月约 43 分 48 秒；每季度约 2 小时 11 分；每年约 8 小时 45 分。这个量级开始有压力了：一次人工定位 15 分钟、回滚 10 分钟，两次事故就把一个月吃干净。

99.99%（四个 9）：每小时 0.36 秒；每天 8.64 秒；每月约 4 分 23 秒；每季度约 13 分 9 秒；每年约 52 分 33 秒。这个量级已经不允许"人工上机排查"作为主路径了——从告警到人打开电脑，可能 4 分钟就没了。必须自动切换，且切换要在几十秒内完成。

99.999%（五个 9）：每小时 0.036 秒；每天 0.86 秒；每月约 26 秒；每季度约 1 分 19 秒；每年约 5 分 15 秒。这个量级基本告别"出事再处理"的思路，只能靠架构上不存在单点 + 常态化的故障演练 + 自动流量调度来扛。

三种窗口口径的差别，比很多人想的重要。按年度算，99.9% 给你 8 小时 45 分，听上去很宽裕，但它允许一种很糟糕的实际情况：前 11 个月一点事没有，12 月某天连续挂 8 小时——年度达标，业务该死的还是死了。按月度算，同样的目标被切成 12 份，每份 43 分钟，一次大事故直接超支，无法用"其他月份表现好"去抵。按季度算居中，也是不少企业内部 SLO 评审会采用的节奏，因为整改动作需要一个季度的时间来落地。

比较务实的写法是双口径：月度窗口用来触发动作（超支就冻结变更），年度窗口用来做总体评价和对外承诺。只写年度的公司，往往是怕月度数字不好看。

还有一个必须先吵清楚的问题：计划内维护算不算。如果算进 SLO，那 99.9% 的 43 分钟里要预留出升级内核、换硬件、迁数据库的时间，实际能留给故障的只剩二十几分钟；如果不算，就要在 SLO 文档里明确写"计划内窗口不计入，需提前 N 小时公告且每次不超过 M 分钟"，并且这个排除项要有上限，不能变成为所有停机开脱的后门。常见做法是：低峰期、提前公告、单次不超过 30 分钟、每月不超过 2 次，超出部分一律计入预算。

误差预算怎么算，又会被哪些事情消耗掉

误差预算（error budget）的定义极简：预算 = 1 − SLO。SLO 定 99.9%，预算就是 0.1%，落到一个月就是 43 分 48 秒的"允许失败额度"。它不是一个监控指标，是一份可花的配额——你把它花在发版上，就没有额度留给故障了。

预算的计量方式有两种，选哪种取决于你的业务形态：

时间片法：按自然时间计，停机 1 分钟扣 1 分钟。适合对外承诺"系统可用率"的场景，也最直观。

请求计数法：预算 = 允许失败的请求数 / 有效请求总数。比如一个月 1 亿次请求，SLO 99.9%，就允许 10 万次请求失败。这种方式的好处是能反映真实影响面——凌晨 3 点挂 10 分钟可能只有 200 个请求受影响，而晚高峰挂 1 分钟可能打挂 5 万个请求。面向用户的在线服务，用请求计数法更诚实。

预算会被哪些事情消耗掉，是这份账最容易被低估的部分。能想到的至少有五类：

第一类，故障。硬件宕机、进程崩溃、网络中断、机房电力或制冷异常，这些是大家默认会算的。

第二类，变更失败。这是最被低估的一类。一次发布引入一个内存泄漏，回滚花 12 分钟；一次配置推送写错一个参数，全站 5xx 持续 8 分钟；一次数据库表结构变更锁表，写入阻塞 20 分钟。这些都不是"故障"，是你自己人干的，但它们一样从预算里扣。高频发布的团队，预算大概率是被自己烧掉的。

第三类，容量不足。大促流量打进来，连接池打满，服务雪崩。这类问题在账面上常常被记成"业务量超预期"，但用户视角它就是不可用。容量规划没做，等于把预算押在运气上。

第四类，依赖方故障。上游支付接口超时、DNS 解析失败、对象存储 503。你没有改任何代码，但你的成功率就是掉了。这部分要不要计入你的 SLO，取决于你怎么定义服务边界——但用户不管边界，用户只管页面打不打得开。

第五类，恢复过程中的二次伤害。切到备机之后缓存是冷的，数据库要追 binlog，连接池要重建，这一段时间里服务是"起来了但慢得不能用"。如果 SLI 里包含延迟指标，这段时间一样在扣预算。很多人只统计"进程活着没有"，把这一段白白记成可用。

预算耗尽之后怎么办，必须在事前写成书面策略，而不是等超支了再开会吵。通行做法是三件事：冻结非必要变更（新功能、重构、大版本升级全部停掉）、资源转向可靠性（下个迭代的人力优先投给稳定性项，而不是需求）、触发一次 SLO 评审（目标定得对不对、SLI 是不是选错了、架构是不是有单点没处理）。

这里有个组织问题比技术问题更难解：谁有权宣布冻结。如果冻结需要业务方点头，而业务方有 KPI 压着，那这条策略最后一定落不了地。可行的写法是预先约定——预算剩余低于 25% 自动进入预警，归零后由技术负责人单方面冻结，业务方可以申诉但不能先斩后奏，冻结解除条件是连续两个窗口预算回升到 50% 以上。写得越具体，执行的时候越不撕。

还有一种更糟的情况：预算从来没人看。团队装了一堆监控面板，但没有一个人每月去读那个"剩余预算"的数字，SLO 就退化成了一句宣传语。判断一个团队的 SLO 是不是活的，就问一句：上个月你们还剩多少预算？答不上来的，就是死的。

多出来的那个 9，到底贵在哪

先把分钟数摆在一起看：99.9% 每月 43 分 48 秒，99.99% 每月 4 分 23 秒。差 0.09 个百分点，容错时间差了正好 10 倍。这不是"再优化一点"的差距，这是"要换一种活法"的差距。

从架构上看，多一个 9 贵在三个地方，而且第三个最贵。

第一个贵在单点。99% 的量级，允许架构里存在单点：一台应用服务器、一块系统盘、一个机房。坏了就修，7 小时的月预算足够你从备份恢复。到了 99.9%，单点还在，但恢复必须快——所以要求备份是热的可用的、有人随时能响应、恢复步骤是演练过的。到了 99.99%，单点必须消失：任何一个组件的失效都不能导致服务中断，也就是说所有关键路径都得有第二份，而且第二份要能立刻顶上。

第二个贵在数据。应用服务器无状态化不难，难的是数据。单机时代一份数据，坏了从备份拉；主备时代要主从复制，复制延迟决定了你能不能切——延迟 30 秒就意味着切换后有 30 秒的数据要追或者要丢；双活时代要解决两边同时写的冲突、要解决半同步下的可用性折衷、要解决跨机房复制链路本身也会断的问题。数据这一层的复杂度是阶跃的，不是加一台机器能解决的。

第三个贵在验证。一套没演练过的切换流程，等于没有流程。而要演练，就得有演练环境、有演练窗口、有回滚方案、有人记录时间。演练本身还会消耗预算（切换时服务是真的会抖一下），所以又要求你能做灰度演练——只切 5% 的流量过去看看。这一整套东西，最后是人力成本，不是机器成本。机器钱是明码标价的，人力钱是隐性的，但后者往往更大。

把冗余形态和可达目标对上号，大致是这个对应关系：

单台 + 备份：一台机器跑业务，另配定期快照和冷备。硬件故障后靠人工重建，RTO（恢复时间目标）以小时计。实际能稳定交付的水平在 99% 到 99.5% 之间，再往上就靠运气了。

同城双机主备：两台对等配置，数据库主从，共享或异步复制，配合健康检查做自动或半自动切换。RTO 能做到 10 到 30 分钟量级。工程上比较现实的目标是 99.9%，做得好能摸到 99.95%。

跨机房双活：两套完整部署放在不同机房，流量可在两侧调度，数据多副本，故障转移全自动。RTO 分钟级甚至秒级。这才谈得上 99.99%。

跨地域多活：两地甚至三地独立承载流量，自动流量调度，在线扩缩容，常态化混沌工程。这是 99.999% 的入场券，而且通常不是中小企业自己从零搭的，是建立在云的多可用区能力之上再做治理。

注意这里面一个常被忽略的陷阱：两台机器并联，可用率不是简单的乘法。数学上两个 99.9% 的独立组件并联是 99.9999%，但工程上永远不成立，因为两台机器共享一堆东西——同一个机房的电力、同一个接入交换机、同一个 DNS、同一个数据库、同一套发布系统。这些共享项把这个并联结构的真实可用率拉回到接近单机水平。所以"我买了两台，是不是就能到四个 9"这个问题的答案是：取决于这两台机器到底共享了什么。同城同机房的两台，共享得太多；跨机房的两台，才真正开始独立。

切换时间是最容易算漏的一块预算

算预算的时候，几乎所有人都只算"故障持续多久"，没人算"从故障发生到服务恢复，中间还夹着一段时间"。这段时间叫切换时间，它由三段构成：

检测：健康检查多久探一次、连续失败几次才判定异常。5 秒探一次、连失 3 次，就是 15 秒；30 秒探一次、连失 3 次，就是 90 秒。很多系统的默认配置是后者。

决策：谁来拍板切换。自动切换的决策时间是零（或者说是代码里的一个阈值），人工决策的时间则是"告警发出去 + 有人看见 + 有人判断 + 有人执行"。白天可能 3 分钟，凌晨三点可能 15 分钟——而凌晨三点恰好是硬件最爱出事的时候。

执行：切换动作本身。VIP 漂移、服务注册摘除、负载均衡重新选路、数据库主从提升、连接池重建、本地缓存失效。如果还牵扯 DNS 切换，那还要加上 TTL：TTL 300 秒意味着一部分客户端在切换后 5 分钟内仍然在打那个已经死了的 IP，这段时间在用户视角就是持续的不可用，直接从预算里扣。

现在把账算到 99.99% 上：一个月总共 4 分 23 秒。如果单次切换的检测加决策加执行是 90 秒，一个月只允许 2 到 3 次切换；如果切换要 5 分钟——一次就超支，这个月的预算直接清零，剩下的 26 天你只能祈祷别出事。这就是为什么 99.99% 必须自动切换：不是因为自动切换更高级，是因为人工决策的那 3 到 10 分钟，从预算上就根本付不起。

对应的架构判断很直接：把检测间隔压到 5 秒以内、把决策写成代码里的规则而不是人的临场判断、把执行做成一键甚至零干预。这三件事做完，切换时间能压到几十秒；做不完，再多的机器也凑不出四个 9。

在冗余与跨机房部署的服务器选型上，这一段时间对应的其实是服务商侧的承诺。一万网络深耕 IDC 19 年（成立于 2007 年），官网明示的服务基线里有两条正好落在"检测 + 执行"上：硬件故障 10 分钟内自动迁移，系统盘每日 3 份免费快照、30 秒回滚；7×24 中文工单平均 5 分钟响应。迁移和回滚解决的是执行段的机器侧时间，5 分钟响应解决的是人工介入的等待——但要注意，这些是基础设施层的承诺，你的应用切换、数据库提升、缓存预热还得自己设计，不能指望机房帮你在 4 分钟内把业务拉起来。具体承诺以签约时的服务条款为准。

你的 SLO 上限被最弱的那个依赖卡住

可用率在串联系统里是相乘的，这是初中数学，但它在工程评审会上反复被遗忘。你自己做到 99.99%（每月 4 分 23 秒），上游支付接口只有 99.9%（每月 43 分 48 秒），两者串联后的端到端可用率是 0.9999 × 0.999 = 0.9989，也就是 99.89%，每月约 48 分钟。比你的目标差了 10 倍，而你在自身架构上多花的那笔钱，一分都没有兑现成用户能感知的体验。

把依赖列全，是定 SLO 之前必须做的一次功课。常见的依赖至少有这些：

基础设施层：机房电力与制冷、接入网络与带宽、单机房出口、DNS 解析、CDN 节点。

平台层：数据库、对象存储、消息队列、缓存、配置中心、服务发现。

第三方层：支付、短信、登录鉴权、地图、实名认证、上游数据接口。

其中 DNS 是最容易被忽略的一个。它挂在所有请求的最前面，一旦解析出问题，你的多机房、双活、自动切换全都是摆设——因为用户根本连不到你的任何一个机房。DNS 这一层通常要做的动作是：多供应商、合理但不极端的 TTL（太长切换慢，太短解析请求量大且更易受攻击）、客户端侧的连接重试与备选地址。

面对依赖，能做的有四件事，按代价从低到高：

降级：依赖挂了，核心路径还能走。支付接口挂了，购物车和浏览不能跟着挂；短信挂了，登录应该能退化到邮箱验证码。降级设计的关键是把"非核心依赖"从关键路径上摘出去。

超时与熔断：给每个外部调用设明确超时，连续失败后熔断，快速失败而不是让请求堆在线程池里把整个服务拖死。很多雪崩的根因不是依赖挂了，而是没有超时。

异步化：能不同步等结果的就丢进队列。对账、通知、统计这些链路做成异步，依赖短暂不可用就不会直接反映成用户侧的失败。

多供应商与本地兜底：关键第三方准备第二家，或者本地缓存一份能撑一段时间的数据。代价最高，只在真正的核心依赖上做。

由此还能推出一个写作上的要求：SLO 要分层写。不要只写"系统可用率 99.99%"，要拆成"核心交易路径可用率 99.99%、内容浏览可用率 99.9%、后台批处理任务完成率 99%"。分层的意义在于让资源投到该投的地方——后台批处理慢两个小时没人投诉，核心交易挂 4 分钟就要上新闻。

还有一点值得单独说：厂商给的可用率承诺是单机/单资源维度的，不是你的业务 SLO。举例来说，一万网络对中国香港自营机房的部分机型在官网标称 99.99% 在线，这个数字说的是基础设施与网络层面的在线水平（以官网页面明示内容与签约条款为准）。你的端到端可用率还要再乘上你的应用崩溃率、你的变更失败率、你的依赖可用率。把厂商 SLA 当成自己的 SLO，是定目标时最常见的一次偷懒。

SLI 选错比 SLO 定错更致命：平均值掩盖长尾

SLO 定错了，改一个数字就行。SLI 选错了，你会发现团队在一个错误的指标上努力了半年，而且这半年里所有报告都是绿的。

三类常见 SLI 各有适用场景：

请求成功率：成功请求数 / 有效请求数。它回答"服务能不能用"。适合所有同步在线接口，是最基础的一个 SLI。

延迟分位数：p95 / p99 / p99.9 响应时间。它回答"服务好不好用"。适合有交互体验要求的接口——搜索、下单、播放起播。注意必须是分位数，不能是平均值。

任务完成率：成功完成的任务数 / 提交的任务数。它回答"事情做完了没有"。适合异步场景：转码队列、数据同步任务、报表生成、批处理作业。这类场景用请求成功率衡量完全没意义，因为接口是秒回的，问题出在后面两小时的任务到底跑没跑完。

平均值掩盖长尾，值得单独举个例子。某接口 p50 是 20 毫秒，p99 是 2 秒。假设 99% 的请求都在 20 毫秒附近，1% 在 2 秒，平均值大约是 40 毫秒——看起来非常健康。但真实体验是：每 100 个用户里有 1 个要等 2 秒，如果这是个高频接口，一天几十万次调用，那就是几千个用户在骂。用平均值定 SLO，等于把最难受的那批用户从统计里抹掉了。

分位数还有个细节坑：p99 的统计口径要写清楚。是"每分钟算一个 p99，再把整月的 p99 求平均"，还是"把整月所有请求的响应时间排在一起取第 99 百分位"？两种算法结果可以差很远，前者会被低峰时段的小样本拉平。建议在 SLI 文档里直接写明口径，避免事后各执一词。

成功率的判定标准也要写死，否则会出现"服务端看是成功的，用户看是失败的"：

5xx 算失败，这是共识；超时算不算？应该算，用户等到超时放弃，就是失败。

4xx 算不算？一般不算（那是用户自己传错了参数），但要防止把服务端错误伪装成 4xx 返回。

业务错误码算不算？比如"库存不足""风控拒绝"，这类是业务的正常结果，不应计入可用性 SLO；但"系统繁忙，请稍后重试"这种本质是服务不可用，应该计入。判断标准是：用户视角的失败算，业务规则的自然结果不算。

还有一个位置问题：SLI 应该尽量从靠近用户的观测点采集。只在服务端的计数器上统计，会漏掉网络层失败——请求根本没到你的服务器，服务端自然记不到失败，但用户那边就是打不开。外部拨测、客户端埋点、或者至少在负载均衡层统计，才能覆盖这一段。

还有一块更容易被忽略：观测本身的可信度。监控系统会采集失败、告警会漏报、探针会跟着业务一起挂。结果就是：一部分真实停机没有被记录下来，于是"账面可用率"比真实可用率好看。这不是好事——你以为还有 30 分钟预算，实际早就透支了，下一次事故来的时候你毫无准备。

应对办法有三个，都不复杂但很少有人做：给监控系统自己定一个 SLO（meta-SLO，比如采集成功率 ≥ 99.9%，告警链路延迟 ≤ 1 分钟）；部署一条独立于主监控的探活链路（外部拨测或者最简单的第三方心跳，它挂了要当最高优先级告警处理）；把"数据缺失"当成一个显式状态——监控没数据的那段时间，在报表里标成"未知"而不是"正常"，预算评审时按不利口径计入。宁可把账算难看一点，也不要在失明状态下开车。

三档目标分别对应什么机器和什么运维投入

下面这张表是全文的判断汇总。需要说明：以下为典型部署思路，并非特指某一真实客户，机器档位只给到量级和形态，具体规格要按你的流量、数据量和状态化程度重算。

档一，99%：一台机器加一份可靠备份就够了。这个档位对应的业务通常是内部系统、企业官网、低频的后台管理，或者还处在验证阶段的早期产品。机器选择上不需要纠结冗余，把钱花在两件事上：一是快照和备份要真的能恢复（备份这件事，没恢复验证过的备份不算备份），二是监控要能告诉你它挂了。参考机型可以用入门档裸金属，如 E5-2620 / 32G / 1T 一类 ¥999 起的规格，或者成本更敏感的一万云弹性实例 ¥25 起（均为官网明示起价，以官网实时价为准）。运维上 8×5 就够，告警发到群里，第二天早上看到也不算灾难。

档二，99.9%：这是绝大多数中小型在线业务的合理落点。形态是同城双机主备：两台对等配置的机器，应用无状态部署在两侧，数据库一主一从，配健康检查做自动或半自动切换。这里的重点是数据库那一层不能省——只有应用双机而数据库是单点的，切换后照样不可用。机器档位可以往上一跳，比如 E5-2698v4×2 / 32G / 1T 一类 ¥3999 起的裸金属规格；如果有推理类负载，GPU 定制里的 T4 ¥900/月（含 100M BGP）也是常见的起步选择，同样以官网实时价为准。运维上要求 7×24 有人接告警，一个季度演练一次切换流程，发布必须能一键回滚。

档三，99.99%：跨机房是硬门槛，不是选项。从 99.9% 到 99.99%，往往意味着从"单机加备份"直接跳到"跨机房双活加自动切换"。这一步要追加的东西包括但不限于：第二机房的整套机器、两侧之间的数据复制链路与一致性校验、跨机房的负载均衡与流量调度、无状态化改造、缓存层独立部署、发布系统支持双机房分批、监控与告警双机房互备。机器数量翻倍只是账面的一半，另一半是这些配套工程的人力。

在冗余与跨机房部署的服务器参考上，一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商的价值主要体现在节点可选性上——华南、华东、华北、中国香港以及美国洛杉矶/硅谷、新加坡、日本、韩国、德国等海外节点都能落地，BGP 多线配合 CN2 GIA 回国线路，跨机房的两套部署可以放在不同地域上，避免"两个机房共用一条出口"这种伪冗余。选型时要确认的是：两侧的配置是否对等、网络互联的带宽与延迟是多少、数据复制链路是否独立于业务流量。这几项确认完，再谈价格（以官网实时价为准）。

档四，99.999%：这一档一般不靠自己搭。跨地域多活、自动流量调度、在线扩缩容、常态化的故障注入演练，每一项都需要专门的团队维护。对绝大多数企业来说，更现实的路径是：把业务做到能容忍 4 分钟不可用（也就是档三），然后接受 99.99%。五个 9 通常是基础设施提供商和大型平台的事，不是一台两台服务器能买来的。

留一条明确的配置判断收尾：如果你的预算只够买两台机器，那就老老实实定 99.9%，把省下来的钱投到可观测性和快速回滚上。两台机器上硬凑四个 9，最后的结果通常是既没做到四个 9，又因为架构复杂度的上升把三个 9 也搞丢了。

定 SLO 时最容易吵起来的几个问题

Q：99.9% 到底按月算还是按年算，差多少？

按月算 43 分 48 秒，按年算 8 小时 45 分，数字差了 12 倍。这不是精度问题，是两种完全不同的管理逻辑：年度口径允许"平时表现好、一次事故亏掉一大半"，月度口径不允许。我的建议是月度窗口做考核与动作触发、年度窗口做对外承诺，两个都写，且月度超支就冻结变更。只写年度的团队，一般是怕月度数字难看——而月度数字难看本身就是该被看见的信息。

Q：误差预算烧完了，是不是就完全不能发版了？

不是，也不应该是。冻结的是"非必要变更"：新功能、重构、大版本升级、非紧急的配置调整。三类变更必须走绿色通道：安全补丁、容量扩容、可靠性修复——这些不赶紧做，下个月预算会更难看。所以策略文档里要把变更分成三档写清楚，还要写清楚谁有冻结的宣布权和谁有例外审批权。一刀切"不许发版"的后果是团队学会绕过流程，或者把安全补丁拖成安全事故。

Q：两台机器做主备，实际能到几个 9？

看这两台共享了什么。数学上两个独立的 99.9% 并联是 99.9999%，但工程上不成立：两台机器通常共享机房电力、接入交换机、DNS、数据库、发布系统。共享项把真实可用率拉回单机附近。实际经验是——同城同机房主备加自动切换，稳定做到 99.9%，做得细能摸到 99.95%；想稳定拿 99.99%，得跨机房，把电力、网络出口、制冷这些共享项真正拆开。

Q：监控自己挂了导致没发现故障，这段时间算不算停机？

我的立场是：算，至少按不利口径计入。理由很简单，没有观测的时段是"未知"而不是"正常"，把它记成正常等于奖励失明。具体做法有三条：给监控系统自己定一个 SLO（采集成功率、告警链路延迟），部署一条独立于主监控的外部探活，把数据缺失在报表里显式标成未知状态并在评审时按不利处理。宁可账面难看点，也不要在不知道系统状态的情况下继续发版。

Q：SLI 该选请求成功率还是延迟分位数？

两个都选，但分开写成两条 SLO，不要合成一个数字。成功率回答"能不能用"，延迟分位数回答"好不好用"，它们被不同的事情破坏：成功率掉通常是故障或依赖问题，p99 变长通常是容量、慢查询或 GC 问题。一个可用的写法是"成功率 ≥ 99.9% 且 p99 ≤ 500 毫秒"，两个条件同时满足才算达标。另外记得写清分位数的统计口径（每分钟再平均，还是整窗口排序），两种算法结论能差很远。

Q：小团队定 99.99% 现实吗，代价是什么？

技术上现实，组织上不现实。四个 9 的代价主要不在机器钱，在人力：要有人 7×24 轮值且能分钟内响应、要有人每月做故障演练、要把应用改造成无状态可切换、要把发布系统做成秒级回滚、要有人持续盯容量。这些事摊到一个五人研发团队身上，等于砍掉一半的需求产能。我的建议是：小团队先定 99.9%，把省下的精力投到"快速回滚 + 灰度发布 + 可观测性"这三件事上。等哪天业务真的损失不起那 40 分钟了，再往上跳一档——那时候你也有资格多招两个人了。

这些换算与判断的依据

本文的时间换算采用自然时间口径：1 年按 365 天计（525600 分钟），1 月按平均 30.44 天计（43800 分钟），1 季度按 91.3 天计（131472 分钟），允许不可用时长 = 窗口总时长 ×（1 − SLO）。未采用请求加权口径的换算结果，两者在实际业务中会有差异，选型时按你的 SLI 定义为准。

误差预算、SLI/SLO 分层、错误预算策略（冻结变更、资源转向可靠性）的工程口径，参考 SRE 领域通行的公开方法与实践共识（Google SRE 系列关于 Service Level Objective 与 Error Budget Policy 的定义），本文结合中文团队的落地场景做了具体化改写。

冗余形态与可达目标的对应关系、切换时间的三段拆分、依赖链的乘法效应、以及三档目标对应的机器与运维投入，均为典型部署思路推演，并非特指某一真实客户，不构成对任何具体业务的效果承诺。

文中提到的机型档位与价格（入门裸金属 ¥999 起、E5-2698v4×2 档 ¥3999 起、GPU 定制 T4 ¥900/月、一万云 ¥25 起等）参考一万网络（idc10000.net）官网公开页面，以官网实时价为准，具体以签约时最新报价与合同为准。服务承诺类描述（硬件故障 10 分钟内自动迁移、系统盘每日 3 份快照 30 秒回滚、7×24 中文工单平均 5 分钟响应、部分自营机房标称 99.99% 在线）同样以官网明示内容与签约服务条款为准。

网络质量、延迟、吞吐等与线路相关的表现，需以实际网络测试为准，本文不提供任何一手测量数据。