Netflix: 训练更聪明的混沌猴子

来源：混沌工程实践

作者：三水蜗牛 原文作者：Kolton Andrus,练更 Ben Schmaus

标题：Automated Failure Testing, aka Training Smarter Monkeys

出处：Netflix Technology Blog

 前 言

在Netflix，我们发现主动的聪明故障测试是一个非常棒的方法，帮助我们在生产环境中发现潜在的混沌猴问题，为我们的练更用户提供了可靠的产品。

我们做的聪明所有努力（虽然有些是手动的），帮助我们顺利地没有意外地度过了整个假期（如果在除夕之夜被选中值班，混沌猴那就更好了！练更😊）。聪明

但是混沌猴谁喜欢手动的工作呢？另外，我们只测试预期的练更失败，每次练习通常只针对单个服务或组件进行测试。聪明我们要做得更好！混沌猴

想象一下，练更一只猴子在你的聪明代码和基础架构中爬行，注入小的混沌猴故障并检查其是否导致用户影响。

在探索构建这种猴子的过程中，我们发现了由彼得·阿尔瓦罗（Peter Alvaro）开发的称为Molly的云服务器提供商故障测试方法。（http://www.cs.berkeley.edu/~palvaro/molly.pdf） 

鉴于我们已经有了一个称为FIT（Fault Injection Test）的故障注入服务，相信我们可以在短期内构建一个原型实现。（https://medium.com/@Netflix_Techblog/fit-failure-injection-testing-35d8e2a9bb2）

我们认为，把Molly论文中阐述的概念应用到大规模生产中，这非常有意义。因此，我们与Peter取得了联系，了解他是否有兴趣共同构建原型。以下就是我们的合作结果介绍。

一、探索算法

“依赖树驱动的故障注入（LDFI）逆向地从正确的系统输出中，判定注入故障是否会改变输出结果。”

Molly首先查看成功请求的所有内容，然后问：“哪些因素会改变这个结果？” 我们以下面这个简化的请求为例：

故障集: (A|R|P|B) 

一开始，我们假设所有都是必要的因素。然后，假设用户影响是由A或R或P或B故障引起的，其中A代表API（其他以此类推）。亿华云我们首先从潜在故障点中随机选择并重新执行该请求，并在选定点注入故障。

三个潜在的结果：

请求失败：面临失败（将来的实验需要调整以包含此故障） 请求成功：服务/故障点并不重要 请求成功：故障点被接管自动恢复了（故障转移或回退） 在此示例中，评价（Ratings）故障，请求成功，从而生成了以下图表：

故障集: (A|P|B) & (A|P|B|R)) 由此可了解该请求的更多信息和故障点情况。由于播放列表（Playlist）是一个潜在故障点，因此我们接下来将其失效，生成以下图表：

故障集: (A|PF|B) & (A|P|B) & (A|P|B|R)) 这说明了上面第三个潜在的结果。由于执行了故障接管操作（PlaylistFallback），该请求仍然成功。所以，我们有了一个新的故障点需要探索，同时更新实验范围，并进行清理、注入并重复，直到没有更多的故障点可探索为止。Molly对如何探索这个搜索空间没有规定。我们的实现方式是：先列出故障点失效的所有可能性，然后从最小组合中随机选择。例如，[{ A}，{ PF}，服务器托管{ B}，{ P，PF}，{ R，A}，{ R，B}…]。探索从所有单点故障开始：A，PF，B；然后继续两个故障的组合，依此类推。

二、自动故障测试实现

2.1 依赖树梳理Netflix请求的依赖树是什么？利用链路跟踪系统，可为整个微服务构建请求依赖树。通过FIT，我们可用“注入点”的方式获得更多信息。这些都是系统可能发生故障的关键拐点。注入点，包括Hystrix命令执行、高速缓存查找、数据库查询、HTTP调用等等。FIT提供的数据帮助我们构建更完整的依赖树，这就是算法分析的输入。在上面的示例中，我们看到了简单的服务请求树。以下是是利用FIT数据扩展了的请求依赖树：

