混沌工程、容量规划、Runbook 与 SOP

0. 元信息

• 主题路径：docs/topics/observability-and-sre/subtopics/chaos-and-capacity/README.md
• 父主题：observability-and-sre
• 主分类：工程技术
• 辅助分类：项目与职业能力、安全与可靠性
• 适合对象：能搭可观测栈、想主动验证系统韧性并做容量规划的工程师
• 建议周期：1～2 周（每周 8～10 小时，含 1 次预发故障演练）
• 前置知识：observability-and-sre 父主题；slo-and-incident-response、prometheus-grafana-otel-stack；Kubernetes 基础
• 最终目标：能在预发环境用 Chaos Mesh / Litmus 注入故障、用 USL 做容量规划、写 Sev 1~4 Runbook 与 SOP、主导一次端到端故障演练

1. 学习路线

混沌工程原理（steady-state hypothesis、爆炸半径、blast radius）
  → Chaos Mesh / LitmusChaos 工具链
  → 故障类型（kill / delay / loss / DNS / CPU / memory）
  → 实验设计（单变量、短时长、低风险）
  → Runbook 与 SOP（结构化文档、决策树）
  → 容量规划（Little's Law、USL、DAU / 读写比 / 峰值倍数）
  → 综合演练（预发故障 + Postmortem + 复盘）

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

精简子主题按”故障注入 → Runbook → 容量规划 → 综合演练”四段推进。

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

3. 九阶段表

关键陷阱：生产直接注入故障；爆炸半径过大；不做稳态假设；混沌演练没结论；容量规划靠经验。

4. 第一周任务

5. 阶段通用验收

1. 不看答案独立写一份混沌实验与一份 Runbook；
2. 用自己的话解释 steady-state hypothesis 与 blast radius；
3. 画一张图：故障注入 → 稳态监控 → 爆炸半径控制；
4. 测试正常路径、单变量故障、多变量故障、爆炸半径超限；
5. 至少准备 3 组自定义实验；
6. 记录稳态偏差、爆炸半径、恢复时间；
7. 能修改既有实验加故障类型、加爆炸半径控制。

6. 最终验收

• 独立画出故障演练闭环图；
• 完成至少 6 个混沌实验；
• 写 4 份 Runbook 与 1 份 SOP；
• 用 USL 做容量规划。

7. 综合项目

为微服务 Demo 设计 5 类故障演练（kill pod / 注入 30% 延迟 / DNS 失败 / CPU 100% / DB 只读），写 Runbook 与 SOP，做一次综合演练。成果合入父主题首选综合项目。

本主题贡献

混沌工程的价值在于把 blast radius 与 steady-state 假设变成可重复实验，并用 USL 把容量预算讲清楚。本子主题专门补齐”steady-state 怎么定义”、“Chaos Mesh CRD 怎么写”、“USL 拐点怎么拟合”、“Runbook 与 SOP 怎么落地”四件混沌与容量必答题，并把 Chaos Mesh / LitmusChaos 工具链 + Little’s Law 容量模型串成可落地闭环。

3 职责

1. 用 Chaos Mesh / LitmusChaos 在预发环境注入 kill / delay / DNS / CPU / memory 五类故障，控制 namespace + duration + target 三个 blast radius 维度。
2. 用 Little’s Law（L = λW）与 USL（C(N) = N / (1 + α(N-1) + βN(N-1))）做容量规划，按 SLO 反推节点数与峰值倍数。
3. 写 Sev 1~4 Runbook + 1 份 SOP（结构化决策树），主导一次端到端故障演练 + Postmortem + 复盘。

4 交付物

