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

让facebook自愈：自动化主动机架维护 - 2
Making Facebook self-healing: Automating proactive rack maintenance

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

Pre-disable(预关闭): 这一步主要是保证目前池子中认为是空闲的主机在主机级别关闭或批量操作期间交换多个主机时不会重新被加入到生产环境。

Host-level disable:(主机级关闭)：在一些场景，由于在预关闭时已经被批量关闭了所以这步没有操作。在其他场景这一步会成为继承FBAR的的主机级关闭逻辑的并行操作。

Post-disable(关闭后):这一步主要是用来确认预关闭和主机级关闭成功完成。它也支持作者去检查主机级关闭步骤的结果来决定是否要忽略特定的失败类型如果它们仍在预期的阈值之下。

下面动画展示了这个过程：

启用流程与关闭流程一样： 预启用，主机级启动，启用后。使用自动化，我们可以安全的在机架或多个机架级执行常规维护，并可以最小化地影响其他的工程团队和使用Facebook的人。

与人交互：当自动化不可行（或失败）

尽管我们的目标是自动化所有要在我们基础设施上进行的维护工作，有些时候还是需要人工接入来保证维护可以安全进行。

起飞检查失败或没有自动化

在一些场景，定时任务可能可能会影响很大一批服务器，起飞检查会就拒绝自动化执行维护。我们的自动化故意设置得比较保守，并在可能产生大范围影响的时候使用手动控制。在另外的情况，由于可靠性的原因或服务处于降级状态，此时自动化还没有被实现或者被暂时关闭，我们希望防止自动化变更。

失败自动化

尽管我们调用Aggregate Maintenance Handlers时有很高的成功率，还是有一些情况会出问题。当故障发生时，我们的维护进程会通知服务的负责人自动化失败了。当他们人工确认主机已经被关闭了，维护动作才允许继续进行。

混合自动化与手工工作

为了帮助协调自动与手动的进行，我们开发了Dapper，一个被很多团队(如，数据中心团队，技术经理，基础设施工程师，产品工程师)使用通过提供影响描述并用于调度维护工作的工具。

Dapper的维护执行工作流如下：

学到的经验

我们从早期的自动化单主机修复到机架和多机架学到了一些经验。

关闭逻辑的串行执行

一次关闭一个主机有两个不好的负面影响。第一是在维护期间可能在某个时间点引起容量不够，导致维护工作需要被停止直到人工介入：

更差的是，当服务的交换逻辑是在同机架上重用主机时，我们可能会意外的将主机重新上线到生产环境，或最佳情况，进入了无限循环：

关闭逻辑的并行使用

相对于一次单个执行，并行进行交换主机可以防止串行方式的一些问题，但会引入其他问题。最常见的问题是并行调用单机逻辑可能在独立操作寻找替换主机时造成条件竞争，但聚合结果可能会造成服务容量不足：

扩展自动化

Dapper和Aggregate Maintenance Handlers提供的框架已经从物理维护工作，扩展到包括软件发布/内核/BIOS/OS升级时关闭和启用主机。

工作在Dapper的产品工程师对进一步扩大自动化和开发工具帮助Facebook工程团队降低运维工作的成本，帮助他们解决更大更有挑战性的问题充满激情。

了解更多 FBAR和Aggregate Maintenance Handlers的内容，可以看这个演讲。

---

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