混沌工程：ChaosBlade、Chaos Mesh 与可观测性闭环

某团队在生产做第一次「混沌」：kubectl delete pod checkout-xxx。Pod 15 秒内重建，服务恢复。团队欢呼系统高可用。

但 15 秒内 checkout 可用率从 99.95% 降到 99.1%，消耗两周错误预算；告警一条未响——延迟 SLO 的 PromQL 用了 p50 而非 p99。实验证明了自愈，更证明了可观测性盲区。

混沌工程的价值：不是找代码 bug，是找「告警与 SLO 能否发现这类故障」。稳态用 SLO 工程度量；告警是否触发用告警体系验证；全链路排障见事故复盘剧本。

一、混沌工程的原则

1.1 起源

Netflix Chaos Monkey（2011）随机终止生产实例，验证容错。原则被归纳进 Principles of Chaos Engineering。

1.2 五步循环

步骤	动作	可观测性产出
1 定义稳态	SLO Dashboard 指标	对照组基线
2 提出假设	可判定命题	实验验收标准
3 设计实验	故障类型+半径	注入配置
4 执行观测	注入+看告警	触发时间、漏报
5 分析	预期 vs 实际	Reliability Backlog

1.3 与测试的区别

	单元/集成测试	混沌实验
环境	CI/staging	staging → 可控 prod
目标	功能正确	可观测性+韧性
失败价值	bug 列表	告警/SLO gap

二、三大开源工具对比

2.1 总览

工具	来源	模型	强项	弱项
ChaosBlade	阿里开源	CLI + Operator	上手快、JVM/主机	K8s 编排弱于 Mesh
Chaos Mesh	PingCAP, CNCF	CRD	K8s 原生、Workflow	学习曲线
LitmusChaos	CNCF	Hub + GitOps	模板化、Harness CE	重度依赖 K8s

2.2 ChaosBlade

# 网络延迟（主机）
blade create network delay --time 3000 --interface eth0 --offset 100

# K8s Pod CPU 满载
blade create k8s pod-cpu fullload --namespace checkout --names checkout-xxx --cpu-percent 80

# 销毁实验
blade destroy <UID>

中文文档完善，适合国内团队第一个实验。

2.3 Chaos Mesh

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay-checkout
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: [checkout]
    labelSelectors:
      app: checkout
  delay:
    latency: "200ms"
  duration: "5m"

Workflow 可编排多步实验；Dashboard 可视化。

2.4 LitmusChaos

ChaosHub 提供预置实验模板；与 ArgoCD 集成做 GitOps 混沌。

三、稳态假设与 SLO 判定

3.1 稳态指标示例

可用性：\[\text{SLI}_{avail} \geq 99.9\%\]（5m 窗口）
延迟：p99 < 200ms
吞吐：QPS 在预期区间

3.2 实验假设模板

若对 checkout 单 Pod 注入 200ms 网络延迟 5 分钟，则 p99 延迟 SLO Burn Rate 告警应在 2 分钟内触发，且错误预算消耗 < 1%。

3.3 判定表

观测项	通过	失败 → 行动
SLO 告警触发	是	调整 Burn Rate 规则
Dashboard 异常可见	是	补 Panel / Recording rule
Trace 不断裂	是	修 propagation
自动恢复 < RTO	是	修 HPA/PDB

四、实验工程设计（四阶段）

4.1 Fault Injection

CPU、内存、网络延迟/丢包、DNS、磁盘 I/O、Pod 删除、AZ 故障。

4.2 Observability

并行观察：SLO Dashboard、告警、Logs trace_id、Traces 采样率是否够。

4.3 Recovery

记录 RTO；是否需人工 kubectl rollout undo。

4.4 Analysis

写入 Reliability Backlog：每条 gap 对应 owner 与 due date。

sequenceDiagram
  participant E as 实验编排
  participant F as 故障注入
  participant S as SLI 采集
  participant A as Alertmanager
  participant O as On-call
  E->>F: 注入延迟
  F->>S: 扰动流量
  S->>A: Burn Rate 计算
  alt 告警触发
    A->>O: Page
  else 漏报
    O->>O: 记录盲区
  end

五、爆炸半径控制

5.1 递进策略

单 Pod → 单 Deployment → 单 AZ → Region（极少）。

5.2 Kill Switch

