每个系统，从简单到复杂，只要运行时间足够长，都会受到不可预测的事件和条件的影响。例如负载的增加、硬件故障、软件缺陷、还有非法数据（有时称为脏数据）的引入。我们无法穷举所有可能的事件或条件，但常见的有以下几类：
- 硬件故障；
- 功能缺陷；
- 状态转换异常（例如发送方和接收方的状态不一致）；
- 网络延迟或隔离；
- 上行或下行输入的大幅波动以及重试风暴；
- 资源耗尽；
- 服务之间的不正常的或者预料之外的组合调用；
- 拜占庭故障（例如性能差或有异常的节点发出有错误的响应、异常的行为、对调用者随机返回不同的响应，等- 等）；
- 资源竞争条件；
- 下游依赖故障。
也许最复杂的情况是上述事件的各类组合导致系统发生异常行为。
要彻底阻止对可用性的各种威胁是不可能的，但是我们可以尽可能减轻这些威胁。在决定引入哪些事件时，我们应当估算这些事件发生的频率和影响范围，然后权衡引入他们的成本和复杂度。在 Netflix，我们选择关闭节点的一方面原因就是，节点中断在现实中发生频率很高，同时引入关闭事件的成本和难度很低。对于区域故障来说，即使引入的成本高昂且复杂，我们还是必须要做，因为区域性故障对用户的影响是巨大的，除非有足够的弹性应对它。
文化因素也是一种成本，例如对于传统数据中心来说，健壮性、稳定性、变更的严格控制，在文化上要优先于敏捷性——随机关闭节点类型的实验对传统数据中心文化上是一种挑战。随着迁移到云上带来的硬件职责外部化，工程部门对硬件故障越来越习以为常。这种认知实际上在鼓励一种对待故障可预期性的态度，这种态度可以进一步推动混沌工程的采用和被支持。虽然硬件故障并不是线上事故的最常见原因，但是它相对容易理解，同时也是在组织里引入混沌工程并获益的一个较简单的途径。
和硬件故障一样，一些现实世界的事件也可以直接注入：例如每台机器的负责增加、通信延迟、网络分区、证书失效、时间偏差、数据膨胀等等。除此之外，其他的一些事件的注入可能会具有技术或文化的障碍，所以我们需要找寻其他方法来看看它们会如何影响生产环境。例如发布有缺陷的代码。金丝雀发布可以阻止许多简单和明显的软件缺陷被大规模发布到生产环境，但并不能阻挡全部的缺陷被发布出去。故意发布有缺陷的代码风险太大，可能会造成对用户过度的影响（参见最小化“爆炸半径”一节）。要模拟这类发布带来的缺陷问题，一种办法是对相应的服务调用注入异常。
