设计混沌实验与故障注入框架，验证分布式系统韧性

在分布式系统中设计并执行混沌实验、故障注入和 Game Day 演练，以受控方式暴露故障、验证稳态并推动系统改进。

适用场景

解决思路

1. 按五步核心工作流推进：系统分析（梳理架构、依赖、关键路径与故障模式）→ 实验设计（定义假设、稳态、爆炸半径与安全控制）→ 执行混沌（带监控与快速回滚的受控实验）→ 学习改进（记录发现、实施修复、增强监控）→ 自动化（将混沌测试集成到 CI/CD 实现持续韧性）。
2. 按上下文加载参考指南：实验设计（假设、爆炸半径、回滚）看 references/experiment-design.md；基础设施故障（服务器、网络、可用区、区域）看 references/infrastructure-chaos.md；Kubernetes（Pod、节点、Litmus、Chaos Mesh）看 references/kubernetes-chaos.md；工具与自动化（Chaos Monkey、Gremlin、Pumba、CI/CD 集成）看 references/chaos-tools.md；Game Day（规划、执行、复盘）看 references/game-days.md。
3. 每次实验强制执行安全清单：先定义并验证稳态基线指标再注入故障；从最小影响范围开始，验证后再扩大爆炸半径；实验开始前脚本化并测试好 ≤30 秒的自动回滚路径；一次只改变一个故障条件；面向客户的环境必须有熔断器、功能开关或金丝雀隔离；每个实验必须产出书面学习总结和至少一项被跟踪的改进。
4. 交付物包含五部分：实验设计文档（假设、指标、爆炸半径）、实现代码（故障注入脚本/清单）、监控与告警配置、回滚流程与安全控制、学习总结与改进建议。
5. Pod 故障实验（Litmus Chaos）步骤一：验证基线，执行 kubectl get deploy my-service -n production 与 kubectl top pods -n production -l app=my-service，确认 p99 延迟 < 200ms、错误率 < 0.1%。
6. 步骤二：创建并应用 Litmus ChaosEngine 清单 chaos-pod-delete.yaml，配置 appinfo（appns、applabel、appkind）、engineState: active、chaosServiceAccount: litmus-admin，实验 pod-delete 的环境变量 TOTAL_CHAOS_DURATION=60、CHAOS_INTERVAL=20、FORCE=false、PODS_AFFECTED_PERC=33（限制爆炸半径，一次只影响 1 个副本、最多 33% 副本）；用 kubectl apply -f chaos-pod-delete.yaml 应用，用 kubectl describe chaosengine 与 kubectl get chaosresult -w 观察状态。
7. 步骤三：实验期间监控，用 kubectl logs -l app=my-service -n production --since=2m -f 跟踪应用错误日志，完成后用 kubectl get chaosresult ... -o jsonpath='{.status.experimentStatus.verdict}' 查看裁决结果。
8. 步骤四：若稳态被破坏则回滚/中止，用 kubectl patch chaosengine my-service-pod-delete -n production --type merge -p '{"spec":{"engineState":"stop"}}' 立即停止实验，再用 kubectl rollout status deployment/my-service -n production 确认所有 Pod 健康。
9. 网络延迟实验（toxiproxy）：用 brew install toxiproxy 安装 CLI（Linux 用二进制发布版），启动 toxiproxy-server &，用 toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy 为下游依赖创建代理，用 toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30 注入 300ms 延迟与 10% 抖动（爆炸半径仅限该代理），运行负载测试并观察指标，最后用 toxiproxy-cli toxic remove db-proxy -n latency_downstream 移除毒性恢复正常。
10. Chaos Monkey 实验：编写 chaos-monkey-config.yml，设置 deployment.enabled: true、regionIndependence: false、chaos.enabled: true、meanTimeBetweenKillsInWorkDays: 2、minTimeBetweenKillsInWorkDays: 1、grouping: APP（每个应用杀一个实例而非每个集群），并在 exceptions 中排除生产账号 us-east-1 的 *-canary 金丝雀实例；用 chaos-monkey --app my-service --account staging --dry-run false 应用并触发手动 kill 测试。

适用边界 · 注意事项

• 尚未定义并验证稳态基线指标时，不要注入任何故障。
• 面向客户的生产环境若没有熔断器、功能开关或金丝雀隔离等安全网，不要执行实验。
• 行为尚未被充分理解时，不要同时改变多个故障条件或一次性扩大爆炸半径。