Alertas que alguien atiende

Una alerta que no cambia lo que alguien hace no es una alerta: es ruido. Y el ruido sale más caro que no tener alertas, porque entrena al equipo a ignorarlas — incluidas las buenas. De ahí sale la única regla que importa: un umbral no se elige por intuición, se deriva. Baseline observado → SLO comprometido → alerta que salta antes de incumplirlo.

01 — Las cinco partes

Anatomía de una alerta

Componente	Qué aporta	Qué pasa sin él
Métrica	Qué se observa	—
Condición	El umbral	—
Duration (`for:`)	Cuánto debe mantenerse antes de disparar	Alertas por picos de tres segundos
Severidad	Critical / Warning / Info	Todo es urgente, o sea, nada lo es
Runbook	Enlace a qué hacer	Alguien despierto a las 3 sin saber qué mirar

Los tres marcados en negrita son justamente los que se omiten, y los tres que deciden si una alerta se atiende o se acaba silenciando. Los dos primeros son la parte fácil.

02 — El umbral

No se elige: se deriva

01 · Baseline Observar la métrica dos semanas o más y calcular sus percentiles. Un umbral sin baseline es una opinión con formato de configuración.

02 · SLO Convertir el baseline en un compromiso explícito: «el 99,9 % de las peticiones responden en menos de 500 ms». Ahora hay algo que incumplir.

03 · Alerta Que salte antes de incumplirlo: el warning con margen, el critical pegado al límite. Si la alerta llega cuando el SLO ya está roto, no es una alerta: es un informe.

«Alerta si la CPU pasa del 80 %» no es un umbral. Es un número redondo que alguien copió de otro sitio, y el hecho de que a veces funcione es exactamente lo que hace difícil quitarlo.

// si nadie sabe de dónde salió el número, nadie se atreve a cambiarlo

03 — La cuenta que ordena la conversación

Error budget

Un SLO del 99,95 % mensual deja un presupuesto de error del 0,05 %. Sobre 30 días, eso son unos 22 minutos de incumplimiento al mes. Ese número hace dos cosas que un porcentaje no hace:

Convierte «la fiabilidad» en una cantidad que se gasta y se agota, no en una virtud.
Da una regla de decisión sin discusión: con presupuesto de sobra, se despliega; agotado, se congelan las funcionalidades nuevas y se arregla lo que se rompe.

Es lo que hace que la conversación entre desarrollo y operaciones deje de ser un choque de sensibilidades — «vamos demasiado rápido» contra «sois demasiado conservadores» — y pase a ser una cifra que las dos partes pueden mirar.

04 — Lo que convierte una alerta en ruido

Los cinco antipatrones

Antipatrón	Por qué duele	Arreglo
Alert fatigue	Tantas que se ignoran todas	Alertar solo si exige una acción
Sin runbook	Saben que pasa algo, no qué hacer	Enlace a documentación en la anotación
Umbral fijo	No contempla la variación normal	Baseline, o detección de anomalías
Sin `duration`	Salta por picos momentáneos	`for: 5m`
Todo critical	No hay priorización posible	Severidades reales y rutas distintas

Y una regla de encaminamiento que se lleva por delante la mitad del ruido: si ya hay una alerta critical en un servicio, silencia sus warnings. Eso es una inhibit_rule en Alertmanager, y evita que una sola caída genere quince notificaciones del mismo incidente en tres canales.

05 — Un caso para mirar de cerca

Dónde salta el warning respecto al objetivo

Umbral de warning como % del objetivo · tabla de SLOs de la guía

Latencia p99 80 %

Error rate 50 %

CPU · warning 87,5 %

CPU · critical 106 %

La regla enunciada es «warning al 80 % del umbral». Las tres primeras filas dan 80 %, 50 % y 87,5 %. La cuarta se sale de la barra: el critical de CPU salta al 106 % del objetivo.

Auditoría La guía enuncia la regla «warning al 80 % del umbral, critical al 95 %» y en la tabla de la página siguiente escribe: latencia p99 con SLO de 500 ms → warning a 400 ms (el 80 %, coherente); error rate con SLO del 1 % → warning al 0,5 % (el 50 %); y CPU con SLO «< 80 %» → warning a 70 % y critical a 85 %. La última es la que conviene mirar dos veces: si el objetivo es mantenerse por debajo del 80 %, ¿qué significa que la alerta crítica no salte hasta el 85 %, es decir, cinco puntos después de haber incumplido el objetivo? ¿Es un error de la tabla, o el 80 % de CPU no era en realidad un SLO sino un número de referencia heredado? Y si es lo segundo — que es lo más probable — ¿qué queda de la regla del 80 %, que la propia tabla incumple en dos de sus cuatro filas?

Para hacer

Tres preguntas a la alerta más ruidosa

Coge la alerta que más veces ha saltado en tu equipo en el último mes y hazle tres preguntas, en este orden: ¿qué hizo alguien distinto la última vez que saltó? ¿Tiene for:? ¿Tiene enlace a un runbook?

Si la respuesta a la primera es «nada», las otras dos sobran: bórrala. Una alerta menos que nadie atiende es una mejora medible en la fiabilidad del sistema de alertas, porque lo que se está arreglando no es la métrica — es la atención del equipo, que es el recurso que de verdad se agota.