
使用方式
关于
为分布式系统设计混沌实验、创建故障注入框架,以及组织游戏日演练——生成运行手册、实验清单、回滚流程和事后分析模板。用于设计混沌实验、实现故障注入框架。
混沌工程师
何时使用此技能
- 设计和执行混沌实验
- 实现故障注入框架(Chaos Monkey、Litmus 等)
- 规划和执行演练日活动
- 构建爆炸半径控制和安全机制
- 在 CI/CD 中设置持续混沌测试
- 基于实验发现改善系统韧性
核心工作流程
- 系统分析 - 映射架构、依赖、关键路径和故障模式
- 实验设计 - 定义假设、稳态、爆炸半径和安全控制
- 执行混沌 - 在监控和快速回滚下运行受控实验
- 学习与改进 - 记录发现、实施修复、增强监控
- 自动化 - 将混沌测试集成到 CI/CD 中实现持续韧性
参考指南
根据上下文加载详细指导:
| 主题 | 参考 | 加载时机 |
|------|------|----------|
| 实验 | references/experiment-design.md | 设计假设、爆炸半径、回滚 |
| 基础设施 | references/infrastructure-chaos.md | 服务器、网络、可用区、区域故障 |
| Kubernetes | references/kubernetes-chaos.md | Pod、节点、Litmus、chaos mesh 实验 |
| 工具与自动化 | references/chaos-tools.md | Chaos Monkey、Gremlin、Pumba、CI/CD 集成 |
| 演练日 | references/game-days.md | 规划、执行、从演练日学习 |
安全检查清单
每个实验必须强制执行的非显而易见的约束:
- 先确定稳态 — 注入任何故障前定义并验证基线指标
- 爆炸半径上限 — 从最小可能的影响范围开始;仅在验证后扩大
- 自动回滚 ≤ 30 秒 — 中止路径必须在实验开始前编写脚本并测试
- 单一变量 — 在行为被充分理解前,一次只改变一个故障条件
- 无安全网不上生产 — 面向客户的环境需要熔断器、功能标志或金丝雀隔离
- 闭环 — 每个实验必须产出书面学习总结和至少一个跟踪的改进项
输出模板
实施混沌工程时,提供:
- 实验设计文档(假设、指标、爆炸半径)
- 实现代码(故障注入脚本/清单)
- 监控设置和告警配置
- 回滚程序和安全控制
- 学习总结和改进建议
具体示例:Pod 故障实验(Litmus Chaos)
以下展示了使用 Litmus Chaos 在 Kubernetes 上的完整实验 — 从假设到回滚。
步骤 1 — 定义稳态并应用实验
# Verify baseline: p99 latency < 200ms, error rate < 0.1%
kubectl get deploy my-service -n production
kubectl top pods -n production -l app=my-service
步骤 2 — 创建并应用 Litmus ChaosEngine 清单
# chaos-pod-delete.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: my-service-pod-delete
namespace: production
spec:
appinfo:
appns: production
applabel: "app=my-service"
appkind: deployment
engineState: active
chaosServiceAccount: litmus-admin
experiments:
- name: pod-delete
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: "60"
- name: CHAOS_INTERVAL
value: "20"
- name: FORCE
value: "false"
- name: PODS_AFFECTED_PERC
value: "33"
# Apply the experiment
kubectl apply -f chaos-pod-delete.yaml
# Watch experiment status
kubectl describe chaosengine my-service-pod-delete -n production
kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w
步骤 3 — 实验期间监控
# Tail application logs for errors
kubectl logs -l app=my-service -n production --since=2m -f
# Check ChaosResult verdict when complete
kubectl get chaosresult my-service-pod-delete-pod-delete \
-n production -o jsonpath='{.status.experimentStatus.verdict}'
步骤 4 — 稳态被违反时回滚/中止
# Immediately stop the experiment
kubectl patch chaosengine my-service-pod-delete \
-n production --type merge -p '{"spec":{"engineState":"stop"}}'
# Confirm all pods are healthy
kubectl rollout status deployment/my-service -n production
具体示例:使用 toxiproxy 注入网络延迟
# Install toxiproxy CLI
brew install toxiproxy # macOS
# Start toxiproxy server
toxiproxy-server &
# Create a proxy for downstream dependency
toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy
# Inject 300ms latency with 10% jitter
toxiproxy-cli toxic add -t latency -a latency=300 -a jitter=30 db-proxy
知识参考
混沌工程、Litmus Chaos、Chaos Monkey、Gremlin、toxiproxy、Kubernetes、Prometheus、故障注入、韧性测试、演练日、SRE、爆炸半径控制
兼容工具
Claude CodeCursor
标签
运维部署


