Gestión de Alertas: Alertas en Guardia que Funcionan

Descripción General

Las alertas son la forma en que tus sistemas te indican que algo necesita atención. Hechas mal, crean ruido, agotamiento y respuesta más lenta a incidentes. Hechas bien, dan a la persona correcta la información correcta en el momento correcto para que pueda actuar con decisión.

Esta guía cubre diseño de alertas, clasificación de severidad, estructuras de guardia, políticas de escalamiento y las prácticas operativas que mantienen sano un programa de alertas a lo largo del tiempo.

Cuándo Usar

La gestión de alertas va encima del stack de monitorización — si aún lo estás montando, empieza por la Guía Completa de Monitorización y Alertas y vuelve. Usa esta guía cuando:

• Tu equipo recibe más de 5 alertas por persona por semana
• Las alertas son ignoradas con frecuencia o tratadas como ruido
• Las alertas críticas se pierden por el volumen
• Estás estableciendo o rediseñando una rotación de guardia
• La fatiga de alertas está causando agotamiento o rotación de personal

No aplica si todavía no tienes métricas ni logs sobre los que alertar, o si los incidentes te llegan por quejas de usuarios — arregla primero la observabilidad.

Conceptos Clave

Concepto	Descripción
Fatiga de Alertas	Desensibilización causada por demasiadas alertas de bajo valor
Severidad	Clasificación de urgencia de alerta (crítica, advertencia, info)
Escalamiento	Enrutar automáticamente alertas no reconocidas al siguiente respondedor
Rotación de Guardia	Responsabilidad programada para respuesta a incidentes
Presupuesto de Alertas	Volumen máximo de alertas aceptable por período
Runbook	Guía paso a paso para responder a una alerta específica

Niveles de Severidad

La severidad mapea al impacto en el usuario, no a lo ruidosa que es la métrica. Ata cada nivel a qué debe hacer el respondedor y en cuánto tiempo — la plantilla de runbook de respuesta a incidentes encaja bien aquí.

Nivel	Nombre	Tiempo de Respuesta	Canal	Ejemplo
P1	Crítica	5 minutos	Página/SMS	Servicio caído, impacto en ingresos, pérdida de datos
P2	Alta	30 minutos	Página/Slack	Rendimiento degradado, interrupción parcial
P3	Media	4 horas	Slack/Email	Umbral de capacidad, anomalía no urgente
P4	Baja	1-2 días hábiles	Ticket	Limpieza necesaria, optimización no urgente
P5	Info	Ninguno	Solo dashboard	Métricas para contexto, no requiere acción

Principios de Diseño de Severidad

• P1 significa dejarlo todo y responder inmediatamente
• P2 significa responder dentro del período laboral actual
• P3 e inferiores no paginan; crean tickets o mensajes de Slack
• Si todo es P1, nada es P1
• Revisa la distribución de severidad mensualmente; apunta a <10% P1

Una prueba útil para cualquier alerta propuesta: escribe qué haría realmente el respondedor cuando dispare. Si la respuesta honesta es “mirar un dashboard”, pertenece a P5 — al dashboard, no al pager.

El Ciclo de Vida de una Alerta

Gestión de Alertas Paso a Paso

1. Diseña Alertas que Importan

Cada alerta debe ser accionable e impactar al usuario:

# Ejemplo: Reglas de alerta de Prometheus con severidad

groups:
  - name: service_alerts
    rules:
      # P1: Servicio orientado al usuario está caído
      - alert: ServiceDown
        expr: up{job=~"api|web|payment"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.job }} is down"
          runbook_url: "https://wiki/runbooks/service-down"

      # P2: Tasa de error elevada pero servicio aún responde
      - alert: HighErrorRate
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > 0.05
        for: 5m
        labels:
          severity: high
        annotations:
          summary: "High error rate in {{ $labels.service }}"

      # P3: Advertencia de capacidad — no requiere acción inmediata
      - alert: DiskSpaceWarning
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15
        for: 10m
        labels:
          severity: medium
        annotations:
          summary: "Disk space low on {{ $labels.instance }}"

      # P4: Informativo — seguimiento pero no pagina
      - alert: HighMemoryUsage
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
        for: 30m
        labels:
          severity: low
        annotations:
          summary: "High memory usage on {{ $labels.instance }}"

Checklist de Diseño de Alertas

