深色模式
混沌工程入门
摘要：混沌工程不是"随便搞坏东西"，而是在可控范围内做实验，验证系统对故障的真实反应。本文解释它与压测、测试的区别，给出五项原则和一次最小实验的完整流程。
适用环境
bash
kubectl version --short 2>/dev/null || echo "需要一套可随意破坏的测试集群"
kubectl get ns | head
# 关键前提：测试环境与生产隔离
kubectl config current-context1
2
3
4
2
3
4
操作步骤
第 1 步：先区分三个容易混淆的概念
| 概念 | 目的 | 是否改变系统 |
|---|---|---|
| 测试 | 验证功能正确性 | 否 |
| 压测 | 验证容量 | 加负载 |
| 混沌实验 | 验证故障下的行为 | 注入故障 |
第 2 步：记住五项原则
- 建立"稳态"假设（可量化的正常指标）
- 用真实事件做变量（宕机、延迟、丢包）
- 在生产/准生产环境做（越真实越有价值）
- 持续自动化运行
- 最小化爆炸半径
第 3 步：定义稳态指标
bash
# 用 Prometheus 查询稳态：错误率与 P99 延迟
curl -sS --data-urlencode 'query=sum(rate(http_requests_total{job="demo",code=~"5.."}[5m]))/sum(rate(http_requests_total{job="demo"}[5m]))' \
http://127.0.0.1:9090/api/v1/query | jq -r '.data.result[0].value[1]'1
2
3
2
3
假设写法："注入 200ms 网络延迟后，下单接口错误率仍低于 1%，P99 低于 1.5s。"
第 4 步：跑第一个实验——杀一个 Pod
bash
# 前置：确认有副本冗余
kubectl -n test get deploy demo -o jsonpath='{.status.readyReplicas}{"\n"}'
# 注入：随机删一个 Pod
kubectl -n test delete pod -l app=demo --field-selector=status.phase=Running -n test --dry-run=client 2>/dev/null
kubectl -n test get pod -l app=demo -o name | head -1 | xargs -r kubectl -n test delete1
2
3
4
5
6
2
3
4
5
6
第 5 步：观察并记录结论
bash
# 观察 2 分钟内稳态指标是否守住
watch -n 5 'kubectl -n test get pod -l app=demo'
# 结论三选一：假设成立 / 假设不成立（发现脆弱点）/ 实验无效（指标没动）
echo "结论：" > chaos-log/exp-001.md1
2
3
4
5
2
3
4
5
验证
bash
# 1. 副本数已恢复
kubectl -n test get deploy demo -o jsonpath='{.status.readyReplicas}{"\n"}'
# 2. 稳态指标回到基线
curl -sS --data-urlencode 'query=up{job="demo"}' http://127.0.0.1:9090/api/v1/query | jq -r '.data.result[].value[1]'
# 3. 实验结论已落盘
cat chaos-log/exp-001.md1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
没有稳态指标就开打
"看着好像没问题"不是结论。先定义可查询、可对比的数字，再注入故障。
一上来就打生产
首次实验应在完全隔离的环境进行，用于验证流程本身；流程成熟后再考虑生产小范围。
忘了清理实验
注入后忘记删除实验对象，故障持续生效，被误认为真实故障。每次实验必须有结束时间与清理步骤。