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

Hay una escena que se repite cada mañana en miles de oficinas y 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.

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, está hojeando una revista de Hewlett-Packard. Se encuentra con 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 siempre el último viernes de julio.

Es decir: el día del sysadmin nace del agravio comparativo más legítimo de la historia de la informática. Un tío mirando un anuncio y pensando "oye, pues yo también".

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 literalmente un procedimiento de diagnóstico. DNS falla de una manera especialmente cruel: casi nunca parece DNS. Se manifiesta como "el correo va lento", "la aplicación carga en mi casa pero no en la oficina", "solo falla en un navegador", "va bien pero a ratos". Para cuando has descartado el firewall, la red, el proveedor y la posición de los planetas, resulta que un TTL, un registro caducado o un punto y coma mal puesto 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. Un cambio en la configuración del backbone hizo que BGP retirara las rutas hacia sus propios servidores DNS. Resultado: el dominio dejó de resolver. Facebook, Instagram y WhatsApp caídos a la vez, unos 3.500 millones de usuarios mirando la pantalla y recargando por si acaso.

Pero la mejor parte —la parte que todo sysadmin cuenta con lágrimas en los ojos— es la siguiente: la caída se llevó por delante los sistemas internos. Las tarjetas de acceso dejaron de funcionar. Había gente que no podía entrar físicamente al edificio donde estaba la avería que tenían que arreglar. (Circuló la leyenda de la radial para abrir las jaulas de servidores; la empresa lo desmintió con inusual precisión.)

Doble moraleja, y las dos valen para tu empresa:

1. Era DNS. Siempre es DNS.
2. Tu plan B no puede depender del sistema que se ha caído. Si la contraseña de emergencia está en el gestor de contraseñas que necesita SSO, y el SSO está caído, no tienes un plan B: tienes un dibujo de un plan B.

Julio de 2024: el mes en que se vio 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.

Viernes, cómo no.

CrowdStrike publicó un fichero de actualización a las 04:09 UTC. Lo retiró a las 05:27 UTC. Setenta y ocho minutos. En ese rato, 8,5 millones de equipos Windows entraron en pantallazo azul y bucle de reinicio: aeropuertos, hospitales, bancos, cadenas de televisión, supermercados.

Lo demoledor no fue el fallo. Fue el arreglo.

La solución se supo enseguida y era ridículamente sencilla: arrancar en modo seguro, borrar un fichero, reiniciar. El problema es que el equipo no arrancaba, así que no se podía desplegar nada. Había que ir máquina por máquina. Ocho millones y medio de veces. A mano.

Y la guinda del pastel: muchos de esos equipos tenían BitLocker y pedían la clave de recuperación de 48 dígitos. Muchas de esas claves estaban guardadas en servidores que, sorpresa, también estaban en pantalla azul.

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

GitLab, 2017: cinco redes de seguridad, ninguna atada

El otro clásico obligatorio, porque es el mejor recordatorio de que esto le pasa a todo el mundo.

31 de enero de 2017, cerca de las 23:00 UTC. Un ingeniero de GitLab lleva horas peleándose con una incidencia de carga y una replicación que no arranca. Decide borrar el directorio de datos del servidor secundario para empezar de cero.

Escribe el rm -rf. Lo ejecuta. 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 en pocos segundos.

Entonces tocaba tirar de backups. GitLab tenía cinco mecanismos distintos de copia y replicación. En el postmortem lo dejaron por escrito con una honestidad brutal: ninguno de los cinco funcionaba de forma fiable o estaba realmente configurado. Cinco redes de seguridad, y ninguna atada al suelo.

Se salvaron por pura chiripa: seis horas antes, alguien había lanzado una snapshot manual por si acaso. Aun así se perdieron seis horas de datos —unos 5.000 proyectos, 5.000 comentarios y 700 cuentas nuevas.

Y aquí viene lo que de verdad merece un aplauso: en lugar de esconderse, retransmitieron la recuperación en directo por YouTube, con miles de personas mirando por encima del hombro y 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.

• «¿Tienes un segundo?» — Nunca es un segundo. Y si estaba a mitad de algo delicado, ese segundo cuesta veinte minutos de volver a cargar en la cabeza lo que tenía montado.
• «No funciona nada.» — Falta el 90% del ticket: qué no funciona, desde cuándo, en qué equipo, qué salía exactamente en pantalla y si te ha dado tiempo a hacer una captura. Sin eso, la incidencia se resuelve por telepatía, y la telepatía tiene mala cobertura.
• «Es que antes iba bien.» — Sí. Y ese "antes" contiene una actualización, un cambio de contraseña, una VPN nueva y un cable que alguien movió al pasar la aspiradora.
• «Solo necesito permisos de administrador un momentito.» — La frase que abre el 80% de los postmortems del sector.
• «He reiniciado el servidor por si acaso.» — Enhorabuena: acabas de hacer un cambio en producción sin ventana de mantenimiento, sin aviso y sin plan de vuelta atrás. Justo lo que él lleva diez años evitando.
• «¿Lo subimos hoy? Es viernes, pero es un cambio pequeño.» — No existe el cambio pequeño. Existe el cambio cuyo impacto todavía no conoces. Y el viernes existe para descubrirlo el sábado a las tres de la mañana.
• «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. Se invirtieron cientos de miles de millones y miles de profesionales se pasaron años revisando código 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 de la que ya hablé en «No necesito mantenimiento web»: cuando el trabajo consiste en que no ocurra el problema, el éxito es indistinguible de la suerte. Y la suerte, curiosamente, 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. Un buen ticket 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. Todo eso es lo que evita la reunión mala.
• Respeta sus ventanas de mantenimiento. Esa hora rara en la que actualiza es la hora rara en la que tú duermes tranquilo.
• No despliegues en viernes. Y menos este viernes 31.
• 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. Ese load average 0,04 es la traducción a números de "no ha pasado nada", que es el mejor titular que puede dar un sistema.

(Y sí: 1.247 días de uptime hace tiempo que dejaron de ser un motivo de orgullo para convertirse en un CVE esperando su momento. Pero para la foto quedan preciosos.)

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.