Cómo reducir el burnout del on-call en equipos SRE

El problema real del on-call en SRE

El on-call —la práctica de tener un ingeniero disponible 24/7 para responder a incidentes— es fundamental para mantener sistemas de alta disponibilidad. Pero en la mayoría de equipos, se ha convertido en una fuente importante de burnout, rotación y problemas de salud.

Según el SRE Workbook de Google, los equipos sanos no deberían recibir más de 2-3 alertas accionables por turno de guardia. La realidad en la mayoría de organizaciones es radicalmente diferente: 20-50 alertas por turno, muchas de ellas en horario nocturno.

Las consecuencias son predecibles:

• Privación crónica de sueño durante las semanas de guardia
• Ansiedad anticipatoria que empieza días antes del turno
• Desensibilización hacia las alertas (que paradójicamente aumenta el riesgo)
• Ingenieros senior que buscan trabajo en empresas “donde el on-call sea razonable”

La ironía es que un equipo agotado responde peor a los incidentes reales. El on-call abusivo no solo destruye la vida de los ingenieros: también aumenta el MTTR.

Métricas de salud del on-call

Antes de implementar mejoras, necesitas una línea base. Estas son las métricas que todo equipo SRE debería rastrear:

Alertas por turno de guardia

Objetivo: menos de 5 alertas accionables por turno de 12 horas. Si estás en 20+, tienes un problema estructural de ruido.

% de alertas nocturnas que requieren acción

Si menos del 20% de las alertas que despiertan a alguien resultan en una acción real, el sistema está dañando a tu equipo de forma innecesaria.

MTTR por persona (correlacionado con hora del día)

Los incidentes a las 3am tardan más en resolverse que los de las 10am. ¿Cuánto más? Esa diferencia te dice el coste real de la privación de sueño en tu sistema.

Satisfacción del on-call (eNPS)

Una encuesta simple después de cada turno: “¿Recomendarías este equipo a un amigo en cuanto a la carga de on-call?” Medir la tendencia mes a mes es más útil que el valor absoluto.

Estrategia 1: Reducir el volumen de alertas

La mayoría de equipos intentan gestionar el burnout del on-call mejorando los procesos de escalada o la documentación de runbooks. Eso ayuda marginalmente. El cambio estructural viene de reducir el volumen en origen.

Las tres acciones con mayor impacto:

Eliminar alertas que se autoresuelven

Analiza qué porcentaje de tus alertas de los últimos 30 días se resolvieron solas sin intervención. Si esa métrica supera el 50%, tus umbrales están mal calibrados.

Agrupar eventos del mismo incidente

Un deployment fallido puede generar 40 alertas simultáneas. Sin deduplicación, tu ingeniero de guardia recibe 40 notificaciones para un único problema. Implementar ventanas de agrupación de 5 minutos puede reducir el volumen en un 60-70%.

Filtrado inteligente con IA

La deduplicación manual no escala con el crecimiento del sistema. La solución sostenible es añadir una capa de IA que evalúe la criticidad real de cada alerta antes de escalarla al equipo de guardia.

Estrategia 2: Clasificar por impacto real en negocio

No todas las alertas deberían despertar a alguien a las 3am. La clasificación por impacto de negocio determina qué alertas son realmente urgentes fuera del horario laboral:

• P0 — Despertar inmediato: Afecta directamente a usuarios pagando o a la seguridad de datos
• P1 — Despertar en 15 minutos: Degradación significativa de un servicio de cara al usuario
• P2 — Notificación sin despertar: Anomalía que requiere atención en horario laboral
• P3 — Registro para revisión: Todo lo demás

El error más común es tener todo en P1 o P2 “por si acaso”. Eso hace que en la práctica nadie diferencie entre severidades y todo se trate como ruido.

Estrategia 3: Mejorar el proceso de escalada

Incluso con volumen reducido, el proceso de escalada importa. Los principios clave:

Contexto antes de despertar

La alerta debería llegar con toda la información necesaria para empezar la investigación: causa probable, historial del servicio, últimos deploys relacionados, runbook relevante. Despertar a alguien para que luego pase 20 minutos buscando contexto es un fracaso de diseño.

Handoff estructurado

Al final de cada turno de guardia, un documento de handoff de 5 minutos: qué pasó, qué se investigó, qué queda pendiente. Sin este documento, el siguiente turno empieza sin contexto.

Postmortems para incidentes menores

Los equipos tienden a hacer postmortems solo para incidentes mayores (P0). Los incidentes menores repetitivos son los que más se benefician del análisis: indican un patrón sistémico que con frecuencia precede a un incidente mayor.

Herramientas que marcan la diferencia

El stack mínimo para un on-call saludable en 2026:

• Filtrado inteligente de alertas (centinelAI): Reduce el volumen y añade contexto antes de escalar
• Gestión de on-call rotativo: PagerDuty o similar para distribución equitativa de turnos
• Runbooks vivos: Confluencia, Notion o equivalente con procedimientos actualizados
• Slack con integración de incidentes: Canal dedicado con acciones directas (snooze, declarar incidente) sin salir de la aplicación

La combinación de filtrado inteligente de alertas con un buen proceso de escalada puede reducir la carga del on-call en un 80-90%, pasando de “tortura semanal” a “inconveniencia manejable”.