ITPub博客

首页 > 应用开发 > IT综合 > Netflix: 训练更聪明的混沌猴子

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

IT综合 作者:DevOps订阅号 时间:2021-06-15 09:16:23 2 删除 编辑

来源:混沌工程实践

作者:三水蜗牛 原文作者:Kolton Andrus, Ben Schmaus

标题:Automated Failure Testing, aka Training Smarter Monkeys

出处:Netflix Technology Blog

 前 言



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

我们做的所有努力(虽然有些是手动的),帮助我们顺利地没有意外地度过了整个假期(如果在除夕之夜被选中值班,那就更好了!😊)。

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

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

在探索构建这种猴子的过程中,我们发现了由彼得·阿尔瓦罗(Peter Alvaro)开发的称为Molly的故障测试方法。(~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请求空间,在真正的故障发生之前,找到更多会产生用户影响的潜在故障点,并解决它们!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2776672/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-12

  • 博文量
    61
  • 访问量
    41193