深色模式
混沌工程成熟度
摘要：混沌工程从"手工破坏"到"常态化自动验证"有清晰的阶梯。本文给出五级成熟度模型与判定标准，帮助团队定位当前位置并明确下一步动作。
适用环境
bash
# 自评依赖实验记录与自动化程度的事实，而非印象
ls -1 chaos-experiments/ 2>/dev/null | wc -l
ls -1 gameday/ 2>/dev/null | wc -l
kubectl get cronjob -A 2>/dev/null | grep -i chaos | head1
2
3
4
2
3
4
操作步骤
第 1 步：五级成熟度模型
bash
cat > maturity.md <<'EOF'
| 级别 | 名称 | 判定标准 |
| --- | --- | --- |
| L1 | 手工探索 | 有人手工删过 Pod，无记录无指标 |
| L2 | 有设计 | 实验有假设与指标，产出结论文档 |
| L3 | 有流程 | 定期 Game Day，有中止条件与通知 |
| L4 | 自动化 | 实验以定时任务/CI 持续运行 |
| L5 | 常态化治理 | 实验覆盖核心链路，结果与 SLO 联动 |
EOF1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
第 2 步：逐项打分
bash
cat > self-check.sh <<'EOF'
#!/usr/bin/env bash
score=0
[ -d chaos-experiments ] && [ "$(ls chaos-experiments | wc -l)" -ge 3 ] && { echo "+1 有实验记录"; score=$((score+1)); }
grep -rls '## 假设' chaos-experiments 2>/dev/null | grep -q . && { echo "+1 有假设设计"; score=$((score+1)); }
[ -d gameday ] && [ "$(ls gameday | wc -l)" -ge 1 ] && { echo "+1 有 Game Day"; score=$((score+1)); }
grep -rls '中止条件' chaos-experiments 2>/dev/null | grep -q . && { echo "+1 有中止条件"; score=$((score+1)); }
kubectl get cronjob -A 2>/dev/null | grep -qi chaos && { echo "+1 有定时实验"; score=$((score+1)); }
echo "总分: $score/5"
EOF
chmod +x self-check.sh && ./self-check.sh1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
第 3 步：明确晋级动作
bash
cat > next-actions.md <<'EOF'
L1 -> L2：为每个实验补假设、指标与结论卡片
L2 -> L3：每季度一次 Game Day，补中止条件与通知机制
L3 -> L4：把稳定实验固化为 CronJob/CI 任务
L4 -> L5：把实验结果接入错误预算，纳入发布准入
EOF1
2
3
4
5
6
2
3
4
5
6
第 4 步：把实验变成定时任务（L4 的关键一步）
yaml
# 用 CronJob 周期性创建/删除实验，或直接用 Chaos Mesh 的 scheduler
spec:
scheduler:
cron: '@every 168h' # 每周一次
duration: '120s'1
2
3
4
5
2
3
4
5
bash
# 也可用系统 cron 触发
cat > /etc/cron.d/chaos-weekly <<'EOF'
0 14 * * 2 ops kubectl -n test apply -f /opt/chaos/weekly.yaml
EOF1
2
3
4
2
3
4
第 5 步：每季度复评
bash
{
echo "## 复评 $(date +%F)"
./self-check.sh
echo "实验数: $(ls chaos-experiments 2>/dev/null | wc -l)"
echo "Game Day 次数: $(ls gameday 2>/dev/null | wc -l)"
} | tee -a maturity-history.md1
2
3
4
5
6
2
3
4
5
6
验证
bash
# 1. 自评脚本可执行并给出分数
./self-check.sh
# 2. 晋级动作清单存在且有负责人
grep -c '\->' next-actions.md
# 3. 复评记录随时间累积
grep -c '## 复评' maturity-history.md1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
直接跳到 L4 自动化
没有设计和结论的实验自动化后只是"定时搞破坏"，还会持续消耗团队信任。
只统计实验次数不看覆盖面
做了 50 次 Pod Kill 但从未测过依赖延迟，覆盖率仍然很低。按链路覆盖评估，而非按次数。
把成熟度当作团队 KPI
为了升级而做实验会催生形式主义。成熟度只用于自我定位，不用于横向比较或考核。