1. 一份 Chaos Mesh 实验清单（NetworkChaos / PodChaos / DNSChaos / StressChaos），含 blast radius 控制与定时调度，含 steady-state hypothesis 模板。
2. 一份 USL 容量规划脚本（scipy curve_fit 拟合 α/β），按目标 QPS 反推最优节点数，含 R² 拟合度评估与拐点识别。
3. 一份 Sev 1/2/3/4 Runbook（现象 + 缓解 + 升级路径），含值班表与告警分级，覆盖 P0 响应时间 < 5 分钟的硬指标。
4. 一份 SOP（DB 切换只读 / 流量切换 / 回滚），含检查点 + 责任人 + 回滚条件，并把演练结论进 backlog。

3 指标

1. 混沌演练稳态偏差识别率 100%（steady-state 指标定义覆盖所有注入故障）。
2. USL 拟合 R² ≥ 0.9（实测 QPS 与模型预测一致度）。
3. Runbook 命中 MTTR < 5 min（演练中从告警到缓解的耗时）。

Chaos Engineering（O’Reilly）、Chaos Mesh Documentation、LitmusChaos Documentation、USL 论文（Neil Gunther）、Brendan Gregg: Systems Performance。复制前核对 LICENSE。

8. 推荐资料

Chaos Engineering（O’Reilly）、Chaos Mesh Documentation、LitmusChaos Documentation、USL 论文（Neil Gunther）、Brendan Gregg: Systems Performance。复制前核对 LICENSE。

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

9.1 背景与动机

混沌工程（Chaos Engineering）2010 年由 Netflix 创立，通过 Chaos Monkey 在生产环境随机终止 EC2 实例验证系统韧性。2012 年 Netflix 把 Chaos Monkey 开源，后续推出 Chaos Kong、Chaos Automation Platform、ChAP。2016 年 O’Reilly 出版 Chaos Engineering 一书，把稳态假设、爆炸半径、持续验证等概念体系化。今天 Chaos Mesh（CNCF）与 LitmusChaos（CNCF）成为云原生事实标准。

容量规划（Capacity Planning）历史更久。1980 年代起 queueing theory 与 Little’s Law 给出系统容量与延迟的定量关系；2000 年代 Neil Gunther 提出 USL（Universal Scalability Law），解释为什么 8 节点不是 4 节点性能的 2 倍。今天容量规划必须结合 SLO 与实测压测。

9.2 概念地图

