混沌工程不是「破坏」，而是「验证」
- 年代 Netflix 公开 Chaos Monkey 时，混沌工程被理解为「在生产环境中随机制造破坏的激进实践」。其文化冲击力巨大，同时也带来了误解——要在生产环境中投掷炸弹，需要相当的组织成熟度，对大多数企业而言门槛过高。
- 年的定论已经清晰：混沌工程不是「破坏技术」，而是「验证韧性的规律」，其本质是「以科学实验的方式确认，针对故障的预先设计是否按预期运作」。提出假设、小规模试验、观察、改进——这一 PDCA 循环的整体就是 chaos engineering。将其理解为日本企业广泛参考的 TPM（全员参与的预防维护）或 FMEA（故障模式影响分析）的延伸，有助于简化导入时的说明。
工具选型：Gremlin / LitmusChaos / Chaos Mesh
- 年的主流工具已形成三分格局。Gremlin 是商业 SaaS 的领军者，「Blast Radius（影响范围）控制」与「Halt 条件」是其卖点，即使没有 SRE 团队的组织也能安全导入。网络延迟、CPU 压力、磁盘 I/O 耗尽、可用区故障等数十种标准攻击手段均已内置，通过 Web UI 几次点击即可启动实验。在金融、通信等「需要将混沌工程作为合规应对措施」的场景中尤为有力。
LitmusChaos 是 CNCF Graduated 项目，是 Kubernetes 原生的开源方案。将混沌实验定义为 CRD，可从 ChaosHub 导入社区实验。GitOps 集成堪称一流，结合 Argo CD 可构建「用 Git 声明实验，用 Argo Workflows 执行，用 Prometheus 验证指标，失败时自动回滚」的完整 pipeline。适合 SRE 团队规范已成熟的组织。
Chaos Mesh 是 PingCAP 发起的 CNCF Incubating 项目，专注于 Kubernetes 上的细粒度故障注入。PodChaos、NetworkChaos、IOChaos、TimeChaos、DNSChaos 等 CRD 十分完善，尤其能重现「NTP 偏移」「DNS 污染」等其他工具难以模拟的低层级故障。Chaos Dashboard 的用户体验也优于 LitmusChaos，学习成本更低。
Kubernetes 上的实施：实验三层模型
在 Kubernetes 环境中，将实验分为三层运营已成为标准模式。第一层是「Pod 级别」：通过 PodChaos kill 特定 Deployment 的一个 Pod，确认 HPA 以及服务网格的重试、熔断器是否按预期运作。影响范围最小，可每日自动执行。
第二层是「Node 级别」：通过 NodeChaos drain 一个可用区内的节点，确认 Pod Disruption Budget 与重新调度是否正常运作。建议每周执行一次。第三层是「Region/AZ 级别」：通过 NetworkChaos 阻断跨可用区通信，验证多可用区架构的故障切换。这是按季度进行的 game day 规模。
- 年的现场主流做法是：将第一、二层完全自动化（嵌入 CI pipeline），只保留第三层作为人工介入的 game day。自动化部分从 GitHub Actions 或 Tekton 调用 LitmusChaos，并与 SLO 仪表板联动，必须设置「检测到 SLO 违规时自动停止实验」的 halt 条件。
多区域故障切换的验证
对于具有多区域架构的服务而言，每年 1～2 次的「区域切换 game day」实际上已成为必须实践。方法分三步：首先将 DNS 流量从当前区域逐步切换到备用区域（10% → 50% → 100%），每个阶段确认 SLI 未恶化，如有恶化则回滚；100% 切换后，对当前区域进行有意的网络切断（NetworkChaos 的 partition），观察备用区域是否能够独立运作数小时。
this game day 中频繁发现的问题有三类：(1) 备用区域容量不足（通常处于低流量状态，HPA 上限不够）；(2) 数据库副本延迟骤增（写入集中导致副本滞后）；(3) 第三方 API 的区域限制（特定区域无法调用，或限速更严苛）。这些都是事先难以预料的问题，若不通过 game day 加以验证，只会在真实灾难中首次暴露。
日本企业的文化挑战：「计划停电」vs「生产混沌」
导入混沌工程最严重的障碍不是技术，而是文化。日本企业有「计划停电（事先告知，短时间停止服务）」的文化，但对「在正在运行的生产系统中有意注入故障」的抵触情绪非常强烈。「破坏生产系统是何等行为」这种来自管理层的反应并不罕见。
突破这一壁垒的实务策略有三点：第一，最初从「非生产环境的混沌」开始。在 Staging 环境中每天运行 PodChaos，建立在发布前验证 SLO 的文化。在能够说明「尚未在生产环境中实施」的状态下积累半年至一年的实绩。
第二，引入生产环境时，利用「现有的计划停电窗口」。在月度维护窗口内实施小规模混沌，将其定位为「计划停电的一环」。这样就无需为管理层级别的审批另开流程。
第三，将 game day 品牌化为「演训」。称其为「故障应对演训」「BCP 演习」，反而会获得质量管理部门和内部审计部门的好评。实际上，game day 可作为满足 ISO 22301（业务连续性）或 FISC 安全对策基准演练要求的依据。
成熟度与下一步
Chaos Engineering Maturity Model（Casey Rosenthal 提出，2026 年修订版）将成熟度定义为从 Level 1（临时实验）到 Level 5（生产全自动化、持续执行）的五级。日本企业大多正处于从 Level 2（在 Staging 定期实验）向 Level 3（在生产环境进行 game day）迁移的阶段。向 Level 4（生产自动实验）迁移，前提是 SLO、Error Budget、可观测性三件套已完备，且前文提及的多窗口多燃烧率已正常运转。
KGA IT 在对客户进行 SRE 成熟度诊断时，会以 6～18 个月为单位设计「混沌工程导入路线图」。突破文化壁垒的顺序，比工具选型更为重要——选择 Gremlin 还是 LitmusChaos，其实是后半段的议题。