可观测性与 SRE：从 SLI/SLO 到事故响应与混沌工程

0. 元信息

• 主题路径：docs/topics/observability-and-sre/README.md
• 主分类：工程技术
• 辅助分类：安全与可靠性
• 适合对象：写过 Docker / Linux 命令行、想把服务从「能跑」升级到「可观测、可恢复」的开发者与运维
• 建议周期：6～10 周（每周 8～12 小时，至少一半时间用于真机/集群实验与故障演练）
• 前置知识：linux-dev-env、docker-basics、network；熟悉 Linux 命令、Docker / Compose、基本后端知识
• 最终目标：能为一个中等规模的微服务系统定义 SLI / SLO、部署 Prometheus / Grafana / Loki / Tempo / OpenTelemetry、设计告警分级、用 Chaos Mesh / Litmus 做故障演练，并在事故发生时主导 Incident Response 写 Postmortem

1. 学习路线

Metrics / Logs / Traces 三支柱 + OpenTelemetry 采集
  → SLI / SLO / 错误预算 / 告警分级
  → Prometheus / Grafana / Loki / Tempo / Alertmanager 实战
  → 混沌工程 / 容量规划 / Runbook / SOP / 事故响应与 Postmortem

按「先观测 → 再 SLI/SLO → 再告警 → 最后混沌与事故」的顺序学。每个子主题对应一段能力，最后用综合项目把可观测、SLO、混沌、Postmortem 串起来。

2. 阶段周数分配

6 周方案只跑通最小闭环；10 周方案多出时间做混沌演练与容量压测。综合项目占最后一周。

3. 九阶段表

关键陷阱：把 Metrics 当 Logs；告警只看阈值不分类；Postmortem 写成追责报告；混沌只在测试环境做一次；SLO 设完不看板。

4. 第一周任务

Day 1 约定：本计划以 Linux + Docker + 一台 8G 内存的机器为最小实验环境。所有实验记录版本、容器镜像 tag、抓取时间与数据集。

Day 7 步骤 A 只求链路完整：服务 → SDK → Collector → Prometheus / Loki / Tempo → Grafana。步骤 B 每次只改变一个条件（关掉服务 / kill Collector / 清空 Loki / 关闭 SDK）。

5. 阶段通用验收

1. 不看答案独立重写一个三支柱 Collector 配置；
2. 用自己的话解释 SLI / SLO / Error Budget 各自解决什么问题；
3. 画一张图：服务 → SDK → Collector → 后端 → Grafana；
4. 测试正常路径、Collector 重启、抓取失败、日志丢、traceid 断链四类边界；
5. 至少准备 3 组自定义指标 / 日志 / Trace 数据；
6. 记录 P50 / P95 / P99、错误率、饱和度、SLI 命中率 4 个核心指标；
7. 能修改既有服务加 OTel、加告警、加 Runbook，并验证。

6. 最终验收

• 独立画出 Metrics / Logs / Traces 三支柱与 OpenTelemetry 采集架构图；
• 完成至少 30 个实验：三支柱 8 个、Prometheus 8 个、SLO 6 个、混沌与事故 8 个；
• 完成 1 个综合项目：微服务 Demo + SLI/SLO + Grafana 看板 + Alertmanager 告警 + 一次混沌演练 + Postmortem；
• 能用 15 分钟讲清「为什么 SLO 不止 4 个 9、为什么告警分级比阈值重要、为什么混沌要在预发做」。

7. 综合项目

首选：用 docker-compose / kind 起一个 3 服务微服务（API / Worker / DB）+ Prometheus + Grafana + Loki + Tempo + OTel Collector + Alertmanager，定义 3 个 SLO、配置 5 条分级告警、跑一次混沌演练（kill 一个服务 / 注入 30% 延迟 / 把 DB 切到只读）、写 1 份 Postmortem。

