混沌工程概述
大家好，我是老张。在交易系统这个行当摸爬滚打了十几年，今天咱们来聊聊混沌工程。
说实话，我第一次接触混沌工程是在2016年。那时候Netflix刚把Chaos Monkey开源出来，圈子里都在讨论。我当时的第一反应是——这帮人疯了吧？主动往生产环境里注入故障？
后来我才明白，这恰恰是最理性的做法。
混沌工程的起源
混沌工程这个概念，最早由Netflix提出。2011年，他们搞了个叫Chaos Monkey的工具，专门在随机时间杀掉生产环境里的实例。
为什么要这么干？
Netflix的架构是微服务，服务之间依赖关系复杂。你想想看，一个服务挂了，会不会引发雪崩？会不会导致整个系统不可用？
传统做法是——祈祷它别挂。但Netflix选择了另一种方式：主动让它挂，然后观察系统反应。
我个人觉得，这背后其实是一种思维转变：从「如何避免故障」变成「如何优雅地应对故障」。
核心洞察：故障不是「会不会发生」的问题，而是「什么时候发生」的问题。混沌工程就是提前演练，确保系统在故障发生时依然能正常运转。
核心原则
混沌工程不是乱搞。它有自己的方法论和原则。我总结下来，最核心的有这么几条：
1. 稳态假设
这是混沌工程的基石。说白了，就是先定义「系统正常运行时是什么样子」。
比如一个交易系统，稳态可能是：
- 订单处理延迟 < 10ms
- 成交率 > 99.9%
- 数据库连接池使用率 < 70%
然后你注入故障，观察这些指标是否偏离了稳态。如果偏离了，说明系统有问题；如果没偏离，说明系统够健壮。
我的经验：定义稳态指标时，别贪多。选3-5个最关键的就行。我曾经见过一个团队定义了20多个指标，结果实验做了一半，自己都搞不清该看哪个了。
2. 爆炸半径最小化
这个原则我特别有感触。混沌实验不是核试验，你不能把整个机房都炸了。
爆炸半径最小化，意思就是：控制故障的影响范围。
具体做法：
- 先在小范围做实验（比如1%的流量）
- 使用影子用户（不影响真实用户）
- 设置熔断机制（一旦指标异常，自动停止实验）
血的教训：我曾经在一次实验中，忘了设置熔断阈值。结果一个CPU打满的实验，直接影响了整个集群的订单处理。那天的交易量直接掉了30%。从那以后，我每次做实验前都会反复检查熔断配置。
3. 持续验证
混沌工程不是一次性的。系统在变，依赖在变，故障模式也在变。
我建议把混沌实验做成自动化流水线，每周甚至每天跑一次。就像体检一样，定期检查系统的健康状况。
与传统测试的区别
很多人问我：混沌工程和传统测试到底有啥区别？
我画了张图，你看完就明白了：
说白了，传统测试是「已知的已知」——你知道输入是什么，也知道期望输出是什么。而混沌工程是「未知的未知」——你不知道故障会以什么形式出现，也不知道系统会怎么反应。
我举个例子：
- 传统测试：测试下单接口，输入一个合法订单，期望返回成功。
- 混沌工程：突然杀掉下单服务的一个实例，看系统会不会自动切换到其他实例，用户会不会感知到异常。
你看，这是两种完全不同的思维方式。
一句话总结：传统测试问「功能对不对」，混沌工程问「挂了能不能扛」。
为什么交易系统需要混沌工程
交易系统对可用性的要求极高。你想想看，一秒几万笔订单，系统宕机一分钟，损失可能就是几百万。
而且交易系统的链路特别长：
- 客户端 -> 网关 -> 路由 -> 风控 -> 撮合 -> 清算 -> 结算
- 中间还依赖数据库、缓存、消息队列、行情源...
任何一个环节出问题，都可能导致整个交易链路中断。
我记得有一次，我们做了一次混沌实验，模拟行情源延迟。结果发现，行情延迟超过500ms时，风控模块会直接拒绝所有订单。这个bug在传统测试中根本发现不了，因为测试环境里的行情源永远是正常的。
这就是混沌工程的价值——发现那些你根本想不到的问题。
我的建议：刚开始做混沌工程，别想着一步到位。先从最核心的链路开始，比如「订单处理」这条线。把这条线跑通了，再扩展到其他模块。
好了，这一章就聊到这儿。混沌工程不是什么高深的技术，它更多的是一种思维方式——承认系统会出问题，然后主动去验证系统的应对能力。
下一章，咱们聊聊混沌工程的具体实验设计方法。
公众号:蓝海资料掘金营，微信deep3321