SLA：99.9% 是 43.2 分钟，以及为什么先承诺 99.5%

客户说的是 99.9%，他要换算成「每个月到底能坏几分钟」。

一、客户要 99.9%，他先算了一个月有多少分钟

2026 年 8 月 5 日上午，方工把采购模板的附件发过来，第 6 页写着：服务可用性不低于 99.9%，未达标按年费比例赔付，上限 15%。程野没有先回「可以」，而是打开计算器：30 天 × 24 小时 × 60 分钟 = 43,200 分钟，0.1% 就是 43.2 分钟。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

43.2 分钟是什么概念：六次事故里有三次落在额度内——20 分钟、30 分钟、40 分钟，分别是缓存抖动、数据库迁移回滚与证书过期；另外三次是 210、310、375 分钟。99.9% 的额度比 40 分钟只多 3.2 分钟——只要有一次超过 44 分钟，这个月就已经违约。

接着他拉监控。2 月到 7 月共六次停机，按事件汇总：30、310、20、210、40、375 分钟，合计 985 分钟。分母是 6 × 43,200 = 259,200 分钟。

985 ÷ 259,200 = 0.38%，也就是 99.62%。离 99.9% 差 0.28 个百分点，换成分钟是 985 − 259.2 = 725.8 分钟。这个换算比百分比直观：半年的差距是十二个小时，而不是「零点二八」。

他把六次事故各写一行：时间、影响面、发现方式、恢复动作。写完发现 375 分钟那次占了全部停机的 38%，原因是一个没有上限的索引重建。一次事故就决定了一份合同能不能签。

六次事故可以分成两类：一类是改配置改坏的，有明确回滚路径；一类是容量到顶，只能等任务跑完。375 分钟那次属于后者——索引重建没有设置语句超时，回滚也回不到中间状态。

这个分类决定了后面所有谈判：可控事故可以承诺更短的恢复时间，不可控的只能靠架构改造或提前扩容。先分类再承诺，比承诺之后再解释便宜得多。

二、四个 9 到一个月多少分钟

四个 9 不是四个形容词，是四个分钟数。下表按 30 天的月份与 365 天的年份折算，最后一列用近六个月的六次停机逐月比对。

逐月比对的结果是：30 分钟、20 分钟、40 分钟这三个月过了 99.9%，对应 99.931%、99.954%、99.907%；310、210、375 这三个月没过，对应 99.282%、99.514%、99.132%。

99.5% 只剩两次违约，是因为第四个月（5 月）的 210 分钟刚好低于 216 分钟的门槛，差 6 分钟。这条线不是设计出来的，是算出来的：同一份数据换一个承诺，违约次数从 3 变成 2。

99.99% 每月只允许 4.3 分钟。一次部署 6 分钟就超了，一次 DNS 切换 10 分钟就超了。做到它不靠加监控，靠换故障模型：多区域、无状态、故障时流量已经切走。

所以四个 9 的差别不是努力程度，而是「你假设故障多久能修好」。99.9% 假设一小时内能修完，99.5% 假设四小时内能修完，99.99% 假设根本不需要修——流量不在故障的那一边。

四个 9 之间也不是线性关系。从 99.0% 到 99.5%，每月少 216 分钟；从 99.9% 到 99.99%，每月只少 38.9 分钟，但工程成本翻几倍。越往上，每一分钟都更贵。

他把这张表发给方工时加了一行「我们近六个月的实际水平：99.62%」。客户看到的是「你们离 99.9% 差 0.28 个点」，而不是「你们不肯承诺」；同一件事，换个说法就从态度问题变成了差距问题。

三、月度口径与季度口径

同一份 985 分钟，按月结算和按季度结算会得出不同结论。客户模板默认月度，他在回复里提出了季度，并把两种算法都写进附件。

月度把一年切成 12 次考试，季度切成 4 次。事故集中在某一个月时，月度会放大惩罚；事故分散时，两种口径接近。Q1 的 360 分钟里，310 那次单独就超过了 129.6，加上 30 与 20 仍然是 360——季度口径没有救回 99.9%，因为一次两小时以上的事故就足以吃掉整个季度预算。

季度 99.9% 仍然是两次违约，因为 129.6 分钟的季度预算太小，任何一次超过两小时的事故都会击穿。真正让违约归零的是「季度 + 99.5%」这一组：允许 648 分钟，Q1 用掉 360，Q2 用掉 625。

Q2 只差 23 分钟，不是「轻松通过」。如果 7 月再出一次 200 分钟的事故，Q3 就会违约。写这一段是为了提醒：季度口径降低的是结算频率，不是事故概率。

他没有用季度口径逃避责任：合同里同时写了「每月 5 日前公示上月可用性」，客户随时能看到当月数字，只是赔付按季度结算。公示是月度的，钱是季度的，两件事分开写，比含糊地写「按季度考核」清楚。

季度口径还有一个副作用：归属日期。Q2 的 625 分钟里有 375 来自一次事故，如果那次事故从 6 月 30 日 22 时 45 分开始、7 月 1 日 5 时恢复，它算 Q2 还是 Q3？合同里要写清按「中断开始时刻」归属，否则同一个事故会在两个季度里各被算一次。

四、赔付上限与三类排除项

赔付按「违约月 × 月费 10%」计算：1,500 × 10% = 150 美元一次。按 99.9% 算是三次违约、450 美元；按实际承诺的 99.5% 算是两次、300 美元。年度上限是 18,000 × 15% = 2,700 美元，450 只用到上限的 16.7%。

