深色模式
SLO 与成本权衡
摘要：SLO 不是越高越好。为了 99.99% 你可能要多活、要冗余、要常备容量，成本翻几倍。Google SRE 的核心思想：在“用户能感知”的边界上设 SLO，超出部分就是浪费。
适用环境
- 已运行服务并产生云/硬件成本
- 能拿到 SLO 达标率与对应资源开销
操作步骤
1. 算“达标成本曲线”
text
可用性 99% → 单活，成本低
可用性 99.9% → 双活冗余，成本 ×2
可用性 99.99%→ 多活+常备容量，成本 ×5+
问：用户真的感知到 99.99% 和 99.9% 的差别吗？1
2
3
4
2
3
4
2. 识别过度达标
promql
# 长期预算剩余远高于目标：说明 SLO 定松了？还是资源配多了？
slo_error_budget_remaining > 0.5 # 半年都只用了不到一半预算1
2
2
3. 做减法
text
- 内部工具 SLO 从 99.9% 降到 99.0%，撤掉一套冗余
- 非高峰时段降低常备容量
- 把省下的预算投入到真正用户感知的链路1
2
3
2
3
4. 用预算政策平衡
预算长期用不掉 → 适当收紧目标或降成本；频繁耗尽 → 加容量（见前文）。
DANGER
“为达标而达标”会无脑堆冗余。降本前确认该 SLO 真的影响用户，否则省的是无谓开销还是关键保障要分清。
验证
bash
# 调整后观察成本与达标率，确认用户侧无感知下降1
常见坑
WARNING
- 一刀切降本把关键链路也砍了，事故时才发现预算早被省没；分级对待。
- 成本视角只看账单不看风险，一次事故损失可能远超省下的冗余费。