我们六月在生产测试中的会议专门讨论了混沌工程。 首席软件工程师Norah Jones从Netflix如何进行生产测试开始。
“混乱的工程……这是在生产中进行的实验，目的是在系统中发现漏洞，然后再为客户提供不适合的服务。 在Netflix，我们使用称为ChAP的工具来运行它们……[它]捕获漏洞并允许我们实施服务和生产中的故障。 这些故障在导致完全中断之前确认了有关这些服务的假设。”
观看有关她的团队如何帮助用户（Netflix工程师）安全地在生产中进行测试并积极确定其系统中的漏洞的演示（或阅读成绩单）。
解密
今天很高兴来到这里。
Netflix在生产中积极使用测试。 我们通过混沌工程来实现它们，并且最近我们将团队更名为Resiliance Engineering [可持续发展]，因为混沌工程是实现整体可持续性的一种方式。 我今天要谈论这个。
我们的目标是通过主动搜索服务漏洞来增加正常运行时间。 我们通过生产实验来做到这一点。 团队有信心只能在实际流量中检测到特定类型的漏洞和问题。
首先，您应该注意安全性和监视，否则您将无法在生产中部署常规测试。 这样的测试可能会令人恐惧：如果感到恐惧，您应该听这个声音并找出原因。 可能是因为您没有良好的安全系统。 还是因为没有良好的监控。 在我们的工具中，我们确实关心这些事情。
如果我们用一句话来形容混乱的工程，那么这就是生产实验的学科，目的是在系统中的漏洞使服务不适合客户之前先找出漏洞。 在Netflix，我们使用称为ChAP的工具来运行它们，这意味着混沌自动化平台（Chaos Automation Platform）。 ChAP捕获漏洞，并允许用户实施服务和生产中的故障。 这些故障会在导致全面中断之前确认用户对这些服务的假设。
我将告诉您该平台的工作原理。 这是一组假设的微服务依赖关系。 有一定的代理。 它向服务A发送请求，然后服务A，服务B和服务D分散无风扇，仍然存在一定程度的持久性。 服务D访问Cassandra，然后服务B访问缓存。
我急于总结一切，因为本质从此开始。 我们要确保服务D对缓存失败具有鲁棒性。 用户进入ChAP界面，然后选择服务D作为观察缓存失败的服务和失败服务。 ChAP实际上将服务B克隆为两个副本。 我们将它们用于实验集群中的控制：它们以某种方式像A / B测试或Canary测试一样工作。 这些副本比服务B小得多。我们仅向这些群集发送非常少量的客户，因为显然，我们不希望出现全面的故障。 我们基于当前使用该服务的当前用户数来计算此百分比。
然后，ChAP指示故障转移系统标记符合我们标准的请求。 这是通过将信息添加到请求标头来完成的。 创建了两组标签。 在第一组有关故障和路由到金丝雀副本的指令中，在第二组中-仅关于路由到监视元素的指令。
当RPC客户端和服务A收到路由请求所必需的指令时，它们实际上将流量定向到监视群集或实验群集。 然后，实验集群的RPC级别的故障实现系统会看到该请求已标记为故障，并返回失败的响应。 和以前一样，实验性集群将执行代码以将故障作为来自缓存的不成功响应来处理。 我们以容错为前提，对吗？ 但是有时我们看到情况并非如此。 从服务A的角度来看，一切看起来都像正常行为。
我们会仔细控制混乱的工程，这可能会非常不利。 Netflix刚开始进行此类实验时，我们没有一个好的控制系统。 我们发出了一个人为的小故障，坐在房间里，手指交叉，检查一切正常。 现在，我们对安全性有了更多的关注。
我们查看关键业务指标。 其中之一称为SPS（每秒流启动），即每秒开始视频流。 如果您考虑什么对Netflix的业务最重要，那么用户就可以在任何时候运行任何系列。
在图中，您可以看到一个真实的实验。 它显示了在测试过程中实验集群与对照集群之间的SPS差异。 您可能会注意到，这些图彼此之间有很大的偏差，这不应该如此，因为将相同百分比的流量发送到两个群集。
因此，测试使用自动金丝雀分析。 它给出了一个信号，使得图形之间的偏差非常大。 在这种情况下，测试将立即中断，以便人们可以在该站点正常工作。 从用户的角度来看，这更像是发生这种情况时的短期故障。
我们还有许多其他补救措施。 我们限制了每个地区的测试流量，因此我们不仅仅在美国西部2区进行实验，我们在各地进行测试，并限制一次可以在该地区进行的实验数量。 测试仅在工作时间内通过，因此如果出现问题，我们不会唤醒工程师。 如果测试失败，则除非有人明确手动更正并确认：“嘿，我知道测试没有通过，但我已修复了所有需要的内容，否则无法自动再次启动。”
可以将自定义属性应用于群集。 如果服务像许多Netflix服务一样被分为多个碎片，这将很有用。 此外，您可以根据设备类型实施故障。 如果我们在Apple设备或某种类型的电视上遇到任何问题，我们可以专门针对它们进行测试。
ChAP发现了许多错误。 这是我的最爱之一。 我们进行了一项实验，以检查服务的备份路径（这对于服务的可用性至关重要），并在那里发现了一个错误。 在导致服务可用性事件之前，该问题已得到解决。 这是一个非常有趣的情况，因为该备份路径并不经常执行。 因此，用户并不真正知道它是否可以正常工作，因此我们可以模仿它。 我们实际上导致了服务故障，并检查了它是否在壁板上，以及是否正常工作。 在这种情况下，用户认为他的服务是不重要的或次要的，但实际上这是一项重要的服务。
这是另一个例子。 我们进行了一个实验，以在注册过程中重现该问题，该问题在夜间出现在某些服务器上。 服务发生了奇怪的事情。 引入了500毫秒的延迟后，问题再次出现。 在测试期间，在上传到大数据门户的日志中发现了问题。 这有助于了解为什么在某些情况下注册不起作用。 仅通过ChAP实验，我们才得以了解正在发生的事情以及原因。
配置ChAP测试需要大量信息。 我们需要找出引入错误的适当要点。 团队必须确定他们是否要崩溃或延迟。 这完全取决于注入点。 您可以使Cassandra，Hystrix（我们的备份系统），RPC服务，RPC客户端，S3，SQS或我们的缓存崩溃，或添加延迟。 或两者都做。 您还可以提出不同实验的组合。
您需要做的就是与服务团队聚会，并提出一个好的测试。 这将花费很多时间。 设置实验时，您还应该定义ACA（自动Canary分析）配置或自动Canary配置。
我们有一些现成的ACA配置。 SPS有一种ChAP配置。 有一个带有监视系统指标的。 另一个检查了RPS崩溃。 另一个确保我们的服务确实可以正常工作并正确实现错误。 我们意识到设计测试非常耗时，因此发生了。 创建的测试很少。 一个人很难记住一个好的实验所需的一切。 我们决定使用ChAP实现自动化。 我们查看了指标：呼叫去向和呼叫者，带有超时的文件，重复呼叫。 显然所有信息都来自不同的地方。 有必要对其进行汇总。
我们将分析扩展到了ChAP级别，在该级别上处理信息更加方便，您可以使用Monocle。 现在，可以在一个地方研究有关应用程序和集群的所有信息。 在这里，每行代表一个依存关系，这些依存关系代表混乱工程实验的温床。
我们在一个地方收集了所有信息以进行实验开发，但不了解这种聚合本身非常有用，因此这是一个有趣的副作用。 您可以在这里查看与特定服务相关的反模式。 例如，检测到的依赖关系不被认为是关键的，但是没有后备路由。 显然，现在她正在变得批判。 人们可能会看到超时不匹配，回调不匹配。 我们使用此信息来评估某种类型实验的重要性，并将其输入确定优先级的算法中。
每行代表一个依赖关系，这些行可以扩展。 这是一个有趣的例子。
在这里，顶部的蓝线表示某人的超时，底部的紫色线表示正常的运行时间。 如您所见，距离超时非常非常远。 但是大多数信息不可用。 如果我们在超时后立即运行测试会怎样？ 你觉得呢 他会通过吗？ 这是一个有趣的问题。 我们试图在运行测试之前为用户提供这一详细级别，以便他们得出结论并更改设置。
我想玩个小游戏。 该Netflix服务中存在一个漏洞，请尝试检测到它。 稍等一下。
为了给您一些背景信息，远程Hystrix命令同时包含sample-rest-client和sample-rest-client.GET。 Hystrix超时设置为500毫秒。 Sample-rest-client.GET的超时为200 ms，并且有一次重试，这很不错，因为总计为400毫秒，这符合Hystrix限制。 第二个客户端有一次重试的超时为100和600。
在这种情况下，不能考虑Hystrix shell的超时完成重试，即Hystrix在客户端可以接收响应之前拒绝该请求。 这就是漏洞所在。 我们将这些信息提供给用户。 有趣的是，实现这些功能的大多数逻辑都在不同的地方，并且在它们无法比较之前。 他们认为一切正常，但这是一个错误。
为什么会这样呢？ 当然，开发人员很容易看到冲突并更改超时，对吗？ 但是我们想找出原因。 我们可以更改超时时间，但是如何保证不再发生这种情况？ 我们还帮助找出原因。
在创建自动化测试时，我们还使用Monocle。 用户在多种类型的输入数据上创建实验。 我们接受了所有这些，并自动创建了这样的测试，以使用户不会打扰。 我们会自动创建Hystrix实验和RPC实验并对其进行优先级排序，这些实验会因延迟而导致延迟和失败。 默认情况下，会添加ACA配置。 我们具有SPC，系统指标，查询统计信息和自动运行的实验。 还创建了实验优先级。 一种高级算法可以为它们工作。 我们使用带有RPS统计信息的存储桶。 我们使用一些重试和相关的Hystrix命令。 整个集合被适当地加权。
此外，还考虑了没有备份执行路径的团队数量以及客户端对其依赖项添加的任何外部影响（策动影响）。 外部影响会极大地影响授权，注册和SPS程序。 而且，我们真的会评估其效果，如果结果是否定的，我们不会进行实验。 然后对测试进行排序，并按关键程度降序运行。 关键评分越高，测试开始的越早且越频繁。
具有讽刺意味的是，Monocle为我们提供了反馈，使我们可以在生产中进行较少的测试。 我们进行了许多测试，结果形成了反馈环：我们看到了测试之间的联系。 现在，您可以查看特定的配置文件并查看特定的反模式。 即使没有对此信息进行测试，也可能了解导致故障的确切原因，而我们之前并未了解。
这导致了新的安全级别。 以前，未成功的实验被标记为已解决。 现在，将其标记为已解决，然后重新启动。 但是现在我们可以明确地将外部（策画）影响添加到成瘾中。 用户进入他的Monocle并指出：该因素正好影响授权程序。 这是在SPC上。 而且我们正在研究反馈周期，因此，如果反馈周期失败，那么还会添加这种策展效果。
因此，ChAP中的Monocle是收集所有信息的重要工具，它会自动生成实验，自动对漏洞进行优先级排序和搜索，然后再导致全面关闭。 总而言之，重要的是要记住为什么我们要从事混沌工程并在生产中进行所有这些实验。 这样做是为了了解客户如何使用服务，而不是忽略他们。 您想为人们提供最便捷的服务。 因此，监视和安全至关重要。 Netflix应该始终显示视频。
谢谢啦