Diseñar alarmas con sentido: pocas notificaciones, cada una con un siguiente paso

Objetivo

Un conjunto de alarmas en el que cada notificación desencadena una acción y nadie aprende a ignorar el localizador.

Requisitos previos

El capítulo «Monitoring Distributed Systems» del libro de SRE de Google menciona las cuatro señales doradas —latencia, tráfico, errores y saturación—, distingue los síntomas («qué está roto») de las causas («por qué») y exige que cada aviso oriente una acción («Every page should be actionable»). El SRE Workbook describe las alarmas basadas en la tasa de consumo del presupuesto de errores («burn rate»). En la práctica hacen falta indicadores de servicio medidos en el borde del usuario, un sistema de alarmas con tiempo de espera antes de disparar —en Prometheus, la cláusula for, complementada con keep_firing_for contra el parpadeo durante la remisión— y una vía de escalado documentada.

Pasos

1. Establecer para cada servicio los síntomas que perciben los usuarios: tasa de errores, percentiles de latencia, disponibilidad, actualidad de los datos. Solo ellos pueden despertar. Las causas, como una carga de CPU elevada o un disco lleno al 80 por ciento, se convierten en tickets o en paneles del dashboard.
2. Derivar los umbrales de los objetivos: el Workbook indica como punto de partida para un aviso el consumo del 2 por ciento del presupuesto de errores en una hora o del 5 por ciento en seis horas; una tasa más lenta (10 por ciento en tres días) genera un ticket en lugar de un aviso.
3. Dotar a cada regla de un tiempo de espera (for: 10m) para que un solo valor atípico no dispare la alarma, y añadir una regla que salte cuando el propio sistema de medición deje de entregar datos.
4. Incluir en las anotaciones de cada alarma un enlace al runbook, los dashboards afectados y el primer paso de comprobación.
5. Llevar la urgencia como etiqueta (severity: page frente a ticket) y dirigir el enrutamiento según esta; por la noche, solo el primer nivel llega a una persona.
6. Revisar semanalmente todas las alarmas disparadas: toda alarma que no dio lugar a una acción se reajusta o se elimina; todo incidente sin una alarma previa recibe una.

Resultado esperado

Pocos avisos, cada uno con un siguiente paso claro; el monitoreo detecta los incidentes antes que los usuarios; el equipo de guardia confía en el localizador.

Límites y base de verificación

Las alarmas por síntomas detectan tarde los deterioros progresivos; algunos indicadores adelantados de baja urgencia (longitud de la cola, pronóstico «disco lleno en dos días») las complementan. Los principios siguen los capítulos de SRE citados; la mecánica, la documentación de Prometheus citada; no está demostrado aquí si un equipo se insensibiliza a partir de cierta tasa de alarmas, ni a partir de cuál.