3:12 a.m., PagerDuty: "Disco 75% staging-db". La siesta de guardia. 3:28 am: “Memoria alta de Prometheus-dev”. Siesta. 4:05 a. m.: “Tasa de error de pago del 15 %” – ahogado en ruido, leído a las 9 a. m. Pérdida estimada: cuatro horas de ventas.
La fatiga de alerta no es un problema de herramienta. Es un problema de contrato: demasiadas señales sin gravedad, sin runbook, sin administrador, hasta que el canal se convierte en spam y la verdadera urgencia pasa desapercibida. Prometheus, Datadog o Grafana no crean ruido: la ausencia de gobernanza permite que se acumule.
Gravedad, enrutamiento y regla de página
| Nivel | Canal | Ejemplo |
|---|---|---|
| P1 crítico | Buscapersonas telefónico | Pago inicial, pérdida de datos |
| P2 | Flojo @oncall | p95 x2 30 min |
| P3 | Boleto | Tendencia del disco 7 días |
| Información | Panel de control | Planificación de capacidad |
Una alerta sin enlace de runbook y sin administrador de servicios debería prohibirse en producción. Si la persona de guardia no sabe qué hacer en sesenta segundos, no es una alerta, es una notificación.
Cada página nocturna debe cambiar una acción concreta; de lo contrario, nunca debería haber desaparecido.
Síntomas del usuario versus métricas de vanidad
Bueno: tasa de error 5xx al finalizar la compra; Velocidad de grabación SLO de ventanas múltiples. Malo: CPU superior al sesenta por ciento sin correlación; El certificado caduca en treinta días (un boleto es suficiente).
Prometheus Alertmanager permite group_by e inhibición: si el centro de datos no funciona, inhibir las alertas infantiles evita una avalancha innecesaria. Pero la herramienta no reemplaza la elección de señales; consulte Prometheus Metrics para instrumentar lo que importa.
Ventanas, histéresis y aleteo.
para: 10 m evita un solo pico. Umbrales con margen: repagar solo si la situación es peor que ayer y por encima del SLO. El aleteo indica un umbral o métrica incorrecto: arregle la raíz, no repita el silencio.
Una alerta que fluctúa entre activada y resuelta cada diez minutos desgasta al equipo más que una interrupción real. Mida la tasa de falsos positivos trimestralmente.
Propiedad y revisión trimestral
Auditoría: ¿activada en los últimos noventa días? ¿Acción tomada? ¿Tasa de falsos positivos? Suprime sin piedad el ruido. La preproducción no debería incluir la misma rotación de producción: etiqueta env=staging → ticket solamente.
Cada alerta debe tener un propietario designado, no el "equipo de infraestructura". Sin propiedad, nadie aboga por eliminar el ruido o mejorar el runbook.
Restricción humana: sueño y rotación.
Rotación de al menos tres personas, entrega documentada, compensación de tiempo. Después del incidente: ¿falta alerta? ¿demasiado ruidoso? ajustarse, sin culpa. Un guardia exhausto pasa por alto las emergencias reales tanto como una alerta mal calibrada. También documente quién puede silenciar una alerta y durante cuánto tiempo; el silencio permanente durante la puesta en escena es saludable; El silencio permanente sobre el pago es un fracaso no tratado.
La cumbre: vigilando quién grita el lobo
Decide y avanza sin puntos ciegos
Primero, reclasifique las alertas existentes según la gravedad real y el impacto en el usuario. Luego reemplace los umbrales del procesador con alertas basadas en los SLO del usuario cuando la correlación lo permita. Agregue un runbook a cada alerta que despierte a alguien por la noche. Programe una revisión trimestral con supresión explícita de ruido. Aislar la preproducción de la rotación de producción nocturna. Compare el seguimiento gestionado a través del directorio y el comparador. Apunte a más del ochenta por ciento de páginas nocturnas procesables.
Preguntas frecuentes
¿Cuántas alertas de buscapersonas hay en producción?
Poco: cada página requiere una acción inmediata. El resto va al ticket o al panel. Menos de cinco páginas despiertas por semana si está bien calibrado; más allá de eso, el equipo normaliza el ruido.
¿Cuál es la diferencia entre advertencia y crítica?
Página crítica con runbook y administrador; Advertencia solo durante el horario comercial. Nunca mezcle los dos canales nocturnos; esto destruye la credibilidad del servicio de guardia.
¿Cómo probar una alerta?
Ejercicio simulado, inyección de errores, activación y verificación de runbook. Una alerta que nunca se prueba probablemente sea falsa o se ignore. Programe un día de juego trimestral.
¿Alertas de infraestructura frente a SLO de usuario?
Primero los síntomas del usuario; procesador sólo si se demuestra correlación. Una CPU alta sin impacto para el usuario no debería despertar a nadie.
Una alerta que no cambia una acción nocturna no debería despertar a nadie.