SLI / SLO / 错误预算与事故响应与 Postmortem

0. 元信息

• 主题路径：docs/topics/observability-and-sre/subtopics/slo-and-incident-response/README.md
• 父主题：observability-and-sre
• 主分类：工程技术
• 辅助分类：项目与职业能力
• 适合对象：理解三支柱、能写后端服务、想做值班与事故响应的开发者
• 建议周期：1～2 周（每周 8～10 小时，含 1 次模拟事故）
• 前置知识：observability-and-sre 父主题；metrics-logs-traces；Prometheus / Grafana 基础
• 最终目标：能为一个服务定义 SLI / SLO 与错误预算、设计 burn rate 多窗口告警、在事故中担任 IC 写 Postmortem

1. 学习路线

SLI / SLO / SLA 三者区别
  → 选 SLI（可用性 / 延迟 / 吞吐）
  → 4 个 9 反推月度预算
  → burn rate 单窗口与多窗口
  → Prometheus 多窗口告警规则
  → 告警分级（Sev 1~4）+ 抑制 / 静音
  → on-call 轮值与疲劳治理
  → Incident Response（IC / Comms / Ops / Postmortem）
  → blameless Postmortem 与 action items

2. 阶段周数分配（34 周，每天 1.52 小时）

精简子主题按”SLO → 告警 → 响应 → 复盘”四段推进。

选 3 周方案时把第 4/5 阶段压成 1 周。每周留 0.5 天复盘。

3. 九阶段表

关键陷阱：SLO 设完不看板；Postmortem 写成追责；on-call 噪声淹没；告警不分级；burn rate 阈值随手设。

4. 第一周任务

5. 阶段通用验收

1. 不看答案独立写出 SLO 文档与告警规则；
2. 用自己的话解释 SLI / SLO / SLA；
3. 画一张图：SLI → SLO → 错误预算 → burn rate → 告警；
4. 测试正常路径、burn rate 超阈值、Sev 1 事故；
5. 至少准备 3 组自定义 SLI；
6. 记录 P99、错误率、SLO 命中率、预算剩余；
7. 能修改既有服务加 SLO、加告警、加 Postmortem。

6. 最终验收

• 独立画出 SLO → burn rate → 告警时序图；
• 完成至少 6 个实验；
• 主持 30 分钟 IC 会议；
• 写 1 份 blameless Postmortem。

7. 综合项目

为微服务 Demo 定义 3 个 SLO（API 可用性 99.9% / API P99 < 500ms / Worker 错误率 < 1%）、设计 burn rate 告警、模拟一次 Sev 1 事故、写 Postmortem。成果合入父主题首选综合项目。

本主题贡献

SLO 不是写完就完事，burn rate 多窗口告警 + IC 分工 + blameless Postmortem 才让错误预算真生效。本子主题专门补齐”4 个 9 怎么反推预算”、“多窗口 burn rate 阈值怎么选”、“IC / Comms / Ops 三角色怎么演练”三件 SRE 必答题，并把 Sev 分级 + Alertmanager 抑制做成可落地的告警降噪闭环。

3 职责

1. 用 SLI 公式（availability / latency / throughput）选 3 个核心 SLI，按 (1 - SLO) × 月分钟反推错误预算。
2. 用 burn rate 多窗口告警（1h + 6h + 24h + 3d）覆盖快/慢燃烧场景，配 Alertmanager 路由 + 抑制 + 静音。
3. 主导一次 Sev 1 IC（IC / Comms / Ops 分工），写 1 份 blameless Postmortem，action items 带 DRI + deadline。

4 交付物

1. 一份 SLO 文档（3 个 SLI + 目标 + 月度预算 + burn rate 阈值表），含 (1 - SLO) × 月分钟公式与 99.9% / 99.99% 预算对比。
2. 一份 Prometheus 多窗口告警规则（Google SRE Workbook 模板，1h×14.4 / 6h×6 / 24h×1 / 3d×1），含 histogram_quantile 算 P99 SLI。
3. 一份 Alertmanager 路由 + 抑制（page vs ticket 分流），含 Sev 1/2/3/4 值班表与 on-call fatigue 治理规则。
4. 一份 Postmortem（时间线 / 影响 / 5 Whys / action items with DRI），含 blameless 文化要点与 action items 跟踪闭环。

