«No es DNS. No puede ser DNS. Era DNS.» Feliz Día del Sysadmin

Cada mañana, en miles de oficinas, ocurre una escena que no ve absolutamente nadie.

Alguien enciende el portátil. El correo entra. La VPN levanta a la primera. El ERP abre. La impresora de la tercera planta imprime (y hasta por las dos caras). La web responde en 300 milisegundos. Los backups de anoche terminaron a las 04:12.

Y no pasa nada.

Ese no pasa nada es el trabajo. Un trabajo tan bien hecho que se vuelve invisible, y tan invisible que hubo que inventarse un día al año para recordarle al mundo que alguien lo está haciendo.

Ese día es este viernes 31 de julio: el System Administrator Appreciation Day, el Día del Administrador de Sistemas. La 27ª edición.

Un armario de cableado en su estado natural. Foto en dominio público, vía Wikimedia Commons.

Todo empezó con un anuncio de impresoras

La historia del origen es tan tonta que resulta perfecta.

Año 2000. Ted Kekatos, administrador de sistemas, hojea una revista de Hewlett-Packard y se encuentra un anuncio: un sysadmin rodeado de compañeros felices que le entregan flores y una cesta de fruta para agradecerle que haya instalado las impresoras nuevas.

Kekatos acababa de instalar ese mismo modelo de impresoras en su empresa unos días antes. Ni flores, ni fruta, ni un mísero correo.

Así que hizo lo único razonable: inventarse la fiesta. La primera celebración fue el 28 de julio de 2000 y desde entonces cae el último viernes de julio.

El sysadmin del anuncio era ficticio. La cesta de fruta, también. El cabreo era muy real.

El folclore: hay un haiku, y siempre es DNS

Todo oficio con solera acaba generando su propio folclore. El de los sysadmins tiene refranes, criaturas mitológicas y, sobre todo, un haiku que se recita como una oración:

No es DNS. No hay forma de que sea DNS. Era DNS.

Tiene gracia, pero es un procedimiento de diagnóstico. DNS falla de una manera especialmente cruel: casi nunca parece DNS. Se manifiesta como «el correo va lento», «carga en mi casa pero no en la oficina», «va bien pero a ratos». Para cuando has descartado el firewall, la red y el proveedor, resulta que un TTL o un registro caducado llevaban tres horas riéndose de ti.

Y no es cosa de pymes con dos servidores.

El 4 de octubre de 2021, Facebook desapareció de internet durante casi seis horas. Y aunque todo el mundo lo recuerda como «un fallo de DNS», el orden de los acontecimientos importa, porque explica por qué tardaron tanto en volver:

1. Durante una tarea de mantenimiento, un comando destinado a evaluar la capacidad del backbone tumbó todas las conexiones de esa red troncal. La auditoría que debía impedir un comando así tenía un fallo y no lo paró.
2. Sus servidores DNS están diseñados para retirar sus propios anuncios BGP cuando no pueden hablar con los centros de datos, porque eso indica una red enferma.
3. Al quedarse aislados, hicieron exactamente eso: retiraron las rutas.
4. Resultado visible: los servidores DNS seguían funcionando, pero eran inalcanzables, así que el dominio dejó de resolver para todo el planeta.

Lo demás también estaba caído, empezando por las herramientas internas con las que se investiga una avería así, y hubo que mandar gente a unos centros de datos que —explica el informe— son difíciles de acceder por diseño y con equipamiento difícil de modificar incluso estando dentro. (Lo de las tarjetas que dejaron de abrir puertas y lo de la radial para las jaulas circuló mucho aquellos días, pero es relato de prensa: el informe oficial no lo recoge.)

Doble moraleja, y las dos valen para tu empresa:

1. El síntoma apareció en DNS, pero la causa estaba tres capas más abajo. Por eso el haiku funciona y por eso hay que seguir bajando.
2. Tu plan B no puede depender del sistema que se ha caído. Si la contraseña de emergencia está en el gestor que necesita SSO, y el SSO está caído, no tienes un plan B: tienes un dibujo de un plan B.

Julio de 2024: cuánto trabajo manual sostiene «la nube»

Si quieres entender qué hace un sysadmin, no mires un día normal. Mira el 19 de julio de 2024.

CrowdStrike publicó una actualización de contenido para su sensor a las 04:09 UTC y la retiró a las 05:27 UTC. Setenta y ocho minutos. En ese rato, según la estimación de Microsoft, unos 8,5 millones de equipos Windows entraron en pantallazo azul y bucle de reinicio —aeropuertos, hospitales, bancos, supermercados— porque el sensor leía en modo núcleo unos datos mal formados y provocaba una lectura fuera de rango.

Pero lo demoledor no fue el fallo. Fue el arreglo.

La solución era ridículamente sencilla —arrancar en modo seguro, borrar un fichero, reiniciar— y precisamente por eso no servía de nada: el equipo no arrancaba, así que no había forma de desplegarla. Había que ir máquina por máquina, millones de veces, a mano. Y en los equipos con cifrado de disco hacía falta además la clave de recuperación, que en más de una organización estaba guardada en sistemas que también estaban en pantalla azul.

