如何避免大规模线上故障。|沃维修网

文章目录 [+]

作者 | 曹春晖责编 | 欧阳姝黎

Fail at Scale 是 Facebook 2015 年在 acm queue 上颁发的一篇文章。主要写了常见的线上故障和应对办法，内容照样比拟其实的。

（图片来源网络，侵删）

公众What Would You Do If You Weren't Afraid?公众和 "大众Fortune Favors the Bold."大众是 FB 公司信条，挂墙上那种。

为了能在快速变革的体系中使 FB 的体系稳固，工程师们对体系故障进行了一些总结和抽象，为了可以或许树立靠得住的体系必需要懂得故障。而为了懂得故障，工程师们树立了一些对象来诊断问题，并树立了对事故进行复盘，以避免将来再次产生的文化。

事故的产生可以被分为三年夜类。

为什么会产生故障

单机故障

通常环境下，单机会到的伶仃故障不会影响到根基举措措施的其他部门。这里的单机故障指的是：一台机械的硬盘呈现了故障，或者某台机械上的服务遇到了代码中的差错，如内存毁坏或死锁。

避免单个机械故障的症结是主动化。经由过程总结已知的故障模式，并与探讨未知的故障症状相联合。在发现未知故障的症状(如相应迟缓)时，将机械摘除，线下阐发，并将其总结至已知故障中。

事情负载变化

实际天下的重年夜变乱会对 Facebook 网站根基举措措施带来压力，好比：

奥巴马被选总统，他的 Facebook 页面阅历了创纪录的运动程度。

重年夜体育赛事的热潮部门，如超等碗或天下杯，会导致极高的帖子数目。

负载测试，以及新功效宣布时的引流阶段会不向用户展现但引入流量。

这些变乱中网络到的统计数据会为体系设计提供奇特的视角。重年夜变乱会导致用户行动变化，这些变化能为体系后续的决议计划提供数据根据。

工资差错

图 1a 显示了周六和周日产生的事故是若何年夜幅削减的，只管网站的流量在整个一周内坚持同等。图 1b 显示了在六个月的光阴里，只有两个礼拜没有产生事故：圣诞节的那一周和员工要为对方写同业评论的那一周。

上图阐明年夜部门故障都是工资缘故原由，由于变乱的统计与人的运动纪律是同等的。

故障的三个缘故原由

故障的缘故原由许多，不外有三种最为常见。这里列出的每一种都给出了预防步伐。

快速部署的设置装备摆设变革

设置装备摆设体系每每被设计为在环球规模内快速复制变化。快速设置装备摆设变革是壮大的对象，然而，快速设置装备摆设变革可能导致部署问题设置装备摆设时产生事故。下面是一些防止设置装备摆设变革故障的手腕。

所有人公用统一套设置装备摆设体系。使用一个配合的设置装备摆设体系可以确保法式和对象实用于所有类型的设置装备摆设。

设置装备摆设变化静态反省。很多设置装备摆设体系容许疏松类型的设置装备摆设，如 JSON 布局。这些类型的设置装备摆设使工程师很容易打错字段的名称，在必要使用整数的处所使用字符串，或犯其他简单的差错。这类简单的差错最好用静态验证来捕获。布局化格局(Facebook 使用 Thrift)可以提供最根本的验证。然而，编写法式来对设置装备摆设进行更具体的营业层面的验证也是应该的。

金丝雀部署。将设置装备摆设先部署到小规模，防止变革造成劫难性效果。金丝雀可以有多种情势。最简单的是 A/B 测试，如只对 1% 的用户启用新的设置装备摆设。多个 A/B 测试可以同时进行，可以使用一段光阴的数据来跟踪指标。

就靠得住性而言，A/B 测试并不克不及满意所有需求。

一个被部署到少数用户的变革，假如导致相关服务器瓦解或内存耗尽，显然会发生超越测试中有限用户的影响。

A/B 测试也很消耗光阴。工程师们常常愿望在不使用 A/B 测试的环境下推送小的变化。

为了避免设置装备摆设导致的显著问题，Facebook 的根基举措措施会主动在一小部门服务器上测试新版本的设置装备摆设。

例如，假如我们愿望向 1% 的用户部署一个新的 A/B 测试，会起首向 1% 的用户部署测试，保证这些用户的哀求落在少量服务器上，并对这些服务器进行短光阴的监控，以确保不会由于设置装备摆设更新呈现异常显著的瓦解问题。

