Advent of SysAdmin 2025

• El calendario de Adviento 2025 para administradores de sistemas es una serie de desafíos de Linux y DevOps de 12 días que se lleva a cabo del 1 al 12 de diciembre
  • Cada día se publica una nueva tarea basada en escenarios con distintos niveles de dificultad
• Los participantes pueden seguir su progreso mediante el registro gratuito de una cuenta (se necesita una cuenta para gestionar puntajes y rankings)
• También se ofrece un escenario que puede probarse sin registrarse, para que cualquiera pueda empezar de inmediato
• Se enfoca en fortalecer las capacidades de resolución de problemas y administración de sistemas en entornos DevOps reales

Escenario de ejemplo: “Auderghem: containers miscommunication”

• Nombre del escenario: “Auderghem: containers miscommunication”
  • Dificultad: Easy
  • Tipo: Fix
  • Método de acceso: requiere verificación por correo electrónico
  • Límite de tiempo: 30 minutos
• Descripción del problema:
  • El contenedor Docker de nginx debe recibir tráfico en el puerto 80 y redirigirlo a dos contenedores distintos (statichtml1, statichtml2), pero no está funcionando
  • El participante debe corregir este problema
  • Todos los contenedores pueden reiniciarse, pero no pueden detenerse ni eliminarse
• Condiciones de prueba:
  • curl http://localhost → “Welcome to nginx”
  • curl http://localhost/1 → “HelloWorld;1”
  • curl http://localhost/2 → “HelloWorld;2”
  • El botón “Check My Solution” ejecuta el script /home/admin/agent/check.sh para validar el resultado

Información sobre la plataforma SadServers

• SadServers, la plataforma proveedora, ofrece escenarios prácticos y de entrevista para resolución de problemas en entornos Linux y DevOps

[roxie]

¡Así que era una historia de un servidor triste! De verdad es una plataforma excelente.

[GN⁺]

Comentarios en Hacker News

• Resume 12 desafíos reales de Sysadmin/DevOps que se viven en el trabajo
  1. Hacer que los usuarios no inicien sesión como root
  2. Acabar con la práctica de que todos los usuarios compartan una sola cuenta y contraseña en todos los servidores
  3. Lograr que alguien actualice las dependencias de su aplicación a una versión posterior a 2010
  4. Hacer que usen herramientas de gestión de configuración en lugar de andar aventando archivos de configuración del laptop al servidor con scp
  5. Hacer que usen imágenes inmutables (immutable image) con la configuración incluida en vez de gestión de configuración
  6. Hacer que dejen Jenkins y se cambien a GitHub Actions
  7. Acabar con la situación de tener las llaves secretas de producción amontonadas en un solo archivo en S3, y hacer que usen un sistema de gestión de secretos
  8. Convencer a directivos y usuarios que dicen: “si por años no ha habido ningún problema, ¿para qué necesitamos un servidor nuevo?”, para
  conseguir la aprobación para comprar servidores nuevos explicando que en realidad todo el hardware está a punto de fallar en fuente de poder, disco, NIC y RAM, y que además ya no hay refacciones
  9. Conseguir de la dirección el permiso para forzar la rotación de una llave de acceso de AWS que no ha cambiado en nada menos que 8 años
  10. Hacer que se detenga la locura de que una aplicación use la llave de acceso de la cuenta root de AWS
  11. Hacer que los usuarios construyan la aplicación como contenedor
  12. Hacer que los usuarios desplieguen por su cuenta sin tu ayuda
  Te tomas un whisky escocés cada vez que completes un reto. ¡Felices fiestas!

  • Sobre el punto 6 de GitHub Actions: hubo un problema donde un worker autenticado desaparecía del pool si quedaba inactivo unos 5 días
    Habían armado un workflow de PR complejo, pero si no había PRs por varios días, de repente se rompía
    En GitHub tampoco había guía ni alternativa al respecto. Para CI, creen que hay soluciones mucho mejores
  • El primer paso para este tipo de problemas es explicar de forma concreta y documentada por qué importa
    La mayoría son obvios, pero no lo son para todo el mundo
  • ¿Cambiar de Jenkins a GitHub Actions?… de verdad no entiendo por qué habría que hacerlo
  • Sobre la frase “Sysadmin/DevOps ahora son sinónimos”, alguien dijo en broma que lo denunció ante las autoridades
  • Los puntos 5 y 6 son cuestión de preferencia y trade-offs, pero con el resto coincide por completo

