Netflix猿猴军团（Simian Army） | IDCF

云是关于冗余和容错的。由于没有任何一个组件能够保证100%的正常运行时间（即使是最昂贵的硬件，最终也会出现故障），我们必须设计一个云架构，在这种架构中，单个组件可以出现故障而不会影响整个系统的可用性。

实际上，我们必须做到，比我们最薄弱的那个环节更强大。我们可以使用一些技术，比如依赖性故障时的优雅降级，以及节点、机架、数据中心、可用区乃至区域的冗余部署。然而，仅仅设计一个容错架构是不够的。我们必须不断地测试自己是否有能力在这些“难得一遇”的故障中生存下来。

想象一下轮胎瘪了。即使你的后备箱里有备胎，你知道它是否充气了吗？你有弄它的工具吗？最重要的是，你还记得怎么做才是正确的吗？有一种方法，可以确保你能半夜在下雨的高速公路上处理爆胎的问题，那就是：每个星期天下午，在你的轮胎上捅一个洞，然后进行更换轮胎的练习。在现实世界中，这既昂贵又耗时，但在云上是（几乎）免费的，还能自动化实现。

这就是我们在构建“混沌猴子（Chaos Monkey）” 时的理念。它是一个工具，可以随机禁用我们的生产实例，以确保我们能够在这种常见的故障类型中生存，而不会对客户造成任何影响。这个名字源于这样一个想法：在数据中心（或云区域）释放一只带武器的野猴子，会随机击落实例（instance）和啃穿电缆，而在此期间，我们持续、不间断地为客户提供着服务。

通过在工作日中运行的混沌猴子，在一个仔细监控的环境中，工程师也随时待命解决任何问题，我们仍然可以吸取关乎系统弱点的教训，并建立自动恢复机制来进行处理。因此，当下一次在星期天凌晨3点出现实例故障时，我们甚至都不会注意到它。

受到混沌猴子成功运行的启发，我们已经开始创造新的猿猴，它们可以引发各种故障或检测异常情况，并测试我们的生存能力。这是一个虚拟的“猿猴军队（Simian Army）”，保持我们的云的安全、可靠和高可用性。

• 延迟猴子（Latency Monkey）在我们的RESTful客户端-服务器通信层中，引入人工延迟来模拟服务降级，并衡量上游服务是否适当地响应。此外，通过制造非常大的延迟，我们可以模拟一个节点甚至整个服务的停机时间（并测试我们在这种情况下的生存能力），而不必从物理上关闭这些实例。这在测试新服务的容错性时尤其有用，方法是模拟其依赖项的故障，而不会导致这些依赖项对系统的其余部分不可用。
• 一致性猴子（Conformity Monkey）发现不符合最佳实践的实例，并关闭它们。例如，我们知道，如果我们发现有实例不属于自动扩容组，那么就可能会有麻烦的事情发生。我们关闭它们，是为了让服务所有者有机会重新启动它们。
• 医生猴子（Doctor Monkey）通过运行在每个实例上的健康检查，并监视外部的其他健康迹象（例如CPU负载），来检测不健康的实例。一旦检测到不健康的实例，它们将被从服务中移除，并在给服务所有者一些时间来查找问题根因之后，最终将被终止掉。
• 看门猴子（Janitor Monkey）确保我们云环境的运行没有混乱和浪费。它搜索未被使用的资源，并清除掉它们。
• 安全猴子（Securiy Monkey）是一致性猴子的延伸。它会发现安全违规项或漏洞（如配置不当的AWS安全组），并终止有问题的实例。它还确保我们所有的SSL和DRM认证都是有效的，并且不会过期。
• 10-18 猴子（10-18 Monkey，本地化-国际化的缩写，或110n-i18n）使用不同的语言和字符集，检测服务于多个地理区域客户实例中的配置和运行时问题。
• 混沌大猩猩（Chaos Gorilla）类似于混沌猴子，但模拟了整个Amazon可用区（availability zone）的中断。我们想验证我们的服务是否能自动重新均衡到功能可用区，而不会导致用户可见的影响或手动干预。

我们身边的Netflix猿猴军团不断壮大，随着它们持续地测试我们对各种故障的应变能力，对于处理生产环境中不可避免的故障、以及尽量减少或消除这些故障对用户的影响，我们对自己的能力感觉更加自信。

云模型对我们（以及这个行业的其他人）来说，都是全新的；容错的工作正在进行中，我们有办法充分实现它的好处。猿猴军团的一部分已经构建好，但还有许多地方有希望优化，等待有才华的工程师加入这项工作并使之成为现实。

新猿猴的创意，来得比我们能跟上的速度更快。如果你有想法，我们很乐意听到！猿猴军团是我们推出的众多举措之一，旨在提高我们服务的可靠性，并为客户提供持续不断的娱乐。

Source: Netflix Technology Blog, Jul 19, 2011

作者：Yury lzrailevsky, 云系统基础设施总监；Ariel Tseitlin, 云解决方案总监

译者：林伟丹

首发：IDCF社区