• Alerta sobre síntomas que sienten los usuarios (errores, latencia), no causas (disco lleno)
• Cada alerta P1/P2 debe tener un enlace a runbook
• Usa for: para prevenir oscilación (requiere falla sostenida)
• Incluye summary y description que digan al respondedor qué revisar
• Añade labels para servicio, entorno, equipo y severidad

Dos patrones mantienen el volumen bajo sin perder cobertura. Alerta sobre síntomas, no causas: ServiceDown dispara cuando los usuarios ven errores; DiskSpaceWarning se queda en P3 porque un disco al 85% no daña a nadie hoy. Deduplica por incidente: si mueren 50 pods a la vez, el respondedor necesita una página (“deployment X no disponible”), no cincuenta.

2. Construye Rotaciones de Guardia

Diseña rotaciones justas y sostenibles:

Tipo de Rotación	Mejor Para	Estructura
Primario/Secundario	Equipos pequeños (3-6)	Un primario, un respaldo
Follow-the-sun	Equipos globales	Turnos de 8 horas entre zonas horarias
Rotación semanal	Equipos medianos (6-12)	Una semana de guardia, 3-5 semanas de descanso
Rotación diaria	Equipos grandes (12+)	Un día de guardia, resto de semana de descanso

Prácticas de Rotación

• Limita la frecuencia de guardia a no más de 1 semana en 4
• Asegura que el traspaso entre turnos incluya incidentes activos
• Compensa el tiempo de guardia (pago o tiempo libre)
• Permite exclusión por eventos personales con cobertura
• Rastrea y revisa la frecuencia de incidentes por rotación

El traspaso merece su propio checklist: un documento compartido o hilo de Slack con incidentes abiertos, silencios activos y todo lo que disparó pero no se resolvió antes de terminar el turno. Los traspasos que viven solo en la cabeza del respondedor saliente son la forma en que los incidentes se pierden entre turnos.

Rampa a los respondedores nuevos por etapas en vez de tirarles el pager: una semana de sombra (ellos miran, el primario actúa), una semana como secundario (reciben la página de escalamiento), y después primario con un respaldo nombrado que sabe que es su primera rotación. Nadie aprende el oficio de guardia desde una wiki — se aprende viendo a alguien triagiar una página real a las 2am.

3. Define Políticas de Escalamiento

Asegura que las alertas no reconocidas lleguen a un humano:

Ruta de Escalamiento Ejemplo:

Alerta Dispara
    → Guardia primario (página + SMS)
        → ¿Reconocida? (detener)
        → No reconocida en 5 min
            → Guardia secundario (página)
                → ¿Reconocida? (detener)
                → No reconocida en 10 min
                    → Gerente de Ingeniería (página)
                        → No reconocida en 15 min
                            → Director de Ingeniería (página)

Principios de Escalamiento

• Escala rápido para P1 (intervalos de 5-10 minutos)
• Escala más lento para P2 (intervalos de 30-60 minutos)
• Incluye al respondedor anterior en la cadena de escalamiento
• Configura canales de Slack de equipo para visibilidad
• Registra todos los escalamientos para revisión post-incidente

Ajusta el timeout por severidad y por la realidad: si tu primario está dormido o en el metro, cinco minutos ya es generoso para un P1. Todo lo que pase de tres saltos casi nunca llega a un humano que pueda ayudar — arregla la rotación en vez de alargar la cadena.

4. Crea Runbooks para Cada Alerta

Un runbook convierte una alerta en un problema resoluble:

# Runbook: ServiceDown

### Alerta
ServiceDown: `{{ $labels.job }}` está caído

### Impacto
Los usuarios no pueden acceder a `{{ $labels.job }}`. Impacto en ingresos si es pago o API.

### Pasos de Diagnóstico
1. Revisa el endpoint de salud del servicio: `curl http://{{ $labels.instance }}/health`
2. Verifica si el pod está corriendo: `kubectl get pods -l app={{ $labels.job }}`
3. Revisa despliegues recientes: `kubectl rollout history deployment/{{ $labels.job }}`
4. Revisa uso de recursos: `kubectl top pod -l app={{ $labels.job }}`
5. Revisa logs: `kubectl logs -l app={{ $labels.job }} --tail=100`

### Pasos de Resolución
1. Si el pod falló: `kubectl rollout restart deployment/{{ $labels.job }}`
2. Si recursos agotados: escala el deployment o el pool de nodos
3. Si el despliegue causó el problema: `kubectl rollout undo deployment/{{ $labels.job }}`
4. Si una dependencia está caída: revisa su estado y escala al equipo propietario

