结论先行：稳定性目标要落到可考核的数字上，做法是三步：从分位耗时、错误率、饱和度里各挑少量 SLI；按业务环节而不是全系统来定 SLO，并写明统计窗口；把 SLO 折算成错误预算，规定预算消耗过半与耗尽时分别做什么。目标一旦能算出剩余额度，"今天还能不能发版"就从争论变成了查表。
为什么"可用率 99.9%"不够用
可用率是事后统计值，它有三个问题：口径模糊，一次超时算不算不可用、计划内维护算不算，各团队理解不同；粒度太粗，全站一个数字会掩盖"支付正常、查询已经劣化"的事实；结果滞后，等到月度统计出来，用户早就流失了。更麻烦的是它回答不了眼前的问题——今天的版本到底能不能发。
换成 SLO（服务等级目标）之后，衡量对象变成具体的业务环节，判定依据是事先约定的 SLI（服务等级指标），能否发版由错误预算的剩余额度决定。
三类 SLI 怎么挑
SLI 不是越多越好，每个业务环节挑两到三个即可。
| 类别 | 典型指标 | 口径要点 | 适用环节 |
|---|---|---|---|
| 延迟 | P95、P99 分位耗时 | 不用平均值；明确统计窗口与是否含重试 | 交易、查询、登录类接口 |
| 正确性 | 错误率 | 区分超时、限流与业务拒绝，只统计服务端原因造成的失败 | 对外接口、异步任务 |
| 饱和度 | 线程池使用率、连接池占用、队列堆积 | 取峰值而非均值，与容量上限对比 | 中间件依赖重的环节 |
SLO 怎么定才不会变成口号
三条约束值得写进文档：其一，按业务环节分别定，不给整个系统定一个值；其二，写明统计窗口，滚动 28 天比自然月更稳定，能避免月初重置带来的错觉；其三，目标要留余量，定得过于激进会导致预算长期为零，团队索性不再看它。
| 业务环节 | SLI | 目标值（示例） | 统计窗口 |
|---|---|---|---|
| 登录 | P95 耗时、错误率 | 800 毫秒以内、0.5% 以内 | 滚动 28 天 |
| 下单 | P99 耗时、错误率 | 2 秒以内、0.3% 以内 | 滚动 28 天 |
| 支付 | P99 耗时、错误率 | 1.5 秒以内、0.1% 以内 | 滚动 28 天 |
| 查询 | P95 耗时、错误率 | 1 秒以内、1% 以内 | 滚动 28 天 |
目标值建议先用一到两个月的实测数据反推，先设为参考值运行两周再正式生效，而不是直接照搬行业数字。
错误预算怎么算、怎么用
预算 =（1 − SLO）× 统计窗口内的请求总量。以支付环节为例，窗口内 1000 万次请求、目标 99.9%，允许的失败次数就是 1 万次。这个数字的好处是直观：每次故障消耗多少、还剩多少、按当前速度还能撑几天，都能算出来。
- 预算充足（剩余 50% 以上）：按正常节奏发版，不必额外审批。
- 消耗过半：变更需更严格的验证，灰度批次拉长，暂停非必要的功能发布。
- 预算耗尽：冻结功能发布，资源转向稳定性改进；确需发布的走例外审批，写明责任人与回滚方案。
还要约定由谁在什么时候看。建议固定到每周一次简短复盘，把剩余额度、消耗最快的环节、本周消耗原因三件事过一遍，不要等耗尽才讨论。
SLO 与动态基线的分工
两者常被混用。动态基线回答"和它自己的历史比，现在反不反常"，适合发现没有先例的异常；SLO 回答"有没有越过对用户承诺的线"，适合判定是否构成故障。基线发现异常但没破线时记入待办，不必告警；一旦破线，无论历史是否曾经更差，都按 SLO 的处置流程走。
落地三步与常见坑
- 选一个核心业务域，梳理它包含的环节与接口，挑出两到三个 SLI。
- 用一个月实测数据反推目标值，先设为参考值运行两周，再正式生效。
- 把预算看板接进发布流程，让"能不能发版"在系统里查得到，而不是靠会议决定。
三个坑值得提前规避：把 SLO 直接当考核指标，数据很快会失真；所有环节共用一套目标，等于没有重点；只定目标不接流程，最后变成一张没人看的报表。
奇摩技术团队在为金融与制造客户做可观测性建设时，通常把 SLO 与错误预算放在告警分级之后推进——先让告警能说清影响面，再让目标能约束发布节奏。若您的团队正在梳理稳定性目标，欢迎 预约咨询，我们可以结合现有接口清单与历史数据协助确定第一批 SLI。