开展月度 SLO 评审

概述

SLO 定义用户应获得的可靠性以及允许承担的风险，其价值在于支撑决策：预算健康时加快发布，预算耗尽时优先处理可靠性工作。没有定期评审，这个数字只是装饰。

步骤

1. 用记录规则固定错误率定义，保证仪表盘、告警和评审使用同一口径：

- record: job:request_error_ratio:5m
  expr: |
    sum(rate(http_requests_total{job="payments-api",code=~"5.."}[5m]))
    /
    sum(rate(http_requests_total{job="payments-api"}[5m]))

2. 查询 30 天可用性并换算剩余错误预算：

1 - (
  sum(increase(http_requests_total{job="payments-api",code=~"5.."}[30d]))
  /
  sum(increase(http_requests_total{job="payments-api"}[30d]))
)

3. 准备简短议程：预算消耗、主要错误来源、继续发布还是暂停修复的决策。
4. 将决策、负责人和跟进日期写入评审日志并提交。

验证

预期评审记录中包含 30 天可用性、已消耗预算比例和明确的后续动作。若数字明显好于用户反馈，应检查是否遗漏了某些入口路径或错误分类；抽查一个错误高峰，确认能对应到发布或依赖故障。

注意事项

• 可用性 SLO 不覆盖延迟与正确性，需要配合延迟目标。
• 30 天窗口对突发回归反应慢，应同时配置燃烧率告警。
• 低流量时比例波动大，应设置请求量下限或使用更长窗口。
• 目标应每季度复核，长期轻松达标说明过松，长期无法达标说明不现实。