凌晨两点，手机突然震动。告警信息一条接一条地弹出来——线上服务大面积超时，用户登录不了，订单提交失败。你一边抓头发一边翻日志，心里只有一个念头：早知道当初就把可靠性目标定得再严一点。
什么是SRE的可靠性目标？
SRE（Site Reliability Engineering）不是单纯地救火，而是提前规划系统能承受多少“折腾”。可靠性目标说白了就是：我们允许这个系统坏到什么程度，还能忍？
比如一个电商网站，全年停机时间不超过5分钟，这就是一种目标。但更常见的做法是用“可用性百分比”来表达，像99.9%、99.99%，这些数字背后对应的是每年可接受的宕机时长。
从数字看容忍度
很多人觉得99.9%已经够高了，算下来一年也就8小时多点故障时间。可真到了大促那天，这8小时可能全砸在双11当晚，那就不是技术问题，是公关危机了。
来看一组实际换算：
99% 可用性 → 每年约 3.65 天不可用
99.9% → 约 8.77 小时
99.99% → 约 52.6 分钟
99.999% → 约 5.26 分钟每多一个‘9’，技术和投入成本都翻倍。所以定目标不能拍脑袋，得看业务能不能扛。
怎么定才不脱离现实？
有个做在线教育的朋友讲过一个例子：他们最初给直播课平台定了99.99%的目标，结果发现网络抖动、CDN切换、客户端兼容性问题加起来就超标了。后来改回99.9%，把省下来的精力放在优化用户体验上，反而投诉少了。
定目标前先问三个问题：
- 用户真正感知到的服务中断是什么？
- 业务最怕哪种故障？是完全打不开，还是响应慢？
- 修复一次故障平均要多久？有没有自动恢复机制？
这些问题的答案决定了你的SLI（服务等级指标）和SLO（服务等级目标）。比如你可以定义SLI为“HTTP请求中延迟小于500ms的比例”，然后SLO设为99.9%。
别忘了错误预算
这是SRE里最有意思的概念之一。假设你定的SLO是99.9%，那剩下的0.1%就是“错误预算”。只要没花完，开发团队就可以继续上线新功能；一旦超了，立刻冻结发布，先修稳定。
就像信用卡额度，刷多了就得停手。有家公司就靠这套规则说服产品经理：别急着推新活动页，上周API错误率已经用掉70%预算了。
目标不是一成不变
新系统刚上线时，99%可能都难保。这时候硬套高标准只会让人天天加班。合理的做法是阶段性提升目标，先稳住核心链路，再逐步收紧。
反过来，有些老系统常年跑在99.99%以上，其实资源严重浪费。这时候可以适当放宽一点，腾出服务器去做别的事，也是一种优化。
关键是把目标变成团队共有的语言，而不是贴在墙上的口号。每次事故复盘时回头看看：这次破的是哪条SLO？为什么没预警？下次能不能在预算耗尽前发现苗头？
系统永远不可能完全不坏，但只要坏得在计划之内，你就还掌握主动权。