Alerting bien hecho: De la fatiga de alertas a notificaciones accionables
Demasiadas alertas son igual de problemáticas que ninguna. Mostramos cómo construir un sistema de alerting que solo se dispare cuando realmente importa.
El problema de la fatiga por alertas
Cuando su ingeniero de guardia recibe 50 alertas al día, de las cuales 48 son falsos positivos, las dos reales también se ignoran. La fatiga por alertas es uno de los mayores riesgos para la fiabilidad del sistema.
Principios para buenas alertas
- Basadas en síntomas: Alerte sobre síntomas (alta tasa de errores, tiempos de respuesta lentos), no sobre causas (CPU alta). Una CPU al 90% sin impacto no es una alerta.
- Accionables: Cada alerta debe tener una instrucción de acción clara. Si nadie puede hacer nada, no es una alerta, sino una entrada de log.
- Niveles de severidad: Distinga entre P1 (despertar ahora) y P3 (revisar mañana). No todo es una alerta de pager.
Alertas basadas en SLOs
El enfoque más moderno: defina Service Level Objectives (SLOs) y alerte cuando el Error Budget se agote.
- Error Budget: Con un SLO del 99.9%, dispone de aproximadamente 43 minutos de presupuesto de inactividad por mes.
- Burn Rate: Alerte cuando el presupuesto se consume más rápido de lo esperado, no ante cada error individual.
- Multiwindow: La combinación de una ventana rápida (5 min) y una lenta (1 h) reduce drásticamente los falsos positivos.
Consejos prácticos
Realice revisiones periódicas de alertas. Elimine las alertas a las que nadie responde. Documente runbooks para cada alerta restante. Y respete la rotación de guardia: quien no ha dormido, comete errores.
¿Preguntas sobre este tema?
Le asesoramos con gusto sobre las tecnologías y soluciones descritas en este artículo.
Contactar
