深色模式
SLO 与容量关联
摘要：很多“SLO 不达标”的根因不是代码 bug，而是容量不够——流量一涨就超时、队列堆积、错误率飙升。本文讲如何把容量指标和 SLO 关联，提前扩容避免预算被吃光。
适用环境
- 已定义 SLO 并能观测饱和度（CPU、连接数、队列长度）
- 服务可水平扩容
操作步骤
1. 找“容量型”超标信号
promql
# 饱和度接近上限
avg(cpu) by(instance) > 80
# 队列堆积
kafka_consumer_lag > 100000
# 超时率随 QPS 同步上升（典型容量不足特征）1
2
3
4
5
2
3
4
5
2. 建容量预警先于 SLO 告警
yaml
groups:
- name: capacity
rules:
- alert: HighSaturation
expr: avg(cpu) by(instance) > 75
for: 10m
labels: { severity: warning }
annotations:
summary: "CPU 超 75%，可能拖垮 SLO"1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
3. 把容量纳入预算归因
text
月度复盘时标注：本次预算耗尽主因=容量不足（占 60%）
→ 推动扩容/限流，而非只修代码1
2
2
4. 设容量红线
text
单实例 CPU < 70%、消费延迟 < 阈值、错误预算剩余 > 20% 时允许接新流量1
DANGER
容量不足时只靠“修 bug”救 SLO 是治标；根因是容量规划缺失，必须扩容或限流，否则下次流量高峰再来。
验证
bash
# 压测抬升 QPS，观察饱和度与 SLI 是否同步劣化，确认容量是瓶颈1
常见坑
WARNING
- 只盯 SLO 不盯容量，等超标才发现已来不及扩容，需要提前的容量预警。
- 扩容后没重新评估 SLO，目标仍基于旧容量，照样会被吃光。