穷举所有故障是不可能的，做混沌工程要结合真实情况进行测试，模拟接近于真实的场景。
2、开发团队不接受任何失败
开发工程师们，不接受自己开发的系统是存在故障的。
普通的开发工程师不是系统运维工程师，很多开发对于自己写的代码是具备天生的信任，殊不知一个人写的代码是OK的，一个团队写出来的代码堆在一起，马上就会发现问题。
在开发环境中（尤其是本地的开发环境），是不会主动去制造各种单机故障进行测试的，例如：FullGCpz、CPU突然飙升、其他进程突然抢占内存等等。
说白了，有些开发工程师就是不接受计划外的故障。
当测试工程师提一些预期外的Bug时，开发会说“哎呦，这算什么Bug？用户不会这样操作的，哪有人会做这么傻的操作哦？”
当你通过混沌工程实验发现了一个「在CPU高负荷运转下才会导致系统运行龟速的Bug」时，开发会说“哎呦，这个Bug太难重现了，现在生产环境的机器不会莫名CPU占用飙升的，这种百年一遇的Bug你也提？”
系统上线后，只要允许用户访问，就得包容用户的任何操作。
此时此刻你认为机器的CPU正常，那不代表这台机器以后CPU都会永远正常运行。
3、不敢在生产环境做混沌测试
这点最坑，也最冤枉。
有些公司出于各种政策或是安全性考虑，肯定不能在生产有调试、测试行为的，这个可以理解。
但有些公司没有这样的限制，可大家仍然不敢在生产环境做混沌工程实验，怕把生产环境搞乱了。
其实，混沌工程在行业里的主流畅导的做法均是在生产环境上做的。
混沌工程的五大原则，其中有一条就在强调：在生产环境中运行实验。
前面提到了，混沌工程最重要的是模拟真实的情况，如果「实验室环境」和「真实环境」不一致，那实验得出的结论也就不作准了。
所以，如果团队一门心思的想搭建一个属于自己的「实验室」环境，就会发现想跟生产环境保持一模一样是一件非常困难的事情。
4、建立专职的混沌工程团队
据了解，行业中做混沌工程实验的公司或组织中，几乎不会成立专职的混沌工程团队。而是会选择成立「临时的、项目性质的虚拟团队」来完成这项任务。
这个虚拟团队会选拔公司内资深的架构师、测试开发工程师、系统运维工程师等。
虽然混沌工程的工作性质本身有点像测试，只不过测试的对象不是某个功能、不是某个系统，而是系统架构。需要较为强大的架构知识、了解公司系统部署的实际情况、同时也得有测试的专业技能和敏锐嗅觉。
这里面首先面临的有一个问题，国内大部分测试团队在招聘时未对计算机基础知识、系统架构等多方面的知识进行考察和培训，大部分测试工程师只知其然，而不知其所以然。
混沌工程最终的目标，是帮助系统架构最终具备韧性，包括：冗余性、扩展性、不可变基础设施、避免级联事故、无状态应用。
其中避免级联事故又包括了：转移切换、幂等操作、服务降级、拒绝服务、超时机制等。
以上这么多概念，基本上都是IT团队中的架构团队才会经常接触的，普通测试工程师平时接触不到，也意识不到有这些知识可以学习。
俗话说，花半小时看透系统架构本质的人，和花一个星期都弄不清楚系统架构的人，注定拥有截然不同的命运。
5、没事搞一发混沌实验试试看
混沌工程和自动化测试的性质不同，做一次实验的成本非常大。
以接口自动化测试为例，找到相应的用例集，只要在测试环境中有Python或Java的环境就可以编写和执行了。
熟练工一般几分钟能写一个接口自动化测试脚本。
而混沌工程做一发，先得做实验可行性评估、指标设计、场景环境设计，再做实验工具选型、制定实验计划，接下来部署应用、配置参数、利用工具定点破坏，最后收集和分析日志结果，追踪问题。
一整个混沌工程团队折腾几天，系统环境还没搭建好是常有的事。
另外，从混沌工程的开展流程角度来看，一般会有6个大的步骤：先定义静态指标，创建演练计划、导入流量创建沙盘环境、实施实验计划、跟踪观察和实验总结。
可见做一次混沌工程的成本有多少。