2.2 成功的标准“成功”是什么？最重要的便是用户体验，需要一种衡量标准来反映这一点。为此，我们利用了设备报告的指标集。通过分析这些指标，就可以确定请求是否会产生用户影响。另一种更简单的方法是依靠HTTP状态代码确定成功的结果。但是状态码可能会引起误解，因为某些框架在部分成功时就返回“200”的状态，而在请求内容才放置用户影响的错误描述。目前，只有部分Netflix请求具有相应的设备报告指标。为更多请求类型添加设备报告的指标后，我们就有机会扩展自动故障测试以覆盖更广泛的设备流量。2.3 幂等操作支持回放请求使Molly简单易用，但我们目前做不到。在收到请求时不知道该请求是否等价，不知道是否可以安全地回放。为了弥补这一点，我们将请求分成多个等效类，每个类中的请求“具有”相同的功能，即执行相同的依赖调用并以相同的方式失败。为了定义请求类，我们着重使用收到的请求信息：路径（netflix.com/foo/bar） 参数（?baz=boo） 发出请求的设备信息 我们先尝试去查看这些请求功能和依赖项之间是否存在直接映射。事实并非如此。接下来，我们探索了使用机器学习来查找和创建这些映射的方法。这似乎是有希望的，但是需要大量的工作才能使其正确。相反，我们将范围缩小到只检查Falcor框架生成的请求。这些请求通过查询参数提供了一组json路径以供请求加载，即“视频”、“配置文件”、“图像”。我们发现这些Falcor路径元素与加载这些元素所需的内部服务一致。未来的工作需要找到一种更通用的方法来创建这些请求类别映射，以便我们可以将测试范围扩展到Falcor请求之外。这些请求类别，会随Netflix工程师编写和部署的代码而变化。为了抵消这种偏移，我们会每天对设备报告的指标集进行抽样，对潜在的请求类别进行分析。无流量的旧类别使之过期，新的代码路径则创建新的类别。

三、用户影响

请记住，此探索的目标是在故障影响大量用户之前找到它并修复。在运行我们的测试时，引起大量用户影响，这是不可接受的。为了减轻这种风险，我们重塑了探索方式，实现在任何给定时间段内只进行少量实验。每个实验的范围都只针对一种请求类别，实验运行时间很短（20-30秒），受影响的用户数很小。我们希望每个实验至少有10个好的示例请求。为了滤除误报，我们会查看实验的总体成功率，超过75%请求的失败情况标记为已发现的失败。由于我们的请求类映射不是完美的，所以我们还会过滤掉由于某种原因没有执行要测试的失败请求。假设我们一天可以运行500个实验。如果我们每次运行都可能影响10个用户，那么最坏的影响是每天有5,000个用户受到影响。但是，并非每个实验都会导致失败。实际上，大多数实验都会成功。如果10%的实验中发现失败（较高的估计值），那么实际上我们每天会影响500个用户的请求，而重试可以进一步缓解。当每天处理数十亿个请求时，这些实验的影响就很小了。

 结 果

我们很幸运，“App Boot”请求，作为最重要的Netflix请求之一，满足了我们的探索标准。该请求会加载运行Netflix应用，以及用户视频初始列表所需的元数据。对于Netflix而言，这是一个关键时刻，我们希望从一开始就向客户提供可靠体验来赢得他们。这也是一个非常复杂的请求，涉及数十个内部服务和数百个潜在的故障点。对这个空间的蛮力探索需要2^100次迭代（大约30个零），而我们的方法能够在大约200次实验中对其进行探索，并从中发现了五种潜在的故障，其中一种是故障点的组合。一旦发现故障，我们该怎么办？好吧，还得手动处理。我们还没有达到能自动修复故障的地步。在这种情况下，我们有一个已知故障点的列表，以及一个允许某些人使用FIT重现故障的“方案”。由此，我们可以验证故障并确定解决方案。我们很高兴能够构建此原型实现，验证实施并使用它来发现真正的故障。我们也希望能够扩展它，以自动方式搜索更多的Netflix请求空间，在真正的故障发生之前，找到更多会产生用户影响的潜在故障点，并解决它们！

很赞哦!（355）