3 指标

1. SLO 命中率 ≥ 99.9%（30 天滚动窗口 burn rate < 1）。
2. burn rate 多窗口告警误报率 < 5%（页告警真阳性 / 总页告警）。
3. Postmortem action items 闭环率 ≥ 80%（deadline 内完成 / 总 action items）。

Google SRE Book、Google SRE Workbook、Rob Ewaschuk: Implementing SLOs、Prometheus Alerting Rules。复制前核对 LICENSE。

8. 推荐资料

Google SRE Book、Google SRE Workbook、Rob Ewaschuk: Implementing SLOs、Prometheus Alerting Rules。复制前核对 LICENSE。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

SRE（Site Reliability Engineering）2003 年由 Google 创立。SLO（Service Level Objective）是 SRE 的核心创新：用 SLI 量化服务、用 SLO 设目标、用 Error Budget 把业务决策与技术决策绑定。4 个 9（99.99%）对应的月度预算是 4.3 分钟，这迫使团队认真权衡可用性与发布速度。

事故响应（Incident Response）是 SRE 第二大实践：明确 IC（Incident Commander）角色、Comms（通信）、Ops（操作）分工，避免多人抢麦克风。Postmortem（事后分析）blameless 文化来自 NASA 与医疗事故复盘，目的是追责系统而非个人。

今天 SLO 与 IR 已是分布式系统团队的事实标准。

9.2 概念地图

