转载

Twitter的故障处理机制：故障测试

　　对于 Twitter 这样的基础设施规模，硬件和网络错误是不可避免的，但无论是哪一种错误都可能对用户体验造成消极的影响，因此对一个系统而言弹性的错误处理能力是非常重要的，那么 Twitter 是怎样做的呢？最近 Twitter 基础设施工程团队的负责人 Mazdak Hashemi 在官方博客上发表了一篇文章，介绍了 Twitter 的故障测试机制。

　　为了测试服务如何响应异常，Twitter 创建了一个能够将受控的故障条件注入到基础设施中的框架，通过该框架 Twitter 能够发现漏洞，从而更好地为全站范围内的事件处理做好准备，保证系统对意外故障具有较好的容错性。

　　框架

　　Twitter 的故障测试框架由一个 Python 类库和一个命令行可执行程序组成，通过该框架工程师能够将故障条件直接引入到产品基础设施中，然后能够在测试执行期间监控全站范围的健康指标，并在状态发生变化的时候发送系统通知。

　　该框架包含三个模块：

故障引入（Mischief）模块，在产品服务和基础设施中引入或者撤回故障测试
监控模块，检查服务的健康指标，查找可能导致全站范围事件的状态
通知模块，与 HipChat 和 JIRA 等系统交互，在故障测试执行期间提供实时的状态更新

　　到目前为止，框架支持的故障条件包括：

发送命令给 IPMI 控制器和 PDU 的功率损耗
Mesos 中服务集群的部分或者全部丢失
推送新转换配置造成的网络丢失

　　下面是一个介绍工程师如何使用框架测试故障条件的示例，该示例为 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的故障处理机制：故障测试

　　挑战

　　Twitter 运行的基础设施具有异构且动态的特性，所以在为一个具体的服务引入故障测试时需要细心的设计和计划，考虑要全面。例如，托管在 Apache Aurora 上动态调度的服务与直接运行在硬件设备上的服务不同。为了找到引发异常的真正原因，必须捕获完整的测试环境，包括机架配置、服务类型以及流量等信息，因为在某些情况下，异常可能是由上游或下游的问题，或者是服务恢复行为引发的。

　　使用情况与经验教训

　　在过去的 6 个月，这一框架驱动了 Twitter 所有的故障测试，帮助 Twitter 发现了大量的漏洞，让 Twitter 对 Apache Mesos 和 Apache Aurora 等主要系统的弹性故障处理机制有了非常强烈的信心。

　　另外，Twitter 还总结了一些经验教训。例如，从机架顶部开关损坏的故障中总结出：当这种情况发生的时候，运行在该机架上的服务要么全部从网络上丢失，要么丢失部分包，对于前一种情况 Twitter 的服务能够很好地处理，但是后一种情况却几乎总是会造成某些内部的影响，这种影响的严重程度取决于机架的配置和 Mesos 从机上运行的服务种类。

　　未来的工作

　　Twitter 将继续使用该框架测试基础设施对随机故障的处理能力，找到系统的瓶颈。同时，故障测试程序的范围也会增加，将来扩展 RPC 系统层也将支持这种机制。

正文到此结束