La historia de cómo redujimos la cantidad de alertas en 95.7% y mejoramos la fatiga por alertas
(velog.io)Contexto del problema: se separaron los canales de alertas críticas y de advertencia (Warning), y se introdujo la recepción de llamadas para las alertas críticas, pero la explosión de más de 10 mil alertas de advertencia al mes provocó que se ignoraran las alertas y aumentara la fatiga del on-call.
Insight clave: las alertas excesivas terminan convirtiéndose en un simple health checker de mensajería y perjudican la visibilidad del sistema. Como métrica clave para reducir alertas, se propuso medir la "tasa de respuesta a alertas" usando emojis de Slack (👀, ✅).
Proceso de solución:
Se ajustaron y eliminaron alertas cuya intención de configuración original ya no coincidía con el entorno actual (por ejemplo, discrepancias en el umbral de aumento de volumen de EBS).
También se eliminaron sin dudar las alertas sin sentido cuya intención original era imposible de conocer.
Logro adicional: después de eliminar el ruido de alertas, se descubrió que la causa del alto iowait en un servidor específico era un recordsize de ZFS configurado de forma excesiva para la carga real de trabajo, y se normalizó.
Resultado: reducción de 95.7% en las alertas de advertencia (10,553 al mes → 453). Reducción de más de 70% en las llamadas por alertas críticas durante la madrugada y días festivos. Se resolvió la falta de sueño del on-call y mejoraron de forma tangible la disponibilidad y visibilidad reales del sistema.
3 comentarios
Los logs, las métricas y las alertas requieren una práctica de ajuste periódico.
Me sonaba el apodo; es la misma persona que antes escribió un texto divertido sobre la salida de
cron. También leí muy bien este artículo :DGracias, me alegra que te haya parecido interesante.