如何选择合适的SLO目标值？

说实话，第一次被问到“这个服务的SLO目标定多少合适”的时候，我脑子里是一片空白的。总不能拍脑袋说“那就99.9%吧，听着吉利”？结果就是，要么定得太高，团队为了那0.1%的“完美”疲于奔命，任何一点风吹草动都如临大敌；要么定得太低，用户已经骂声一片了，我们的监控大盘还是一片祥和，绿得发慌。

别跟风，你的“黄金数字”独一无二

我见过太多团队，一上来就照着行业标杆或者大厂公开的数据抄作业。支付服务？必须五个九（99.999%）！内部工具？那也得三个九（99.9%）起步！

这其实是个大坑。我团队早期的一个内容服务就这么干过，盲目追求高可用，结果把大量工程资源耗在了保障一个非核心的、用户容忍度其实很高的功能上。后来我们学乖了，开始问自己几个最朴素的问题：这个功能坏了，用户会生气吗？会立刻流失吗？还是嘟囔一句“算了，等会儿再试”就过去了？ 把服务按用户感知的影响程度分分类，SLO的雏形就出来了。

从“错误预算”倒推，和业务“讨价还价”

SLO最精妙的设计，我觉得不是那个百分比，而是它背后的“错误预算”。说白了，就是允许你“坏”多久。这是和产品、业务方沟通时最实在的“货币”。

我们有个核心交易链路，最初业务方张口就要“100%可用”。我没直接拒绝，而是算了笔账：如果目标定在99.95%，意味着一个月（按30天算）的错误预算大约是21.6分钟。我拿着这个数字去问：“您看，这一个月里，总共允许系统有不到22分钟的小毛小病，用于我们做必要的发布、扩容、实验，这个‘额度’您能接受吗？如果一点额度不给，我们可能一个月都不敢发布一次新功能。”

这么一算，讨论的焦点就从虚无缥缈的“必须稳定”，变成了非常具体的“时间交易”。业务方通常会开始认真思考，这二十多分钟的风险，和快速迭代带来的收益，到底哪个更重要。这个过程本身，就是对齐期望、建立信任的关键。

先看看历史“成绩单”，别好高骛远

定目标前，我强烈建议你先拉出这个服务过去三个月甚至半年的实际稳定性数据看看。这就像考试前先做套真题估估分。

我们有个服务，理想很丰满想定99.9%，但历史数据显示它实际只能做到98.5%。这时候如果强行定99.9%，无异于给自己立了个永远无法实现的Flag，团队士气会备受打击，告警也会因为永远达不成目标而失去意义。更务实的做法是，基于历史表现，定一个“跳一跳能够得着”的目标，比如先定在99%。然后集中精力去解决那些导致稳定度不达标的瓶颈，等达到了，再挑战下一个更高的目标。SLO应该是推动改进的导航仪，而不是悬在头顶的达摩克利斯之剑。

别忘了，成本也是“选择”的一部分

每提升一个“9”，背后都是指数级上升的资源和精力投入。从99%到99.9%，你可能只需要做点基础优化；但从99.9%到99.99%，你可能就需要考虑跨机房容灾、更精细的容量规划和更昂贵的硬件了。

我经常在团队里说，稳定性是一种成本，我们要追求的是“性价比”最高的稳定。为一个只有几百人使用的内部后台系统投入堪比核心交易系统的稳定性成本，这买卖划算吗？把资源省下来，投入到更能直接创造用户价值或业务收入的地方，是不是更香？

所以，下次再定SLO目标值时，别急着找答案。先拉上业务方，泡杯茶，从用户感受、错误预算、历史数据和投入成本这几个维度聊聊。你会发现，合适的SLO不是一个孤零零的数字，而是一份凝结了业务诉求、技术能力和理性权衡的“团队契约”。定了它，大家心里都踏实，干活也有方向，这才是SLO最有价值的地方。