### Escalamiento
Si no se resuelve en 15 minutos, escalar a: platform-team@company.com

Prácticas de Runbooks

• Un runbook por alerta P1/P2
• Incluye diagnóstico, resolución y escalamiento
• Vincula el runbook directamente en la notificación de alerta
• Revisa y actualiza los runbooks trimestralmente
• Mide qué tan bien funcionan (tiempo de resolución cuando se siguen)

La plantilla de runbook de alertas te da esta estructura lista para copiar. La parte que se suele saltar es la última — medir de verdad si el runbook acortó la resolución, para que los runbooks malos se arreglen en vez de confiarse en ellos.

5. Reduce la Fatiga de Alertas

Mide y reduce activamente el volumen de alertas:

Métrica	Objetivo	Acción si se Excede
Alertas por persona por semana	< 5	Ajustar umbrales, eliminar alertas ruidosas
Alertas P1 por mes	< 2	Arreglar causas raíz, no síntomas
Tiempo de reconocimiento de alerta	< 5 min para P1	Mejorar runbooks, entrenamiento
Tasa de falsos positivos	< 10%	Aumentar for:, añadir condiciones
Alertas sin runbooks	0	Crear runbooks faltantes

Tácticas de Reducción de Fatiga

• Consolida: agrupa alertas relacionadas en una notificación
• Suprime: silencia ventanas de mantenimiento conocidas — siempre con fecha de expiración
• Deduplica: una alerta por incidente, no por host afectado
• Auto-remedia: auto-reinicio, auto-escalado para problemas recuperables conocidos
• Elimina: remueve alertas que disparan más de una vez sin acción

Usa las inhibit_rules de Alertmanager (o el equivalente de tu herramienta) para parar el ruido en cascada: cuando dispara un P1 como ServiceDown, inhibe los warnings dependientes que solo repiten el mismo hecho. Los silencios funcionan igual — son para mantenimiento planificado, no para esconder alertas que aún no arreglaste.

Diseñando Umbrales

El umbral es donde las alertas viven o mueren. Un número demasiado ajustado pagina a la gente por varianza normal; demasiado suelto y el incidente termina antes de que alguien mire.

Parte de la línea base, no de una suposición: saca las últimas 4 semanas de la métrica y mira el p95/p99 de la operación normal. Pon la alerta justo por encima de lo peor de lo “normal” — si la tasa de error normalmente pica en 2%, alerta en 5%, no en 3%. Para métricas con ciclos diarios o semanales fuertes, un solo número estático siempre estará mal en alguna parte del día; usa una alerta basada en percentiles (quantile_over_time) o una de desviación que compare el valor actual con el mismo momento de ayer.

Añade histéresis para que las alertas no puedan oscilar en el límite: dispara cuando la tasa de error supera el 5% durante 5 minutos, y solo marca recuperación cuando baja del 3%. La mayoría de herramientas lo implementan con umbrales separados de disparo/recuperación o con for: más una segunda expresión resolved. El hueco entre los dos números es la diferencia entre una alerta útil y un metrónomo.

Decide también quién es dueño del umbral. El equipo que carga el pager debería poner el número — ellos pagan el coste de equivocarse en ambas direcciones. Cuando un equipo de plataforma posee las reglas pero un equipo de producto carga las páginas, los umbrales derivan hacia lo que deja bonito el dashboard, y el respondedor hereda la brecha. Pon el fichero de alertas en el mismo repo que el servicio, revísalo en el mismo proceso de PR, y deja que el equipo de guardia vetee una regla que no pueda nombrar su acción.

Un guarda más que vale la pena: una pregunta de revisión en cada deploy. Cualquier PR que añade una alerta responde “¿qué hace el respondedor cuando esto dispara?” en la descripción. Las reglas que no pueden responderla se devuelven — es la pregunta de revisión más barata de todo el proceso y filtra la mayoría de alertas que de otro modo vivirían y morirían como ruido.

Silencios, Inhibiciones y Diseño de Notificaciones

Los silencios y las inhibiciones son las dos herramientas que evitan que el ruido correlacionado convierta un solo incidente en cincuenta páginas. Son mecanismos distintos: un silencio anula una alerta durante una ventana (mantenimiento planificado, deploy sabido problemático); una inhibición anula alertas de menor severidad mientras una de mayor severidad ya está disparada.

