¿No has oído mucho sobre el equipo de Infraestructura de DreamHost (aparte de las Partes 1 y 2 de esta serie)? ¡Eso significa que están haciendo su trabajo!
En su mundo, el silencio es oro y el caos siempre está a solo unos milisegundos de distancia.
Mientras el resto de nosotros transmitimos, dormimos o construimos nuestra presencia en línea, este equipo camina por los pasillos fríos, revisa paneles de control, reemplaza tarjetas RAID y se prepara para emergencias que (con suerte) nunca ocurren.
Esta es una mirada dentro de las salas de guerra, momentos extraños y vigilancia 24/7 que mantiene a DreamHost, y a tu sitio, en línea.
El día que Portland se apagó
Si hay una historia que resume la resiliencia del equipo, es el apagón de Portland de noviembre de 2023.
“PGE (Portland General Electric) estaba realizando mantenimiento en una de las dos líneas de alimentación eléctrica del centro de datos”, explicó Chris Lewis, Gerente de Operaciones de Centros de Datos de DreamHost, en relación con un problema en el suministro eléctrico del edificio.
Luego falló la otra línea de alimentación, provocando una pérdida total de energía.
Las baterías entraron en funcionamiento. Los generadores rugieron y todo parecía estar bien. Pero cuando PGE volvió a encender la línea de mantenimiento, provocó un mal funcionamiento en el sistema de conmutación, enviando una peligrosa carga eléctrica que causó un incendio y quemó un conjunto de cortacircuitos. Con solo unos minutos de batería de respaldo restantes, el equipo enfrentó el peor escenario posible: la falla total del centro de datos.
“Casi el 75-80% de nuestros racks se apagaron, incluyendo la red principal”, dijo Chris. “Fue una locura”.
Y aun así, en 14 horas y con una colaboración total del equipo, todo volvió a funcionar. Así fue como recuperaron el servicio mucho más rápido que la estimación de entre 2 días y una semana (peor caso):
- Anticipación de la catástrofe
- El equipo esperaba una falla catastrófica (no esta en particular) que cortara la energía y migró proactivamente a un sistema donde la mayoría de las máquinas pudieran arrancar sin depender de la red, lo que ahorró tiempo significativo.
- Mantenimiento preventivo y sistemas resistente
- El mantenimiento preventivo constante y los sistemas resistentes (RAID y zpools) protegieron los datos y permitieron tiempos de reemplazo razonables, en lugar de apresurarse a restaurar matrices dañadas.
- Proximidad y preparación del personal de guardia
- Los administradores de guardia viven a menos de una hora del centro de datos y llegaron rápidamente al sitio (en este caso, el administrador de guardia llegó 20 minutos después de recibir la alerta).
- Con la pérdida de energía bloqueando las puertas desde el exterior y deshabilitando los sistemas de seguridad física, tener a alguien en el sitio para verificar manualmente las identidades fue fundamental—ya que dejar entrar a cualquiera sin la verificación adecuada sería una grave violación de seguridad (o peor, un escenario tipo Misión: Imposible).
- Equipo técnico amplio y global con liderazgo claro
- Un equipo técnico amplio, capacitado y global brindó relevos frescos y supervisión remota.
- Un liderazgo claro canalizó la información y priorizó las tareas, respaldado por un profundo entendimiento de las capas y confianza en el equipo para mantener a todos actualizados sobre el estado de las piezas en movimiento.
💡¿Sabías que?
Los generadores diésel de DreamHost pueden alimentar centros de datos completos hasta por 24 horas siempre que continúen las entregas de combustible. Durante el apagón, fueron la única razón por la que las luces (y los sitios) permanecieron encendidos.
Redundancia: El arte de ser paranoico (en el buen sentido)
La recuperación ante desastres no se improvisa en el momento, se diseña con mucha antelación.
“Suponemos que algo se romperá”, dijo Luke Odom, Director de Operaciones de TI de DreamHost. “Así que diseñamos para fallar”.
- ¿Energía? Cada rack tiene unidades de distribución de energía redundantes (PDUs) en líneas separadas.
- ¿Red? Múltiples proveedores de internet (ISP) a través de diferentes puntos de entrada.
- ¿Almacenamiento? Matrices RAID, capas de replicación y copias de seguridad listas para usar.
Chris lo dice claramente, aplicando la Ley de Murphy: “Todo lo que pueda salir mal, saldrá mal”; no es cuestión de si ocurrirá la falla, sino de cuándo. El factor crítico radica en qué tan rápido pueden recuperarse, o mejor aún, prevenir que estos eventos inesperados ocurran.
Monitoreo: El escudo silencioso
Mantener las cosas en línea no es glamoroso, es constante.
“Caminamos por el piso, revisamos luces, revisamos paneles todos los días”, dijo Chris. “A veces el hardware no reporta su propia falla, así que vamos a buscarla”.
Esa diligencia significa que los problemas pequeños se detectan antes de que se conviertan en apagones completos.
Los proyectos actuales incluyen actualización de firmware, parcheo de vulnerabilidades de código y despliegue de mejores sistemas de reporte para que los problemas puedan detectarse (y resolverse) aún más rápido.
“Monitoreamos todo lo que podemos”, dijo Chris. “Y cuando algo se nos escapa, averiguamos por qué y arreglamos el sistema”.
Cuando la automatización falla (porque lo hace)
La automatización es útil, hasta que deja de serlo.
“Rompemos la automatización con frecuencia”, dijo Luke. “La mitad de lo que hacemos no es realmente automatización, son solo herramientas que hacen que nuestro trabajo manual sea más rápido y fácil”.
Una vulnerabilidad de seguridad importante, por ejemplo, obligó al equipo a reiniciar casi todo y actualizar el BIOS en toda su infraestructura. Fue tedioso y no automatizado, hasta que construyeron una herramienta para agilizar los pasos repetibles. Todavía la usan hoy.
El aprovisionamiento de servidores que antes requería horas ahora toma 20 minutos usando OpenStack y Ansible. Pero si cambian el firmware, las versiones del sistema operativo o los controladores, los scripts fallan y hay que volver al trabajo manual.
Historia de guerra #2: Edición campo de vacas
A veces, el soporte de infraestructura ocurre en… lugares poco convencionales.
Mientras estaba de vacaciones en el sur de Georgia, Luke recibió una llamada: falla de RAID. Hardware caído y servidores fuera de línea. Como último recurso, el equipo llamó a Luke para pedir ayuda.
“Estaba sentado en un cuatrimoto mientras arreaba vacas”, dijo. “Guié al técnico para volver a ensamblar la matriz con un solo disco funcionando. La duplicamos, reconstruimos el RAID y devolvimos el servicio a los clientes”, dijo.
Sí, desde el medio de un campo de vacas.
Historia de guerra #3: Gamer Jimmy, el cazador de fraudes
Hace casi una década, DreamHost fue golpeado con una ola de registros fraudulentos. Los hackers comprometían cuentas, pedían servidores dedicados o VPS y los usaban para lanzar ataques o minar criptomonedas.
Entra: Gamer Jimmy.
No era miembro del equipo, sino un hacker notorio cuya actividad inspiró un script interno.
“Uno de los chicos escribió un script con el nombre de ‘Gamer Jimmy’”, dijo Chris. “Escaneaba en busca de indicadores de fraude y rechazaba automáticamente solicitudes sospechosas”.
Funcionó.
💡¿Sabías que?
El FBI una vez instaló una intervención secreta en un cliente de DreamHost: debajo del piso del centro de datos. Más tarde fue descubierta durante un apagado del centro. La ubicación de la etiqueta de activo era literalmente: bajo el piso.
Infraestructura de DreamHost: Los héroes invisibles
Al final del día, el equipo de infraestructura de DreamHost no se trata solo de luces parpadeantes y flujo de aire. Son quienes dejan todo—reuniones, sueño, incluso vacaciones—para mantener tu sitio en línea.
“No nos ves hasta que algo se rompe”, dijo Chris. “Pero ese es el punto. Si somos invisibles, lo estamos haciendo bien”.
¿Y si los ves?
Probablemente haya un tablero en llamas o un cuatrimoto involucrado. Y de alguna manera, tu servidor sigue funcionando.