Prevención de sobreabundancia de alertas

1) Problema y objetivo

Alert fatigue se produce cuando el sistema tiene demasiadas notificaciones irrelevantes o no activables. El resultado es ignorar las paginas, el crecimiento de MTTA/MTTR y omitir incidentes reales.
Objetivo: hacer que las señales sean raras, significativas y ejecutables, enlazándolas a SLO y playbooks.

2) Taxonomía de las señales (canal = consecuencias)

Page (P0/P1) - despierta a la persona; sólo cuando se requiere una acción manual ahora y hay un runbook.
Ticket (P2) - trabajo asíncrono en horas/día; no despierta, pero se mueve por SLA.
Dash-only (P3) - observación/tendencia sin acciones activas; no crea ruido.
Silent Sentry - métricas/auditorías en el fondo (para RCA/post-mortem).

3) Diseño de la alerta «correcta»

• Objetivo/hipótesis (lo que defendemos: SLO, seguridad, dinero, cumplimiento).
• Condiciones de activación (umbral, ventana, quórum de origen).
• Runbook/Playbook (breve ID de paso + enlace).
• Propietario (equipo/grupo de rol).
• Criterios de finalización (cuándo cerrar, auto-resolve).
• La clase de la vulnerabilidad (user-impact / platform / security / cost).

4) Monitoreo orientado a SLO

SLI/SLO → señales primarias: disponibilidad, latencia, éxito de las operaciones comerciales.

• Corto: 5% del presupuesto en 1 hora → Page.
• Largo: 2% del presupuesto en 6 horas → Ticket.
• Cohortes: alertas por regiones/proveedores/segmentos VIP - menos falsas alarmas globales.

5) Técnicas de reducción de ruido

1. Sondas de quórum: activación sólo si ≥2 fuentes independientes (diferentes regiones/proveedores) confirman el problema.
2. Deduplicación: agrupar los mismos eventos (llaves de agregación: servicio + región + código).
3. Histéresis/duración: «en la zona roja ≥ N minutos» para filtrar las espinas.
4. Rate-limit: no más de X alertas/hora/servicio; si se supera, un page + resumen.
5. Auto-snooze/supresión inteligente: alerta repetitiva en la ventana T → traducción a Ticket antes de eliminar la raíz.
6. Correlación de eventos: una «alerta maestra» en lugar de docenas de síntomas (por ejemplo, «DB inaccesible» bloquea 5xx de los microservicios).
7. Mantenimiento de la ventana: los trabajos programados suprimen automáticamente las señales esperadas.
8. Anomaly + guardrails: anomalías - sólo como Ticket si no hay confirmación de señal SLO.

6) Enrutamiento y prioridades

Prioridades: P0 (Page, 15 min de actualización), P1 (Page, 30 min), P2 (Ticket, 4-8 h), P3 (observación).
Routing por atajos: service/env/region/tenant → correspondiente on-call.
Escalaciones en el tiempo: sin ack en 5 min → P2 → Duty Manager/IC.
Quiet Hours: horario nocturno para los no críticos; Page está prohibido para P2/P3.
Política fatigue: si el ingeniero> N page/change - redistribuir a P2, escalar la contaminación de las señales.

7) Calidad de alertas: arreglos

Actionability ≥ 80%: la gran mayoría de los pages conducen a la acción del runbook.
False Positive ≤ 5% para las señales de página.
Time-to-Fix-Alert ≤ 7 días - la alerta defectuosa debe corregirse/eliminarse.
Ownership 100% - cada alerta tiene un propietario y un repositorio con su definición.

8) Ciclo de vida de alerta (Alert as Code)

1. Crear PR (descripción del objetivo, condiciones, runbook, propietario, plan de prueba).
2. Sandbox/Shadow: shadow-alert escribe en chat/logs, pero no pagina.
3. Canario: audiencia limitada on-call, medimos FP/TP.
4. Prod: activación con rate-limit + observación 2-4 semanas.
5. Revisión semanal: métricas de calidad, revisiones/retiros.
6. Deprechate: si la señal duplica una más alta o no es actionable.

9) Métricas de madurez (mostrar en dashboard)

Alertas per on-call hour (mediana/95-percentil).
% actuable (hay pasos completados) y falso-positivo.
MTTA/MTTR alrededor de las paginas y la proporción de page→ticket (no debe ser alta).
Top-talkers (servicios/reglas que generan ≥20% de ruido).
Mean time to fix alert (desde la primera FP hasta el cambio de regla).
Cobertura Burn-rate: una proporción de servicios con alertas SLO en dos ventanas.

10) Check-list «Higiene de alertas»

• Alert está vinculado a SLO/SLI o a negocios/seguridad.
• Hay un runbook y un propietario; especificado contacto y canal de war-room.
• Se han configurado dos ventanas (corta/larga) y el quórum de las fuentes.
• Incluye dedoup, rate-limit, auto-resolve y auto-snooze.
• Se especifican las ventanas de mantenimiento y suppression durante las liberaciones/migraciones.
• Pasar por Shadow/Canary; medido por FP/TP.
• Se incluye un informe sobre las métricas de calidad de las alertas.

11) Mini plantillas

Especificación de alerta (idea YAML)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Texto de actualización estándar (para reducir el ruido)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Procesos: semanal «Alert Review»

1. Las reglas más ruidosas (top-talkers) → corregidas/eliminadas.

2. FP/TP a través de las señales de página → ajustamos los umbrales/ventanas/quórum.

3. Los aspirantes a la baja del canal (Page→Ticket) y viceversa.

4. Estado «Time-to-Fix-Alert»: los retrasos se escalan para los propietarios de servicios.

5. Verifique la cobertura con alertas SLO y la presencia de runbook.

13) Relación con lanzamientos y operaciones

Las anotaciones de versión agregan automáticamente supresión temporal.
Cambiar Windows: en los primeros 30 minutos después del lanzamiento, sólo señales SLO.
Los playbucks contienen el paso «bajar/suprimir alertas no clave» para concentrarse en la raíz.

14) Seguridad y cumplimiento

Señales de seguridad (piratería/fugas/accesos anormales) - canales separados, sin quiet hours.
Auditoría-registro de todas las supresiones/ventanas silenciosas: quién, cuándo, por qué, plazo.
Requerimiento de inmutabilidad para alarmas críticas (firma del evento).

15) Anti-patrones

«Cada gráfico = alerta» → avalancha.
Umbral «! = 0 errores» en la venta.
Una sonda/una región como fuente de verdad.
Page sin runbook/propietario.
Eternas «supresiones temporales» sin término.
«Arreglemos el sudor» las alertas defectuosas - han estado acumulando durante años.
Mezcla de ruido de lanzamiento con incidentes de producción.

16) Hoja de ruta para la implementación (4-6 semanas)

1. Inventario: descargar todas las alertas, colocar los propietarios y los canales.
2. Núcleo SLO: introduzca reglas burn-rate con ventanas dobles sobre servicios críticos.
3. Control de ruido: habilitar quórum, dedoop y rate-limit, iniciar una revisión semanal.
4. Cobertura de Runbook: cerrar el 100% de las señales de Page con playbooks.
5. Política Fatig: límites Page/Change, Quiet Hours, redistribución de carga.
6. Automatización: Alert-as-Code, Shadow/Canary, informes sobre métricas de calidad.

17) Resultado

El silencio no es una falta de monitoreo, sino señales de diseño cualitativo relacionadas con SLO y procesos. El quórum, las ventanas dobles, el dedoup y el enrutamiento estricto convierten las alertas en raras, precisas y ejecutables. El equipo duerme, los usuarios están satisfechos, los incidentes están bajo control.