Es trabajar de administrador de sistemas linux (servidores) en remoto la verdadera saluc?

El mito del sysadmin que vive en calzoncillos​

Levantarse a las tantas, conectarse por SSH con clave pública/privada al servidor de turno, comprobar que los servicios (servidor web, MySQL) funcionan, actualizar repositorios y parches, dejar una aplicación de monitorización con alertas programadas y ponerse a ver una película hasta que acabe el turno. Ese es el relato que abre el debate: el administrador de sistemas linux en remoto como el trabajo soñado, sin interactuar con nadie, mientras el desarrollador de aplicaciones se quema el cerebro aprendiendo frameworks que mutan cada año. La discusión, sin embargo, se rompe en mil pedazos en cuanto alguien que ha estado de guardia de verdad coge el teclado.

La jornada que nunca termina​

El primer golpe al relato es el horario. La jornada del administrador de sistemas no acaba a las seis. Quien ha cubierto guardias reales describe noches enteras sin dormir: intervenciones a las 02:00, avisos a las 04:00 y una última llamada a las 06:30 que ya te impide recuperar el sueño, así que te metes un café doble y empiezas a sacar el trabajo acumulado del día anterior. Todo ello, además, con responsables que no entienden por qué no has terminado lo que tenías pendiente.

A eso se suma que las averías no avisan. Un disco duro puede freírse en cualquier momento; un servidor puede recibir un ataque a una hora aleatoria. La monitorización existe precisamente para avisar de esos problemas, lo que implica que alguien tiene que reaccionar rápido, a cualquier hora. El programador, en cambio, tiene un horario y cuando acaba desconecta. El administrador de sistemas queda disponible de forma permanente, y esa disponibilidad es la que rompe la vida personal.

El día que todo se cae a la vez​

La imagen del técnico rascándose la barriga dura hasta la primera avería. Cuando un servicio se cae sin motivo aparente, no arranca y nadie ha tocado nada, empieza la fiesta. Y no suele venir sola: dos máquinas caídas a la vez, un ataque, una pérdida de rendimiento, otra avería encadenada. Hay quien describe ese tramo como una pérdida de cuatro kilos de peso en pocos días y la constatación de que el trabajo no es lo que parecía.

El cálculo más optimista asume que, con los deberes hechos, una guardia puede ser relajada. El escenario pesimista parte de que la observabilidad y los indicadores existen precisamente porque un sistema puede funcionar «sin errores» y aun así tener la tasa de éxito en la miseria por una configuración errónea. Nadie discute que las guardias se paguen; se discute si el precio es solo económico.

¿Es un trabajo con techo o una base sólida?​

El segundo frente es el salarial y de carrera. Un administrador de sistemas, se argumenta, tiene un crecimiento limitado: mantiene lo que otros crean, no revaloriza su trabajo, y su figura se parece más a la de un funcionario de la informática que a la de un emprendedor. Un desarrollador, en cambio, puede crear una aplicación y venderla a miles de usuarios. Esa asimetría es real, aunque también lo es que el desarrollador se come las horas extra cuando llegan los plazos.

Frente a esa visión, hay quien sostiene que el trabajo se ha complejizado hasta extremos que el relato inicial ni imagina: identidades en la nube, pipelines de integración y despliegue continuos, contenedores, alta disponibilidad y escalado. Lo que antes hacía un becario el primer día —crear directorios, inicializar servicios, gestionar certificados— hoy es solo el punto de partida de una cadena de herramientas que se pelean entre sí. El cálculo completo, con todas las capas que entran en juego, da una foto bastante menos amable que la del técnico viendo películas.

Monitorización, observabilidad y el arte de renombrar la rueda​

Una de las derivadas más curiosas del intercambio es la discusión sobre la jerga. Lo que la industria llama observabilidad, se argumenta, no es más que la supervisión continua que los sistemas SCADA industriales llevan décadas haciendo: captura de datos históricos, alarmas cuando un parámetro sale de rango y control del proceso. La diferencia, dicen, es que ahora se le añade la capa de negocio —cuántos pedidos entran, cuántos se pierden, cuánto dinero se va por el desagüe— y se le pone un grafana más bonito. Reinventar la rueda y ponerle nombre nuevo, resumen, es una tradición del sector.

El perfil que de verdad sostiene el sistema​

Más allá del sueldo y las guardias, el retrato que emerge es el de un profesional que automatiza tareas con scripts y herramientas propias mientras otros siguen picando hojas de cálculo durante semanas. Un trabajo que puede ser simple y mal pagado o complejo y pagado solo con detalles, pero que en cualquier caso exige estar midiendo constantemente, aunque no haya alarmas. La pregunta, al final, no es si el trabajo es cómodo. Es si alguien quiere ser el que sostiene la infraestructura cuando todo lo demás falla, sabiendo que el teléfono puede sonar a las tres de la mañana.