Alerting

Umbrales, SLOs, SLIs, on-call, alert fatigue, escalación y cómo diseñar un sistema de alertas efectivo.

¿Por qué importa el alerting?

Tener métricas y dashboards es inútil si nadie los mira cuando algo falla. El alerting es el mecanismo que convierte datos de observabilidad en acciones: notifica a las personas correctas cuando algo requiere atención, antes de que los usuarios se vean afectados.

Pero un sistema de alertas mal diseñado puede ser peor que no tener alertas. Si el equipo recibe 50 alertas diarias que no requieren acción, eventualmente las ignoran todas — incluyendo las críticas.

SLIs, SLOs y SLAs

SLI (Service Level Indicator)

Un SLI es una métrica cuantitativa que mide un aspecto del servicio desde la perspectiva del usuario:

• Disponibilidad: Porcentaje de requests exitosas.
• Latencia: Porcentaje de requests completadas en menos de X ms.
• Throughput: Requests procesadas por segundo.
• Correctitud: Porcentaje de respuestas con datos correctos.

SLO (Service Level Objective)

Un SLO es un objetivo interno sobre un SLI. Define qué nivel de servicio se compromete a mantener el equipo:

• “El 99.9% de las requests deben completarse en menos de 500ms.”
• “La disponibilidad mensual debe ser al menos 99.95%.”
• “El 99% de los pagos deben procesarse en menos de 3 segundos.”

SLA (Service Level Agreement)

Un SLA es un contrato formal con consecuencias (generalmente financieras) si no se cumple. Los SLAs suelen ser menos estrictos que los SLOs internos para tener margen de seguridad.

Error Budget

El error budget es la diferencia entre el 100% y el SLO. Si tu SLO de disponibilidad es 99.9%, tu error budget mensual es 0.1% — aproximadamente 43 minutos de downtime permitido.

El error budget permite tomar decisiones informadas:

• Si queda mucho budget: podés priorizar features y velocidad de desarrollo.
• Si el budget se está agotando: priorizá estabilidad y reducí riesgos.

Diseño de alertas

Alertas basadas en síntomas vs causas

• Alertas por síntomas (recomendado): “La tasa de errores 5xx supera el 1%”. Detectan el impacto al usuario.
• Alertas por causas: “El uso de CPU supera el 90%”. Pueden generar falsos positivos — CPU alta no siempre significa problemas.

Priorizá alertas por síntomas. Usá alertas por causas solo como complemento para diagnóstico.

Umbrales estáticos vs dinámicos

Umbrales estáticos: Valores fijos definidos manualmente.

• Ventaja: Simples de entender y configurar.
• Desventaja: No se adaptan a patrones de tráfico variables.

Umbrales dinámicos: Calculados automáticamente basándose en patrones históricos.

• Ventaja: Se adaptan a variaciones normales (más tráfico en horario laboral).
• Desventaja: Más complejos de implementar y pueden generar falsos positivos durante cambios legítimos.

Severidades

Definí niveles claros de severidad con acciones asociadas:

Ventanas de evaluación

No alertes sobre picos instantáneos. Usá ventanas de tiempo para evitar falsos positivos:

• for: 5m — La condición debe mantenerse durante 5 minutos antes de disparar la alerta.
• Ventanas más largas para métricas ruidosas, más cortas para métricas críticas.

Alert fatigue

¿Qué es?

Alert fatigue ocurre cuando el equipo recibe tantas alertas que deja de prestarles atención. Es uno de los problemas más comunes y peligrosos en operaciones.

Señales de alert fatigue

• El equipo silencia alertas sin investigarlas.
• Las alertas se acumulan sin ser atendidas.
• Incidentes reales se detectan por quejas de usuarios, no por alertas.
• El equipo on-call está agotado y desmotivado.

Cómo combatirla

1. Cada alerta debe ser accionable: Si no requiere acción humana, no es una alerta — es un log o una métrica.
2. Revisión periódica: Revisá las alertas mensualmente. Eliminá las que no generaron acción útil.
3. Agrupación: Agrupá alertas relacionadas para evitar cascadas de notificaciones.
4. Deduplicación: Si la misma alerta se dispara 10 veces en 5 minutos, enviá una sola notificación.
5. Runbooks: Cada alerta debe tener un runbook asociado que explique qué hacer.

On-call

Rotaciones

Un sistema de on-call efectivo incluye:

• Rotaciones semanales: Distribuir la carga entre todo el equipo.
• Escalación: Si el on-call primario no responde en X minutos, escalar al secundario.
• Compensación: El on-call debe ser compensado — es trabajo fuera de horario.

Escalación

Definí una cadena de escalación clara:

1. Nivel 1: Ingeniero on-call del equipo dueño del servicio.
2. Nivel 2: Tech lead o ingeniero senior del equipo.
3. Nivel 3: Incident commander / management.

Los tiempos de escalación dependen de la severidad:

• Critical: Escalar después de 15 minutos sin respuesta.
• Warning: Escalar después de 1 hora sin respuesta.

Herramientas de on-call

• PagerDuty: Plataforma líder de gestión de incidentes y on-call.
• OpsGenie (Atlassian): Alternativa con buena integración con Jira.
• Grafana OnCall: Solución open-source integrada con Grafana.

Runbooks

Un runbook es un documento que describe los pasos a seguir cuando se dispara una alerta específica.

Estructura de un runbook

1. Descripción: Qué significa esta alerta.
2. Impacto: Qué experimenta el usuario.
3. Diagnóstico: Pasos para investigar la causa raíz.
4. Mitigación: Acciones inmediatas para restaurar el servicio.
5. Resolución: Pasos para resolver la causa raíz.
6. Contactos: A quién escalar si no se puede resolver.

Automatización de runbooks

Cuando un runbook tiene pasos repetitivos y bien definidos, considerá automatizarlos:

• Scripts de diagnóstico que recolectan información automáticamente.
• Acciones de mitigación automáticas (restart de servicio, scaling).
• Bots que ejecutan los primeros pasos del runbook y notifican el resultado.

Buenas prácticas

Empezá simple

No intentes alertar sobre todo desde el día uno. Empezá con las métricas RED de cada servicio crítico y expandí gradualmente.

Testea tus alertas

Las alertas son código — deben testearse:

• Verificá que se disparan cuando la condición se cumple.
• Verificá que no se disparan con variaciones normales.
• Simulá fallos periódicamente para validar la cadena completa.

Post-mortems

Después de cada incidente significativo, realizá un post-mortem:

• ¿La alerta se disparó a tiempo?
• ¿El runbook fue útil?
• ¿Qué se puede mejorar?

Usá los post-mortems para mejorar continuamente el sistema de alertas.

Resumen

Un sistema de alertas efectivo es el puente entre la observabilidad y la acción. Basá tus alertas en SLOs, priorizá síntomas sobre causas, combatí activamente el alert fatigue y asegurate de que cada alerta tenga un runbook asociado. El objetivo no es tener más alertas, sino tener las alertas correctas que permitan al equipo mantener el servicio saludable.