Loading
En los últimos años observo cada vez con mayor frecuencia el mismo argumento en el sector: la necesidad de “superar” a un supuesto perfil de profesional anclado en el pasado.
El personaje del sysadmin purista es caricaturizado como el del kernel compilado a mano, el que convierte cada instalación en un ritual de dolor y desprecia cualquier herramienta que reduzca fricción. El problema es simple: ese perfil, tal como se lo suele describir, prácticamente no existe en entornos productivos desde hace más de una década, y cuando se construyen discursos enteros para combatir fantasmas, el resultado no es claridad, sino ruido.
Compilar el kernel nunca fue el objetivo
Un punto frecuente de estos argumentos es la compilación del kernel como el sustento del antiguo sysadmin. Compilar el kernel nunca otorgó “el pan de cada día” al trabajar en producción.
Fue —y sigue siendo— una operación de último recurso, una necesidad puntual en escenarios muy concretos (hardware específico, restricciones corporativas, requisitos regulatorios), o una actividad de aprendizaje, experimentación u ocio/hobby. Confundir eso con práctica profesional habitual es mezclar contextos que nunca estuvieron pensados para convivir.
Incluso cuando Linux era más áspero, la tendencia siempre fue reducir fricción, no glorificarla. Que una distro avanzada se volviera más fácil de instalar fue celebrado. Que las distros generalistas priorizaran estabilidad y repetibilidad fue una victoria tecnológica, no una derrota ideológica. Las distribuciones deliberadamente “difíciles” siempre fueron nichos: laboratorios, entornos personales, aprendizaje dedicado, o tuning muy específico. No el estándar de una empresa que paga salarios estándares y necesita resultados repetibles.
El falso dilema del ROI y el dolor
Aquí suele aparecer un argumento protagonizado por una víctima que se volvió típica: “El ROI no entiende de purismos”, lo cual, realmente, concretamente, nadie discute. Pero tampoco entiende de caricaturas.
ROI significa Retorno de Inversión, por su sigla en inglés que significa “Return on Investment”
La imagen del sysadmin que invierte horas en ganar un 1% de rendimiento “teórico” en producción no describe una práctica real. Describe un relato diseñado para parecer razonable mientras no apunta a nada real.
En el mundo en que vivimos, si alguien hace eso:
- El contexto lo exige,
- es parte de un experimento controlado,
- o no está en el puesto correcto. El pragmatismo no es nuevo. Siempre estuvo ahí. Lo que ha cambiado no es la mentalidad, sino las herramientas disponibles.
Mascotas, ganado, religiones y falsas dicotomías
En las nuevas generaciones de DevOps se habla de que la nueva forma de operar infraestructura es tratar a los servidores como ganado (cattle, en inglés), mientras que los “sysadmins antiguos” los trataba como mascotas (pets, en inglés). El paso del modelo pets al modelo cattle fue útil para explicar un cambio de escala, no para invalidar todo lo anterior.
Tratar servidores como “mascotas” no significaba mimarlos constantemente. Significaba automatizar hasta que dejaran de hacer ruido. Cuanto menos se sabía de ellos en el día a día, mejor estaba hecho el trabajo. El administrador de sistemas conocía el servidor de punta a punta, y en el momento que el servidor pestañeaba raro, el administrador sabía exactamente qué estaba pasando. Minimizando el downtime de manera preventiva. Adelantándose a las catástrofes. Mientras tanto, hoy el modelo cattle requiere de dashboards, monitoreo, y reactividad en base al monitoreo continuo. Sólo el ojo entrenado puede anticiparse a lo que el dashboard va a mostrar.
Y con los avances, llegan las modas: El modelo cattle se volvió credo, utilizándose como regla para prácticamente cualquier escenario. Hoy abundan contextos donde el modelo cattle es excesivo, prematuro o directamente más caro. No todo problema necesita un clúster. No toda empresa necesita operar como si fuera Google. Entender eso es parte de la madurez profesional.
Seniority no es antigüedad. Definitivamente no es moda.
La madurez profesional no se mide por el sufrimiento invertido en una solución que no escala. De la misma manera, la madurez va en contra de la adopción acrítica de lo “moderno”. Se mide por:
- criterio,
- lectura de contexto,
- elección correcta de escala,
- y responsabilidad sobre las consecuencias técnicas y de negocio.
Es normal escuchar gente jactándose de crear un ambiente de Kubernetes en escasos minutos. Esto puede ser una genialidad o un error estratégico; después alguien tiene que mantenerlo, y el cliente tiene que poder entender la solución para poder tomar decisiones de negocio más adelante. Aplicar soluciones industriales a problemas pequeños no es pragmatismo: es marketing ganándole a la ingeniería.
En una avenida de dos vías: simultáneamente depende y afecta el problema, el equipo, el horizonte y el costo real.
El sistema operativo nunca dejó de importar
Hoy en día se dice que “el sistema operativo ya no es el fin, sino solo la plataforma”. Suena bien, pero es engañoso.
El sistema operativo siempre fue la base. Nada se ejecuta “en el aire”. Desde los celulares que usamos día a día, pasando por los contenedores, orquestadores, funciones serverless: Todo descansa sobre decisiones que siguen siendo profundamente operativas: kernel, red, almacenamiento, aislamiento, observabilidad. Lo que cambió no fue la importancia del sistema operativo, sino cuánto trabajo manual nos exige. Y eso es progreso, no ruptura.
Conclusión
El mayor problema de este tipo de discursos no es técnico. Es cultural.
Se construye una figura obsoleta para marcar distancia, para redefinir estatus, para trazar una nueva línea divisoria: antes sysadmins vs desarrolladores, ahora devops vs sysadmins. Es una pelea innecesaria, porque los buenos profesionales ya cruzaron esa frontera hace años.
La industria no “superó” a los sysadmins. La habitan quienes entendieron el contexto, automatizaron los puntos de fricción y asumieron nuevas responsabilidades. El resto es ruido posmoderno.
){kind=link}