Las guardias son una de esas decisiones que se toman en una reunión de treinta minutos y condicionan la vida del equipo durante años. Se reparte el teléfono entre los que saben, se acuerda una compensación y se da por resuelto. El problema aparece dieciocho meses después, cuando las dos personas que sostenían el sistema se van con seis semanas de diferencia.
El coste real no está en la nómina
Cuando se calcula lo que cuesta una guardia se suma el complemento de disponibilidad y poco más. Esa cuenta ignora la partida más cara: la rotación de personal.
Sustituir a una persona de ingeniería con contexto del sistema cuesta, entre proceso de selección, curva de aprendizaje y productividad perdida del equipo que la acompaña, varios meses de su salario. Si el diseño de las guardias provoca una sola salida evitable al año, ha costado más que cualquier inversión razonable en automatizar alertas.
Hay además un coste silencioso: quien ha dormido mal tres noches escribe peor código el resto de la semana. No aparece en ningún panel, pero está en la tasa de fallos.
El tamaño de la rotación decide casi todo
Es la variable con más impacto y la que menos se discute. Con una rotación de tres personas, cada una está de guardia una semana de cada tres: eso no es un complemento ocasional, es una condición laboral permanente que ninguna compensación razonable equilibra.
El umbral práctico está en seis personas o más. Una de cada seis semanas es asumible y sostenible en el tiempo. Por debajo de ese número, la conversación honesta no es cómo compensar la guardia: es si el servicio necesita realmente cobertura fuera de horario, o si se puede definir una ventana de atención más estrecha y aceptar formalmente el riesgo del resto.
Y si el equipo no da para seis, hay dos salidas legítimas: compartir la rotación con otro equipo mediante formación cruzada, o externalizar la primera línea. Lo que no es una salida es repartir el dolor entre tres personas y confiar en su profesionalidad.
Despertar a alguien tiene que estar justificado
La regla es sencilla de enunciar y difícil de sostener: si una alerta no exige que un humano actúe ahora, no es una alerta. Es un registro, o como mucho un aviso para el día siguiente.
El deterioro llega despacio. Se añade una alerta tras un incidente para que no vuelva a pasar desapercibido. Luego otra. Al cabo de un año hay ochenta reglas, la mitad se disparan sin que nadie haga nada, y el equipo ha aprendido a mirar el móvil y volver a dormirse. Ese es el punto en el que las guardias dejan de proteger el servicio y solo desgastan a la gente.
El criterio que aplicamos: se alerta sobre síntomas que nota el cliente, no sobre causas internas. La CPU al 90% no es un problema si el servicio responde. La latencia por encima del objetivo comprometido sí lo es. Vincular las alertas a objetivos de nivel de servicio acordados con negocio reduce el ruido drásticamente y, además, convierte cada aviso en algo que se puede explicar fuera del departamento técnico.
La parte formal
Conviene tener por escrito, y acordado con quien corresponda en la organización, cuatro cosas: qué compensación tiene la disponibilidad, qué compensación tiene la intervención efectiva, qué descanso corresponde tras una noche de trabajo real, y cuál es el procedimiento de escalado cuando la persona de guardia no puede resolverlo sola.
Ese último punto es el que más se olvida y el que más ansiedad genera. Saber a quién se puede llamar a las cuatro de la mañana sin sentir que se está molestando cambia por completo la experiencia de estar de guardia.
Qué medir
- Avisos fuera de horario por turno. Si la mediana pasa de dos o tres, hay un problema de diseño, no de mala suerte.
- Porcentaje de avisos que requirieron acción. Por debajo del 70% se está entrenando al equipo para ignorar las alertas.
- Avisos repetidos. El mismo problema tres veces es trabajo pendiente que se está pagando en noches en vez de en horas de oficina.
Revisar estos tres números una vez al mes, en una reunión corta y con capacidad de decidir, es lo que separa una rotación que mejora de una que se degrada.
¿Vuestras guardias se están volviendo insostenibles? Hablemos de cómo están montadas →
Sigue leyendo
- Postmortems sin culpables: convertir una caída en mejora real
- Cuatro métricas para saber si tu DevOps funciona de verdad
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.