混沌工程杂谈

在生产环境中实际运行大型分布式系统，难免会有各种不可预料的突发和异常事件发生。一方面，随着云原生技术微服务架构的发展应用，后端系统的复杂性不断提升，另一方面，随着业务侧系统的广泛使用，用户规模和数据规模都在经历爆发式的增长，这些都给软件系统以及基础设施带来了巨大的挑战。

庞大的分布式系统天生有着各种复杂依赖，可能出错的地方不仅数不胜数，更是防不胜防，我们已经很难评估某个单点故障对整个系统的影响。同时业务和技术的迭代速度快，在这种背景下，如何持续地，有信心地保障系统的稳定性和高可用性受到了有史以来最大的挑战，如果处理不好就会导致业务受损，或者是其他各种无法预期的异常行为。

在复杂的分布式系统中，我们已经无法阻止这些故障的发生，所以我们应该致力于在这些异常行为被触发之前，尽可能多地识别它们。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。

我们知道发生故障的那一刻不是由你来选择的，而是那一刻来选择你，你能做的就是为之做好准备。为此，我们需要化被动为主动，不是等到故障发生了再去处理，而是先下手为强，通过人为的故障注入，主动来发现问题并解决问题，这就是混沌工程( Chaos Engineering）这一理念诞生的初衷。

介绍混沌工程的文章和内容其实网上比较多，我这里就不打算赘述了，我今天主要是想和你谈谈我对混沌工程的一些理解和思考，希望对你有所启发。

混沌工程是对测试底层逻辑的颠覆

从一定程度来讲，混沌工程是对传统软件测试底层逻辑的颠覆。为什么会这么说？在传统软件测试体系下，我们的本能认知告诉我们，如果被测环境有问题，我们通常会以“测试环境问题”为由而不再继续开展测试活动，等到环境问题修护后才会继续测试，也就是说测试必须在环境没有问题的情况下开展。但是，混沌工程实践却颠覆了这一本能认知，混沌工程会人为制造各种环境故障，在有故障的情况下来观察和测试系统的行为，以此发现我们之前不知道的系统新信息。

混沌工程的实施依赖对于架构的理解

混沌工程需要在系统中的各种位置注入故障，包括IaaS层、PaaS层和SaaS层等等，这就要求测试设计人员对被测系统的软件架构，包括物理架构、逻辑架构和业务架构，都需要有清楚的认知。否则根本无法有的放矢地设计出合理有效的故障注入点。这对测试人员能力也提出了更高的要求，传统基于黑盒功能测试的人员已经无法胜任。

混沌工程实验和故障注入测试之间的区别

很多人会认为混沌工程实验和故障注入测试是在讲一件事，其实两者直接还是有本质上的区别的。这种本质上的区别体现在“实验”和“测试”的差异上。

测试更多是的验证，也就是说在测试执行之前，已经对预期结果有了提前的预判，测试的目的是去验证实际情况与预判是否一致，如果一致，测试结果就是通过，如果不一致就是失败。而实验就很不一样了，在实验执行之前，我们并不知道会发生什么，实验的目的更多的是去探索未知，而不是去验证已知的结果。总结来说，测试是验证结果，实验是探索可能性。

理解了这一点，就能很好地理解混沌工程实验和故障注入测试之间的区别了，虽然两者都会涉及故障注入，但是故障注入测试的目标是去验证在故障注入场景下系统的行为是不是遵循原先的设计，而混沌工程实验则是探索在故障注入场景下的系统行为到底是啥，系统在故障情况下到底会以什么样的形式表现出来，我们在实施混沌工程试验前，这些信息都是未知的。

混沌工程和搞破坏的区别

对于混沌工程有了初步的认识后，很多人会把混沌工程和搞破坏画上等号，其实这两之间也是有本质区别的。为了便于你的理解，我先来问你几个问题让你思考一下：

• “随机拔IDC机房中某些服务器的电源”这一行为是混沌工程还是搞破坏？

• “把整个IDC机房的路由器网线拔了”这一行为是混沌工程还是搞破坏？

• “随机停掉应用集群中的一些实例”这一行为是混沌工程还是搞破坏？

• “直接停掉某一功能的整个应用集群”这一行为是混沌工程还是搞破坏？

• ...

是不是感觉被我问懵了呀？其实区分混沌工程和搞破坏的标准只有一个，那就是做这一故障注入行为执行后的不良后果是不是已知的，如果是完全已知的，那这个行为就是在搞破坏，如果是不确定的，那这个行为可就是混沌工程。

怎么来理解这个概念呢，拿上面的问题举个例子你就懂了。

对于“把整个IDC机房的路由器网线拔了”这一行为，如果你确切知道拔了之后的后果，那就是在搞破坏，如果你不知道确定的后果，比如IDC本身是有两地三中心的HA设计的，那拔了之后我们想观察业务是否能够顺利做迁移，迁移过程中的影响有哪些，那么这就是混沌工程。

混沌工程在生产环境实施的必要性

虽然最早的混沌工程实践是在生产环境实施的，而且Netflix也倡导在真实的生产环境中实施混沌工程，但是我个人对于这一观点持保留态度。

早年的测试环境和生产环境之间的差异比较大，主要体现在物理拓扑、网络环境、集群规模和数据规模等方面，这样的差异使得在测试环境中模拟的IaaS层和PaaS层故障对真实生产环境的参考价值比较有限，所以那时我们都希望直接在生产环境实施混沌实验。

但是在今天，云原生架构的普及已经使得测试环境和生产环境在IaaS层和PaaS层的差异很小，所以在测试环境开展混沌实验的参考价值是有保证的，毕竟在生产环境实施会有较大的业务风险。

另外，对于SaaS层，也就是从业务领域来看，由于测试环境和生产环境的业务逻辑基本是完全一致的，所以业务逻辑故障的模拟就完全没有必要在生产环境中开展了，这样不仅实施风险更低，而且能够探索的方向也会更广，另外，还可以发布之前更早地开展混沌实验。

混沌工程自动化的必要性

随着混沌实验在软件企业普及程度不断变高，混沌工程自动化的概念也被提了出来，但是我认为就实验本身而言，实现自动化的必要性比较有限，原因有以下几点：

1. 每次实验都有其特殊性，带有探索的性质，其核心价值在于发现系统新的信息，识别薄弱环节，这些都大量依赖于人的判断与能力，因此自动化回归执行的价值就非常有限，

2. 混沌实验发现的问题在被解决之后，很长的时间里面具有“免疫性”，只要架构和设计没有大的变革，往往不需要每次发布后都回归混沌实验，这样混沌工程自动化也就没啥用处了。

3. 混沌实验的数量一般很多，往往会涉及在IaaS层、PaaS层和SaaS层大量的故障注入，所以每次发布并不会实施所有的混沌实验，而是分批逐渐开展的，每次发布可能只涉及其中一部分故障注入，这次做过的实验下次没必要重复去做，不像自动化功能测试用例是像滚雪球一样越来越多的，所以混沌工程自动化的述求不会很强。

当然，对于构造故障的工具，如果自动化程度能够做的比较好，这对于混沌实验的便利程度来讲还是很有帮助的。

混沌工程的核心是各个层级故障变量的收集

混沌工程的理念并不复杂，实施的原则也很清晰，所以要想把混沌工程的价值最大程度发挥的关键在于：各种故障变量的收集，能够把各种可能的故障和异常都想到。用通俗的话来讲就是“不怕你做不到，就怕你想不到”，我们要努力缩小团队的“Unknow unknow”。所以一个系统的故障变量收集不能仅仅依赖自身系统发生问题的积累，而是要“博采众长”，把历史上出现过的各类故障和异常进行分类收集，并形成故障变量图谱，这才是有效实施混沌工程的关键。