一句话定义：混沌工程（Chaos Engineering）是有计划地往生产系统里注入故障——断网、超时、杀掉某个服务、把模型接口拖慢——用来验证系统在真实异常下还能不能正常工作的一门实践。
为什么需要它
传统测试的思路是"我先假设会出什么错，再写用例去验证"。问题是，人只能想到自己想到的错。真实故障往往来自几个"小毛病"的叠加：某个依赖变慢、重试放大流量、缓存雪崩，最后一发不可收拾。
混沌工程换个方向：不猜故障，直接制造故障，看系统怎么反应。
打个比方。消防演练不会真的等你家着火才第一次跑流程，而是主动拉响警报、模拟浓烟、封掉一部电梯，看疏散要多久、哪条通道会堵、谁不知道该往哪走。混沌工程就是给线上系统做消防演练——只不过放的不是烟，是真实的故障。
在 AI 服务里，它长什么样
AI 系统比传统后端多了一批独有环节，也就多了一批独有故障：
- 模型推理接口延迟从 200ms 变成 5s，上游还傻等吗？
- 某个模型供应商限流或返回 5xx，有没有降级到备用模型或规则兜底？
- 检索（RAG）里的向量库挂掉，是直接报错，还是转成"无检索直接回答"？
- 输入被塞进超长文本、异常字符、乱码，服务会不会直接崩？
- GPU 显存被占满，调度层是把请求排队，还是雪崩式全部失败？
这些问题只有真跑一遍才知道答案。所以混沌实验通常遵循一个循环：先定义"稳态指标"（比如成功率、P95 延迟、业务转化），再提出假设"如果模型接口延迟翻十倍，成功率仍应高于某个阈值"，然后注入故障、观察指标、决定要不要修。
和相邻概念的区别
| 概念 | 何时做 | 目的 | 典型做法 |
|---|---|---|---|
| 单元/集成测试 | 开发阶段 | 验证功能对不对 | mock 掉外部依赖 |
| 故障注入（Fault Injection） | 测试环境为主 | 制造某个具体错误 | 改代码、加代理 |
| 混沌工程 | 接近生产的环境甚至生产 | 验证系统在真实异常下的整体行为 | 有假设、有爆炸半径控制、可随时中止 |
| 可观测性 | 贯穿始终 | 让你看得见发生了什么 | 日志、指标、链路追踪 |
关键差别在"假设驱动"和"爆炸半径"。混沌工程不是乱砸，每次只影响一小部分流量、一小部分实例，并且随时能一键停止。没有可观测性的混沌实验等于蒙眼拆弹，所以它通常和监控告警一起建设。
对从业者的实际意义
对架构和运维同学，混沌工程是把"我们以为很健壮"变成"我们知道哪里会断"。它不是找谁的锅，而是提前把故障成本从"用户投诉时的紧急救火"挪到"工作日下午的可控演练"。
对做 AI 产品的普通职场人，它给的是一个承诺的边界：你答应用户"99% 可用"，这个数字得经得起上游模型抖动、依赖超时的考验。上线前问一句"如果模型挂了会怎样"，比事后写复盘便宜得多。
具体工具怎么部署、参数怎么配，各家方案差别很大，以官方文档为准。