ChaosBlade: blade destroy
Chaos Mesh: kubectl delete networkchaos --all -n chaos-testing
脚本: timeout 300

5.3 生产准入

staging 同模板通过
on-call 值守
变更窗口审批
回滚/停止演练过一遍

六、驱动可观测性改进的案例

6.1 网络延迟 → 告警盲区

注入 200ms → p99 升无告警 → PromQL 用 p50 → 改为 p99 + Burn Rate。

6.2 Kafka broker → Trace 断裂

杀 broker → 降级无完整 trace → Kafka client 未传播 traceparent → 修 OTel 配置。

6.3 DNS 超时 → 日志缺失

gRPC DNS 错误未打日志 → 补 error log + span event。

七、工程坑点

未 staging 验证就上生产——违背实验伦理。
无超时——CPU stress 打满节点。
不监控实验本身——注入是否成功未知。
只做自动化不做 Game Day——组合故障只有人才能发现。
实验未关联 SLO——无法量化用户影响。

八、落地清单

稳态 Dashboard 与 SLO 对齐
实验库 Git 版本化
爆炸半径 policy 文档
每季度 Game Day
实验结果 → Backlog 闭环

九、关键概念回顾

混沌输出 = 可观测性盲区清单
稳态必须 可度量（SLO）
半径递进 + Kill Switch

十、常见误解

误解	事实
混沌=删 Pod	需假设、稳态、观测、分析
通过=系统可靠	通过=本次故障可被观测
只能 QA 做	SRE 主导，研发参与分析

十一、下一步

治理层收束。下一篇中国可观测性厂商对比。

附录 A：实验目录模板

ID	故障	假设	半径	工具
EXP-001	PodKill k8s	验证 PDB/HPA	checkout 单 Pod	Chaos Mesh
EXP-002	NetworkDelay 200ms	延迟 SLO 告警	单 Deployment 1 副本	Chaos Mesh
EXP-003	CPUStress 80%	CPU 不应 Page 除非 SLO 坏	单节点	Chaos Mesh
EXP-004	DNSChaos timeout	日志+Trace 可见	namespace 级	Chaos Mesh
EXP-005	IOChaos latency	块设备 Metrics vs 应用延迟	带 PVC Pod	Chaos Mesh
EXP-006	TimeChaos skew	证书/TTL 问题	仅 staging	Chaos Mesh
EXP-007	JVMChaos ChaosBlade	GC/延迟关联	Java 服务	Chaos Mesh
EXP-008	AZFailure network partition	多 AZ SLO	需审批	Chaos Mesh

十二、Chaos Mesh Workflow 编排示例

apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: checkout-resilience-day
  namespace: chaos-testing
spec:
  entry: serial
  templates:
    - name: serial
      templateType: Serial
      children:
        - network-delay
        - pod-kill
    - name: network-delay
      templateType: NetworkChaos
      deadline: 5m
      networkChaos:
        action: delay
        mode: one
        selector:
          namespaces: [checkout]
          labelSelectors:
            app: checkout
        delay:
          latency: 200ms
    - name: pod-kill
      templateType: PodChaos
      deadline: 3m
      podChaos:
        action: pod-kill
        mode: one
        selector:
          namespaces: [checkout]

十三、LitmusChaos ChaosEngine 模板

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: checkout-network-chaos
spec:
  appinfo:
    appns: checkout
    applabel: app=checkout
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            - name: NETWORK_LATENCY
              value: "200"
            - name: TOTAL_CHAOS_DURATION
              value: "300"

十四、稳态与 SLO 联动的 Recording Rule

实验期间建议预建 chaos:experiment_active 指标（由实验 CronJob 打 1），告警规则排除或单独路由：

