前端里混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。
特别是近几年，业界讨论很热烈，很多公司已经开始实践。
不过，对混沌工程的理解而言，仍然存在不少的误解。本文就是来细细探讨一下混沌工程常见的五个误解。
误解 1：技术能力够强才可使用
不少人觉得，只有团队的技术能力够强，才可以使用混沌工程。不少人观察到，混沌工程是 Netflix 最先提出的，且在其他大型互联网公司被广泛使用，就得出这样一个结论：必须具有 Netflix 级别的先进技术（因此具有高度的可靠性），才能在生产系统上进行混沌工程实验。
但现实是，混沌工程的诞生是源于 Netflix 上云转型，即决定搬出数据中心并大规模迁移上云。没有云的支撑，没有云原生实践的大量投入，混沌工程无从谈起，更不会应运而生。我们现在知道，当时的 Netflix 在可用性方面，并没有什么突出的业界声誉。他们通过（安全地）对其系统进行混沌工程实验，并从中学到了有关系统行为的新知识，再将这些新知识付诸改造实践，才逐步拥有更稳定的系统，进而在可用性实践上获得了业界的瞩目。这是一个逐步积累的过程，也是一个去除技术债的过程。我们都可以从现在开始，开始实践混沌工程，累积相应的经验，有一天也能达到 Netflix 的可靠性水平。
误解 2：高度监管行业不能使用
不少人觉得，高度监管行业如银行、医疗机构等等，不应使用混沌工程，万一出问题就是大事故。对于此类公司而言，发生可用性事件的后果，肯定比 Netflix 宕机要严重得多，但这并不意味着这些公司不会发生可用性事件。这类公司其实更应该使用混沌工程来更好地了解其复杂的系统。
被誉为“金融科技黄埔军校”的 Capital One，英国史达琳银行，澳洲国家银行，美国医疗信息技术供货商（塞纳公司），美国联合健康集团都已经实施了混沌工程。这些组织已经将其作为上云转型的重要环节，同时也通过混沌工程实验来更好地了解系统本身的复杂性。
2016 年，英国史达琳银行就已经将混沌工程应用到了核心银行系统。前首席技术官格雷格·霍金斯（Greg Hawkins）谈到这段经历时提到：
从这一刻起，你知道系统再也不容易受到某类事件的伤害。看看这个决定的效果有多大吧？尤其是你能像史达琳银行尽早开始。当人们（无论技术人员还是业务人员）都能了解到服务器故障的原因时，您将朝着可视化、规范化和嵌入更多实验这个方向迈出重要的一步。
误解 3：实验性质并不安全
从根本上说，混沌工程是一种实验练习，它可以帮助您了解系统的安全边界，以及当您向这些边界漂移时，一旦跨越边界，它们就会掉下悬崖，产生破坏。系统向安全边界的漂移，往往是缘起于下面这些约束条件：
-
不确定性或竞争压力
-
资源缺乏或成本压力
-
多个相互矛盾的目标
人们开始进行大小不等的权衡措施，调和矛盾和减轻压力。这些权衡取舍开始将系统逐步地推向安全边界，但是人们很少能意识到它正在漂移。
希德尼·德克在他的《Drift into Failure》一书中，详细介绍了这种权衡和漂移，如何导致诸如此类的危险事件：
-
挑战者号航天飞机空难
-
英国石油公司深海钻油平台发生井喷爆炸
误解 4：给生产系统带来破坏
混沌工程不会给您的系统中添乱，而是能助力发现系统中本身已经存在的但未暴露的问题。这个误解主要是由于人们认为混沌工程是新的尖端技术而产生的（新东西往往不可靠）。
恰恰相反，混沌工程借鉴了一个悠久的传统形式，即使用实验来验证或驳斥人们对系统形成的先入为主的假设。每个实验都以一个假设开始，该假设解释了将变更引入系统后所期望发生的情况。对于可用性实验，这种假设的形式可以是：
在____的情况下，客户仍然可以正常使用我们的产品。
空白处要填的就是，真实世界的可用性事件。
设计精良的实验，可以根据真实世界的可用性事件发生后的结果来验证（或驳斥）这个假设。当然，还有一个特别重要的内容，和实验的可靠性息息相关，即控制爆炸半径以确保系统的安全性。这样的好处是从混沌工程实验获得更多有关复杂系统行为的新认知，而又不会使系统状况变得更糟。
误解 5：本质上就是一种测试
大多数时候，一个好的测试计划会讨论负载测试、安全性测试和负载下的功能测试。
不幸的是，我们仅在非生产环境中进行这些测试，并寄希望于该系统在生产环境中的行为与测试一致。混沌工程，则强调尽可能接近生产，推荐在生产环境中进行实验，正是解决上述问题的方法。
混沌工程和测试之间的另一个区别是，混沌工程的实验结果带来了有关系统行为的新知识，而开发人员或测试人员可能之前都不了解这些。
结束语
本文探讨了混沌工程常见的 5 种误解的根源和问题所在，希望可以引发大家的思考和讨论。
-
技术能力够强才可使用混沌工程 -
高度监管行业不能使用混沌工程 -
混沌工程具有实验性质并不安全 -
混沌工程会给生产系统带来破坏 -
混沌工程本质上就是一种测试
