每个软件从业者从写下第一行代码开始，就一刻不停地在和软件中的错误做斗争。
近年来，随着系统架构逐渐向微服务架构演化，开发效率以及系统扩展性大幅提高。但同时，系统的复杂性也随之提高，传统的测试方法已经不能全面理解和覆盖系统所有可能的行为，测试的有效性被大打折扣。我们通过各种测试、SRE、DevOps、金丝雀发布、蓝绿部署、预案、故障演练等方法，希望能够防患于未然。但服务规模不断增长，服务之间的依赖性所带来的不确定性也呈指数级增长。在这样的服务调用网中，任何一环出现的正常或异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。
软件系统自身复杂度的激增、开发者在引入复杂性的同时对风险的低估和忽视，是系统可用性面临的两大挑战。
为了应对这两大挑战，Netflix 选择了一条不同寻常的路。
2008年Netflix开始将服务从数据中心迁移到云上，之后就开始尝试在生产环境中开展一些系统弹性的测试。过了一段时间，这个实践过程才被称为混沌工程。最早被大家熟知的是“混乱猴子”（Chaos Monkey），因为其在生产环境中随机关闭服务节点而“恶名远扬”。进化成为“混乱金刚”（Chaos Kong）之后，这些之前获得的小规模益处被扩大到非常大。规模的扩大得益于一个叫作“故障注入测试”（Fault Injection Test，FIT）的工具。
随后确立了混沌工程的若干原则，用于将这个实践进行规范并学科化，同时推出了混沌工程自动化平台，使得混沌工程实验能够在微服务体系架构上7×24小时不间断地自动运行。
从混乱猴子开始，Netflix 为应对不确定性的领域带来了一种全新的思维方式——主动出击。这种主动出击的思维方式衍生出的一套实践方法，就是混沌工程，它旨在从根本上改变开发者应对软件缺陷和故障的思维方式。
在此之前，我们期望通过一系列的测试验证手段，尽最大的可能确保在线上运行的系统没有缺陷和故障。而混沌工程的理念认为这既不现实，也不符合系统自然发展的规律。混沌工程提倡我们首先要正面接受系统一定会存在缺陷，并且一定会时不时地发生故障的事实；然后，要求我们通过一系列实验找出可能发生问题的风险点，进而在不断加固系统的同时，促使开发者在开发软件时必须选择将防御性内建在系统中。
“混乱”一词让我们想起随机性和无序性。然而，这并不意味着混沌工程的实施也是随机和随意的，也不意味着混沌工程师的工作就是引发混乱。让系统在每一次失败中获益，然后不断进化，这是混沌工程的核心思想。
在实践中，混沌工程提倡用一系列实验来真实地验证系统在各类故障场景下的表现，通过频繁地进行大量实验，既使得系统本身的反脆弱性持续增强，也让开发者对系统越来越有信心。因为在每天自动运行的大量实验下，开发者不得不在编码时思考“我的代码如何在这些混沌实验场景下存活下来”，并逐步提高质量，形成正向循环。
混沌工程非常适合用于暴露生产系统中未知的脆弱环节，但如果你很确定一个混沌工程实验会导致系统出现严重的故障，那么进行这样的实验是没有任何意义的。你需要先解决这个问题，然后再回到混沌工程，在进行混沌工程实验之后，你要么能继续发现更多未知的脆弱点，要么能对系统真实的弹性水平更有信心。
另外，你需要用配套监控系统来判断系统当前的各项状态。如果无法对系统行为进行观察，你就无法从实验中得出有效的结论。
你可以将混沌工程视为一种解决“我们的系统离混乱边缘有多少距离”的经验方法。从另一个角度去思考，“如果我们把混乱注入系统，它会怎么样？”
减少问题的最好方法就是让问题经常性地发生，通过不断重复失败过程并找出解决方案，来持续提升系统的容错能力和弹性。混沌工程作为一门新兴学科，还处于一个定义和被定义的过程。如果你对混沌工程感兴趣，愿意去了解和实践混沌工程，非常推荐你从《混沌工程：Netflix系统稳定性之道》一书开始行动。
