Llevas años en esto. Sabes lo que es quedarte dormido con el teléfono encima de la almohada, con un ojo abierto y el otro rezando para que no suene. O el finde que empiezas con planes y acabas conectado al VPN desde el coche porque hay una alerta que no espera. Eso es el oncall (estar de guardia como SysAdmin), y conviene hablar de ello con honestidad, porque en muchas empresas es uno de los temas peor gestionados que existen.
No todo oncall es igual, y eso importa mucho
Hay una diferencia enorme entre hacer reten en un entorno donde los sistemas son estables, la carga es liviana y en un mes entero recibes dos llamadas… y otro donde cada noche tienes alertas, incidentes reales o señales falsas que igualmente te obligan a levantarte a las tres de la madrugada a revisar logs.
El primer caso es asumible. Una molestia, sí, pero manejable. El segundo es insostenible. Y lo curioso es que en muchas organizaciones conviven los dos modelos sin que nadie haga esa distinción. Se trata el oncall como un concepto homogéneo cuando en realidad puede ser la diferencia entre algo tolerable y algo que quema a las personas.
Y ojo, no hablamos solo de noches. Los fines de semana son otra dimensión del problema. Tienes tus planes, tu vida, tu familia, y llevas el teléfono contigo a todas partes como si fuera un grillete digital. Eso tiene un coste que no siempre aparece en las hojas de cálculo de recursos humanos.
El técnico que trabaja por la noche y también por el día
Aquí está una de las grandes asignaturas pendientes: ¿qué pasa al día siguiente?
Hay empresas que lo tienen claro: si te llamaron durante el oncall, al día siguiente no trabajas, o trabajas menos. Punto. Es lo lógico, es lo humano y además es lo inteligente desde el punto de vista operativo, porque un técnico con cuatro horas de sueño tomando decisiones sobre sistemas críticos es un riesgo real.
Y luego hay empresas que no contemplan eso. El técnico aguanta la noche como puede y a las nueve entra como si nada. Y claro, eso se puede hacer una semana, quizás dos, pero no es sostenible. Hay quienes llevan años en esto y describen lo que algunos han llamado «IT PTSD»: el sonido de un teléfono sonando provoca ansiedad y miedo incluso años después de haber dejado atrás esos turnos. No es metáfora, es una consecuencia real de haberlo gestionado mal durante demasiado tiempo.
He visto casos en los que el propio volumen de incidentes nocturnos obligó a la empresa a replantear todo el modelo. Al final hubo que crear turnos de trabajo reales con horario nocturno, porque la carga no era compatible con que una persona «estuviera disponible» de fondo mientras descansaba. Cuando la carga es constante, lo que tienes no es un oncall, tienes un turno de noche disfrazado de guardia. Y llamarlo de otra forma no lo hace más sostenible.
Lo que no está delimitado, se convierte en un problema
Uno de los errores más comunes en la gestión de guardias es no definir bien qué es crítico y qué no lo es.
Parece obvio, pero cuesta de aplicar. Al final, por inercia, por falta de criterio o porque nadie quiere ser el responsable de decir «esto no se atiende fuera de horario», el oncall acaba recibiendo de todo. Alertas de sistemas que no son críticos para el negocio, avisos de bajo riesgo, notificaciones que perfectamente podrían esperar a primera hora del día siguiente.
Si los técnicos de guardia reciben constantemente páginas por problemas que no son urgentes, acaban desarrollando resentimiento hacia el trabajo. Y lo que es peor: pueden llegar a ignorar o silenciar alarmas por pura fatiga, con el riesgo de que esa vez sea una alerta real. Es el clásico cuento del pastor que gritó «¡lobo!» demasiadas veces.
Si hay un departamento de operaciones o un NOC, tiene que estar claro para qué se llama a guardia y para qué no. Esa definición es tan importante como cualquier runbook técnico.
La documentación para guardias: otra guerra
Documentación. Esa gran batalla.
Conviene separar dos cosas que a veces se mezclan: la documentación técnica general de los sistemas, que es extensa, detallada y necesaria para el día a día, y la documentación específica para guardias, que es otra cosa completamente distinta.
En mitad de la noche no tienes tiempo ni ganas de leer un manual de trescientas páginas. Lo que necesitas es una referencia rápida: qué hacer si pasa X, cómo escalar si la cosa se complica, qué sistemas dependen de qué. Una checklist clara, concisa y validada. Pocas cosas, pero las correctas.
Y el escalado. Saber a quién llamar y cuándo, sin ambigüedades, especialmente cuando el problema supera lo que el técnico de guardia puede resolver solo. Eso no es una señal de debilidad, es parte del protocolo. Pero claro, solo tiene sentido si de verdad estamos hablando de sistemas críticos para el negocio o la entidad. Si no lo son, quizás la pregunta es por qué existe esa guardia.
Apagar fuegos está bien, pero hay que analizar las causas
Esto lo he visto muchas veces y es una mala práctica que se instala sin que nadie lo decida conscientemente.
El técnico de guardia recibe la alerta a las dos de la mañana, hace lo que puede, el servicio vuelve a levantarse y todo el mundo a dormir. Perfecto. Hasta que la misma alerta vuelve tres noches después. Y la siguiente semana. Y así.
Resolver el síntoma en caliente es necesario, nadie dice que no. Pero si al día siguiente, en frío y con el equipo completo, nadie analiza qué pasó, por qué pasó y cómo evitar que vuelva a pasar, ese incidente se convierte en recurrente. Y cada vez que se repite, hay alguien que pierde horas de sueño por algo que podría haberse evitado.
El análisis post-incidente no es burocracia, es lo que marca la diferencia entre un equipo que aprende y uno que repite los mismos errores de forma indefinida.
El experto del equipo: el que siempre acaba cargando
Hay un patrón que se da en casi todos los equipos técnicos: el que más sabe acaba pagando un precio desproporcionado.
No importa si no está de guardia esa noche. Si hay un problema gordo, le llaman. Porque es el que sabe. Porque da confianza. Porque «un momento, que te lo pregunto a ti». Y esa persona acaba siendo la red de seguridad informal de todo el equipo, con la carga que eso conlleva y generalmente sin ningún reconocimiento adicional.
Un testimonio habitual en foros técnicos es el de quienes recuerdan que, en un momento dado, se convirtieron en la persona a la que todo el mundo llamaba cuando algo se rompía. Al principio se sentía bien, incluso halagador. Luego se dieron cuenta de que no podían desconectar sin que les asaltara la ansiedad de qué podría estar fallando en su ausencia.
Conozco esa sensación. Y si tú también la conoces, sabes perfectamente de lo que hablo.
Un poco de perspectiva honesta
El oncall es necesario. Igual que hay guardias en los hospitales, hay sistemas que no pueden quedarse sin atención fuera del horario laboral. Eso es una realidad, y negarlo sería absurdo.
Pero necesario no significa que haya que gestionarlo mal. Y en muchos sitios se gestiona fatal: sin definición clara de criticidad, sin compensación real, sin análisis posterior de incidentes, sin documentación útil y, sobre todo, sin contemplar el impacto en las personas.
Si te toca hacer oncall en un puesto, lo primero es intentar tenerlo claro antes de aceptarlo: ¿cuánta carga real tiene esa guardia? ¿Hay compensación si hay llamadas? ¿Qué pasa al día siguiente? ¿Existe documentación de emergencia o vas a improvisar solo a las tres de la madrugada?
La calma en un incidente nocturno se entrena y se aprende, sí. Pero también hay empresas donde, por muy tranquilo que estés y por mucho que hagas las cosas bien, el sistema está tan mal diseñado que no hay forma de que salga bien para el técnico. Y en ese caso, tal vez la pregunta no es cómo sobrevivir al oncall, sino si ese es el sitio donde quieres seguir estando.
Seamos honestos: a veces la respuesta es que no.
¿Tienes tus propias historias de oncall, las buenas y las malas? Me las puedes dejar en los comentarios. Este es un tema del que conviene hablar más.