说「一直在线」不要成本，说「每月不超过 216 分钟」才要。
一、他说产品一直在线
骆一舟的产品上线十四个月，从没做过可用性记录。用户问起来，他的回答是「基本一直在线，偶尔有点慢」。
直到一个团队客户在续费前发来一张表，第一栏是「过去十二个月的可用性」。他翻遍后台，只找到四次故障的工单截图，加起来大约两个小时，却说不清具体分钟数，也说不清哪一次是依赖方造成的。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
「基本在线」不是承诺，是印象。 印象在续费谈判里换不来任何东西；能换的是一串可以复核的分钟数。
可用性不是技术指标，是预算。 一个月给你 43200 分钟，你打算用掉多少、留多少，才是要决定的事。
二、把可用性换成分钟
百分比看不见，分钟看得见；先把口径换成分钟，再谈承诺。
| 目标 | 每月允许停机 | 每年允许停机 | 意味着什么 |
|---|---|---|---|
| 99.0% | 432 分钟 | 87.6 小时 | 每月可以坏一整个工作日 |
| 99.5% | 216 分钟 | 43.8 小时 | 每月可以坏三个多小时 |
| 99.9% | 43.2 分钟 | 8.76 小时 | 每月只够修一次小故障 |
| 99.95% | 21.6 分钟 | 4.38 小时 | 一次没在五分钟内发现就会超 |
四周月与自然月的差别要写清。 本文按 30 天、43200 分钟计算；换成 31 天的月份，分母不同，结论会差 3%。
停机要有定义。 是全站打不开，还是核心路径失败？两个人的团队可以把「登录与支付不可用」算停机，「某个次级页面慢」不算。
不同路径可以分档。 登录与支付按全量计，导出与报表按半数计；分档的意义是让数字贴近用户感受，而不是让数字好看。
按用户视角计，不按进程视角计。 进程还活着但用户无法完成关键动作，就是停机；反过来，进程重启但用户没有感知，不必全额计入。
部分故障可以按影响面折算。 120 个账户里有 34 个受影响，占 28.3%；一次持续 10 分钟的部分故障，折算 2.8 分钟。折算规则要事先写，不要事后挑一个对自己有利的系数。
分钟数按事件记录，不按记忆补。 每次故障记开始、恢复与影响面三个时间点；没有这三个点，事后只能估算。
三、四个 9 的价格
每多一个 9，代价不是线性的。
| 目标 | 需要增加的措施 | 月成本（教学假设） | 一个人扛得住吗 |
|---|---|---|---|
| 99.5% | 单实例、自动重启、每日备份、五条探针 | 55 美元 | 扛得住，每月约 1 小时 |
| 99.9% | 多可用区、只读副本、自动故障转移、值班告警 | 190 美元 | 勉强，每月约 4 小时 |
| 99.95% | 多区域、流量切换、演练与变更评审 | 640 美元 | 扛不住，等于半份运维工作 |
从 99.5% 到 99.9%，多花 135 美元买 172.8 分钟。 折合每分钟 0.78 美元；从 99.9% 到 99.95%，多花 450 美元买 21.6 分钟，折合每分钟 20.8 美元，涨了约 27 倍。
停机本身的收入损失很小。 月收入 1800 美元对应每分钟 0.0417 美元，216 分钟约 9 美元；真正贵的不是这两位数，是用户对你的判断、退款与续费。
所以买的是信任，不是分钟。 决定档位的应该是「谁是客户」：个人用户能接受每月一次小故障，团队客户会在采购表上核对。
先买 99.5%，再按季度升级。 客户结构没变之前，多出来的 135 美元买不到对应收益；等到有团队客户在采购表上要求 99.9%，再升级也不迟。
别承诺你测不到的东西。 合同写 99.9%，却没有能证明 99.9% 的探针与记录，等于给自己埋一条违约线。
四、对外承诺与内部目标分开
对外写低一档，对内做高一档；中间那一档是缓冲。
月历 30 天 = 43200 分钟
近 90 天 = 90 × 1440 = 129600 分钟
实测停机 4 次、累计 138 分钟
可用性 = 1 − 138 ÷ 129600 = 99.8935% ≈ 99.89%
内部目标 99.9% → 90 天允许 129.6 分钟 → 超出 8.4 分钟
对外承诺 99.5% → 90 天允许 648 分钟 → 余量 510 分钟
停机收入敞口 = 1800 ÷ 43200 × 216 ≈ 9.0 美元/月
超出内部目标时：先冻结发布，再排一次恢复演练
对外 99.5%、对内 99.9%，是本文建议的起点。 对外留 510 分钟余量，说明一次持续一小时的事故不会让你违约；对内留 43.2 分钟，说明任何一次超过十分钟的故障都必须复盘。
超出内部目标不等于要加钱。 8.4 分钟的超出可能来自一次依赖故障；先看构成，再决定是买冗余还是改流程。
客户问起时给区间，不给形容词。 「过去 90 天 99.89%，最长一次 82 分钟」比「很稳定」有用；区间还能顺带说明你打算怎么改。
季度重算一次。 分母、停机分钟与客户结构都会变；上一季度算出的档位不能直接沿用到下一年。
两个口径都要能追溯到探针。 说 99.9% 就要有五条探针与 90 天记录；追溯不到的承诺，在争议里等于没有。
承诺要写进状态页与合同两端。 只有状态页写 99.5%、合同写 99.9%，等于对外有两个口径，出事时两边都站不住。
五、行动清单与复算验收
可用性账只需要四个数字：分母、停机分钟、实测百分比、超限动作。
- 定义什么算停机，写下一句可判断的标准。
- 取最近 90 天的故障记录，补齐开始、恢复与影响面。
- 用 129600 分钟作分母，算出真实可用性。
- 把四次故障按「自因」与「依赖方」分开计。
- 写下对外承诺一档、内部目标一档，并说明差别。
- 为超出内部目标写一个具体动作，不写「加强监控」。
- 在状态页与合同里核对两个数字是否一致。
- 设一个季度重算日，写进日历。
清单之外的动作都是临时发挥：没有折算规则时，每次事故都要重新争论一遍；把规则写下来，下次只用填数。
验收标准：你能说出过去 90 天的停机分钟数与可用性百分比，并给出对外承诺、内部目标与超限动作；说不出，说明你还没有可用性账。
使用边界与实操验收
本文处理的是一人产品的可用性口径，不涉及多区域架构与合规审计。
合规口径不归本文。 合同里的赔偿条款、数据处理与审计要求走合规专题；本文只算分钟。
可用性不等于体验。 一个每月只停 10 分钟但每天都很慢的产品，用户感受比数字差得多。
折算规则要先写。 部分故障、计划维护与依赖故障各按什么比例计入，必须在第一次事故前定好。
维护窗口也要计入。 计划内维护若影响用户，就占预算；把它藏到「计划内」里，预算会失真。
别把依赖方故障当免责。 对用户而言，你的产品不可用就是不可用；可以标注原因，但不能不计入。
数字要能复核。 每个分钟数都要能追到一条记录；追不到就标「估算」，不要混进实测。
别把内部目标写进合同。 内部 99.9% 是你给自己的压力，写进合同就变成赔偿义务。
不要为了数字改口径。 出事后调整「什么算停机」，等于把预算变成装饰。
关键参考与核验范围
核验日期：2026-10-25。以下链接用于核对服务水平目标与错误预算的一般做法，本文未逐条引用其内容。
- Google SRE：服务水平目标 ：用于核对 SLO、SLI 与错误预算的基本定义。
- Google SRE Workbook：实施 SLO ：用于核对把目标落到度量与告警上的做法。
引用口径。 本文只借用「用错误预算约束可靠性投入」这一一般思路；43200、99.89%、55 与 190 全部是教学假设，与上述材料无关。
口径一致。 本文的 138 分钟停机与《最小监控》里的探针频率、《告警降噪》里的 4 小时运维预算共用同一套假设，可以互相对照。
核验范围。 核验的是「分钟化 + 两档承诺」这套结构是否仍可操作，不是比对某家云厂商的 SLA 条款。
不引用具体报价。 文中 55、190 与 640 只用来展示数量级差异；真实价格随区域、实例与合同变化，代入前请以账单为准。
如何自行复核。 取最近一次故障，用状态页或工单时间戳重算分钟数；若与本文的 138 分钟口径相差超过 10%，先检查是否漏计了部分故障。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。