Chaos Engineer 是一个面向韧性测试与混沌工程的技能，核心目标是帮助团队通过受控实验验证系统在故障场景下的表现，并推动反脆弱系统设计。
用途方面，该技能适用于：重大发布前验证系统韧性；测试数据库、区域、可用区的故障转移机制；验证告警链路是否正常触发；组织工程团队开展 Game Day 演练；在 CI/CD 中实施自动化混沌（持续验证）；排查分布式系统中难以复现的缺陷，如竞态条件与超时问题。
主要能力围绕实验设计矩阵与工具选型展开。实验设计按层次划分：基础设施层可进行 Pod/容器杀死、节点排空或重启、网络延迟/丢包/分区；应用层可阻断数据库或 Redis 访问、施加 CPU/内存压力、注入 HTTP 500 或延迟；平台层可撤销 IAM 密钥、阻断 DNS 解析。工具选型建议：Kubernetes 环境使用 Chaos Mesh 或 Litmus 做原生实验；云环境使用 AWS FIS 或 Gremlin 模拟可用区中断、EC2 停止等；服务网格使用 Istio 故障注入处理 HTTP 错误与延迟；Java/Spring 应用可使用 Chaos Monkey for Spring。
使用方式强调爆炸半径控制与审批：本地/开发环境单容器风险低、无需审批；预发环境全集群风险中等、需 QA 负责人审批；生产金丝雀 1% 流量风险高、需工程总监审批；生产全流量风险极高、需 VP/CTO 审批。技能还给出应升级至 sre-engineer 的红旗信号：缺少停止按钮、存在可观测性盲区、识别到级联故障风险且无缓解措施、有状态数据实验缺少备份。
核心工作流包括 Kubernetes Pod 混沌实验（定义 PodChaos 清单、提出假设、执行并监控 Grafana 指标、验证结果）以及区域中断模拟 Game Day（通知值班团队、阻断区域网络或停止 RDS 主实例、测量 RTO 与 RPO 目标）。
适用场景涵盖微服务 Pod 故障恢复验证、多区域数据库故障转移验证、第三方 API 依赖的优雅降级测试等。限制与注意事项方面，技能明确反对在生产环境首次测试、无观测情况下执行混沌、以及无目的的随机混沌，强调先在低环境验证假设、可观测性优先、采用有针对性场景。质量检查清单涵盖规划、安全、执行与复盘四个阶段，要求明确假设、限定爆炸半径、准备停止按钮与回滚计划、实验期间保持仪表盘可见、记录实验起止时间，并在复盘后分配行动项与分享发现。