• En su empresa usan Sad Servers para evaluar candidatos de DevOps/SRE
  Dicen que durante la entrevista genera algo de tensión, pero al final todos comentan que fue una buena experiencia
  Solo mandan el enlace por el chat de Zoom y comparten pantalla, así que la eficiencia de la entrevista es muy alta

  • Qué gusto escuchar eso; a partir de hoy yo también quiero empezar el reto diario de Sad Servers
    Tengo experiencia con homelab y como tech lead en empresas pequeñas, pero todavía no en entornos grandes
    Ahorita estoy enfocado en cerrar huecos de conocimiento y prepararme para certificaciones

• Cuando uno está deprimido y no tiene nada que hacer, suena divertido resolver problemas de Sad Server como si los estuvieras hackeando

• Imagínate querer borrar una palabra en la terminal con Ctrl+w, pero en realidad estás en la ventana del navegador y se te cierra la pestaña… tristeza pura

  • Antes levantaban una terminal en el navegador usando gotty, y todo el equipo remapeó Ctrl+w a Ctrl+`
    Después de año y medio desarrollando en ese entorno, hasta hoy les da miedo que se cierre una terminal real cada vez que presionan Ctrl+w
  • Por eso uno vuelve a agradecer lo bien pensado que está separar la tecla Command en macOS
  • Aun así, con Ctrl+Shift+T puedes reabrir la pestaña cerrada recientemente
  • (Creador) Perdón. Solo hay que volver a hacer clic en el botón “Open the Server Terminal in a New Window”
  • Te entiendo; a mí también me pasa seguido cuando uso KVM

• Últimamente parece que a esto le llaman SRE
  No me gusta que nada más le cambien el nombre para inventar buzzwords

  • Mi definición favorita era: “SRE es tratar las operaciones como un problema de software”
  • A mí tampoco me gustan las buzzwords, pero SRE sí es claramente un rol distinto
  • SRE es el rol encargado de que las aplicaciones sigan funcionando sobre la plataforma
    Maneja herramientas de todo tipo, como recolección de métricas y automatización de despliegues
    En empresas pequeñas el Sysadmin suele llevar también el rol de SRE, pero al crecer la escala se separan claramente

• Parece que el progreso no se guarda

  • (Creador) Que revisen el dashboard y, si aún no funciona, que contacten por correo o por el formulario del sitio

• Les encanta Sad Servers, y están esperando que salga una versión para Windows

  • (Creador) Gracias, y que en algún momento también están considerando una versión para Windows

• Piensan que estaría bien tener una plataforma así también para el ecosistema de contenedores como k8s o Docker

  • (Creador de SadServers) Ya hay escenarios basados en k8s
    También existe una versión que corre en una sola VM, y están experimentando con correrlo por pods en un clúster de k8s para PoC
    Más adelante también planean agregar escenarios de podman

• Sin entrar en spoilers: resolvieron el problema, pero el script de verificación no pasa
  curl funcionaba bien, pero el script forzaba una forma específica de configurar las cosas
  Creen que sería mejor, como en un CTF, validar solo el resultado

  • (Creador) Gracias por el feedback; ya desplegaron una imagen nueva para que solo revise el objetivo
    Una verificación perfecta es difícil, pero siguen mejorando para minimizar los falsos negativos

• (Conversación sobre un comentario eliminado)

  • Alguien mencionó que Advent of Code también requiere cuenta
  • (Creador) En la plataforma solo hay que hacer clic dos veces en Home → “give me a server” y te entrega una VM al instante
    Cree que casi no existen SaaS que te den una VM sin registro
    Agradeció el feedback y dijo que agregó un botón claro en la página /advent
  • También hubo una respuesta medio en broma: “Entonces, ¿cómo querías que funcionara? ¿de verdad eres sysadmin?”