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）

以下展示了一个完整的实验——从假设到回滚——使用 Litmus Chaos 在 Kubernetes 上。

步骤 1 — 定义稳态并应用实验

# 验证基线：p99 延迟 < 200ms，错误率 < 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
  # 限制爆炸半径：每次仅 1 个副本
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"          # 秒
            - name: CHAOS_INTERVAL
              value: "20"          # 每 20 秒删除一个 pod
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "33"          # 最多影响 33% 的副本

# 应用实验
kubectl apply -f chaos-pod-delete.yaml

# 查看实验状态
kubectl describe chaosengine my-service-pod-delete -n production
kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w

步骤 3 — 实验期间监控

# 跟踪应用日志以发现错误
kubectl logs -l app=my-service -n production --since=2m -f

# 完成后检查 ChaosResult 判定
kubectl get chaosresult my-service-pod-delete-pod-delete \
  -n production -o jsonpath='{.status.experimentStatus.verdict}'

步骤 4 — 如果稳态被破坏则回滚/中止

# 立即停止实验
kubectl patch chaosengine my-service-pod-delete \
  -n production --type merge -p '{"spec":{"engineState":"stop"}}'

# 确认所有 pod 健康
kubectl rollout status deployment/my-service -n production

具体示例：使用 toxiproxy 注入网络延迟

# 安装 toxiproxy CLI
brew install toxiproxy   # macOS；Linux 上使用二进制发布版

# 启动 toxiproxy 服务器（与你的服务一起运行）
toxiproxy-server &

# 为下游依赖创建代理
toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy

# 注入 300ms 延迟，抖动 10% — 爆炸半径：仅此代理
toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30

# 在此运行你的负载测试/观察指标...

# 移除 toxic 以恢复正常行为
toxiproxy-cli toxic remove db-proxy -n latency_downstream

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

# chaos-monkey-config.yml — 限制到单个 ASG
deployment:
  enabled: true
  regionIndependence: false
chaos:
  enabled: true
  meanTimeBetweenKillsInWorkDays: 2
  minTimeBetweenKillsInWorkDays: 1
  grouping: APP           # 每个应用杀死一个实例，而非每个集群
  exceptions:
    - account: production
      region: us-east-1
      detail: "*-canary"  # 绝不杀死金丝雀实例

# 应用并触发手动杀死以进行测试
chaos-monkey --app my-service --account staging --dry-run false

文档