chaos-engineer

混沌工程师

何时使用此技能

• 设计并执行混沌实验
• 实现故障注入框架（Chaos Monkey、Litmus 等）
• 规划并开展演练日活动
• 构建爆炸半径控制和安全机制
• 在 CI/CD 中设置持续混沌测试
• 根据实验结果提升系统韧性

核心工作流

1. 系统分析 - 梳理架构、依赖关系、关键路径和故障模式
2. 实验设计 - 定义假设、稳态、爆炸半径和安全控制措施
3. 执行混沌实验 - 在监控和快速回滚的支持下开展受控实验
4. 总结与改进 - 记录发现、实施修复、增强监控
5. 自动化 - 将混沌测试集成到 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 秒 — 实验开始前，必须编写并测试中止路径脚本
• 单一变量 — 在充分了解行为之前，每次只改变一种故障条件
• 生产环境必须有安全措施 — 面向客户的环境必须配备断路器、功能标志或金丝雀隔离
• 形成闭环 — 每次实验都必须产出书面的经验总结，并至少跟踪一项改进

输出模板

实施混沌工程时，请提供：

1. 实验设计文档（假设、指标、爆炸半径）
2. 实现代码（故障注入脚本／清单）
3. 监控设置和告警配置
4. 回滚流程和安全控制措施
5. 经验总结和改进建议

具体示例：Pod 故障实验（Litmus Chaos）

以下示例展示了如何在 Kubernetes 上使用 Litmus Chaos 完成一次实验，涵盖从假设到回滚的全过程。

步骤 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
  # Limit blast radius: only 1 replica at a time
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"          # seconds
            - name: CHAOS_INTERVAL
              value: "20"          # delete one pod every 20s
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "33"          # max 33% of replicas affected

# 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; use the binary release on Linux

# Start toxiproxy server (runs alongside your service)
toxiproxy-server &

# Create a proxy for your downstream dependency
toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy

# Inject 300ms latency with 10% jitter — blast radius: this proxy only
toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30

# Run your load test / observe metrics here ...

# Remove the toxic to restore normal behaviour
toxiproxy-cli toxic remove db-proxy -n latency_downstream

具体示例：Chaos Monkey（Spinnaker／独立运行）

# chaos-monkey-config.yml — restrict to a single ASG
deployment:
  enabled: true
  regionIndependence: false
chaos:
  enabled: true
  meanTimeBetweenKillsInWorkDays: 2
  minTimeBetweenKillsInWorkDays: 1
  grouping: APP           # kill one instance per app, not per cluster
  exceptions:
    - account: production
      region: us-east-1
      detail: "*-canary"  # never kill canary instances

# Apply and trigger a manual kill for testing
chaos-monkey --app my-service --account staging --dry-run false

由 @jeffallan 维护；Synergetic Solutions 首席顾问

文档