混沌工程：主动发现系统弱点
概述 传统的可靠性保障思路是"尽量不出故障"——加监控、加告警、加冗余。但这种被动防御有一个根本缺陷：你不知道系统在故障发生时的真实表现，直到故障真正发生。 混沌工程反其道而行之：主动、可控地注入故障，在故障变成事故之前发现系统的弱点。 它不是搞破坏，而是一种科学的实验方法——提出假设（“系统应该能承受某节点故障”），设计实验（杀掉一个节点），验证假设（服务是否仍然正常），发现弱点（如果服务异常了）。 Netflix 的 Chaos Monkey 开创了这一领域，如今混沌工程已经成为 SRE 体系的重要组成部分。从原理、实验设计、爆炸半径控制、Kubernetes 实战到常态化实践，详细梳理如何把混沌工程从"概念"落地为"日常实践"。 关于混沌工程的原则，可参考 Principles of Chaos Engineering 和 Chaos Engineering Book。 一、混沌工程的原理 核心思想 混沌工程的核心思想是： 在正常流量期间，通过有意注入故障来验证系统的弹性，从而在故障变成事故之前发现并修复弱点。 这与传统的测试有本质区别： 维度 传统测试 混沌工程 目标 验证"代码是否正确" 验证"系统是否能承受故障" 环境 测试环境 生产环境（或接近生产的预发环境） 故障来源 预定义的测试用例 真实模拟的故障场景 发现时机 开发阶段 运行阶段 关注点 功能正确性 系统弹性 为什么要在生产环境做 混沌工程最反直觉的一点是"在生产环境注入故障"。为什么不 在测试环境做？ 测试环境无法复制生产的复杂性：生产环境的流量模式、数据量、网络拓扑、依赖关系与测试环境完全不同 测试环境的故障不会造成真实影响：没有压力，就不会暴露在压力下才出现的问题 只有在生产环境才能验证完整的恢复链路：告警是否触发？On-Call 是否响应？自动恢复是否生效？ 当然，直接在生产环境做混沌实验需要严格的控制——这正是"爆炸半径控制"要解决的问题。 混沌工程的四条原则 根据 Principles of Chaos Engineering，混沌工程遵循以下原则： 围绕稳态行为定义"正常"：先定义系统的正常状态（SLI/SLO），再注入故障看是否偏离 假设稳态在对照组和实验组中都保持：一部分流量/节点不注入故障（对照组），一部分注入（实验组），对比差异 在真实环境中实验：生产环境或接近生产的环境 自动化持续运行：不是一次性实验，而是持续自动化运行 混沌工程的收益 chaos_engineering_benefits: direct_benefits: - "提前发现系统弱点和单点故障" - "验证告警和恢复机制是否有效" - "提升团队对故障的响应能力" - "验证架构设计假设是否成立" indirect_benefits: - "建立团队对系统弹性的信心" - "驱动架构改进（从'看起来能扛'到'验证过能扛'）" - "减少真实故障的 MTTR（因为已经演练过类似场景）" - "培养'故障不可避免'的工程文化" 二、从 Chaos Monkey 说起 Netflix 的混沌工程演进 Netflix 是混沌工程的开创者，其演进路径值得参考：...