保持可以运行的设置装备摆设。设置装备摆设体系设计计划保证在产生失败时，保存原有的设置装备摆设。开发职员一样平常倾向于设置装备摆设产生问题时体系直接瓦解，不外 Facebook 的根基举措措施开发职员以为用老的设置装备摆设，使模块能运行比向用户返回差错好得多。(注：我只能说这个真的要看场景)

设置装备摆设有问题时回滚要快速。有时，只管尽了最年夜尽力，有问题的设置装备摆设照样上了线。敏捷回滚是办理这类问题的症结。设置装备摆设内容在版本治理体系中进行治理，保证可以或许回滚。

强依附焦点服务

开发职员倾向于以为，焦点服务：如设置装备摆设治理、服务发现或存储体系，永久不会失败。在这种假设下，这些焦点服务的短暂故障，会酿成年夜范围故障。

缓存焦点服务的数据。可以在服务当地缓存一部门数据，如许可以低落对缓存服务的依附。提供专门 SDK 来使用焦点服务。焦点服务最好提供专门的 SDK，如许保证年夜家在使用焦点服务时都能遵循雷同的最佳实践。同时在 SDK 中可以斟酌好缓存治理和故障处置，使用户一劳永逸。进行练习训练。只要不进行练习训练，就没法知道假如依附的服务挂了本身是不是真的会挂，以是经由过程练习训练来进行故障注入是必需的。

延迟增长和资本耗尽

有些故障会导致延迟增长，这个影响可以很小(例如，导致 CPU 使用量微微增长)，也可以很年夜(服务相应的线程死锁)。

少量的额外延迟可以由 Facebook 的根基举措措施轻松处置，但年夜量的延迟会导致级联故障。险些所有的服务都有一个未处置哀求数目的限定。这个限定可能是由于哀求相应类服务的线程数目有限，也可能是因为基于变乱的服务内存有限。假如一个服务遇到年夜量的额外延迟，那么挪用它的服务将耗尽它的资本。这种故障会层层流传，造成年夜故障。

资本耗尽是分外具有破坏性的故障模式，它会使哀求子集所使用的服务的故障引起所有哀求的故障：

一个服务挪用一个新的试验性服务，该服务只向 1% 的用户推出。通常环境下，对这个试验性服务的哀求必要 1 毫秒，但因为新服务的失败，哀求必要 1 秒。使用这个新服务的 1% 的用户的哀求可能会耗费许多线程，以至于其他 99% 的用户的哀求都无法被执行。

下面的手腕可以避免哀求聚积：

延迟节制。在阐发曩昔涉及延迟的变乱时，工程师发现年夜量哀求都是聚积在行列步队中期待处置。服务一样平常会有线程数或内存使用上的限定。因为服务相应速率 < 哀求传入速率，行列步队会越来越年夜，直达到到阈值。想要在不影响正常运行靠得住性的条件下限定行列步队年夜小，FB 工程师研讨了 bufferbloat 问题，这里的问题和 bufferbloat 问题很相似，都是在拥塞的时刻不引起过度延迟。这里实现了 CoDel(controlled delay 缩写)算法的一个变种：

注：固然里面写着 M 和 N，但实在 M 和 N 是定值，N = 100ms，M = 5ms

onNewRequest(req, queue):

if queue.lastEmptyTime() < (now - N seconds) { timeout = M ms } else { timeout = N seconds; } queue.enqueue(req, timeout)

在这个算法中，假如行列步队在曩昔的 100ms 内没有被清空，那么在行列步队中消费的光阴被限定在 5ms。假如服务在曩昔的 100ms 可以或许清空行列步队，那么在行列步队中消费的光阴被限定为 100 ms。这种算法可以削减列队（由于 lastEmptyTime 是在迢遥的曩昔，导致 5ms 的列队超时），同时容许短光阴的列队以到达靠得住性的目标。固然让哀求有这么短的超时彷佛有悖常理，但这个进程容许哀求被快速丢弃，而不是在体系无法跟上传入哀求的速率时聚积起来。较短的超不时间可以确保服务器接受的事情老是比它现实能处置的多一点，以是它永久不会闲置。

前面也说了，这里的 M 和 N 根本上不必要按场景调整。其他办理列队问题的办法，如对行列步队中的项目数目设置限定或为行列步队设置超时，必要按场景做 tuning。M 固定 5 毫秒，N 值为 100 毫秒，在年夜多场景下都能很好地事情。Facebook 的开源 Wangle 库和 Thrift 使用了这种算法。

