当你在 Twitter 这样规划的根底架构上运转时，硬件和网络毛病变得不可避免。每一个毛病都有可能对用户体验发生负面影响，因而咱们规划体系时要尽可能地使其对毛病具有弹性。
为了测验咱们的服务对意外毛病的反应，咱们创建了一个结构，可以向 Twitter 根底架构注入受控毛病条件。这使咱们可以发现缝隙，以便更好地预备处理整个站点的事情。经过在咱们自己的体系中引发毛病，咱们可以构建更具弹性的服务。
结构
咱们的结构由一个 Python 库和一个指令行可执行文件组成，旨在直接向生产根底架构引进毛病条件、监控整个站点的健康方针，并在测验过程中向体系发送状况更新。它供给了灵敏的、基于 YAML 的装备语法，而且可以经过模块化规划轻松地扩展额外功用。
该结构包括三种模块类型：
- 顽皮模块在生产服务和根底设施中引进和反转毛病条件。
- 监控模块旨在检查 Twitter 服务的健康方针来历，寻觅可能导致整个站点事情的状况。假如检测到至少一个这些状况，结构将当即反转已引进的毛病条件。
- 告诉器模块旨在与 HipChat 和 JIRA 等体系进行接口，以在毛病测验执行过程中供给实时状况更新。
在 Twitter 根底架构中进行毛病测验的方针是经过查询 Twitter 的资产清单数据库来选择的，该数据库是一切数据中心硬件和相关属性信息的来历。该结构结合了这些查询，允许针对支持单个 Twitter 服务的机器（假如在咱们的内部云上运转）或机器角色准确认位测验。
现在，该结构支持引进以下毛病条件：
- 经过向 IPMI 控制器和 PDUs 发送指令来断电
- Mesos 中运转的 Twitter 服务群集的部分到悉数丢掉
- 经过推送包括交换机端口毛病、部分数据包丢掉、回绝一切 IP 流量、一切流量到一个或多个 TCP/UDP 端口等的新交换机装备来丢掉网络
为了演示工程师怎么运用结构测验毛病条件，以下是一个装备示例，将在 rack abc 中的一切 Hadoop DataNode 上引进 30 分钟的断电毛病，监控测验执行期间的健康方针，并向聊天室发送状况更新：
failure_test:
name: Power loss within rack abc in datacenter abcd
duration_mins: 30
mischief:
- power_loss:
datacenter: abcd
selectors:
- group:
type: role
name: hadoop.datanode
- group:
type: rack
name: abc
notifiers:
- chat:
rooms:
- Failure Testing
monitors:
- observability:
datacenter: abcd
queries: !snippet
将此装备传递给结构的指令行东西后，它将收集引进毛病条件所需的一切信息，例如方针机器主机名和其 IPMI BMC 接口的地址。假如这个顽皮预备过程成功，结构将经过检查装备的监控保证一切测验体系处于健康状况。然后，它将测验引进请求的毛病条件。假如成功引进这些条件，结构将暂停装备的测验时间长度，以分钟为单位检查装备的监控，以保证一切监控在测验期间坚持健康状况。
假如任何监控检测到不健康的根底架构条件，结构将认为毛病测验失败。不然，假如监控在整个测验期间陈述健康条件，结构将认为测验成功。在这两种状况下，结构将当即反转一切引进的毛病条件，停止测验。
测验过程的可视化：
应战
由于咱们在 Twitter 上运转的根底架构是异构的动态根底架构，因而引进针对特定服务的毛病条件需求仔细规划和规划。保管在 Apache Aurora 中的服务与直接在硬件上运转的服务不同，由于它们是动态调度的。
为了确认意外服务行为的根本原因，咱们需求捕获完整的测验环境，其间可能包括机架装备文件、服务类型、服务多样性统计数据、流量量等。在某些状况下，咱们检测到的异常只是上游或下游问题的副作用，或者是服务的恢复行为。
运用和经验教训
这个结构在曩昔六个月启动了 Twitter 上一切的毛病测验，并协助咱们发现了咱们堆栈中的许多缝隙。此外，它还让咱们对 Apache Mesos 和 Apache Aurora 等几个首要体系的毛病弹性发生了决心，在这些体系中，咱们测验了大规划的毛病，但没有对用户形成影响。 在咱们根底设施中常见的一个毛病状况示例是顶部机架（TOR）交换机呈现问题。当呈现这种状况时，运转在这个机架内的服务将阅历整个网络丢掉或部分数据包丢掉。咱们发现，咱们的服务很好地处理了彻底网络丢掉的状况，而部分数据包丢掉简直总会导致一些内部影响。咱们还发现，这种影响的严峻程度取决于机架装备文件和在该机架上运转的 Mesos 隶属服务的服务类型。
该结构可以确认 Twitter 服务怎么在各种常见的硬件毛病场景下做出呼应，为站点可靠性工程师供给了很多的实际数据。这些数据大多围绕着在面对毛病条件时，由强壮的 Finagle 库调解的服务间 RPCs 的行为。
Finagle 为一切服务间 RPCs 赋予了逻辑，以保证每个 RPC 尽可能顺利地进行；但是，为了充分利用这种逻辑，下游服务客户端需求正确调整请求超时和重试值。经过运用结构毛病测验发生的数据，咱们的工程师可以供给调整值和高雅降级逻辑，这可以更好地保持 SLAs 并防止用户面临的事情。
未来的工作
当然，咱们将持续测验咱们的根底设施抵挡随机毛病的才能。这个结构现已用于驱动探索性的毛病测验，协助咱们找到并推进 Twitter 根底架构的极限。随着咱们未来几个月毛病测验方案范围的扩大，该结构将在工作时间内持续运转。经过这样做，该结构将协助咱们保证咱们对硬件毛病条件的弹性不会从已反复证明的状况中退化。此外，咱们正在研究在咱们可扩展的 RPC 体系 Finagle 的层面注入毛病条件。
经过向 Twitter 根底架构注入受控毛病条件，咱们可以保证咱们的体系在生产中更好地容忍意外毛病。这使咱们可以编写更能接受毛病并在需求时高雅降级的服务。终究，经过运转这些测验，咱们可以找到并解决根底架构中的这些缝隙。
假如毛病和可靠性测验听起来像是一个风趣的应战，咱们可以用得上您的协助 — 加入咱们吧！