flowchart LR
  Hypo[Steady-State Hypothesis] --> Exp[Experiment Design]
  Exp --> Blast[Blast Radius 控制]
  Exp --> Inject[故障注入]
  Inject --> Mesh[Chaos Mesh / Litmus]
  Mesh --> Observe[三支柱观测]
  Observe --> Diff[稳态偏差]
  Diff --> Learn[Learn]
  Learn --> Fix[Fix / SOP / Runbook]
  Fix --> Hypo
  Cap[容量规划] --> Little[Little's Law]
  Little --> USL[USL]
  USL --> Plan[Capacity Plan]
  Plan --> SLO[SLO 反推容量]

9.3 基础知识讲解

9.3.1 论文 / 规范

9.3.2 书

9.3.3 博客 / 文档

9.3.4 人物

| 人物 | 关注点 | |---|---|---| | Casey Rosenthal | Netflix Chaos Monkey | | Lorin Hochstein | Chaos Engineering 作者 | | Netflix Chaos Team | ChAP / FIT | | Neil Gunther | USL 论文 |

9.3.5 方法

• Steady-state first：先定义稳态再注入故障；
• Blast radius limit：用 namespace / duration / target 控制；
• Single-variable：一次只注入一种故障；
• Continuous validation：把混沌演练接入 CI/CD；
• Capacity from SLO：用 SLO 反推容量。

9.3.6 重点训练材料

• Chaos Engineering（O’Reilly）
• Principles of Chaos 网站
• USL 论文
• Chaos Mesh 与 Litmus 文档

9.4 经典问题与经典案例

9.5 学习难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

混沌工程验证韧性；容量规划保证可用性；Runbook / SOP 减少 MTTR。

9.6.3 Structure

Chaos Mesh CRD：StressChaos / PodChaos / NetworkChaos / DNSChaos / TimeChaos。Runbook：现象 + 缓解 + 升级。USL：C(N) = N / (1 + α(N - 1) + βN(N - 1))。

9.6.4 Ecosystem

混沌：Chaos Mesh / Litmus / Gremlin / ChaosBlade。容量：k6 / wrk / vegeta / USL。Runbook：Confluence / Notion / Git。

9.6.5 Depth Tiers

本子主题目标：L3。

9.6.6 Source

• Chaos Mesh Documentation
• LitmusChaos Documentation
• Principles of Chaos
• USL 论文
• 引用版本快照日期：2026-07-30。

10. 常见误区

• 生产直接注入故障；
• 爆炸半径过大；
• 不做稳态假设；
• 混沌演练没结论；
• 容量规划靠经验；
• Runbook 不更新；
• SOP 没有责任人；
• 演练频次过低；
• 演练结论不落地；
• 不复盘。

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

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

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

代码块 1：Chaos Mesh NetworkChaos

# chaos/latency.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: api-latency-30pct
  namespace: chaos-testing
spec:
  action: 
  mode: all
  selector:
    namespaces: [api]
  :
    latency: "200ms"
    jitter: "50ms"
  duration: "5m"
  scheduler:
    cron: "@every 1h"

代码块 2：Chaos Mesh PodChaos

# chaos/kill-pod.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: api-pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces: [api]
    labelSelectors:
      app: api
  duration: "2m"
  scheduler:
    cron: "@every 30m"

代码块 3：Runbook 模板

# Runbook: API 5xx 错误率突增

## 现象
- 告警：APIErrorBudget5xx > 1%
- 影响：API 错误率超阈值

## 紧急缓解（5 分钟内）
1. 检查最近部署：`kubectl rollout history deployment/api`
2. 如有可疑部署：`kubectl rollout undo deployment/api`
3. 检查依赖：`curl -I http://db:5432`、`curl -I http://cache:6379`

## 升级路径
- 5 分钟未恢复 → Sev 1 → @oncall-lead
- 15 分钟未恢复 → Sev 1 PagerDuty

## 复盘
- 触发条件：最近部署 / 依赖故障 / 流量异常
- 行动项：写入 Postmortem

代码块 4：USL 容量规划

# capacity.py
# USL: C(N) = N / (1 + alpha * (N - 1) + beta * N * (N - 1))
# alpha = 冲突系数（contention）
# beta = 一致性系数（coherency）
import numpy as np

def usl(N, alpha, beta):
    return N / (1 + alpha * (N - 1) + beta * N * (N - 1))

# 压测数据：4 节点吞吐 3800 QPS；8 节点吞吐 6400 QPS
# 用 scipy.optimize.curve_fit 拟合 alpha/beta
# 目标：SLO 99.9% → P99 500ms → 峰值 QPS 50000 → 需要节点数

# 简化估算
nodes = np.arange(1, 33)
throughput = usl(nodes, alpha=0.05, beta=0.001)
target_qps = 50000
n_optimal = nodes[np.argmax(throughput >= target_qps / 8)]  # 假设单核 8 QPS
print(f"Optimal nodes for {target_qps} QPS: {n_optimal}")

代码块 5：故障演练闭环

flowchart LR
  Hypo[稳态假设: 错误率 < 0.1% + P99 < 500ms] --> Exp[实验设计: 注入 30% 延迟]
  Exp --> Inject[Chaos Mesh NetworkChaos]
  Inject --> Observe[Grafana 看板]
  Observe --> Diff[稳态偏差: 错误率 +5%]
  Diff --> Decide{可接受?}
  Decide -->|否| Fix[修复 / SOP 更新]
  Decide -->|是| Learn[Learn]
  Fix --> Hypo
  Learn --> PM[Postmortem]
  PM --> Hypo