groups:
  - name: chaos-slo
    rules:
      - record: chaos:checkout_availability_5m
        expr: |
          sum(rate(http_requests_total{service="checkout",status!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{service="checkout"}[5m]))

详见 SLO 工程 §三。

十五、告警验证矩阵

故障	应触发信号	期望告警	常见盲区
PodKill	可用性 Burn Rate	5m 内应 Page	HPA 恢复时间
200ms delay	延迟 Burn Rate	2m 内应 Ticket+	p99 recording
CPU 80%	不一定告警	仅 SLO 坏才 Page	禁止裸 CPU Page
DNS fail	可用性+日志	应有 error log	gRPC resolver
Kafka down	可用性+Trace	降级可见	trace context
磁盘满	日志+Metrics	node disk alert	应用层超时

十六、Game Day 组织手册

16.1 角色

角色	职责
Commander	决定继续/中止
Observer	盯 SLO/告警面板
Injector	执行 Chaos CR
Comms	对内/对客户通报

16.2 时间线（示例 2h）

T+0    开场，确认稳态基线
T+15m  EXP-001 网络延迟
T+45m  复盘 gap，休息
T+60m  EXP-002 PodKill
T+90m  汇总 Backlog
T+120m 结束，发纪要

十七、Reliability Backlog 条目模板

## [CHAOS-042] p99 延迟告警未触发
- **实验**: EXP-003 network 200ms
- **预期**: Burn Rate > 14.4 in 1h within 2min
- **实际**: 无告警；Dashboard 手动可见
- **根因**: recording rule 用 p50
- **修复**: 改为 histogram p99 SLI + 多窗口规则
- **Owner**: @sre-oncall
- **Due**: 2026-07-01

十八、故障类型与可观测性信号对照

NetworkChaos

变体：delay, loss, duplicate, corrupt
备注：Checkout 依赖 Redis
必查：SLO、Logs、Traces、Events 变更

StressChaos

变体：CPU, memory
备注：节点级注意 cgroup
必查：SLO、Logs、Traces、Events 变更

IOChaos

变体：latency, fault
备注：需 PVC 权限
必查：SLO、Logs、Traces、Events 变更

DNSChaos

变体：error, random
备注：service mesh 场景
必查：SLO、Logs、Traces、Events 变更

TimeChaos

变体：offset
备注：仅 staging，破坏 TLS
必查：SLO、Logs、Traces、Events 变更

HTTPChaos

变体：abort, delay
备注：入口网关
必查：SLO、Logs、Traces、Events 变更

JVMChaos

变体：ChaosBlade
备注：Java 老系统
必查：SLO、Logs、Traces、Events 变更

十九、混沌与可观测性深度 1

主题：与 CI 流水线集成：merge 前跑 PodKill 于 preview 环境

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十、混沌与可观测性深度 2

主题：与 13-events 联动：实验本身作为 Change Event

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十一、混沌与可观测性深度 3

主题：多区域实验的 SLO 聚合

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

二十二、混沌与可观测性深度 4

主题：服务网格 mTLS 下 NetworkChaos

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十三、混沌与可观测性深度 5

主题：serverless 冷启动与 PodKill 差异

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十四、混沌与可观测性深度 6

主题：数据库主从切换实验

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

二十五、混沌与可观测性深度 7

主题：缓存穿透与延迟实验

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十六、混沌与可观测性深度 8

主题：限流 429 是否计入 SLI（对照 18 篇）

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十七、混沌与可观测性深度 9

主题：混沌期间的 tail sampling 临时上调

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

二十八、混沌与可观测性深度 10

主题：on-call 演练而非真 Page 的路由技巧

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

二十九、混沌与可观测性深度 11

主题：实验失败即成功：文档化盲区

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十、混沌与可观测性深度 12

主题：合规：生产混沌的客户通知模板

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

三十一、混沌与可观测性深度 13

主题：与 K8s PDB minAvailable 冲突

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十二、混沌与可观测性深度 14

主题：混沌 Operator 自身 HA

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十三、混沌与可观测性深度 15

主题：实验数据保留用于季度回顾

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

三十四、混沌与可观测性深度 16

主题：自动化回归：每周 staging EXP-001

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十五、混沌与可观测性深度 17

主题：领导层关心的混沌 ROI 表述

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十六、混沌与可观测性深度 18

主题：从删 Pod 到 formal workflow 的迁移路径

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>

三十七、混沌与可观测性深度 19

主题：开源工具版本升级回归实验

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十八、混沌与可观测性深度 20

主题：跨团队依赖的联合 Game Day

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

三十九、混沌与可观测性深度 21

主题：事故后补做的混沌验证

假设模板：若注入 X，则 [SLO/告警/Trace] 在 T 分钟内可观测。

输出：更新告警体系规则或埋点哲学采样策略。

# ChaosBlade 实验超时包装
timeout 300 blade create k8s pod-network delay \
  --namespace checkout --names checkout-xxx --time 200 --interface eth0
blade status <UID>
blade destroy <UID>