复算：30 天 = 30 × 1,440 = 43,200 分钟
　　　99.9%：43,200 × 0.1% = 43.2 分钟/月；525,600 × 0.1% = 525.6 分钟/年
　　　99.5%：43,200 × 0.5% = 216 分钟/月；525,600 × 0.5% = 2,628 分钟/年
　　　99.0%：43,200 × 1% = 432 分钟/月；525,600 × 1% = 5,256 分钟/年
　　　99.99%：43,200 × 0.01% = 4.3 分钟/月；525,600 × 0.01% = 52.6 分钟/年
　　　近六个月：30 + 310 + 20 + 210 + 40 + 375 = 985 分钟
　　　可用性：1 − 985 ÷ 259,200 = 1 − 0.380% = 99.62%
　　　与 99.9% 的差距：985 − 259.2 = 725.8 分钟
　　　Q1：30 + 310 + 20 = 360；Q2：210 + 40 + 375 = 625
　　　季度 99.5% 允许：3 × 216 = 648；360 ≤ 648，625 ≤ 648，违约 0 次
　　　赔付：1,500 × 10% = 150/次；150 × 3 = 450；上限 18,000 × 15% = 2,700

这一轮 SLA 在售前工时里记 5 小时：2 小时算分钟与赔付，2 小时改条款，1 小时与方工逐条过排除项。三类排除项要逐条写清，不能只写「不可抗力除外」。

第一类是计划内维护：提前 7 天书面通知，每月累计不超过 60 分钟，避开客户工作时段 9 时到 19 时。这 60 分钟不计入停机；客户如果要求更严，只能压到 30 分钟，代价是发布窗口变窄。

第二类是客户侧原因：客户网络、浏览器、误删数据，以及客户自己的身份服务故障导致无法登录。这一条要写具体，否则客户会认为你把所有登录问题都推给他。

第三类是上游基础设施。这里他做了区分：单可用区故障不排除，区域级中断经双方确认后按 50% 计入停机。把上游全部排除，等于客户买了一份「只保我自己写错代码」的承诺，签下来也不体面。

赔付条款里最容易忽略的是「怎么算一次」。同一天两次故障间隔 40 分钟，算一次还是两次？他写的是「恢复后 60 分钟内再次中断，合并计为一次」，避免把一次事故拆成多次小额赔付，也避免客户按次累加。

上限 2,700 美元看起来很高，但它是年费的 15%，也就是最坏情况下这一年这单只剩 15,300。真正要问的不是「上限够不够高」，而是「触发上限的那种事故发生后，我还能不能继续做生意」。

为什么先承诺 99.5%：近六个月平均每次事故 164 分钟（985 ÷ 6），要满足 99.9% 得把每次压到 43.2 分钟，等于把恢复时间砍到四分之一；99.5% 只要求压掉 310 与 375 两次的根因，而这两个根因都能在 4 周内改掉。

五、行动清单与复算验收

• 把承诺换算成每月允许分钟数，写在合同附件第一行。
• 拉最近六个月的事故记录，逐月与允许值比对，标出违约月。
• 给每次事故写一行根因，找出占停机总时长最大的那一次。
• 决定结算口径是月度还是季度，并在合同里写死。
• 定赔付比例与年度上限，算一遍最坏情况下的现金支出。
• 列三类排除项，逐条自问「客户会不会觉得这是逃避」。
• 承诺前做一次恢复演练，记录从发现到恢复的真实分钟数。
• 每月公示可用性，哪怕赔付按季度结算。

验收标准：任取一个月，都能在 1 分钟内说出该月允许停机多少分钟、实际停机多少分钟、是否触发赔付，以及赔付金额。

前四条是「把承诺变成数字」，后四条是「让数字经得起对账」。如果只有半小时，先做第一条和第二条：没有近六个月的记录，任何承诺都是猜的。

承诺 99.5% 不是保守，是把「做不到的 0.4 个百分点」换成了「做得到的赔付与修复计划」。客户真正在意的不是那个数字，而是出事之后你有没有人、有没有时限、有没有钱赔。

使用边界与实操验收

SLA 是商务条款，不是技术指标。 同样的 99.9%，配上不同的赔付比例、排除项与结算口径，风险可以差十倍。只看百分比签字，等于只看了合同的第一行。

口径必须写死。 「月度」指自然月还是滚动 30 天，「停机」指全站不可用还是核心接口不可用，都要在附件里定义。定义含糊时，争议一定发生在最忙的那个月。

排除项要能被客户复述。 如果客户说不清哪些情况不赔，说明条款写失败了；能复述的排除项才是可执行的排除项。

承诺的边界不是敢不敢，而是赔不赔得起。 如果一年赔 2,700 会让现金流断掉，这个承诺本身就不该签，哪怕技术做得到。技术能做到和生意扛得住是两件事。

99.62% 是教学基线。 它来自本组统一口径的六个月停机记录，不构成对任何产品可用性的预测，也不构成对任何客户的服务承诺。

不替代法律意见。 赔付比例、责任上限与排除条款在部分司法辖区受强制法约束，最终文本应以专业意见为准。

关键参考与核验范围

• AWS Well-Architected 可靠性支柱 ：用于核对可用性目标、故障隔离与恢复策略的设计框架。
• NIST SP 800-61 ：用于核对事件响应流程与恢复阶段的划分。
• NIST SP 800-53 ：用于核对应急计划与可用性相关的控制项分类。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人如何把可用性承诺换算成分钟、选择结算口径与设定赔付上限，不讨论多区域架构的具体实现、具体司法辖区的责任法结论，也不评价任何云服务商的 SLA 条款。

系列导航

• 上一篇：DPA 与子处理者：七个供应商、二十八页条款与三处缺口
• 下一篇：SSO 与 SCIM：二十六小时的工程与三档报价
• 回到目录：一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单
• 相关阅读：可用性是一份预算：四个 9、停机分钟与一个人的取舍