Plantilla de Política de Monitoreo y Alertas

Descripción General

Una Política de Monitoreo y Alertas define cómo una organización detecta problemas, notifica a las personas correctas y escala cuando los incidentes no se resuelven rápidamente. Sin una política clara, los equipos caen en uno de dos modos de fallo: fatiga de alertas por avisar de ruido, o incidentes perdidos porque nadie era responsable de la señal. Esta plantilla te da un marco estructurado para niveles de severidad, umbrales, reglas de enrutamiento, caminos de escalación y la cadencia de revisión que mantiene todo el sistema honesto.

Un disparador típico para escribir esta política: la rotación de guardia acaba de quemarse porque las alertas P2 sonaron toda la noche por avisos sobre los que nadie podía actuar. Escribir las reglas — a quién se avisa, por qué y cuándo escala — es la solución. Si lo que necesitas es la plataforma de monitoreo en sí y no la capa de política, la guía completa de observabilidad con el stack de Grafana cubre la parte de herramientas.

Cuándo Usar

• Al configurar una nueva plataforma de observabilidad o stack de monitoreo.
• Al incorporar un nuevo servicio o equipo al sistema de alertas.
• Al revisar la calidad de las alertas tras un periodo de ruido o incidentes perdidos.
• Al definir responsabilidades de guardia y caminos de escalación.
• Al preparar una auditoría de madurez operacional o de respuesta a incidentes.

Cuándo no usarla: un equipo de dos personas con un único servicio no necesita una matriz de enrutamiento formal — un canal de Slack compartido y una rotación de avisos bastan. La política compensa cuando varios equipos comparten infraestructura y “quién responde” deja de ser obvio.

Prerequisitos

• Una plataforma de monitoreo y observabilidad como Prometheus, Datadog, Grafana, New Relic o PagerDuty.
• Una lista de servicios críticos y componentes de infraestructura.
• Rotaciones de guardia y contactos de escalación definidos.
• Un canal de comunicación para alertas, como Slack, Microsoft Teams o correo.
• Un proceso de respuesta a incidentes que las alertas activarán.

La Plantilla de Política

Las seis tablas siguientes son el cuerpo de la plantilla. Cópialas a tu documentación interna, reemplaza los valores de ejemplo y rellena tus propios equipos, canales y umbrales. La prosa tras cada tabla explica el razonamiento para que la política sobreviva a las revisiones.

1. Niveles de Severidad de Alertas

Severidad	Tiempo de Respuesta	Ejemplo	Canal de Notificación
P1 - Crítica	Inmediato (5 min)	Servicio caído, pérdida de datos, impacto en ingresos	Aviso al guardia + notificación ejecutiva
P2 - Alta	15 minutos	Rendimiento degradado, backups fallidos	Aviso al guardia + alerta Slack
P3 - Media	1 hora	Tasa de errores alta, presión de recursos	Slack o correo al equipo responsable
P4 - Baja	Próximo día laboral	Advertencia de capacidad, desviación no urgente	Correo o aviso en dashboard
P5 - Informativa	Ninguno	Métricas de uso, datos de tendencia	Solo dashboard

La línea importante está entre P2 y P3: P1 y P2 interrumpen a una persona, todo lo demás no. Mantén esa línea estricta. Si te descubres avisando por eventos P3, o están mal categorizados o tus umbrales son demasiado ajustados — la tabla de puntuación de más abajo te ayuda a detectarlo.

2. Categorías de Alertas

Categoría	Propósito	Ejemplos
Disponibilidad	Detectar servicio inalcanzable	HTTP 5xx, timeout de conexión, fallo de health check
Rendimiento	Detectar latencia y throughput	Latencia p99 > 500ms, profundidad de cola alta
Capacidad	Detectar agotamiento de recursos	CPU > 85%, disco > 80%, presión de memoria
Tasa de error	Detectar tasas de fallo inusuales	Tasa de error > 1% durante 5 minutos
Seguridad	Detectar actividad sospechosa	Inicios de sesión fallidos, límites de tasa, tráfico bloqueado
Negocio	Detectar impacto en ingresos o flujos	Pagos fallidos, caída de órdenes, registro fallido
Salud de datos	Detectar problemas de calidad o pipelines	Datos obsoletos, particiones faltantes, lag de sincronización

Las categorías importan más para el enrutamiento que para los dashboards. Una alerta de disponibilidad y una de negocio suelen necesitar responsables distintos aunque se disparen en el mismo servicio, así que etiqueta cada regla con su categoría y deja que la capa de enrutamiento la resuelva.

3. Matriz de Enrutamiento de Alertas