flowchart LR
  SLI[SLI: 延迟 / 错误率 / 吞吐] --> SLO[SLO: 99.9%]
  SLO --> Budget[Error Budget = (1 - SLO) × 月分钟]
  Budget --> Burn[burn rate = 当前 / 预算]
  Burn --> Alert[Burn Rate 多窗口告警]
  Alert --> IC[IC 启动]
  IC --> Comms[状态页 / Slack #incident]
  IC --> Ops[Ops 修复]
  Ops --> Resolve[解决]
  Resolve --> PM[Postmortem]
  PM --> ActionItems[Action Items with DRI]
  ActionItems -.防止复发.-> SLI

9.3 基础知识讲解

9.3.1 论文 / 规范

9.3.2 书

9.3.3 博客 / 文档

9.3.4 人物

9.3.5 方法

• SLI-first：先选 SLI 再设 SLO；
• Multi-window burn rate：1h + 6h + 24h + 3d；
• Blameless Postmortem：追系统不追人；
• Action items with DRI：每条有负责人 + deadline；
• Sev-based routing：Sev 1 走 PagerDuty，Sev 2/3 走 Slack。

9.3.6 重点训练材料

• SRE Book 第 14 + 811 章
• SRE Workbook 第 4~5 章
• Rob Ewaschuk Implementing SLOs
• Prometheus 多窗口告警模板

9.4 经典问题与经典案例

9.5 学习难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

SLO 是量化锚点；Alertmanager 是路由与抑制；Postmortem 是反馈环。

9.6.3 Structure

Prometheus 告警规则：expr + for + labels + annotations。Alertmanager 配置：route / inhibit_rules / silence。Postmortem 模板：时间线 + 影响 + 根因 + action items。

9.6.4 Ecosystem

告警：Alertmanager / PagerDuty / OpsGenie / Grafana Alerting。事故管理：incident.io / FireHydrant。Postmortem：Confluence / Notion。

9.6.5 Depth Tiers

本子主题目标：L3。

9.6.6 Source

• Google SRE Book
• Google SRE Workbook
• Prometheus Alerting
• 引用版本快照日期：2026-07-30。

10. 常见误区

• SLO 设完不看板；
• Postmortem 写成追责报告；
• on-call 噪声淹没；
• 告警不分级；
• burn rate 阈值随手设；
• IC 没人主导，会议拉跨；
• 错误预算耗尽也不停 feature；
• blameless 文化缺失；
• action items 没 DRI；
• 不复盘。

11. 所有知识点分类（统一规则）

1. 编程语言；2. 数据结构与算法；3. 计算机基础；4. 工程技术；5. Web 与后端；6. 前端与客户端；7. 数据与人工智能；8. 项目与职业能力；9. 安全与可靠性。

本计划归属：工程技术 主 + 项目与职业能力 / 安全与可靠性 辅。

代码块 1：Prometheus 多窗口 burn rate 告警

# alerts/slo_burnrate.yaml
groups:
- name: slo.burnrate
  rules:
  - alert: SLO_BurnRate_High
    expr: |
      (
        sum(rate(http_requests_total{job="api",status=~"5..",code!~"5xx-noisy"}[1h]))
        /
        sum(rate(http_requests_total{job="api"}[1h]))
      ) > (14.4 * 0.001)
      and
      (
        sum(rate(http_requests_total{job="api",status=~"5..",code!~"5xx-noisy"}[6h]))
        /
        sum(rate(http_requests_total{job="api"}[6h]))
      ) > (14.4 * 0.001)
    for: 2m
    labels: { severity: page, slo: api-availability }
    annotations:
      summary: "API SLO burn rate 14.4x over 1h+6h"
      runbook: "https://wiki/runbooks/slo-api-availability"

  - alert: SLO_BurnRate_Medium
    expr: |
      (
        sum(rate(http_requests_total{job="api",status=~"5.."}[24h]))
        /
        sum(rate(http_requests_total{job="api"}[24h]))
      ) > 1
    for: 5m
    labels: { severity: ticket, slo: api-availability }

代码块 2：Alertmanager 路由 + 抑制

# alertmanager.yml
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [{ severity = "page" }]
      receiver: 'pagerduty'
      group_wait: 10s
    - matchers: [{ severity = "ticket" }]
      receiver: 'slack-tickets'

inhibit_rules:
  - source_matchers: [severity="page"]
    target_matchers: [severity="ticket"]
    equal: ['alertname', 'cluster']

receivers:
  - name: 'default'
    slack_configs: [{ api_url: 'https://hooks.slack.com/...', channel: '#alerts' }]
  - name: 'pagerduty'
    pagerduty_configs: [{ service_key: '...' }]
  - name: 'slack-tickets'
    slack_configs: [{ channel: '#tickets' }]

代码块 3：Postmortem 模板

# Postmortem: <incident title>
Date: 2026-07-31
Authors: <IC>, <Comms Lead>
Status: Draft / Reviewed / Final

## Summary
一两句描述事故。

## Impact
- 用户影响：N 个用户 / M 分钟
- SLO 影响：消耗 X% 错误预算
- 业务影响：订单/营收

## Timeline (UTC)
- T+0 检测
- T+2m IC 上线
- T+5m 缓解（回滚）
- T+12m 解决
- T+30m 状态页恢复

## Root Cause
5 Whys + 故障树。

## What Went Well
- IC 决策快
- Runbook 完整

## What Went Wrong
- 检测延迟 2m
- 回滚脚本过期

## Action Items
| ID | Action | DRI | Deadline | Status |
|---|---|---|---|---|
| A1 | 升级告警检测 | @alice | 2026-08-15 | open |
| A2 | 回滚脚本重写 | @bob | 2026-08-30 | open |

代码块 4：SLO 文档示例

# slo/api-availability.yaml
service: api
description: API HTTP 5xx 错误率低于 0.1%
slis:
  - name: availability
    spec:
      type: http_5xx_ratio
      threshold: 0.001
slo:
  target: 0.999
  window: 30d
  error_budget:
    total_minutes: 43.2  # (1 - 0.999) × 30 × 24 × 60
    burn_rate_alerts:
      - window: 1h
        threshold: 14.4  # 2% 预算 / 5 分钟
      - window: 6h
        threshold: 6