• 必输出：（1）Compose / Helm 部署清单；（2）OTel Collector 配置；（3）Grafana 看板 JSON（RED + USE + SLO）；（4）Prometheus 告警规则；（5）Runbook（Sev 1~4 各一份）；（6）一次故障演练录像；（7）Postmortem（含时间线、影响、根因、action items）；
• 关键指标：可用性 99.9%、P99 延迟 < 500ms、错误预算月度未耗尽；
• 进阶可选：接入 PagerDuty / OpsGenie、用 OTel Kubernetes Operator 注入 sidecar、用 LitmusChaos 做集群级演练。

备选：用 Kubernetes（kind）做同一份需求。
备选：把一个生产事故日志（脱敏后）按本计划走一遍 IR + Postmortem。
备选：用 eBPF + Prometheus 做基础设施可观测。

任何综合项目都必须包含：

1. 需求与 SLO（可用性 / 延迟 / 错误率）；
2. 三支柱 + OTel 采集架构图；
3. SLI 公式与 SLO 文档；
4. Grafana 看板 JSON（RED + USE + SLO 预算）；
5. Prometheus 告警规则（含 burn rate 多窗口）；
6. Runbook 与 SOP（Sev 1~4）；
7. 一次故障演练录像与记录；
8. Postmortem（时间线、影响、根因、action items）；
9. 复盘 notes/retrospective.md。

8. 推荐开源资料

默认使用顺序：先读 SRE Book 第 1~4 章建立 SLO 思维 → 装 Prometheus / Grafana / Loki / Tempo 起一个最小栈 → 接入 OTel SDK 与 Collector → 定义 SLO 与告警 → 写 Runbook → 做混沌演练 → 模拟事故 → 写 Postmortem → 复盘到 notes/retrospective.md。

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

本节由本计划生成。链接指向原始材料或作者公开内容。规范与版本会演进，实验记录必须写明版本与日期。

9.1 背景与动机

可观测性（Observability）这个词来自控制论。系统越复杂、内部越不可见，越需要从外部输出反推内部状态。分布式系统从单机能解决到多机协作，监控从「ping + uptime」升级到「Metrics + Logs + Traces」三支柱。

2003 年 Google 成立 SRE 团队，把运维工程化：Service Level Objective（SLO）、Error Budget、Toil、Incident Response、Postmortem 成为行业模板。2014 年 Prometheus 借鉴 Borgmon 思路发布，把 pull-based 时序数据库、PromQL、多维标签写成事实标准。2017 年 OpenTelemetry 把 Metrics / Logs / Traces 三件套合并到同一 SDK 与协议。2019 年 Grafana Labs 推出 Loki（日志）与 Tempo（Trace），与 Prometheus 组成 Grafana Stack。

今天一个中等规模系统每天产生 TB 级日志、百万级指标 span、千亿级 Trace。可观测不是「装上 Prometheus」，而是「用 SLI/SLO 量化服务、用三支柱快速定位、用混沌主动验证、用 Postmortem 持续改进」的工程闭环。

9.2 概念地图

flowchart LR
  Service[微服务] --> SDK[OTel SDK / Prometheus client]
  SDK --> Collector[OTel Collector]
  SDK --> Prom[Prometheus scrape]
  Prom --> PromDB[(Prometheus TSDB)]
  Collector --> Loki[(Loki)]
  Collector --> Tempo[(Tempo)]
  PromDB --> Grafana
  Loki --> Grafana
  Tempo --> Grafana
  Grafana --> Alert[Alertmanager]
  Alert --> PagerDuty[PagerDuty / OpsGenie]
  SLO[SLI/SLO] --> Prom
  SLO --> Burn[Burn Rate 告警]
  Burn --> Alert
  Chaos[Chaos Mesh / Litmus] -.故障注入.-> Service
  IR[Incident Response] --> IC[IC / Comms / Ops]
  IC --> PM[Postmortem]
  PM -.action items.-> Service

核心关系：服务通过 SDK 与 exporter 把数据送到 Collector / Prometheus；Grafana 把数据可视化并触发告警；SLO 是告警阈值与预算来源；混沌验证 SLO 是否真实可达；事故与 Postmortem 形成反馈环。