自顺应 LIFO(落后先出)。年夜多半服务以 FIFO 的次序处置行列步队。然而，在年夜量列队时代，先入的哀求每每已经等了好久，用户可能已经废弃了哀求相关的行动。这时刻处置先入队的哀求，会将资本消耗在一个不太可能使用户受益的哀求上。FB 的服务使用自顺应落后先出的算法来处置哀求。在正常的操作前提下，哀求是 FIFO 处置模式，然则当行列步队开端义务聚积时，则切换至 LIFO 模式。如图 2 所示，自顺应 LIFO 和 CoDel 可以很好地共同。CoDel 设置了较短的超不时间，防止了形发展行列步队，而自顺应 LIFO 模式将新的哀求放在行列步队的前面，最年夜限度地进步了它们满意 CoDel 设置的末了刻日的机遇。HHVM 实现了这个落后先出算法。

并发节制。CoDel 和自顺应 LIFO 都在服务器端运行。服务端是低落延迟的最佳场合--server 为年夜量的 client 服务，且有比 client 端更多的信息。不外有些故障较严重，可能导致服务真个节制无法启动。为了兜底 FB 还在客户端实施了一个策略：每个客户端都邑在每个服务的根基上跟踪未完成的出站哀求的数目。当新的哀求被发送时，假如对该服务的未决哀求的数目跨越可设置装备摆设的数目，该哀求将立刻被标志为差错(注：应该相似熔断)。这种机制可以防止单一服务垄断其客户的所有资本。

赞助诊断故障的对象

只管有最好的预防步伐，故障照样会产生。故障时代，使用正确的对象可以敏捷找到基本缘故原由，最年夜限度地削减故障的连续光阴。

使用 Cubism 的高密度仪表板在处置事故时，快速获守信息很紧张。好的仪表盘可以让工程师快速评估可能呈现非常的指标类型，然后应用这些信息来推想基本缘故原由。然而仪表盘会越来越年夜，直到难以快速阅读，这些仪表盘上显示的图表有太多线条，无法一览无余，如图3所示。

为相识决这个问题，我们使用 Cubism 构建了我们的顶级仪表盘，这是一个用于创立地平线图表的框架--该图表使用色彩对信息进行更密集的编码，容许对多个相似的数据曲线进行轻松比拟。例如，我们使用 Cubism 来比拟分歧数据中心的指标。我们环抱 Cubism 的对象容许简单的键盘导航，工程师可以快速查看多个指标。图 4 显示了使用面积图和程度线图的分歧高度的统一数据集。在面积图版本中，30像素高的版本很难浏览。统一高度下地平线图异常容易找到峰值。

比来产生了什么变革。

因为失败的首要缘故原由之一是工资差错，调试失败的最有用办法之一是探求人类比来的变化。我们在一个叫做 OpsStream 的对象中网络关于比来的变化的信息，从设置装备摆设变化到新版本的部署。然而，我们发现跟着光阴的推移，这个数据源已经变得异常喧华。因为数以千计的工程师在进行转变，在一个变乱中每每有太多的转变必要评估。

为相识决这个问题，我们的对象试图将故障与其相关的变化接洽起来。例如，当一个非常被抛出时，除了输出客栈跟踪外，我们还输出该哀求所读取的任何设置装备摆设的值比来产生的变化。通常，发生很多差错客栈的问题的缘故原由便是这些设置装备摆设值之一。然后，我们可以敏捷地对这个问题做出反响。例如，让上线该设置装备摆设的工程师赶紧回滚设置装备摆设。

从失败中进修

失败产生后，我们的变乱审查进程有助于我们从这些变乱中进修。

变乱审查进程的目标不是为了指责。没有人由于他或她造成的变乱被审查而被开除。审查的目标是为明晰解产生了什么，解救使变乱产生的环境，并树立平安机制以削减将来变乱的影响。

审查变乱的办法 Facebook 创造了一种名为 DERP（detection, escalation, remediation, and prevention）的办法，以赞助进行富有成效的变乱审查。

检测 detection。若何检测问题--报警、仪表板、用户申报。

进级 escalation。正确的人是否敏捷参与。这些人是否可以经由过程警报被拉进故障处置流程，而不是工资拉进来。

解救 remediation。采取了哪些步调来办理这个问题。这些步调是否可以主动化。

预防 prevention。哪些改良可以避免同类型的故障再次产生。你若何能优雅地失败，或更快地失败，以削减此次故障的影响。

在这种模式的赞助下，纵然不克不及防止同类型的变乱再次产生，也至少可以或许在下一次更快规复。

一把梭的时刻少出故障

公众move fast公众的心态纷歧定与靠得住性冲突。为了使这些理念兼容，Facebook 的根基举措措施提供了平安阀：

设置装备摆设体系可以防止不良设置装备摆设的快速部署；