Aquel fin de semana el mundo volvió a funcionar gracias a miles de personas con un pendrive y una paciencia infinita. Ningún titular llevaba sus nombres.

GitLab, 2017: cinco redes de seguridad, ninguna atada

31 de enero de 2017, cerca de las 23:00 UTC. Un ingeniero de GitLab, después de horas peleándose con una incidencia de carga, borra el directorio de datos del servidor que cree secundario. Un segundo después se da cuenta de que la sesión era la del primario: unos 300 GB de base de datos de producción, evaporados.

Entonces tocaba tirar de backups. GitLab tenía cinco mecanismos distintos de copia y replicación y, según reconocieron en el postmortem con una honestidad brutal, ninguno funcionaba de forma fiable o estaba realmente configurado. Cinco redes de seguridad, ninguna atada al suelo.

Se salvaron por chiripa: unas seis horas antes, alguien había tomado una instantánea del volumen para montar un entorno de pruebas. No era un backup, era un efecto colateral. Aun así se perdieron unas seis horas de datos de base de datos: en torno a 5.000 proyectos, 5.000 comentarios y 700 cuentas nuevas. Los repositorios Git y las wikis no resultaron afectados, cosa que conviene decir porque es lo que casi siempre se cuenta mal.

Y lo que de verdad merece un aplauso: en lugar de esconderse, retransmitieron la recuperación en directo por YouTube, con un documento público actualizándose en tiempo real. Sigue siendo uno de los actos de transparencia técnica más valientes que se recuerdan.

La lección la resume bien cualquier sysadmin con canas: un backup no es un backup, es una hipótesis. Se convierte en backup el día que lo restauras entero y funciona.

Frases que le dices a un sysadmin sin saber que le haces daño

Con cariño. Todas las hemos dicho. Yo también.

• «No funciona nada.» — Falta casi todo el ticket: qué no funciona, desde cuándo, en qué equipo, qué salía en pantalla y si hay captura. Sin eso, la incidencia se resuelve por telepatía, y la telepatía tiene mala cobertura.
• «Solo necesito permisos de administrador un momentito.» — El momentito dura tres años y aparece en el inventario de accesos como una sorpresa.
• «Esto me lo hace mi sobrino en un rato.» — Probablemente sea verdad. Lo que tu sobrino no hace en un rato es estar disponible el martes de madrugada cuando eso que hizo en un rato se cae.

La paradoja de cobrar por el incendio que no ocurrió

Todo esto desemboca siempre en el mismo sitio: nadie aplaude un desastre que no ha ocurrido.

El ejemplo definitivo es el efecto 2000. Miles de profesionales se pasaron años revisando código —con un gasto mundial que las estimaciones sitúan en cientos de miles de millones y sobre cuyo cálculo todavía se discute— para que la noche del 31 de diciembre de 1999 no pasara nada. No pasó nada. Y la conclusión popular fue: «menudo timo, si al final no era para tanto».

Pues claro que no fue para tanto. Ese era exactamente el entregable. Es la misma trampa del mantenimiento: cuando el trabajo consiste en que no ocurra el problema, el éxito es indistinguible de la suerte. Y la suerte nunca pasa factura.

Cómo felicitar a un sysadmin sin que suene a cachondeo

La tradición manda tarta. Y la tarta está muy bien. Pero si de verdad quieres alegrarle el día:

• Escribe tickets con contexto. Qué hacías, qué esperabas, qué pasó, a qué hora y una captura. Un buen ticket es un regalo; uno con la hora exacta es un regalo caro.
• No reportes incidencias a las 23:47 por WhatsApp con un «hola» a secas y un «?» diez minutos después.
• Dale las gracias un día que NO haya pasado nada. Es el único agradecimiento que mide el trabajo real.
• Aprueba el presupuesto aburrido. Copias probadas, monitorización, licencias al día, el segundo enlace, el disco de repuesto. Nada de eso luce en una reunión, y todo eso es lo que evita la reunión mala.
• Y sí, tarta. Pero que quede claro: la tarta no restaura una base de datos.

Un último apunte

$ uptime
 03:31:12 up 1247 days,  4:02,  1 user,  load average: 0,04 0,03 0,00

Ese 1 user eres tú, a las tres y media de la mañana, comprobando por última vez que todo sigue en pie. Y ese load average es la traducción a números de «no ha pasado nada», que es el mejor titular que puede dar un sistema.

(Aunque 1.247 días de uptime hace tiempo que dejaron de ser un motivo de orgullo: no demuestran ninguna vulnerabilidad concreta, pero sí tres años sin reiniciar, y hay parches —los del núcleo, sin ir más lejos— que no terminan de aplicarse hasta que se reinicia.)

Así que este 31 de julio, si abres el portátil y todo va —el correo entra, la web carga, el ERP responde y nadie está gritando en el pasillo—, acuérdate de que eso no es el estado natural de las cosas.

No ha sido suerte. Ha sido alguien.

Felicidades, sysadmin. Y que el load average te sea leve.