Facebook 的自愈配置检查器将一个错误值变成持续 2.5 小时的停摆

2010 年 9 月，Facebook 宕机约两个半小时。公司工程团队在软件工程总监 Robert Johnson 当天发布的一篇罕见的公开事后分析中称，这是该网站四年多来遭遇的最严重宕机。每一位访客、每一个页面都遇到错误，直到网站恢复。

根本原因是一个旨在保持配置值健康的自动化系统：它将缓存值与持久化存储进行比对，并替换任何被判定为无效的值。那天，一次变更在持久化存储本身留下了一个错误值。每个客户端都看到了这个“无效”值并试图修复它，而修复意味着查询一个数据库集群，于是该集群每秒被数十万次查询击中。

错误处理让情况更糟。当客户端的查询失败时，它把失败解读为“值仍然无效”，并删除对应的缓存键——从而又生成一次修复查询。即使最初的错误值被修复后，这个循环仍在自我喂养。唯一的出路是停止所有发往该数据库集群的流量，这意味着将网站完全关闭，让数据库恢复，然后再让用户缓慢重新进入。

整站宕机约 2.5 小时——Facebook 自己的工程师称这是四年多来最严重的宕机

校验器假定持久化存储始终正确；当它持有错误值时，每个客户端都收到了同样被污染的修复指令。

错误处理将“数据库过载”与“值无效”混为一谈，因此每次失败都产生更多负载——一个放大的反馈循环。

出错时删除缓存键，移除了本可吸收重试风暴的那一层。

客户端与集群之间没有断路器，因此唯一剩下的杠杆就是完全关闭网站。

把每个错误都当作“去修复它”的自愈代码会放大故障，而不是吸收故障。限制每个客户端的重试次数，抑制反馈循环，并保留一个不必完全关闭即可使用的恢复杠杆。

Facebook 当天关闭了自我纠正的配置系统，并表示正在围绕能够容忍瞬时峰值和反馈循环的模式重新设计它。服务当天完全恢复，这家当时全球最大的社交网络在数小时内公布了技术细节。该事件至今仍被引用为错误处理将小故障变成自我维持风暴的教科书案例。