用途
chaos-engineer 是一个面向混沌工程实践的技术技能，用于设计并执行混沌实验、构建故障注入框架，以及规划和主持分布式系统的 game day 演练。其目标是通过受控的故障注入来验证系统的容错能力，并基于实验结果持续改进系统韧性。
主要能力与工作流
该技能覆盖以下核心工作流：
- 系统分析 —— 梳理架构、依赖关系、关键路径和故障模式。
- 实验设计 —— 定义假设、稳态、爆炸半径和安全控制。
- 执行混沌 —— 在监控下运行受控实验，并支持快速回滚。
- 学习与改进 —— 记录发现、实施修复、增强监控。
- 自动化 —— 将混沌测试集成到 CI/CD，实现持续韧性验证。
技能还按主题提供参考指引，包括实验设计、基础设施混沌（服务器、网络、可用区、区域故障）、Kubernetes 混沌（Pod、节点、Litmus、Chaos Mesh）、工具与自动化（Chaos Monkey、Gremlin、Pumba、CI/CD 集成）以及 game day 的规划与执行。
安全约束
资料明确要求每次实验都必须遵守以下安全清单：
- 稳态优先：注入任何故障前先定义并验证基线指标。
- 爆炸半径上限：从最小影响范围开始，验证后才扩大。
- 自动化回滚 ≤ 30 秒：中止路径必须在实验开始前脚本化并测试。
- 单一变量：在行为被充分理解前，一次只改变一个故障条件。
- 生产环境必须有安全网：面向客户的环境需要断路器、功能开关或金丝雀隔离。
- 闭环：每个实验必须产出书面学习总结和至少一项可追踪的改进。
输出模板
实施混沌工程时，该技能要求提供：
- 实验设计文档（假设、指标、爆炸半径）
- 实现代码（故障注入脚本/清单）
- 监控设置与告警配置
- 回滚流程与安全控制
- 学习总结与改进建议
使用方式示例
资料提供了多个具体示例，展示从假设到回滚的完整流程：
Kubernetes Pod 故障实验（Litmus Chaos）：先验证基线（如 p99 延迟 < 200ms、错误率 < 0.1%），再创建并应用 Litmus ChaosEngine 清单，通过 TOTAL_CHAOS_DURATION、CHAOS_INTERVAL、PODS_AFFECTED_PERC 等环境变量控制故障时长、间隔和受影响副本比例；实验过程中查看日志与 ChaosResult 判定，若稳态被破坏则立即通过将 engineState 设为 stop 中止实验，并确认 Pod 健康。
网络延迟（toxiproxy）：使用 toxiproxy-cli create 创建下游依赖代理，再用 toxiproxy-cli toxic add 注入延迟和抖动，实验后移除 toxic 恢复正常。
Chaos Monkey：通过配置文件限制到单一 ASG，设置杀伤间隔、分组方式，并排除金丝雀实例，可手动触发测试。
适用场景
- 设计并执行混沌实验
- 实现故障注入框架（如 Chaos Monkey、Litmus）
- 规划和开展 game day 演练
- 构建爆炸半径控制与安全机制
- 在 CI/CD 中建立持续混沌测试
- 基于实验结果改进系统韧性
限制
资料未提供该技能的独立安装方式、运行环境要求、平台限制或收费信息；相关细节需参考上游文档。此外，所有实验均需遵守上述安全约束，在缺乏监控与回滚能力的环境中不宜直接对生产系统执行故障注入。
引用文档
以下为作者声明的引用来源，保留指定版本、署名和许可。
- jeffallan/claude-skills/skills/chaos-engineer/SKILL.md — 署名：Jeffallan；许可：MIT；版本：
3bf9a24b76a7c122f1fc05e83929fbc84e1c207a。