📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Hay war stories de sistemas que enseñan más que cualquier libro de arquitectura, y esta es una de ellas. Hace un par de días se publicó el recuerdo de Michael Bacarella, del equipo de sistemas de un fondo financiero de Nueva York, sobre la madrugada en que su teléfono sonó desde la oficina de Hong Kong: la alarma de humo del datacenter había saltado y había que moverse ahora, porque en unas horas la sala podía estar llena de agua presurizada lista para caer sobre los racks.
El contexto ya es oro. Por paranoia razonable, ese datacenter no estaba en un recinto aislado con camiones de refrigeración: estaba en un piso intermedio de un rascacielos de oficinas, a un pasillo del escritorio. La razón era doble: que nadie pudiera robar los servidores con las estrategias dentro, y que siempre hubiese alguien capaz de cruzar la sala y apagar todo tirando los cables de la pared. La cultura de riesgo venía de un socio que había servido en un submarino nuclear: no confías en la automatización a menos que exista una palanca física para cortar todo.
Cómo se fabrica una inundación sin fuego
La cadena de fallas es de manual, y por eso vale la pena desarmarla. Los contratistas estaban cortando cosas en una dependencia vecina, levantaron polvo y dispararon el detector. Lo que pocos saben de los aspersores de oficina: las cañerias normalmente no llevan agua durante el día; cuando el detector de humo salta, las cañerias se presurizan, pero el agua no sale todavía, porque cada cabezal se abre solo cuando su propio plug térmico se derrite con calor de fuego real.
Hasta ahí, sin fuego, no habría chorro: el sistema está diseñado exactamente para eso. El problema es un detalle que arruina todo: la misma alarma de humo apaga los aires acondicionados de la sala, para no soplar aire sobre una llama. En una sala llena de racks eso significa que la temperatura empieza a escalar sin freno. Y cuando cruza el umbral térmico de los cabezales, los aspersores abren sobre servidores que están prendidos y que nadie alcanzó a apagar todavía. Fuego: cero. Agua presurizada: caleta.
Correr 33 pisos y desconectar a mano
La respuesta fue brutalmente física: llegar a la sala y desconectar con las propias manos el cable de cada equipo, fila por fila, mirando el termómetro. 141°F, 142, 143, 143,5, 143,6. Ahí se detuvo. Como los mercados locales ya habían cerrado, el downtime fue mínimo y al día siguiente todo estaba corriendo. Pero el detalle incómodo es cómo se enteraron: por casualidad, alguien mirando una pantalla notó que varios servidores mostraban temperatura en ascenso al mismo tiempo. Ninguno tenía alerta de temperatura configurada, y con razón: un servidor caliente pasa todo el día. Uno solo no significa nada. La flota completa subiendo en bloque significa un fallo generalizado de refrigeración, y ese patrón nadie lo miraba.
La lección que me robo
La solución que montaron después me parece brillante por lo simple: un monitor que cada minuto le pregunta la temperatura a cada servidor, calcula el promedio por locación y avisa si el promedio sube. No confían en la telemetría del CRAC ni en un sensor dedicado que puede fallar: preguntan directo a la flota.
Es un principio que conviene aplicar en todos lados. He visto montañas de alertas por servidor que nadie lee, porque la temperatura de una máquina sola es ruido permanente. La señal útil casi siempre es la agregada: cuando varios componentes se desvían juntos, el problema no es cada componente, es el entorno. Y ojo con la otra lección: un mecanismo de emergencia que se dispara en cadena sin verificación puede fabricar por sí solo el desastre que quería prevenir. Antes de instalar esa automatización, pregúntate qué pasa si se activa sin emergencia. A veces la respuesta es: inunda el datacenter.
Fuente de inspiración: How a false smoke alarm almost drowned Jane Street’s only NYC datacenter
