深色模式
如何选 SLI
摘要：SLI（Service Level Indicator）是衡量服务质量的“尺子”。选错尺子，SLO 再漂亮也没用。本文给出四类常用 SLI 与挑选原则：选用户能感知的、可量化的、能自动采集的。
适用环境
- 已明确要保障的核心服务
- 有指标采集能力（Prometheus / 访问日志 / APM）
操作步骤
1. 从用户视角列四类候选
| 类别 | 示例 SLI | 定义 |
|---|---|---|
| 可用性 | 成功请求占比 | 非 5xx 且及时响应 / 总请求 |
| 延迟 | P99 延迟 | 99% 请求 < 300ms |
| 质量 | 正确率 | 返回正确结果 / 总请求 |
| 饱和度 | 队列堆积 | 积压任务 < 阈值 |
2. 用“用户会因此投诉吗”过滤
text
候选 SLI → 如果它变差，用户会察觉/投诉吗？
会 → 保留
不会 → 降级为内部监控，不进 SLO1
2
3
2
3
3. 落地为可算指标
promql
# 可用性 SLI 示例
sum(rate(http_requests_total{code!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# 延迟 SLI 示例
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))1
2
3
4
5
2
3
4
5
4. 一个服务 2-4 个 SLI 足够
别贪多，每个 SLI 都要配 SLO 和告警，过多反而没人看。
DANGER
不要把“CPU 使用率”当 SLI——用户不关心 CPU，只在它导致变慢/报错时才感知。那是饱和度指标，不是 SLI。
验证
bash
# 在 Prometheus 里先跑通 SLI 表达式，确认有数据、数值合理
# 再考虑据此设 SLO1
2
2
常见坑
WARNING
- SLI 定义里的“成功”要和业务一致：返回 200 但业务说“下单失败”不算成功，需按业务码判断。
- P99 比平均值更能反映长尾用户体验，SLO 尽量用分位数。