# Alertmanager: inhibir warnings cuando la alerta crítica ya los cubre
inhibit_rules:
  - source_match:
      alertname: ServiceDown
      severity: critical
    target_match:
      severity: high
    equal: ["service"]  # solo silencia warnings del mismo servicio

Y la propia notificación merece diseño. Una página que dice “HighErrorRate” es ruido. Una página que dice “api checkout: 8% errores desde hace 5 min — runbook: — dashboard: — silenciar: ” es accionable. Toda notificación debería llevar cuatro cosas: qué está roto, con qué severidad, por dónde empezar el diagnóstico (enlace a runbook) y una forma de un clic para reconocer o silenciar. Si tu herramienta de paginado no renderiza enlaces, al menos incluye la URL del runbook en la anotación para que sobreviva hasta Slack y email.

Un último hábito: anota las alertas con contexto de deploy. Un label o anotación con la revisión del último despliegue (deployment_revision) convierte “subieron los errores” en “subieron los errores 6 minutos después del release 2026-10-24-14” — esa es la diferencia entre una página y un diagnóstico.

Presupuestos de Alertas

Trata las páginas como un presupuesto de error para humanos. Fija un presupuesto semanal por respondedor — cinco alertas accionables suele bastar como punto de partida — y trata el sobregasto como tratarías quemar el error budget: para el trabajo de features y paga la causa. Si la semana pasada quemó 9 páginas contra un presupuesto de 5, la pregunta del retro no es “por qué fuiste lento” sino “qué alertas gastaron el presupuesto y cómo lo recuperamos”.

El presupuesto funciona porque convierte una sensación difusa (“recibimos demasiadas páginas”) en un número sobre el que un manager puede actuar. Publícalo, revísalo en la reunión semanal, y haz que el respondedor de guardia lo reporte en dos minutos, no veinte. Los equipos que rastrean el presupuesto descubren siempre lo mismo: tres o cuatro reglas producen la mayor parte del ruido, y arreglarlas recupera todo el presupuesto.

Un Ejemplo Trabajado: Arreglando una Alerta Ruidosa

Una pasada concreta a la regla CPUHigh de la tabla de auditoría de arriba — disparó 41 veces en 90 días, nadie la reconoció, nadie actuó:

# Antes: umbral estático, sin contexto, dispara en cada corrida batch
- alert: CPUHigh
  expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.8

# Después: desviación de línea base, sostenida, con contexto
- alert: CPUHigh
  expr: |
    avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))
      > 1.5 * avg(rate(node_cpu_seconds_total{mode!="idle"}[1h] offset 1d))
  for: 15m
  labels:
    severity: medium
  annotations:
    summary: "CPU on {{ $labels.instance }} is 50% above yesterday's baseline"
    runbook_url: "https://wiki/runbooks/high-cpu"

Los cambios: expresión relativa a la línea base para que los picos de batch nocturnos dejen de paginar, for: 15m para que una ráfaga de 30 segundos muera en silencio, una severidad que merece de verdad (media — nadie necesita despertar por CPU alta), y un resumen que dice al respondedor qué cambió en vez de repetir el nombre de la métrica. Si sigue disparando sin que nadie actúe tras un mes de la versión nueva, se borra — esa es la regla.

Archivos complementarios: el repo companion de alert-management-guide tiene el YAML completo de reglas de alerta, la configuración de inhibit_rules y el runbook de ServiceDown como archivos independientes.

Auditando tu Inventario de Alertas

Cada pocos meses, exporta tus reglas de alerta y puntúa cada una con tres preguntas: ¿disparó en el último trimestre?, ¿alguien actuó sobre ella?, ¿esa acción cambió algo? Las alertas que fallan las tres son las que hacen invisibles al resto.

Salida de auditoría de alertas (ejemplo):

ALERTA                   | Disparos/90d | Reconocidas | Actuadas | Veredicto
ServiceDown              | 2            | 2           | 2        | mantener
HighErrorRate            | 7            | 6           | 5        | mantener
DiskSpaceWarning         | 18           | 3           | 1        | reajustar umbral
CPUHigh                  | 41           | 0           | 0        | eliminar
SlowQueries              | 12           | 4           | 0        | fusionar en alerta de latencia

