混沌猴

定义

混沌猴是奈飞开发的随机故障注入工具，作用对象是生产环境中正在运行的虚拟机和容器实例，行为方式是在不预先通知的情况下随机终止其中一部分^[2]。它的设计目标并非制造破坏本身，而是把偶发的实例失效变成一种可预期、可观察的常态，从而验证系统是否具备冗余与自动恢复能力^[1]。

在混沌工程的工具谱系中，混沌猴通常被归为最早的实践工具，功能边界相当明确，只做实例终止这一种注入^[3]。围绕它逐步扩展出了一整套被统称为猴子军团的故障注入工具集^[1]。

原理

混沌猴的工作方式接近一个持续运行的调度脚本。它借助持续交付平台获取当前可用的服务器清单，再按既定的时间间隔从中随机选取目标，向其下达终止指令，观察流量是否被自动转移到其他实例^[4]。早期版本基于亚马逊云服务的软件开发工具包以 Java 编写，行为近似一个随机数生成器，选定机器后即发送终止命令^[5]。

后期的重构版本改用 Go 语言实现，并与奈飞的持续交付平台 Spinnaker 绑定，必须由该平台托管应用才能执行终止操作，理论上可对接多种云平台与容器编排系统^[2]。

与后来出现的实验型工具不同，混沌猴不带假设检验流程，其背后的基本假设是集群服务不应当受到单个实例失效的影响。一些受其思路影响的实现把这一模式移植到了应用内部，例如面向 Spring Boot 应用的组件通过面向切面编程监听被注解标记的公共方法，再按配置注入延迟、抛出运行时异常或直接终止应用进程^[6]。

发展历程

2008 年，奈飞的主要数据库发生故障，导致其 DVD 租赁业务中断数日，此后公司开始寻找替代架构并逐步将系统迁移到亚马逊云服务上^[7]。迁移过程中，团队从物理设施转向云端，为确认云实例失效不会影响用户体验，于 2010 年内部开发出用于随机终止 EC2 实例的混沌猴。

2011 年，奈飞在混沌猴之外推出了一系列故障注入工具，统称猴子军团，覆盖网络延迟、合规检查、安全漏洞等不同故障维度^[1]。2012 年，公司将该工具以 Java 版本在 GitHub 上开源，并对外表示通过经常性制造故障使服务变得更有弹性。

2014 年，奈飞在猴子军团的基础上提出故障注入测试(FIT)概念，让开发者可以更灵活地控制注入故障的影响范围，这一控制粒度的改进被认为促成了混沌工程这一术语的成型。2017 年，用 Go 重写的 2.0 版本开源，需与 Spinnaker 集成使用^[3]。

应用

混沌猴最初服务于奈飞自身的流媒体系统。这类系统由大量互相调用的服务组成，单个服务的失效在所难免，公司因此在生产环境中持续运行该工具，以确认服务在非关键下游依赖失效时能够优雅降级^[1]。这种做法被认为有助于把冗余与自动化容错的要求固化到工程团队的设计习惯中。

在实践方法上，混沌猴常与稳态假设、爆炸半径控制等概念配合使用：先定义系统正常时的可测量指标，再从小范围注入开始，逐步扩大实验范围，并在指标超出安全区间时立即中止^[8]。除奈飞之外，云原生生态中也出现了面向 Kubernetes 的同类工具，用于以随机删除 Pod 的方式验证服务韧性^[9]。

局限

混沌猴的功能相当单一，只覆盖实例或容器的终止这一种故障，不涉及网络异常、资源耗尽、依赖服务变慢等场景，因此不足以全面反映系统的失效模式^[10]。有分析指出，相比后来的混沌工程平台，它在实验规模与强度的控制上灵活性较低，早期架构以 AWS EC2 为主要目标，面对多云的云与容器生态时存在一定适配局限^[10]。

由于该工具直接作用于生产环境，其行为本身带有风险。在缺少准备与保护措施的情况下于生产环境模拟意外故障，可能产生反效果；因此爆炸半径控制被普遍视为区分混沌工程与单纯的破坏行为的关键，实验也必须配备随时中止的手段^[11]。

此外，该工具与奈飞自有的持续交付平台耦合较紧，脱离这一生态使用会受到限制，这也促使更多通用型混沌工程平台在随后出现^[12]。

参见

• 混沌工程 —— 混沌猴所服务的核心工程实践，主张以受控实验主动暴露系统弱点。

• 猴子军团 —— 奈飞在混沌猴基础上构建的一整套故障注入工具集。

• 爆炸半径 —— 衡量混沌实验影响范围的概念，是安全开展故障注入的前提。

• 故障注入 —— 混沌猴所采用的技术手段，即人为向系统引入故障。

• 站点可靠性工程 —— 与混沌工程相互补充的运维实践体系。

• Spinnaker —— 与该工具后期版本绑定的持续交付平台。