Una falsa alarma de humo casi inunda el centro de datos de Jane Street en Nueva York

Un ingeniero de sistemas en Jane Street tuvo que correr físicamente a través de un rascacielos y desconectar manualmente los cables de alimentación de cada servidor en una sala de máquinas para evitar que una falsa alarma de humo provocara una inundación catastrófica. El incidente ocurrió porque los protocolos de seguridad del edificio estaban diseñados para priorizar la supresión de incendios sobre la preservación del hardware, creando un escenario en el que una alarma inducida por el polvo casi destruye el único centro de datos de la firma en Nueva York.

El mecanismo de la casi inundación

La infraestructura de seguridad del centro de datos seguía una lógica específica: si se detecta humo, el sistema apaga las unidades CRAC para evitar que el oxígeno alimente un posible incendio. Simultáneamente, la alarma de humo indica al sistema de aspersores que llene sus tuberías con agua presurizada.

Debido a que la sala estaba llena de racks de servidores de alta densidad, la pérdida de refrigeración provocó que las temperaturas internas aumentaran rápidamente. Dado que los cabezales de los aspersores eran sensibles al calor, el aumento de la temperatura ambiente amenazaba con provocar una inundación en toda la sala, a pesar de que no existía ningún incendio real.

“Y así, mi misión quedó clara: lo más rápido posible, regresar a Jane Street, entrar en la sala de máquinas y tirar del cable de alimentación de cada dispositivo en esa sala antes de que la temperatura superara los 150 F y los aspersores lo destruyeran todo.”

— How a false smoke alarm almost drowned Jane Street’s only NYC datacenter

Intervención manual y cultura de riesgo

La cultura de riesgo de Jane Street priorizaba las anulaciones manuales de 'botón rojo', una filosofía influenciada por un socio con experiencia en submarinos nucleares. Esta cultura dictaba que la sala de máquinas debía mantenerse cerca de la sala de operaciones para que el personal pudiera intervenir físicamente en emergencias.

Cuando se activó la alarma, un ingeniero de sistemas corrió al lugar y avanzó fila por fila, gabinete por gabinete, tirando de los cables de alimentación de cada dispositivo. Este esfuerzo manual detuvo con éxito el aumento de temperatura en 143.6°F, justo por debajo del punto de activación de los aspersores.

Telemetría y salvaguardas futuras

Tras el incidente, el equipo identificó una debilidad en su monitoreo: la telemetría a nivel del edificio para la refrigeración y los sensores no era lo suficientemente fiable para detectar 'desconocidos desconocidos'.

Para resolver esto, el equipo escribió un servicio de monitoreo en OCaml para consultar directamente cada servidor Linux en su flota para obtener datos de los sensores a bordo. Al calcular una media simple de estas temperaturas, crearon un sistema de alertas más duradero que puede detectar fallos de refrigeración generalizados independientemente de si los sensores del edificio funcionan correctamente.