只要你有过在生产环境中实际运行过分布式系统的经历，你就应该清楚，各种不可预期的突发事件一定会发生。分布式系统天生包含大量的交互、依赖点，可以出错的地方数不胜数。硬盘故障、网络不通、流量激增压垮某些组件，我们可以一直列举下去。这都是每天要面临的常事儿，处理不好就会导致业务停滞，性能低下，或者是其他各种无法预期的异常行为。
在复杂的分布式系统中，人力并不能够阻止这些故障的发生，我们应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的，在系统中脆弱的，易出故障的环节。当我们识别出这些风险，我们就可以有针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性（弹性：系统应对故障、从故障中恢复的能力）系统的同时，树立运行高可用分布式系统的信心。
混沌工程正是这样一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实证的验证方法显然可以为我们打造更具弹性的系统，同时让我们更透彻的掌握系统运行时的各种行为规律。
实践混沌工程可以简单如在 STG 环境的某个实例上运行 kill -9 来模拟一个服务节点的突然宕机，也可以复杂到在线上挑选一小部分（但足够代表性）的流量，按一定规则或频率自动运行一系列实验。
混沌工程的前提条件
在判断你的组织是否已经准备好实施混沌工程之前，需要回答这样一个问题：你的系统是否已经具备一些弹性来应对真实环境中的一些异常事件，像某个服务异常、或网络闪断、或瞬间延迟提高这样的事件。
如果你的答案是明确的“No”，那么在实施本书中讨论的各项原则之前，你需要先做一些准备工作。混沌工程非常适合于揭示生产系统中未知的脆弱环节，但如果你很确定混沌工程实验会导致系统出现严重的故障，那运行这样的实验是没有任何意义的。你需要先解决这个问题，然后再回到混沌工程，然后你不仅能继续发现更多不知道的脆弱点，还能提高对系统真实弹性水平的信心。
混沌工程的另一个前提条件是监控系统，你需要用它来判断系统当前的各项状态。如果没有对系统行为的可见能力，就无法从实验中得出有效的结论。由于每个系统都是独一无二的，对于如何针对混沌工程揭示出的脆弱环节进行根本原因分析，我们留给读者作为练习。