Rastrea dos métricas de salud del propio programa: MTTA (tiempo medio hasta reconocimiento — debe quedar bajo tu timeout de escalamiento) y MTTR (tiempo medio hasta resolución — debe bajar a medida que los runbooks mejoran). Si el MTTA está bien pero el MTTR sube, tu problema son los runbooks y el diagnóstico, no las alertas.

Haz la auditoría parte del seguimiento de incidentes también. Cada postmortem de P1 o P2 debería responder tres preguntas de alertado: ¿disparó la alerta correcta, con la severidad correcta, y su runbook ayudó de verdad? Cuando la respuesta a cualquiera es no, el arreglo aterriza en el backlog de alertas con dueño — no en una lista de “algún día” que nadie lee.

Lo que funciona

• Alerta sobre síntomas, no causas — un disco lleno es una causa, las peticiones lentas son el síntoma que sienten los usuarios.
• Cada alerta debe exigir acción; si la respuesta honesta es “esperar y ver”, no merece paginar a nadie.
• Usa for: para que la métrica tenga que mantenerse violada antes de despertar a alguien — las alertas oscilantes son ruido con horario.
• Separa paginado de logging: interesante no es lo mismo que urgente.
• Revisa el inventario mensualmente — qué alertas disparan, cuáles se reconocen, cuáles se ignoran — y mata o arregla las ignoradas.
• Paga a la gente por cargar el pager: la guardia es trabajo, y tratarla como gratis es como pierdes respondedores.

Errores Comunes

• Alertar sobre todo: más alertas no significan mejor cobertura, significan más ruido hasta que nadie escucha.
• Sin ruta de escalamiento: el primario no responde y la alerta muere en silencio mientras producción arde.
• Runbooks faltantes: una alerta sin runbook obliga al respondedor a adivinar a las 3am, y la adivinanza suele salir mal.
• Ignorar la fatiga: el volumen alto quema a los respondedores hasta que la alerta crítica que importa se pierde con el resto.
• Umbrales estáticos en métricas cíclicas: los picos de CPU durante jobs batch son normales — alerta sobre desviación de línea base o paginarás a alguien cada noche a las 2am por nada.

Variantes

• Alertas sin operador: remediación totalmente automatizada para fallos recuperables conocidos (reinicios por OOM, limpieza de disco). Funciona bien para un conjunto pequeño de fallos bien entendidos; peligroso donde una auto-acción equivocada empeora las cosas.
• Enrutamiento por severidad: canales distintos por severidad (Slack para P3+, PagerDuty para P1/P2). Barato de implementar y normalmente la primera personalización que vale la pena.
• Propiedad por equipo: las alertas se enrutan al equipo dueño del servicio. Requiere un mapa de propiedad mantenido — sin él, las alertas rebotan a la bandeja equivocada y mueren ahí.
• Alertas asistidas por IA: detección de anomalías que adapta los umbrales a la línea base en vez de números estáticos. Útil en métricas cíclicas; mantén un suelo estático para que una línea base degradada no suba la barra sin ruido.

Solución de Problemas

• La alerta dispara y se resuelve constantemente (flapping): aumenta la duración for:, ensancha la banda del umbral, o alerta sobre una tasa/derivada en vez del valor bruto.
• La alerta nunca dispara aunque debería: comprueba la expresión contra datos reales en la UI de métricas, verifica que for: no sea más largo que la ventana del incidente, y confirma que el routing de alertmanager llega a un receptor.
• El escalamiento nunca se activa: el primario reconoce pero no actúa — acorta la expectativa de ack-a-resolución y revisa a quién paginó. Los escalamientos que nunca disparan suelen ser un problema de propiedad, no de configuración.
• El silencio expira y la alerta vuelve: la causa raíz nunca se arregló. Convierte los silencios recurrentes en tickets con dueño, o acepta borrar la alerta.
• El mismo incidente pagina a 30 hosts: configura group_by sobre el label común (servicio, cluster, alertname) y añade group_wait para que la notificación llegue como una sola.
• El runbook existe pero los respondedores no lo usan: enlázalo dentro de la anotación de la alerta (runbook_url), mantenlo por debajo de 10 pasos y poda los pasos que ya no reflejan la realidad — los runbooks obsoletos enseñan a ignorarlos.

Lectura Adicional

• Google SRE Book — Monitoring Distributed Systems — la filosofía canónica de alertas
• PagerDuty — Alerting Best Practices — diseño de escalamiento y guardias