深色模式
用户旅程 SLI
摘要：系统级“平均可用”常常掩盖了“下单这条线早就挂了”。用户旅程 SLI 把指标按关键路径拆解，哪一步差就在哪一步设 SLO，精准对齐用户体感。
适用环境
- 已画出核心用户旅程（如 电商：浏览→加购→下单→支付）
- 各步骤有可采集的成功/失败信号
操作步骤
1. 列出关键路径与失败判据
| 步骤 | 成功定义 | 失败定义 |
|---|---|---|
| 登录 | 返回 token | 401/超时 |
| 加购 | 购物车+1 | 接口报错 |
| 下单 | 生成订单号 | 下单失败 |
| 支付 | 支付成功 | 支付异常 |
2. 为每步定义 SLI
promql
# 下单成功率
sum(rate(order_created_total{result="success"}[5m]))
/ sum(rate(order_created_total[5m]))
# 支付成功率
sum(rate(pay_total{result="success"}[5m]))
/ sum(rate(pay_total[5m]))1
2
3
4
5
6
2
3
4
5
6
3. 给关键步骤单独 SLO
yaml
# 不要把整条链路混成一个 SLI
# 支付比浏览更重要，SLO 应更高
slo:
browse: 99.0
order: 99.5
pay: 99.91
2
3
4
5
6
2
3
4
5
6
4. 旅程整体可用性
promql
# 端到端成功 = 各步成功率之积（近似）
browse * order * pay1
2
2
DANGER
别用“全链路平均”掩盖短板：浏览 99.99% 但支付 95%，平均看着还行，用户实际在下单环节大量失败。
验证
bash
# 各步骤 SLI 表达式逐一在 Prometheus 跑通
# 注入支付失败，确认支付 SLI 下降并触发告警1
2
2
常见坑
WARNING
- 步骤拆太细（几十步）反而没人维护，聚焦 3-5 个真正关键步骤。
- 成功率要用业务结果字段，不能只看 HTTP 200。