混沌工程：让系统在“自我破坏”中，慢慢长出免疫力

大家好，我是 Echo_Wish。
一个写过代码、背过 on-call、也亲手“搞挂过自己系统”的工程老兵。

今天这个话题，乍一看有点吓人——混沌工程。

很多人第一次听到这个词，反应都差不多：

「啥？
好好的系统不跑，你还主动去搞破坏？」

我一开始也是这么想的。
但后来经历了几次 凌晨事故 + 全员救火 之后，我才慢慢意识到一句话：

系统不是被“搞坏”的，
而是被“你以为它没问题”害死的。

一、为什么混沌工程不是“作死”，而是“续命”？

咱们先把话说清楚。

1️⃣ 真实世界，本来就是混沌的

你想象中的生产环境是这样的：

• 网络稳定
• 机器健康
• 依赖永远在线

但真实世界是：

• 网络抖一下
• JVM 突然 Full GC
• 下游服务 5% 超时
• 某台机器磁盘满了

问题不是“会不会出事”，而是“什么时候出事”。

混沌工程要做的，不是制造灾难，
而是把“未知的灾难”，提前变成“可控的练习”。

2️⃣ 不做混沌工程，你只是“运气好”

很多团队会说：

「我们系统挺稳定的，没出过大事故。」

这句话我听过太多次了。

但你仔细想一句话就够了：

如果现在随机 kill 掉一台核心节点，
你敢不敢打包票说：
服务还能稳稳地活着？

如果你不敢，那不是系统强，
只是 还没轮到你倒霉。

二、混沌工程，到底“混沌”在哪？

别被名字吓到，其实它非常朴素。

一句话总结：

在可控范围内，
主动注入故障，
验证系统是否符合你的预期。

常见的“破坏方式”，一点都不玄学：

• 🔥 杀进程 / 杀 Pod
• 🌐 增加网络延迟
• ⛔ 模拟依赖不可用
• 💾 制造 CPU / 内存压力

这些事情，生产环境迟早都会遇到。

混沌工程只是说：

那不如我们 自己先来一遍。

三、从一个最简单的例子说起：杀实例

假设你有一个很常见的微服务部署：

• 服务 A
• 3 个实例
• 前面有负载均衡

你心里默认的假设是：

「死一台，另外两台能顶住。」

那咱们别猜，直接试。

1️⃣ 最朴素的混沌实验（Kubernetes）

kubectl delete pod service-a-xxxx

就这么简单。

然后你要盯三件事：

1. 请求有没有失败？
2. 延迟有没有明显抖动？
3. 自动拉起是不是够快？

如果你发现：

• 接口大量 5xx
• 重试风暴
• 告警狂响

那说明一件事：

你之前的“高可用”，
只是写在 PPT 里。

四、真正有价值的混沌，不是“搞破坏”，是“验证假设”

混沌工程的核心不是动作，而是 假设。

一个标准的混沌工程思路是这样的：

1. 系统在正常情况下的稳态指标

   • QPS
   • 延迟
   • 错误率

2. 提出一个假设

   • 「单节点故障不会影响整体 SLA」

3. 注入故障

4. 观察结果

5. 总结 & 修复

你看，它本质上是一个 工程实验。

五、再进阶一点：网络延迟，才是分布式系统的噩梦

很多系统：

• 不怕宕机
• 怕的是 慢

你可以用 tc 模拟网络延迟：

tc qdisc add dev eth0 root netem delay 200ms

这 200ms，会暴露出一堆平时看不到的问题：

• 同步调用链过长
• 超时配置不合理
• 线程池被慢请求占满

我见过太多系统：

「服务没挂，但全站卡死。」

混沌工程干的，就是把这种“亚健康状态”拉到台前。

六、混沌工程最怕的一件事：没“兜底”

这里我要重点说一句掏心窝子的。

没有兜底机制的混沌工程，
不是工程，是事故制造机。

在你动手之前，至少要有：

• 限流
• 熔断
• 超时
• 回滚方案

否则你不是在做实验，
而是在 赌命。

七、我自己踩过的一个坑

说个我自己的经历。

有一次我们做混沌实验：

• 模拟数据库连接超时
• 以为服务能优雅降级

结果现实是：

• 降级逻辑里又调了另一个服务
• 另一个服务也依赖同一个数据库
• 最终全链路雪崩

那次之后我学到一句话：

降级逻辑，也要参与混沌测试。

否则你永远不知道：
“救命方案，会不会先把你送走。”

八、混沌工程不是工具，是一种“工程心态”

最后我想说点不那么技术的。

混沌工程真正改变的，是团队的认知：

• 不再迷信“理论可用性”
• 开始正视“不完美是常态”
• 接受系统需要“训练”

就像人一样：

不经历风雨，
你永远不知道自己能不能扛。

最后一句话，送给正在做系统的人

混沌工程不是为了制造恐慌，
而是为了在真正的事故来之前，
你已经见过它。

系统不会因为你祈祷就稳定，
但会因为你不断“演练失败”，
而越来越强。