混沌工程应该是最近几年行业里流行的新概念，是很多大厂、很多测试行业大会中热门学科。有趣的是，几年下来，混沌工程这个话题一直温度不降，并像AI测试、精准测试那样，在行业内大放异彩。
为什么「混沌工程」会火起来？我认为原因有二：
1、技术发展快
随着互联网业务发展，微服务架构、分布式架构和虚拟化容器技术的广泛普及，软件架构的复杂度在不断提升，已经远远超过了我们这批「老程序员」的技术认知。
但这样的大规模架构有个缺点，那就是「定位问题」较难，定位问题的成本越来越高，所以，才有了混沌工程现在的江湖地位。
2、开源工具多
在混沌工程的生态里，有诸多开源工具挺好用的：
chaosblade：阿里开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力。
Simoorg：开源故障诱导程序，LinkedIn使用这个程序进行混沌工程实验。
Monkey-Ops：在 Go 中实现并构建的开源工具，用于测试和终止随机组件和部署配置。
Gremlin：一个混沌的工程项目，与AWS和Kubernetes合作，专注于零售和金融行业。它附带了内置冗余，在混沌工程实验威胁系统时阻止它们。
最终，随着开源工具越来越多，帮助大家减少了很多实验的学习和执行成本。
今天，我也来凑凑热点，粗浅地谈一谈如何用「混沌工程」搞垮一个团队。
经济学家刘润曾经讲过这样一个知识点：「真正的洞察力，可以始于相关性，但终于因果链」。
混沌工程实验就是帮助测试工程师增加洞察力的有力方式。
举个栗子：
公司某系统在生产环境中运行的好好的，突然因为一些因素导致了生产问题，为公司造成了很多损失。
这时，老板生气地问，「测试工程师为什么没有提前测出来？」
测试工程师也很冤枉，「老板，我们测试又不是神仙，没办法预知未来啊！」
假如，如果，倘若，譬如，若是……，你曾经参与并对系统做过「混沌工程实验」，那就是完全不一样的两个场景。
你会理直气壮地说，「老板，我们提前预知了这个问题。导致这种问题的原因是因为机器磁盘满了，而机器磁盘满了是因为系统的日志没有定时备份和清理的机制，我们曾经发过混沌工程实验报告，报告中重点提到了这个问题，他们那帮开发根本没把这个问题当回事啊！」
你看，在这种情况下，混沌工程是不是很有用？
什么是混沌测试？
从混乱的猴子开始，Netflix（奈飞公司）为应对不确定性的领域带来了一种全新的思维方式--主动出击。
这种主动出击的思维方式衍生出的一套实践方法，被称为混沌工程（Chaos Engineering），它旨在从根本上改变开发者应对软件缺陷和故障的思维方式。
在此之前，我们期望通过一系列的测试验证手段，尽最大的可能确保在线上运行的系统没有缺陷和故障。而混沌工程的理念认为这既不现实，也不符合系统自然发展的规律。混沌工程提倡我们首先要正面接受系统一定会存在缺陷，并且一定会时不时地发生故障的事实；然后，要求我们通过一些列实验找出可能发生问题的风险点，进而在不断加固系统的同时，促使开发者在开发软件时必须选择将防御性内建在系统中。
说白了，混沌测试和常规测试的区别在于：
常规测试：我等系统开发出来，我再做测试执行，然后我发现Bug来证明你的系统不完善。（属于被动挨打，在需求或系统的条件下开展测试）
混沌测试：系统在各种异常状态下，肯定是存在缺陷的，我要通过实验证明这一点。（属于主动出击，属于技术性质的探索测试）
混沌测试的优势
这块内容就不写太多了，因为混沌工程至少拥有三大优势：找到系统中的盲点、隐藏的错误和性能瓶颈。
混沌测试的限制
你在百度搜索「混沌工程」，大部分的文章都在告诉你混沌工程有多么多好，多么多么优秀，但很少有文章提醒你事物的两面性：有优点，就有缺点。
缺点1：门槛高
门槛太高。
如果你公司内成立了混沌工程的虚拟团队，这个团队一般都是由你们公司的「技术大牛」、「IT架构大佬」、「测试开发专家」组成的。不要说测试工程师了，就连普通的高级开发工程师都没办法入他们的法眼，原因就一个，技术不达标，教起来太累。
缺点2：成本高
成本太高。
要在生产环境做混沌工程实验，这不是开玩笑的，弄不好要丢掉饭碗的。
而且那么多大佬组成的「虚拟团队」，每天白花花的银子花着，老板的心在滴血。
虽然有诸多缺点，但并不会让混沌工程失去也非常依赖实验覆盖的广度与深度，广度越广，深度越深，暴露出系统架构层面的脆弱点才会越多，让整个团队对系统的信心也会越足。
— 用混沌工程搞垮团队的5种方法 —
1、尝试穷举所有的故障
由于我们人类日常的思维都是惯性思维，很少有逆向思维的场景，这就导致了工作中很多需求之外的异常情况我们不会主动去思考，例如：
系统网络永远是正常的
网络绝对不会有延迟
带宽是无上限的，不会被挤占
网络也是安全的
网络拓扑永远不会改变
系统管理员都是经过专业培训的，不会误操作
机房永远不会断电
机房的机器也不会宕机
Docker是完美的
机器上的磁盘空间很大，不会满
我写的代码不会有Bug
……
还有很多很多，如果列举一条马云能给我100元的奖励，我能写到马云破产。
但上述大多问题，一家IT公司从创立到破产，说不定都遇不到1次，那么问题来了，到底哪些实验故障需模拟、哪些故障不需要模拟呢？
穷举所有故障是不可能的，做混沌工程要结合真实情况进行测试，模拟接近于真实的场景。
2、开发团队不接受任何失败
开发工程师们，不接受自己开发的系统是存在故障的。
普通的开发工程师不是系统运维工程师，很多开发对于自己写的代码是具备天生的信任，殊不知一个人写的代码是OK的，一个团队写出来的代码堆在一起，马上就会发现问题。
在开发环境中（尤其是本地的开发环境），是不会主动去制造各种单机故障进行测试的，例如：FullGCpz、CPU突然飙升、其他进程突然抢占内存等等。
说白了，有些开发工程师就是不接受计划外的故障。
当测试工程师提一些「预期外」的Bug时，开发会说「哎呦，这算什么Bug？用户不会这样操作的，哪有人会做这么傻的操作哦」
当你通过混沌工程实验发现了一个「在CPU高负荷运转下才会导致系统运行龟速的Bug」时，开发会说「哎呦，这个Bug太难重现了，现在生产环境的机器不会莫名CPU占用飙升的，这种百年一遇的Bug你也提？」
系统上线后，只要允许用户访问，就得包容用户的任何操作。
此时此刻你认为机器的CPU正常，那不代表这台机器以后CPU都会永远正常运行。
3、不敢在生产环境做混沌测试
这点最坑，也最冤枉。
有些公司出于各种政策或是安全性考虑，肯定不能在生产有调试、测试行为的，这个可以理解。
但有些公司没有这样的限制，可大家仍然不敢在生产环境做混沌工程实验，怕把生产环境搞乱了。
其实，混沌工程在行业里的主流畅导的做法均是在「生产环境上做」的。
混沌工程的五大原则，其中有一条就在强调：「在生产环境中运行实验」。
前面提到了，混沌工程最重要的是模拟真实的情况，如果「实验室环境」和「真实环境」不一致，那实验得出的结论也就不作准了。
所以，如果团队一门心思的想搭建一个属于自己的「实验室」环境，就会发现想跟生产环境保持一模一样是一件非常困难的事情。
4、建立专职的混沌工程团队
据了解，行业中做混沌工程实验的公司或组织中，几乎不会成立专职的混沌工程团队。而是会选择成立「临时的、项目性质的虚拟团队」来完成这项任务。
这个虚拟团队会选拔公司内资深的架构师、测试开发工程师、系统运维工程师等。
虽然混沌工程的工作性质本身有点像测试，只不过测试的对象不是某个功能、不是某个系统，而是系统架构。需要较为强大的架构知识、了解公司系统部署的实际情况、同时也得有测试的专业技能和敏锐嗅觉。
这里面首先面临的有一个问题，国内大部分测试团队在招聘时未对计算机基础知识、系统架构等多方面的知识进行考察和培训，大部分测试工程师只知其然，而不知其所以然。
混沌工程最终的目标，是帮助系统架构最终具备韧性，包括：冗余性、扩展性、不可变基础设施、避免级联事故、无状态应用。
其中避免级联事故又包括了：转移切换、幂等操作、服务降级、拒绝服务、超时机制等。
以上这么多概念，基本上都是IT团队中的架构团队才会经常接触的，普通测试工程师平时接触不到，也意识不到有这些知识可以学习。
俗话说，花半小时看透系统架构本质的人，和花一个星期都弄不清楚系统架构的人，注定拥有截然不同的命运。
5、没事搞一发混沌实验试试看
混沌工程和自动化测试的性质不同，做一次实验的成本非常大。
以接口自动化测试为例，找到相应的用例集，只要在测试环境中有Python或Java的环境就可以编写和执行了。
熟练工一般几分钟能写一个接口自动化测试脚本。
而混沌工程做一发，先得做实验可行性评估、指标设计、场景环境设计，再做实验工具选型、制定实验计划，接下来部署应用、配置参数、利用工具定点破坏，最后收集和分析日志结果，追踪问题。
一整个混沌工程团队折腾几天，系统环境还没搭建好是常有的事。
另外，从混沌工程的开展流程角度来看，一般会有6个大的步骤：先定义静态指标，创建演练计划、导入流量创建沙盘环境、实施实验计划、跟踪观察和实验总结。
可见做一次混沌工程的成本有多少。
我们这个文章的系列属于搞垮系列，其实混沌工程才是真正意义上的搞垮，搞垮开发们写出来的系统。
— 本公众号的搞垮系列 —
职场老炮如何搞垮一个团队（六）
如何用自动化测试搞垮团队（七）
原文作者：茹炳晟聊软件研发；如有侵权，请联系管理员删除。
