可用性 SLO 定到 99.99% 到底值不值这笔账？

背景：最近跟几个团队聊架构，发现一个挺有意思的分歧。同样是做内部业务系统，有的团队把 SLO 直接定到 99.99%（一年停机不超过 52 分钟），有的团队觉得 99.9%（一年 8.7 小时）对绝大多数内部系统已经绰绰有余，还有人干脆说"别定 SLO，能跑就行"。我自己在一线运维 3 年，两边都踩过坑，所以想把这个话题摊开来聊聊。

先把账算清楚（大白话版）：99.9% = 一年允许 8.7 小时停机；99.95% = 4.4 小时；99.99% = 52 分钟；99.999% = 5 分钟。注意，每多一个 9，允许停机的时间是指数级下降，但成本是线性甚至超线性上升的：要多部署一套机房、要做异地多活、要把所有单点拆掉、要引入更复杂的故障切换和一致性方案、值班同学的心理压力也会翻几倍。我见过一个不赚钱的内部工具，因为 SLO 被定到 99.99%，硬生生上了异地双活，运维成本比业务本身还贵，这账怎么算都是亏的。

常见的几种分歧：

1. 「一刀切派」：所有服务统一 99.99%，理由是"简单、好管理"。代价是低价值服务也被迫承担高可用成本。
2. 「分级派」：按业务价值分 P0/P1/P2，P0 上 99.99%、P2 给 99% 甚至不设。代价是需要一套价值评估机制，且容易被拍脑袋。
3. 「错误预算派」（SRE 那套）：用 error budget 来约束发布节奏，预算用完就停止上新功能。这套我觉得最科学，但落地需要监控和度量做得很扎实，小团队经常玩不动。
4. 「不定派」：内部系统不设 SLO，出了问题再说。风险是没人对"什么时候算坏了"负责，事故复盘时扯皮。

我的倾向：分级 + 错误预算。但不是照搬 Google 那套，而是先回答一个问题——"这个系统挂 1 小时，业务上到底损失多少？" 把损失量化成钱或者用户量，再去反推需要几个 9。很多团队定 SLO 是抄来的数字，从来没算过这个账。

想听大家聊聊：

• 你们团队 SLO 是怎么定的？是拍脑袋还是有量化依据？
• 有没有为了"凑一个 9"而上过重设施、最后发现用不上的经历？
• 对内部工具、测试环境、实验项目，你们觉得设不设 SLO？怎么设？
• 错误预算这套在你们这儿落地过吗？卡在哪儿了？

欢迎贴你们的实际数字（脱敏后），越具体越好，空谈意义不大。