El verificador de configuración autorreparable de Facebook convirtió un valor defectuoso en un apagón de 2,5 horas

En septiembre de 2010, Facebook quedó fuera de servicio durante aproximadamente dos horas y media. El equipo de ingeniería de la empresa, en un análisis público poco habitual publicado ese mismo día por el director de ingeniería de software, Robert Johnson, lo calificó como el peor apagón que el sitio había sufrido en más de cuatro años. Todos los visitantes, en todas las páginas, recibían errores hasta que el sitio volvió.

La causa raíz era un sistema automatizado pensado para mantener sanos los valores de configuración: comparaba los valores en caché con un almacén persistente y sustituía todo lo que consideraba inválido. Ese día, un cambio dejó un valor defectuoso en el propio almacén persistente. Todos los clientes veían el valor «inválido» e intentaban repararlo, y como la reparación implicaba consultar un clúster de bases de datos, el clúster recibió cientos de miles de consultas por segundo.

El manejo de errores lo empeoró. Cuando fallaba la consulta de un cliente, este interpretaba el fallo como «el valor sigue siendo inválido» y borraba la clave de caché correspondiente, lo que generaba otra consulta de reparación. Incluso después de corregir el valor defectuoso original, el bucle siguió alimentándose a sí mismo. La única salida fue detener todo el tráfico hacia el clúster de bases de datos, lo que implicó apagar el sitio por completo, dejar que las bases de datos se recuperaran y después permitir la entrada de los usuarios poco a poco.

El sitio completo estuvo caído durante aproximadamente 2,5 horas; los propios ingenieros de Facebook lo calificaron como el peor apagón en más de cuatro años

El verificador daba por sentado que el almacén persistente siempre era correcto; cuando contenía el valor defectuoso, todos los clientes recibían la misma instrucción de reparación envenenada.

El manejo de errores confundía «base de datos sobrecargada» con «valor inválido», de modo que cada fallo generaba más carga: un bucle de retroalimentación que amplificaba el problema.

Borrar las claves de caché ante un error eliminó la única capa que podría haber absorbido la tormenta de reintentos.

No había ningún interruptor de seguridad entre los clientes y el clúster, así que la única palanca que quedaba era el apagado total del sitio.

El código autorreparable que interpreta cada error como «ve a corregirlo» amplifica los fallos en lugar de absorberlos. Limita los reintentos por cliente, atenúa los bucles de retroalimentación y mantén una palanca de recuperación que no exija el apagado total.

Facebook desactivó ese mismo día el sistema de configuración autocorrector y afirmó que lo estaba rediseñando en torno a patrones que toleran picos transitorios y bucles de retroalimentación. El servicio se restableció por completo ese día y la empresa, entonces la mayor red social del mundo, publicó los detalles técnicos en cuestión de horas. El incidente sigue citándose como un caso de manual de manejo de errores que convierte un pequeño fallo en una tormenta autosostenida.