냉각 장애로 위키백과의 페일오버가 강제되었고, 그 페일오버 자체가 전 세계 DNS를 망가뜨렸다

2010년 3월 24일, 위키미디어의 유럽 데이터 센터에서 냉각이 실패했고 많은 서버가 하드웨어를 보호하기 위해 스스로 꺼졌다. 그 사이트가 위키백과와 다른 프로젝트의 유럽 트래픽을 처리하고 있었기 때문에, 운영팀은 표준 신속 페일오버를 실행했다. 즉, 모든 사용자 트래픽이 플로리다 클러스터로 이동하도록 DNS 항목을 변경한 것이다. 몇 분 후 팀은 페일오버 메커니즘 자체가 고장 나 있었고, 유럽뿐 아니라 전 세계적으로 모든 위키미디어 사이트의 DNS 확인이 작동을 멈췄다는 것을 발견했다.

복구 과정에서 두 번째이자 더 조용한 실패 모드가 발생했다. 팀은 리졸버들이 존이 광고한 네거티브 캐시 TTL인 1시간 이내에 잘못된 응답을 버릴 것이라고 예상했지만, 많은 ISP의 리졸버가 그 힌트를 무시하고 실패한 조회를 더 오래 캐시했다. 우회 방법은 단순했다. 영향을 받은 DNS 레코드의 이름을 바꿔 리졸버들이 새로운 이름을 다시 조회하도록 한 것이다. 한편 비상 상황에서 비활성화되었던 secure.wikimedia.org SSL 게이트웨이는 돌아오는 트래픽에 과부하되어 다운되었고, UTC 21:32까지 복구되지 않았다.

몇 시간 동안 세계의 참고 백과사전은 확인 자체가 불가능했고, 지켜볼 만한 장애 상황 스트림도 없었다. Mashable은 트위터가 유일한 추적 수단이었다고 언급했다. 위키미디어 《사인포스트》는 사이트가 '전 세계적으로 몇 시간 동안 오프라인'이었다고 기록했고, 팀은 인프라 엔지니어 Mark Bergsma의 서명이 담긴 당일 설명을 기술 블로그에 게시했다.

모든 위키미디어 사이트가 전 세계적으로 몇 시간 동안 확인을 멈췄고, 이 장애는 CNN, 텔레그래프, Mashable에 보도되며 독자들이 접근하지 못하게 했다.

페일오버 절차는 '표준 신속'이라고 표시되어 있었지만, 실제로 실행했을 때 DNS 단계가 고장 나 있었다. 즉, 복구 경로가 실제 전환에 대해 한 번도 시험된 적이 없었던 것이 분명하다.

복구 예상은 ISP 리졸버들이 광고된 1시간 네거티브 캐시 TTL을 준수할 것이라고 가정했지만, 많은 리졸버가 그렇게 하지 않아 한정된 장애가 끝을 알 수 없는 장애로 늘어났다.

SSL 게이트웨이에는 여유가 없었다. 트래픽이 몰려 돌아오자 secure.wikimedia.org가 과부하되어 다운되면서 장애가 악화되었다.

유럽 서비스가 단일 시설에 집중되어 있었기 때문에, 냉각 장애 하나가 애초에 전 세계 트래픽 전환을 강제하게 되었다.

한 번도 시험되지 않은 페일오버 경로는 메커니즘이 아니라 희망일 뿐이다. 복구 절차를 실제 훈련으로 리허설하고, 다운스트림 캐시가 예정대로 만료된다고 가정하지 말아야 한다.

DNS 레코드 이름이 변경되고 새로운 조회가 전파된 후 접근이 복구되었으며, SSL 게이트웨이는 같은 날 UTC 21:32까지 돌아왔다. 위키미디어 기술 블로그에 게시된 당일 공개 사후 분석은 재단이 이후 사고 회고를 공개하는 관행을 만드는 데 기준을 세웠다. 이중화의 함정 자체는 계속되었다. 2012년 8월에는 광케이블 절단 하나로 애슈번과 탬파 데이터 센터 사이의 '이중화된' 링크 두 개가 모두 끊겨 위키백과가 다시 63분 동안 다운되었고, 그제서야 재단은 서비스 백엔드를 애슈번으로 통합했다.