Fatiga de alertas

¿Qué es la fatiga de alertas?

La fatiga de alertas (alert fatigue) aparece cuando las personas reciben tantas alertas, o tantas de poco valor, que dejan de reaccionar con rapidez o dejan de reaccionar del todo. Afecta por igual a ingenieros de guardia, equipos de soporte y analistas de seguridad. El libro SRE de Google describe el efecto con claridad: cuando las alertas llegan con demasiada frecuencia, la gente duda, las lee por encima o directamente las ignora, y un incidente real se pierde entre el ruido.

Por qué ocurre

• Alertas sobre las que nadie puede actuar, como una métrica alta sin impacto en los usuarios.
• Alertas sobre causas (CPU por encima del 80 %) en vez de síntomas que notan los usuarios (peticiones lentas o fallidas).
• Oscilaciones: una comprobación fallida desde una sola ubicación, o un pequeño corte, avisa a alguien y se resuelve solo un minuto después.
• Duplicados: el mismo problema salta en tres herramientas y cinco canales.
• Alertas que nunca se ajustaron ni se retiraron después de que el sistema cambiara.
• En equipos de seguridad, herramientas de detección con muchos falsos positivos, de modo que los analistas aprenden a descartar avisos.

Qué cuesta

Respuestas más lentas, porque las alertas se revisan más tarde. Incidentes que se pasan por alto, porque el importante se parece a los demás. Pérdida de confianza en la monitorización, y las alertas acaban silenciadas. El libro SRE añade que las caídas pueden durar más porque el ruido estorba un diagnóstico rápido. La solución rara vez son más alertas, sino mejores.

Cómo reducirla

1. Haz que cada aviso sea accionable. Según el libro SRE, si un aviso solo merece una respuesta robótica, no debería ser un aviso. Automatízalo o conviértelo en un ticket.
2. Alerta sobre síntomas. Avisa por lo que viven los usuarios, como peticiones fallidas o lentas. Deja las alertas basadas en causas para los paneles, salvo que apunten a un problema concreto e inminente.
3. Confirma antes de avisar. Exige varios fallos consecutivos, o fallos desde más de una ubicación, antes de enviar una alerta.
4. Enruta por gravedad. Los fallos urgentes al buscapersonas, el rendimiento degradado a un canal de chat y las tendencias lentas a un ticket.
5. Agrupa y deduplica. Un incidente debe generar una notificación, no una por servidor o por comprobación.
6. Revisa con regularidad. Por cada alerta que saltó, pregunta quién actuó. Si nadie, ajústala o elimínala.
7. Silencia el trabajo planificado. Usa ventanas de mantenimiento durante despliegues y migraciones.

Ejemplo

Una comprobación de API falla una vez a las 03:00 desde una sola región por un problema de red pasajero y se recupera en la siguiente ejecución. Con una configuración ingenua, se despierta a la persona de guardia. Tras el ajuste, la comprobación avisa solo si falla dos veces seguidas desde al menos dos ubicaciones. Las respuestas lentas pero correctas van a un canal de chat. La persona de guardia recibe menos avisos y cada uno significa algo.

La fatiga de alertas en la monitorización de APIs de LoadFocus

La monitorización de APIs de LoadFocus incluye varios ajustes contra las falsas alarmas: reintentos, un umbral de fallos consecutivos, un mínimo de ubicaciones con fallo y un umbral de degradación sobre el tiempo de respuesta. Las alertas pueden ir a correo, Slack, Microsoft Teams, Discord, PagerDuty, Opsgenie y webhooks, con enrutamiento por canal para fallo, recuperación, degradación y caducidad de SSL. Las comprobaciones gratuitas se ejecutan cada 5 minutos. Ejecutar cada comprobación desde al menos dos ubicaciones es el propio consejo de la página para evitar falsos positivos. Consulta monitorización de APIs y monitorización sintética para ver cómo funcionan, y buenas prácticas de monitorización para diseñar alertas.

Errores comunes

• Avisar por un umbral de recursos sin impacto en los usuarios.
• Enviar todas las alertas a todas las personas.
• Silenciar un canal ruidoso en lugar de arreglar la regla que lo origina.
• Mantener umbrales por defecto que nadie ha cuestionado.
• Omitir las notificaciones de recuperación, de modo que nadie sabe si el incidente ha terminado.

Fatiga de alertas y respuesta a incidentes

Las buenas alertas son el primer paso de la respuesta a incidentes: deciden con qué rapidez empieza la persona adecuada. Cuando el incidente es real, la comunicación de incidentes y una página de estado mantienen a todos informados, para que los ingenieros no tengan que contestar la misma pregunta una y otra vez.

Preguntas frecuentes

¿Qué causa la fatiga de alertas?

Demasiadas alertas sobre las que no se puede actuar: umbrales ruidosos, alertas sobre causas en lugar de síntomas, duplicados entre herramientas y alertas que nunca se revisaron tras cambiar el sistema.

¿Cómo se reduce la fatiga de alertas?

Avisando solo por síntomas accionables, confirmando los fallos antes de alertar, enrutando por gravedad, deduplicando notificaciones y revisando cada alerta que salta. Ajusta o elimina las que nadie atiende.

¿Es la fatiga de alertas solo un problema de seguridad?

No. Los analistas de seguridad la sufren con herramientas de detección de gran volumen, pero también los equipos de guardia, el soporte y cualquiera que reciba alertas de monitorización.

¿Cómo ayuda la monitorización de APIs?

Las comprobaciones que exigen varios fallos consecutivos o varias ubicaciones con fallo antes de alertar, junto con el enrutamiento por canal, reducen las falsas alarmas aisladas. La monitorización de APIs de LoadFocus ofrece estos ajustes.