SLO/SLI 指标模板
站点上线后，最大的管理难题往往是"说不清到底好不好"：偶尔慢一下是偶然还是趋势？稳定性目标到底定多少合适？SLO 和 SLI 就是把这套模糊感觉变成可衡量指标的工具。SLO（Service Level Objective）是你对外承诺的服务目标，SLI（Service Level Indicator）是实际测量出来的指标值，二者一对比，稳定性一目了然。比如页面变慢不是靠"感觉变慢了"汇报，而是直接拿出"P95 从 700ms 涨到 950ms、超过目标 800ms"这样的数据。
SLO 体系最反直觉的一点是：它鼓励你"主动留出失败空间"，而不是追求 100% 稳定。原因很实际——100% 的目标意味着零容忍，团队会被无穷无尽的告警淹没，为了守住一个不现实的数字疲于奔命，反而没精力做真正重要的优化。SLO 的价值在于让你明确"我们可以接受多差"，然后在这个范围内合理地平衡发版速度和稳定性。
核心指标建议
| 指标 | 建议 SLO | 说明 |
|---|---|---|
| 可用性 | 99.9% | 每月允许宕机约 43 分钟 |
| 页面首字节时间 | P95 < 800ms | 95% 的请求在 800ms 内返回 |
| 关键 API 成功率 | > 99.5% | 核心接口错误率控制在 0.5% 以内 |
| 告警到响应时间 | < 10 分钟 | 故障后多久有人接手 |
这里的数字不是拍脑袋：99.9% 的可用性对应每年约 8.8 小时、每月约 43 分钟的不可用时间。定目标之前，先想想"用户能接受的底线是多少"，而不是"技术能做到多少"。选择指标本身也有讲究：SLI 要选"用户真正能感知到"的东西。对网站来说，可用性和首字节时间（TTFB）比服务器 CPU 使用率更有意义，因为用户感受不到 CPU，只感受得到"打开快不快"。指标不要贪多，一次维护 3-5 个核心 SLI 就足够，太多反而没人认真看。
误差预算怎么用
SLO 和实际 SLI 之间的差额就是误差预算。比如某月可用性目标是 99.9%，实际跑到了 99.99%，多出来的 0.09% 就是预算。预算花完之前可以放心发布新功能，花完了就该收敛变更、优先修复稳定性。这套机制让"要不要发版"从感觉之争变成数字之争。
举一个真实的工作场景。某团队月可用性 SLO 是 99.9%（预算 43 分钟），月中一次数据库迁移引发 25 分钟故障，预算用掉大半。此时团队的做法应该是：冻结非紧急的功能发布，优先排查迁移的残留问题，剩下的 18 分钟预算留着给日常的意外。等到月底如果预算还有富余，再恢复常规发布节奏。这套"按预算决定是否发版"的机制，比任何"这周先别发"的拍脑袋决策都更让人信服。
周报模板
| 指标 | 本周实测 | 目标 | 偏差 | 原因与改进动作 |
|---|---|---|---|---|
| 可用性 | 99.95% | 99.9% | +0.05% | 无 |
| TTFB P95 | 720ms | 800ms | +80ms | 缓存命中率提升 5% |
| API 成功率 | 99.2% | 99.5% | -0.3% | 第三方支付回调超时，已加超时重试 |
每周固定输出这样一张表，偏差原因要落到具体动作上，而不是只写"波动"两个字。持续几周后，就能看出稳定性是在变好还是变坏。
落地建议
SLO 不是写进文档就完事。建议把 SLI 采集接到监控系统，用 Prometheus 这类工具持续记录，相关规则设计可以参考Prometheus 告警规则设计；没有完整监控体系的团队，可以先从合成监控起步，参考合成监控实践。误差预算的具体用法可以看SLO 误差预算实践。
一个实用的进阶做法是用"燃烧速率"告警：不等到月度预算耗尽才提醒，而是当误差预算消耗速度异常时立即告警。比如设定 1 小时内预算消耗超过 2%（即按这个速度本月预算会提前烧完），就触发紧急告警。这样可以把"月末才发现问题"提前到"问题发生的第一小时"。配置示例如下：
# 5 分钟窗口内错误率高于 10%，且持续 10 分钟
sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
> 0.10
这条 PromQL 统计 API 的 5xx 错误率，超过 10% 就告警。数字可以按你的 SLO 换算：误差预算 0.1%（99.9% 目标）时，1 小时烧掉 2% 预算对应的错误率阈值大约是 0.002%，具体公式可以参考上面的误差预算文档。
常见问题
- 目标定 99.99% 是不是更好？ 目标越高压力和成本越高，如果用户和业务能接受 99.9%，没必要硬卷。
- SLI 怎么统计才准？ 采集口径要固定：以负载均衡器还是应用日志为准，选一种并保持一致。
- 没有监控系统能不能做 SLO？ 可以，先用手动巡检和合成监控积累数据，跑一两个月再定目标，比拍脑袋定一个数字靠谱。
- 误差预算耗尽后怎么办？ 冻结非紧急变更、优先排查已知问题，必要时给用户发透明度公告，而不是偷偷把 SLO 改低。
参考
参考：Google SRE 手册（SLO 章节）https://sre.google/sre-book/service-level-objectives/
参考：Google Cloud SLO 文档 https://cloud.google.com/stackdriver/docs/solutions/slo
参考：Google SRE 误差预算相关 https://sre.google/sre-book/implementing-slos/