让facebook自愈：自动化主动机架维护 - 1

Making Facebook self-healing: Automating proactive rack maintenance

原文：https://code.fb.com/productio...
作者： Romain Komorn
翻译： 时序

我们一直希望facebook的产品和服务在任何使用它的人，无论他们在世界的哪里，都能工作正常，这驱动我们主动监测和定位我们基础设施产品的问题，让我们避免可能引起百万用户在任何时间使用facebook时导致变慢或中断服务的情况。

在2011，我们引入了 Facebook Auto Remediation (FBAR)服务，一组运行在每个服务器上用来在检测到软件和硬件故障时自动执行代码的守护进程。每天，不需要人干预，FBAR将这些服务器从生产环境摘除并向我们的数据中心团队发送请求去执行物理硬件维修，保障这些隔离的故障不出问题。

当我们的基础设施不断扩大，我们也需要在机架级别或像网络交换机/备用电源单元等其他故障域检测和定位问题。多个服务可能在一个机架上，每天运行这样的维护可能会在一年中多次中断很多团队。

为了最小化干扰，我们在FBAR之上开发了一个叫做Aggregate Maintenance Handlers(聚合维护处理)的增强功能，可以提供一种一次性自动维护多个服务器的方法。在自动化不够的场景下，我们也开发了Dapper，一个通过人工介入来保证计划内维护可以安全进行的工具。文章后面的内容会介绍Aggregate Maintenance Handlers是怎么样在多种停机场景工作的，包括当自动化失败时会发生什么，Dapper是如何协调自动化和人工处理的。

使用Aggregate Maintenance Handlers进行自动化

FBAR有方法一次disable和reenable一个主机，当在多个主机上一次性地按顺序或并行执行这些方法不够保险。顺序执行的方式可能会太消耗时间或让服务处于容量不足的风险下。并行执行的方式可能会导致出现条件竞争并使服务更快的产生容量不足。

Aggregate Maintenance Handlers提供框架来批量自动disable和enable服务器，为我们的工程师执行维护工作时提供完整的情景上下文和所有被影响的服务器范围。

基于维护影响范围来做决定

停机的影响在大小，长度，类型上都差异很大：一些影响一个单独的机架，一些会影响好几个；它们可以长或短；一些只影响网络连通性而一些会影响电源。不同的服务要使用不同的方式来处理停机。当我们计划一个维护工作，我们提供Aggregate Maintenance Handler四块信息来决定它在我们总体基础设施上的影响：

1. 范围（维护会影响的服务器列表）
2. 维护类型（网络中断，电源中断）
3. 维护开始时间（如太平洋标准时间早上十点）
4. 维护时长（如2小时）

我们的工程师可以用这个影响描述来决定如何自动化并优化怎样处理停机。让我们看下三个简单例子：

1. 一个无状态的web服务器在被从负载均衡池中移除是可以接受任意时长的网络和电源中断。这个场景里唯一需要关心的是保证仍有足够的web服务器来处理所有请求。
2. 一个在内存中保存静态索引的缓存机器可以接受从负载均衡池中摘除时长时间的网络中断。当网络恢复，机器可以立即提供索引服务。一个短的电源中断，则需要重新将索引加载到内存。处理一次重启需要主动替换一个没有被同一次维护影响的服务器。
3. 一个进行高吞吐复制的MySQL复制服务可以接受一次短的电源中断。主机可以被从负载均衡池中移除，数据可以存储在磁盘上，MySQL服务器也可以在重启后快速追平复制进度。相反的，如果中断几小时的网络会导致数据落后太多，所以此时对复制服务器进行主动替换会是一个更好的选择。

计算中断的类型和时长可以让我们为每个服务建立一个简单的决策矩阵：

处理器disable/enable过程

当一个可用的维护计划被计划和选择后，处理器遵循一个四步工作流来关闭影响的主机：

1. 起飞前检查
2. 预关闭
3. 主机级别关闭
4. 关闭后处理

起飞前检查： 起飞前检查会在关闭过程的最开始被调用，用来检查没有被影响的服务器是否有足够的容量来保障动作的安全性。它返回一个true或false来指导维护工作可以继续进行或终止。起飞前检查也可以作为定时调度进程的一部分独立调用，让团队可以有更多时间处理其可能返回false的场景。

让我们想象下给定约束下的6个机架：

现在让我们设想下两个维护场景：

起飞检查会检查两个场景下的web服务器，但在场景B，起飞检查会在缓存和数据库服务器上失败，维护任务不允许自动化运行（这个场景会在下节详细介绍）

当所有起飞检查通过，我们的Aggregate Maintenance Handlers让我们可以在之前已经有的主机级别disable/enable逻辑上包装一层更智能的代码层。

未完待续。

---

本文来自微信公众号「麦芽面包，id「darkjune_think」转载请注明。
交流Email: [e-mail]