Equipo	Horario Principal	Horario de Guardia	Canales	Camino de Escalación
Equipo de plataforma	08:00 - 18:00 UTC	24/7	PagerDuty, #platform-alerts	Gerente, luego VP de Ingeniería
Equipo de aplicación	08:00 - 18:00 UTC	24/7	PagerDuty, #app-alerts	Líder de equipo, luego Gerente de ingeniería
Equipo de seguridad	24/7	24/7	PagerDuty, #security-alerts	Líder de seguridad, luego CISO
Equipo de bases de datos	08:00 - 18:00 UTC	24/7	PagerDuty, #db-alerts	Líder DBA, luego Gerente de plataforma
Operaciones de negocio	Horario laboral	Ninguno	Correo, Slack	Gerente de operaciones

Enruta al equipo que puede arreglar el problema, no a una cola central que reenvía. Cada salto entre la alerta y el responsable añade minutos que no puedes permitirte en un P1. La columna de escalación encaja naturalmente con una plantilla de política de escalación si necesitas el contrato de guardia completo.

4. Lineamientos de Umbrales de Alerta

Señal	Umbral de Advertencia	Umbral Crítico	Ventana de Evaluación
Tasa de error HTTP	> 1% durante 5 min	> 5% durante 2 min	5 minutos móvil
Latencia p99	> 500ms durante 10 min	> 1s durante 5 min	10 minutos móvil
Utilización CPU	> 70% durante 10 min	> 90% durante 5 min	5 minutos móvil
Utilización disco	> 75% durante 1 hora	> 90% durante 15 min	15 minutos móvil
Utilización memoria	> 80% durante 10 min	> 95% durante 5 min	5 minutos móvil
Profundidad de cola	> 1000 durante 10 min	> 5000 durante 5 min	5 minutos móvil
Backup fallido	N/A	Cualquier backup fallido	Por ejecución del job
Vencimiento certificado SSL	< 30 días	< 7 días	Verificación diaria

Trata estos números como punto de partida, no como dogma. Extrae las métricas de tus últimos 90 días, mira dónde empezaron los incidentes reales y pon el umbral de advertencia justo por debajo de esa línea. Los umbrales copiados de una plantilla sin datos históricos son la forma de acabar avisando de ruido — y la fila de calibración trimestral de la tabla de mantenimiento existe exactamente para eso.

5. Reglas de Escalación

Severidad	Alerta Inicial	Sin Reconocimiento	Aún Sin Resolver	Escalación Final
P1	Aviso al guardia inmediato	5 min	15 min	Notificación ejecutiva + sala de guerra
P2	Aviso al guardia	15 min	30 min	Aviso al gerente
P3	Slack al equipo responsable	1 hora	4 horas	Notificación al gerente
P4	Correo o dashboard	Próximo día laboral	N/A	Revisión semanal

Los temporizadores de escalación son un contrato con tus ingenieros de guardia: un aviso sin reconocimiento recibe un aviso más fuerte, no silencio. Si la gente ignora sistemáticamente la primera notificación, eso dice algo sobre la calidad de las alertas, no sobre los ingenieros.

6. Revisión y Mantenimiento de Alertas

Actividad	Frecuencia	Responsable	Salida
Revisión de calidad de alertas	Semanal	Ingeniero de guardia	Alertas más ruidosas, acciones de ajuste
Revisión de runbooks de alertas	Mensual	Equipo SRE	Runbooks actualizados para cada alerta
Calibración de umbrales	Trimestral	Equipo de observabilidad	Ajustes de umbrales con evidencia
Retro de guardia	Después de incidente mayor	Comandante de incidente	Mejoras de alertas, tareas de seguimiento
Revisión de política	Anual	Liderazgo de ingeniería	Documento de política actualizado

La revisión semanal de calidad es la fila de mayor apalancamiento de esta tabla. Quince minutos de “qué alertas sonaron, cuáles eran accionables” detectan la fatiga de alertas antes de que se convierta en un problema de plantilla. Las revisiones post-incidente combinan bien con una plantilla de postmortem de incidente cuando el incidente es suficientemente grande para documentarlo.

Cómo Funciona la Política en la Práctica

Una alerta sigue un ciclo de vida predecible: una métrica cruza un umbral, la regla se dispara, la capa de enrutamiento la entrega al equipo responsable, alguien la reconoce, y el temporizador de escalación corre en segundo plano por si no lo hace. El bucle de revisión del final es lo que mantiene el sistema calibrado — cada alerta ruidosa que sobrevive una revisión se convierte en el aviso ignorado de mañana.

Dos decisiones de diseño cargan con la mayor parte del peso. Primero, la severidad determina tanto el canal como el reloj: los canales de aviso solo existen para P1/P2, y los temporizadores de escalación se acortan al subir la severidad. Segundo, cada alerta lleva un enlace a runbook, de modo que la primera acción del responsable está documentada y no improvisada.

Reglas de Alerta de Prometheus (Ejemplo)

