笔记。 翻译。：本文是 AWS 技术传播者 Adrian Hornsby 一系列精彩文章的延续，他以简单明了的方式解释了通过实验来减轻 IT 系统故障后果的重要性。
“如果你没有准备好计划，那么你就注定会失败。” - 本杰明·富兰克林
В 在本系列文章中，我介绍了混沌工程的概念，并解释了它如何帮助在系统缺陷导致生产故障之前找到并修复它们。它还讨论了混沌工程如何促进组织内积极的文化变革。
在第一部分的最后，我承诺谈论“将故障引入系统的工具和方法”。唉，我的头脑在这方面有自己的计划，在这篇文章中，我将尝试回答想要进入混沌工程的人们中最常见的问题： 首先要打破什么？
好问题！不过，他似乎并没有特别在意这只熊猫……
不要惹乱熊猫！
简短的回答：沿着请求路径定位关键服务。
更长但更清晰的答案：要了解从哪里开始尝试混沌，请注意三个方面：
- 看看 崩溃历史 并识别模式；
- 决定 关键依赖关系;
- 使用所谓的 过度自信效应.
这很有趣，但这部分可以很容易地称为 “自我发现与启蒙之旅”。在其中我们将开始使用一些很酷的乐器“演奏”。
1. 答案就在过去
如果您还记得，在第一部分中，我介绍了错误纠正 (COE) 的概念 - 一种分析我们的错误（技术、流程或组织中的错误）的方法，以便了解其原因并预防以后再复发。一般来说，您应该从这里开始。
“要了解现在，你需要了解过去。” ——卡尔·萨根
查看故障历史记录，在 COE 或事后分析中标记它们并对它们进行分类。确定经常导致问题的常见模式，对于每个 COE，问自己以下问题：
“这是否可以通过故障注入来预测并预防？”
我记得我职业生涯早期的一次失败。如果我们进行一些简单的混沌实验，这种情况就可以很容易地避免：
正常情况下，后端实例响应来自 ）。 ELB 使用这些检查将请求重定向到健康实例。当发现某个实例“不健康”时，ELB 会停止向其发送请求。有一天，在一次成功的营销活动之后，流量增加了，后端对健康检查的响应开始比平常慢。应该说，这些健康检查 ，即检查依赖关系的状态。
然而，有一段时间一切都很好。
然后，在相当紧张的情况下，其中一个实例开始执行一项非关键的常规 ETL cron 任务。高流量和 cronjob 的结合使 CPU 利用率几乎达到 100%。 CPU 过载进一步减慢了对运行状况检查的响应速度，以至于 ELB 认为该实例遇到了性能问题。正如预期的那样，平衡器停止向其分配流量，这反过来又导致组中其余实例的负载增加。
突然，所有其他实例也开始无法通过健康检查。
启动新实例需要下载和安装软件包，并且花费的时间比 ELB 在自动缩放组中一一禁用它们所需的时间要长得多。很明显，整个过程很快就达到了临界点，应用程序崩溃了。
那么我们就永远明白了以下几点：
- 创建新实例时安装软件需要很长时间；最好优先考虑不可变方式 .
- 在困难的情况下，应优先考虑对运行状况检查和 ELB 的响应 - 您最不希望发生的事情就是使剩余实例的生活变得复杂。
- 健康检查的本地缓存有很大帮助（即使是几秒钟）。
- 在困难的情况下，不要运行 cron 任务和其他非关键进程 - 为最重要的任务节省资源。
- 自动缩放时，使用较小的实例。 10 个小样本一组优于 4 个大样本一组；如果一个实例失败，在第一种情况下，10% 的流量将分布在 9 个点上，在第二种情况下，25% 的流量将分布在 XNUMX 个点上。
因此， 是否可以预见到这种情况，并通过引入问题来防止这种情况发生？
是，并以多种方式。
首先，通过使用诸如 или :
❯ stress-ng --matrix 1 -t 60s
压力
其次，通过重载实例 和其他类似的实用程序：
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
这些实验相对简单，但可以提供一些很好的思考，而不必经历真正失败的压力。
然而 不要停在那里。尝试在测试环境中重现崩溃并检查您对问题的回答“是否可以预见到这种情况，并通过引入故障来防止这种情况发生？”这是混沌实验中的一个迷你混沌实验，旨在测试假设，但从失败开始。
这是一场梦，还是真的发生了？
因此，研究失败的历史，分析 COE(技术中心），按“点击半径”（或更准确地说，受影响的客户数量）对它们进行标记和分类，然后寻找模式。问问自己是否可以通过引入问题来预测和预防这种情况。检查你的答案。
然后切换到范围最大、最常见的模式。
2. 构建依赖关系图
花点时间考虑一下您的应用程序。是否有清晰的依赖关系图？你知道如果失败会产生什么影响吗？
如果您不太熟悉应用程序的代码或者它变得非常大，则可能很难理解代码的用途及其依赖项。了解这些依赖关系及其对应用程序和用户可能产生的影响对于了解从何处开始混沌工程至关重要：起点是影响半径最大的组件。
识别和记录依赖关系称为“构建依赖关系图» （依赖关系映射）。这通常是使用代码分析工具针对具有大型代码库的应用程序完成的。 （代码分析） 和仪器仪表 （仪器仪表）。您还可以通过监控网络流量来构建地图。
但是，并非所有依赖项都是相同的（这进一步使该过程变得复杂）。一些 批判的， 其他 - 中学 （至少在理论上，因为崩溃经常是由于被认为是非关键的依赖项问题而发生）.
如果没有关键的依赖关系，服务就无法工作。非关键依赖项”不应该» 跌倒时影响服务。要了解依赖关系，您需要清楚地了解应用程序使用的 API。这可能比看起来要困难得多——至少对于大型应用程序来说是这样。
首先浏览所有 API。突出最 重要且关键的... 拿 根据 从代码存储库中检查出来 连接日志，然后查看 文件 （当然，如果它存在的话 - 否则你仍然有о更大的问题）。使用工具来 分析和追踪，过滤掉外部呼叫。
您可以使用类似的程序 netstat - 命令行实用程序，显示系统中所有网络连接（活动套接字）的列表。例如，要列出所有当前连接，请键入：
❯ netstat -a | more
在AWS中你可以使用 （流日志）VPC 是一种允许您收集有关进出 VPC 中网络接口的 IP 流量信息的方法。此类日志还可以帮助完成其他任务 - 例如，找到为什么某些流量无法到达实例的问题的答案。
你也可以使用 。 X-Ray让你看得细致、“极致” （端到端） 概述请求在应用程序中移动时的情况，并构建应用程序底层组件的映射。如果您需要识别依赖关系，非常方便。
AWS X-Ray 控制台
网络依赖图只是部分解决方案。是的，它显示了哪个应用程序与哪个应用程序通信，但还有其他依赖关系。
许多应用程序使用 DNS 来连接到依赖项，而其他应用程序可能会使用服务发现，甚至在配置文件中使用硬编码的 IP 地址（例如 /etc/hosts).
例如，您可以创建 通过 iptables 看看有什么问题。为此，请输入以下命令：
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS黑洞
如果在 /etc/hosts 或者其他配置文件，你会发现你一无所知的IP地址（是的，不幸的是，这种情况也会发生），你可以再次来救援 iptables。假设你发现了 8.8.8.8 并且不知道这是Google的公共DNS服务器地址。通过使用 iptables 您可以使用以下命令阻止到此地址的传入和传出流量：
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
关闭访问
第一条规则丢弃来自 Google 公共 DNS 的所有数据包： ping 有效，但不返回数据包。第二条规则会丢弃所有从您的系统发送至 Google 公共 DNS 的数据包 - 以响应 ping 我们得到了 操作不被允许.
注意：在这种特殊情况下，最好使用 whois 8.8.8.8，但这只是一个例子。
我们可以进一步深入这个兔子洞，因为所有使用 TCP 和 UDP 的东西实际上也依赖于 IP。在大多数情况下，IP 与 ARP 绑定。不要忘记防火墙...
如果你吃了红色药丸，你就会留在仙境，我会告诉你兔子洞有多深。”
更激进的方法是 关掉 一辆接一辆的汽车，看看有什么坏了......成为“混乱猴子”。当然，许多生产系统并不是为这种暴力攻击而设计的，但至少可以在测试环境中进行尝试。
构建依赖关系图通常是一项非常漫长的工作。我最近与一位客户交谈，他花了近两年的时间开发了一种工具，可以半自动地为数百个微服务和命令生成依赖关系图。
然而，结果非常有趣且有用。您将学到很多关于您的系统、它的依赖关系和操作的知识。再次强调，要有耐心：旅程本身才是最重要的。
3.谨防过度自信
“谁有梦想，谁就相信它。” — 德摩斯梯尼
你可曾听说 过度自信效应?
根据维基百科的说法，过度自信效应是“一种认知偏差，即一个人对自己的行为和决策的信心明显大于这些判断的客观准确性，尤其是当信心水平相对较高时。”
基于直觉和经验...
根据我的经验，这种扭曲是混沌工程从哪里开始的一个很好的暗示。
谨防过度自信的操作者：
查理：“这东西已经五年没有掉下来了，一切都很好！”
Crash：“等等……我马上就到！”
由于影响因素多种多样，过度自信导致的偏见是一种阴险甚至危险的事情。当团队成员全身心投入一项技术或花费大量时间“修复”它时尤其如此。
加起来
寻找混沌工程的起点总是会带来比预期更多的结果，而太快开始打破事物的团队忽视了（混沌）更全球化和更有趣的本质工程 - 创意应用 科学方法 и 经验证据 用于（软件）系统的设计、开发、操作、维护和改进。
第二部分到此结束。请写评论、分享意见或只是拍手 。在下一部分中我 真 我将考虑将故障引入系统的工具和方法。直到！
译者PS
另请阅读我们的博客：
- «“;
- «“;
- «“;
- «“。
来源： habr.com