初识混沌工程（上）

混沌工程（Chaos Engineering）是什么，你一定听说过那只捣乱猴子的故事（如图1），今天我们来聊聊。

有没有这种感觉，当你写下第一行代码的时候，后面等着你的就是不断和系统中的各种错误做斗争？年纪大了，老是害怕在平时的工作中出各种各样五颜六色的问题，一出问题就整宿的加班通宵，熬到六亲不认，枸杞当饭吃。就好像写的代码会跳出来嘲讽你一样：百因必有果，你的报应就是我。

那如果想要减少问题，只能让问题更多频次地暴露出来，然后各种揪头发，通过不断地重演，找到具体的问题并干掉它。琢磨可靠的解决方案，持续提升系统的容错灾备能力和弹性空间。

在最近几年，很多公司的系统架构逐渐向微服务架构演化，这对系统的扩展性要求更高了，同时也造成系统的复杂度急剧上升，导致系统的不确定性也随之增长。假如我们要进行如下的这些线上实验：模拟整个机房IDC宕机、选择一部分网络连连接注入特定时间的延迟、随机让一些函数抛出异常、强制 NTP 时间不同步、生成网络或者磁盘 IO 错误、榨干机器资源（比如CPU、内存等）等，这些试验到底会有什么样的结果，有些我们可以预料，但有些可能我们无法预料，这时候，你需要了解“混沌工程”。

1. 混沌工程

混沌工程（Chaos Engineering），不难理解，最初由 Netflix 提出的想从根本上去改变人们对软件系统缺陷和出现故障的不同视角和思维方式。它希望我们不要逃离现实，需要遵循自然发展的规律去看待现实中的问题。

就好比你们家孩子，到了读中学时，百分百会出现叛逆，那你首先需要的是正确去看待一个孩子的成长，知道这是必然的，然后给予更多的关怀和疏导，不断调整自己的教育方式，而不是一味地打压或者求神拜佛让菩萨保佑他/她不要叛逆。

混沌工程亦可理解为一套基于在原有系统基础设施上去进行反复试错，最终找出系统中存在风险的方法学。由于开发者的能力和认知水平也有边界，不可能所有的细节都可以预估到，系统很脆弱，各种潜在不可预期的突发事件在所难免，我们需要在异常触发之前，尽可能地去筛选出会导致出现有异常问题的、容易造成故障的、系统中明显裂痕的环节。然后进行及时修复、加固和防患于未然，才能打造更具弹性的软件工程系统。

混沌工程是软件测试吗？

测试只能让我们通过最终呈现得知这个结果是否我们预期的，要么正确，要么错误。它不能让我们去探求一些新的未知方向，或者蹦出一些我们始料未及的惊喜。而混沌工程却是我们想要的这一朵奇花，它能帮助我们获取更多、更接地气的认知维度在系统中如何采用新视角去进行实验。

混沌工程，还可看作一门改善、改进复杂系统工程的学科。

很多行业都在不断挖掘其立足点，包括了医疗、保险、金融、农业、航天航空制造等等领域，都是非常值得期待的。

拒绝盲目开展实施混沌工程。

回到上面的解释中，可以知道混沌工程其实更推荐使用在用于暴露生产系统中未知的隐患环节。如果说，你明知道它有问题，你还使用混沌工程的话，将毫无意义。所以，我们有一个前提：你的系统需要具备一定的弹性来面对现实中的一些异常情况，比如服务器异常、网络抖动闪断或流量激增等等。

2. 应对复杂场景

一般我们在系统优化工作上，都会针对性能提升、高可用性和容错能力这三点。但有时候，我们又非常期待高效的新功能开发速度。在架构选型过程中，需要综合考虑到各方面，找到平衡支点。

比如，现在大家喜欢用的微服务架构，确实是方便了小团队之间的松散耦合协作，但需要更高成本的有效沟通为代价。微服务相对提升了开发速度和灵活性，但某种程度上削弱了我们对系统的可掌控度和可理解度。

这里的不足，刚好给混沌工程一个光明的未来。混沌工程通过适时地验证系统弹性，拿到反馈之后，我们可以更好去快速开发新的功能和更多新的实验，让我们整个团队对系统会有更轻松、高效地状态凝聚一起。

很多系统都是慢慢从简单到复杂的，从单一的服务中你也许找不到具体问题，因为它们看起来都是非常合理的，只有在某些特殊的情景下组合起来之后，才会暴露我们意想不到的问题，非我们可以预测的，就跟预测地震一样，很难。在混沌工程中，可以通过一些方式、工具来让潜在的问题、效应浮出水面。我们应要心怀敬畏，前面虽然充满各种未知、也有可能是我们认知之外的东西，不过有混沌工程的陪伴，我们一样能奋力前行。