Así se traducen las etiquetas de severidad y los umbrales de la política a reglas reales de Prometheus — cada alerta lleva las etiquetas severity y team sobre las que trabaja la configuración de enrutamiento de abajo:

groups:
  - name: api_alerts
    interval: 30s
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
          / sum(rate(http_requests_total[5m])) by (service) > 0.05
        for: 2m
        labels:
          severity: P1
          team: platform
        annotations:
          summary: "{{ $labels.service }} tasa de error > 5%"
          description: "{{ $labels.service }} tiene {{ $value | humanizePercentage }} de tasa de error durante 2 minutos"
          runbook: "https://runbooks.example.com/high-error-rate"

      - alert: HighLatencyP99
        expr: |
          histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[10m])) by (le, service)) > 1
        for: 5m
        labels:
          severity: P2
          team: platform
        annotations:
          summary: "{{ $labels.service }} latencia p99 > 1s"
          runbook: "https://runbooks.example.com/high-latency"

      - alert: DiskSpaceLow
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 15m
        labels:
          severity: P2
          team: infrastructure
        annotations:
          summary: "Espacio en disco < 10% en {{ $labels.instance }}"
          runbook: "https://runbooks.example.com/disk-space"

Configuración de Enrutamiento de Alertmanager

El árbol de enrutamiento refleja la tabla de severidad de la política: P1/P2 van a PagerDuty con intervalos de repetición agresivos, P3 va a Slack, P4 a correo. Todo lo demás cae al receptor por defecto.

