冷却故障迫使维基百科进行故障转移——而故障转移本身又导致全球DNS瘫痪

2010年3月24日，维基媒体欧洲数据中心的冷却系统发生故障，许多服务器为保护硬件而自动关机。由于该站点为维基百科及其他项目承载欧洲流量，运维团队执行了标准的快速故障转移：更改DNS记录，将所有用户流量转移到佛罗里达集群。几分钟后，团队发现故障转移机制本身已经失效，所有维基媒体站点的DNS解析均已停止工作——不仅在欧洲，而是全球范围。

恢复过程随后又遭遇了第二种更为隐蔽的故障模式。团队预计递归解析器会在一小时内丢弃错误应答——即该区域所公布的负缓存TTL——但许多ISP的解析器无视这一提示，将失败的查询结果缓存了更长时间。变通办法相当直接：重命名受影响的DNS记录，迫使解析器去查询一个新名称。与此同时，在紧急状态下被停用的secure.wikimedia.org SSL网关在流量回流时不堪重负而崩溃，直到UTC 21:32才恢复。

在数小时内，这座世界参考百科全书的域名完全无法解析，且没有可观看的故障状态信息流——Mashable指出，Twitter是唯一可以追踪此事的地方。维基媒体《Signpost》记录该站点“全球离线数小时”，团队当天在技术博客上发布了说明，署名基础设施工程师Mark Bergsma。

所有维基媒体站点在全球范围内停止解析达数小时，CNN、《每日电讯报》和Mashable均报道了此次故障，读者无法访问。

该故障转移流程被标为“标准快速”，但在实际执行时其DNS步骤已经失效——显然，这条恢复路径从未针对真实切换进行过演练。

恢复时间估计假设ISP解析器会遵守所公布的一小时负缓存TTL；许多解析器并未遵守，使一次本应有界的事故延长为无期限的事故。

SSL网关没有余量：当流量涌回时，secure.wikimedia.org过载并宕机，加剧了故障。

欧洲的服务集中于单一设施，因此一次冷却故障就首先迫使进行全球流量切换。

从未演练过的故障转移路径只是一种希望，而非机制。应将恢复流程作为实战演练来排练，并且永远不要假设下游缓存会按时过期。

在DNS记录被重命名且新的查询传播后，访问得以恢复；SSL网关于当天UTC 21:32前恢复。维基媒体技术博客当天发布的公开事后分析，为基金会后来发布事故复盘的惯例奠定了基调。冗余陷阱本身依然存在：2012年8月，一次光纤切断同时切断了阿什本和坦帕数据中心之间两条“冗余”链路，导致维基百科再次宕机63分钟，直到那时基金会才将其服务后端整合到阿什本。