9.3 基础知识讲解

9.3.1 经典论文 / 规范

9.3.2 经典书籍

9.3.3 优秀博客

9.3.4 核心人物

9.3.5 开发方法

9.3.6 重点训练材料

• SRE Book 第 1~4 章：SLO / Error Budget / Toil / Eliminating Toil。
• SRE Workbook 第 4 章：Incident Response。
• SRE Workbook 第 5 章：Postmortem 文化。
• Prometheus 官方文档：PromQL、Recording Rule、Alert Rule。
• OpenTelemetry 官方文档：SDK / Collector / OTLP / 语义约定。
• Observability Engineering 第 4~6 章：high cardinality / wide events / unknown unknowns。
• Chaos Engineering（O’Reilly）：稳态假设 + 爆炸半径 + 持续演练。

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• Metrics / Logs / Traces 三件套：可观测的「三大支柱」，分别回答「多少 / 为什么 / 哪里」。
• OpenTelemetry：跨语言 SDK + 协议 + Collector + 语义约定。
• Prometheus / Grafana / Loki / Tempo / Mimir：开源可观测后端。
• SLI / SLO / Error Budget：可观测的「量化锚点」。
• Chaos Mesh / LitmusChaos：故障注入工具。
• Incident Response / Postmortem：事故管理流程。

9.6.3 Structure

• OTel SDK 接口：MeterProvider、TracerProvider、LoggerProvider、exporter、自动注入与手动埋点。
• PromQL：聚合函数（rate / histogram_quantile / sum by）、Recording Rule、Alert Rule。
• Alertmanager：route / inhibit / silence / grouping。
• Grafana：数据源（Prometheus / Loki / Tempo）+ 仪表盘（panels + variables）。
• W3C Trace Context：traceparent / tracestate 头。
• OpenMetrics：Prometheus 暴露格式。

9.6.4 Ecosystem

• 监控：Prometheus、Grafana、Datadog、New Relic、Thanos、Cortex、Mimir。
• 日志：Loki、ELK、Fluent Bit、Grafana Loki、Vector。
• Trace：Tempo、Jaeger、Zipkin、Datadog APM、New Relic。
• 告警：Alertmanager、PagerDuty、OpsGenie、Grafana Alerting。
• 混沌：Chaos Mesh、LitmusChaos、Gremlin、ChaosBlade、AWS Fault Injection Service。
• 排障：eBPF + Pixie + kubectl-debug + Polar Signals。

9.6.5 Depth Tiers

本计划目标：L3。综合项目可触及局部 L4，但不作为 6~10 周的硬门槛。

9.6.6 Source

• Google SRE Book
• Google SRE Workbook
• OpenTelemetry Documentation
• Prometheus Documentation
• Grafana Documentation
• Chaos Mesh Documentation
• Brendan Gregg 主页
• Charity Majors 主页
• 引用版本快照日期：2026-07-30。规范与版本会演进，使用前再核对当前版本。

10. 常见误区

• 把 Metrics 当 Logs，丢高基数信息；
• 告警阈值随手设，不分 Sev 等级；
• SLO 设完不看板，到事故才发现预算耗尽；
• Postmortem 写成追责报告，没有 action items；
• 混沌只在测试环境做一次，没有稳态假设；
• OTel Collector 不调优，batch 太大内存爆；
• Prometheus 高基数 label（user_id）撑爆 TSDB；
• Trace 全采样成本高，不做 tail sampling；
• on-call 告警噪声淹没值班；
• 用平均值掩盖 P99；
• IR 没人主导 IC，会议拉跨服务；
• 容量规划靠经验，不算 USL；
• 错误预算耗尽也不停 feature；
• Alertmanager 路由混乱，告警雪崩；
• 监控只看 CPU / 内存，不看饱和度与错误率。

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

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

本计划归属：工程技术 主 + 安全与可靠性 辅。