route:
  receiver: default
  group_by: ["alertname", "service", "severity"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity = "P1"
      receiver: pagerduty-critical
      group_wait: 0s
      repeat_interval: 30m
    - matchers:
        - severity = "P2"
      receiver: pagerduty-warning
      group_wait: 30s
      repeat_interval: 2h
    - matchers:
        - severity = "P3"
      receiver: slack-alerts
      group_wait: 5m
    - matchers:
        - severity = "P4"
      receiver: email-alerts
      group_wait: 1h

receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - service_key: "P1_KEY"
  - name: pagerduty-warning
    pagerduty_configs:
      - service_key: "P2_KEY"
  - name: slack-alerts
    slack_configs:
      - channel: "#alerts"
        api_url: "SLACK_WEBHOOK_URL"
  - name: email-alerts
    email_configs:
      - to: "team@example.com"
  - name: default
    slack_configs:
      - channel: "#alerts"

group_wait y repeat_interval codifican el contrato de escalación en la configuración: las alertas P1 se agrupan al instante y se repiten cada 30 minutos hasta ser reconocidas, mientras que P4 se agrupa cada hora. Ajusta estos valores antes de tocar umbrales — la agrupación suele ser la forma más barata de reducir el volumen de avisos.

Tabla de Puntuación de Calidad de Alertas

Revisa cada alerta trimestralmente con esta tabla — seis criterios, 1–5 puntos cada uno, 30 puntos máximo:

Criterio	Puntuación (1-5)	Notas
Accionable: ¿La alerta desencadena una respuesta clara?
Precisa: ¿La tasa de falsos positivos es menor al 5%?
Oportuna: ¿La alerta se dispara antes del impacto al usuario?
Enrutada: ¿Llega al equipo que puede resolverla?
Documentada: ¿Hay un runbook vinculado?
Única: ¿Esta alerta es redundante con otra?

Interpretación: 18 o más significa que la alerta está sana. Entre 12 y 17, ponla en un plan de mejora de 30 días con un responsable asignado — normalmente eso significa ajustar el umbral, corregir el enrutamiento o escribir el runbook que falta. Por debajo de 12, elimínala; una alerta que no es accionable, precisa ni enrutada está entrenando a tu equipo para ignorar los avisos.

Cómo Implantar Esta Política

Adoptar la plantilla funciona mejor como un despliegue por etapas que como una reescritura de golpe:

1. Inventario — lista cada alerta existente, su severidad declarada y a dónde enruta. La mayoría de equipos descubren alertas huérfanas yendo a canales muertos en este paso.
2. Borrador de severidades — mapea las alertas existentes a la tabla P1–P5. Espera que la mayoría de las alertas “críticas” acaben en P3; es normal, no un problema.
3. Conecta el enrutamiento — configura la matriz de enrutamiento en tus herramientas (la configuración de Alertmanager de arriba cubre el stack de Prometheus) y prueba cada camino con una alerta sintética.
4. Piloto con un equipo — ejecuta la política con un solo equipo durante dos semanas. Registra avisos por turno y tasa de falsos positivos.
5. Revisa y amplía — ajusta umbrales con los datos del piloto, luego despliega al resto de equipos y arranca la revisión semanal de calidad.

El piloto de dos semanas importa más que el documento. Una política que sobrevive al contacto con alertas reales gana confianza; una que avisa a las 3 a.m. por una advertencia de capacidad acaba siendo ignorada en un mes.

Una última nota sobre responsabilidad: asigna un responsable al propio documento — normalmente el líder de SRE o de plataforma — y mantenlo en control de versiones junto a las configuraciones de alertas que describe. Los cambios de umbrales o de enrutamiento deberían pasar por la misma revisión de pull request que los cambios de configuración que los implementan. Una política que vive en un wiki que nadie revisa es indistinguible de no tener política.

Variantes

• Política de alertas cloud-native: Usa Prometheus Alertmanager, Grafana OnCall o PagerDuty para entornos de contenedores y serverless.
• Política de monitoreo empresarial: Se enfoca en infraestructura, red e integración con service desk.
• Política de alertas de seguridad: Enfatiza reglas de SIEM, detección de amenazas y disparadores de respuesta a incidentes.
• Alertas de operaciones de negocio: Rastrea KPIs, ingresos y métricas orientadas al cliente con notificaciones en horario laboral.
• Alertas self-service para desarrolladores: Permite a los equipos definir sus propias reglas de alerta dentro de guardrails.
• Política de alertas multi-cloud: Usa herramientas agnósticas de nube (Grafana, Datadog) para unificar alertas entre AWS, GCP y Azure.
• Política de alertas de coste: Monitorea el gasto en la nube con umbrales de presupuesto y detección de anomalías en métricas de coste.
• Política de alertas de cumplimiento: Rastrea huecos en logs de auditoría, revisiones de acceso fallidas y violaciones de política en entornos regulados.

Lo Que Funciona

• Alerta sobre síntomas que afectan a los usuarios, no solo sobre métricas internas.
• Usa umbrales de multi-ventana o multi-tasa de quemado para reducir falsos positivos.
• Exige que cada alerta tenga un runbook o enlace de troubleshooting asociado.
• Enruta las alertas al equipo que puede resolver el problema, no a una cola central.
• Mantén los mensajes de alerta concisos e incluye contexto como severidad, servicio e impacto.
• Revisa las alertas ruidosas semanalmente y ajústalas o elimínalas.
• Prueba los caminos de escalación durante simulacros regulares.
• Documenta los umbrales y la justificación de los cambios.
• Usa agrupación de alertas para combinar alertas relacionadas en una sola notificación durante incidentes.
• Implementa supresión de alertas para ventanas de mantenimiento y despliegues conocidos.

Errores Comunes

• Alertar sobre cada umbral de métrica sin considerar el impacto al usuario.
• Enviar todas las alertas a un único canal sin enrutamiento.
• Usar la misma severidad para todas las alertas.
• No exigir reconocimiento ni rastrear el tiempo de resolución.
• Ignorar alertas que suenan repetidamente sin acción.
• No tener caminos de escalación para incidentes severos.
• No revisar y retirar alertas obsoletas después de cambios en el sistema.
• Fijar umbrales a ojo en lugar de usar datos históricos.
• No incluir el nombre del servicio y el entorno en las etiquetas de alerta, lo que dificulta el triaje.
• Alertar sobre valores absolutos en lugar de tasas o ratios, lo que provoca falsos positivos en picos de tráfico.

Solución de Problemas

• Tormenta de alertas durante un despliegue: suprime las alertas de los servicios afectados durante la ventana, o afina el group_by para que 50 alertas relacionadas colapsen en una sola notificación.
• Umbral que oscila (se dispara, se resuelve, se dispara otra vez): amplía la ventana de evaluación o añade una segunda condición — una cláusula for por sí sola no detiene una métrica que oscila alrededor de la línea.
• Avisos por alertas sobre las que nadie puede actuar: puntúalas con la tabla de arriba; cualquier cosa por debajo de 12 se elimina, no se silencia.
• La alerta se dispara pero no hay runbook: la anotación se saltó. Haz que el enlace al runbook sea un campo obligatorio en la revisión de código de las reglas nuevas.
• Un silencio que queda activo tras el mantenimiento: los silencios caducados son fáciles de olvidar; revisa los silencios activos en la revisión semanal para que el mantenimiento de ayer no mute el incidente de hoy.
• La misma alerta enrutada a tres canales: deduplica los receptores en la configuración de enrutamiento, o acéptalo — pero la duplicación de avisos es un camino rápido a la fatiga de alertas.

Lecturas Adicionales

• Google SRE Book — Monitoring Distributed Systems y el capítulo Alerting on SLOs del workbook
• Documentación de Prometheus: reglas de alerta
• Documentación de Alertmanager: configuración
• PagerDuty: buenas prácticas de gestión de alertas
• Relacionado en este sitio: la plantilla de SLO para alertas basadas en presupuesto de error.