AWS Builder Center

Builder Center

La alarma sono. Y ahora que? Runbook guiado por SLOs

Sabes cual estadistica usar, que errores rompen el SLO, como computar el SLI, y como visualizarlo, pero son las 3am, la alarma de burn rate acaba de sonar, y nadie te ha dicho que hacer primero.

vtjean

La alarma que nadie entreno

Configuraste todo bien. Estadistica p99 en vez de Average en Amazon CloudWatch. SLI de latencia con la Formula 3 del Blog 3. Presupuesto de error de 201.6 minutos en ventana rolling de 28 dias. Dashboard organizado por SLO con las 4 filas del Blog 4. Alarma de burn rate con umbral 13.44 para fast burn en ventana de 1 hora.
La alarma suena a las 3:12am. Tu telefono vibra. Abres el dashboard.
Y te congelas. Porque nadie escribio el paso siguiente.
Cada blog, cada guia, cada tutorial de observabilidad te dice como configurar alarmas. Ninguno te dice que hacer cuando suenan. El on-call queda solo con un dashboard verde-amarillo-rojo y cero instrucciones.
Este post cierra ese hueco. Es el runbook que conecta los blogs anteriores de esta serie en un protocolo de respuesta: desde que la alarma suena hasta que decides si paginar al equipo o volver a dormir.
Los cuatro blogs anteriores:

Paso 1: Abre Fila 1 -- cual SLO esta en breach?

No abras la consola de Amazon EC2. No abras CloudWatch Logs. Abre el dashboard SLO que construiste en el Blog 4.
Fila 1 muestra la salud de cada SLO como un widget de tipo Number o Gauge con colores:
  • Verde: cumple el SLO
  • Amarillo: zona de reaccion (entre SLO y SLA)
  • Rojo: bajo el SLA
Si Fila 1 esta toda verde y la alarma sono, tienes un falso positivo. El burn rate se disparo por un spike transitorio que ya se resolvio. Verifica que los widgets reflejen el mismo periodo que la alarma. Si confirmas verde, documenta y vuelve a dormir.
Si hay un widget amarillo o rojo, ya sabes cual SLO esta fallando. Latencia? Disponibilidad? Saturacion? Esa respuesta determina todo lo que sigue.
Tiempo invertido: 10 segundos. Un dashboard bien organizado te da la respuesta sin buscar.

Paso 2: Baja a Fila 2 -- cual SLI esta causando el breach?

Fila 2 muestra los SLIs que alimentan cada SLO. Si el SLO de latencia esta en breach, mira el widget de p99 de TargetResponseTime. Si es el de disponibilidad, mira la formula de disponibilidad ((m2-m1)/m2)*100 del Blog 3, Formula 2.
Aqui aplicas lo que aprendiste en el Blog 1: la estadistica correcta te dice la verdad. Si el SLI usa p99 y esta en breach, el problema es real. Si alguien hubiera dejado Average (Error 1 del Blog 2), Fila 2 se veria verde mientras los usuarios sufren.
Identifica el SLI especifico que esta fallando. Si multiples SLIs estan en breach simultaneamente, prioriza por impacto al usuario: disponibilidad > latencia > saturacion. Un servicio caido (disponibilidad) es peor que un servicio lento (latencia), que es peor que un servicio al borde del limite (saturacion).
Tiempo invertido: 30 segundos.

Paso 3: Mira Fila 3 -- cuanto tiempo tienes?

Fila 3 es la que diferencia una emergencia de una investigacion de manana. Muestra dos numeros:
  1. Presupuesto de error restante en minutos
  1. Burn rate actual
El burn rate determina la urgencia. Recuerda del Blog 2:
Plain text
Burn Rate = (minutos unhealthy / minutos en ventana) x (total minutos en intervalo / presupuesto total)

Con un SLO de 99.5% en 28 dias (presupuesto = 201.6 minutos):
Escenario severo: 40 de 60 minutos unhealthy en la ultima hora.
Plain text
BR = (40/60) x (40,320/201.6) = 0.667 x 200 = 133.3

A este ritmo consumes el presupuesto completo en 28 dias / 133.3 = 5 horas. Emergencia.
Escenario leve: 3 de 60 minutos unhealthy en la ultima hora.
Plain text
BR = (3/60) x (40,320/201.6) = 0.05 x 200 = 10.0

A este ritmo consumes el presupuesto completo en 28 dias / 10 = 2.8 dias. No es urgente.

Tabla de severidad por burn rate

Burn Rate
Tiempo hasta agotar presupuesto
Severidad
Accion
> 100
< 7 horas
Critica
Pagina al equipo inmediatamente
14 -- 100
7 horas -- 2 dias
Alta
Abre un incidente, investiga ahora
1 -- 14
2 -- 28 dias
Media
Investiga en horario laboral
< 1
> 28 dias
Baja
Monitorea, no actues
Los umbrales exactos dependen de tu contexto. Un servicio de pagos con SLA contractual puede tratar BR > 14 como critico. Un servicio interno sin SLA puede tolerar BR mas altos. Lo importante es que el burn rate te da un numero objetivo para tomar la decision, no una intuicion. Nota que el umbral 13.44 del Blog 2 (fast burn alert) cae exactamente en la frontera entre Media y Alta: es el punto donde dejas de poder esperar.
Nota sobre falsos positivos en poco trafico: si el burn rate es alto pero el SampleCount es bajo (Error 2 del Blog 2), verifica antes de paginar. Un p99 calculado con 5 data points a las 3am puede ser ruido estadistico. Cruza con Trimmed Count. Si el conteo es menor que el umbral minimo de tu servicio, trata el periodo como datos insuficientes y documenta.
Tiempo invertido: 1 minuto.

Paso 4: Investiga en Fila 4 -- que servicio esta causando el problema?

Solo llegas aqui si el burn rate justifica investigacion. Fila 4 es el dashboard clasico por servicio que ya conoces: CPU, memoria, latencia por recurso, errores por funcion de AWS Lambda, conexiones de base de datos.
Pero ahora llegas con contexto:
  • Sabes que SLO esta en breach (Paso 1)
  • Sabes que SLI esta fallando (Paso 2)
  • Sabes cuanto tiempo tienes (Paso 3)
Eso reduce el espacio de busqueda. Si el SLI de latencia p99 esta en breach, no mires CPU de EC2 (a menos que sea una causa conocida en tu servicio). Ve directo a las metricas que pueden causar latencia alta: ReadLatency de Amazon RDS, Duration de Lambda, TargetResponseTime por target group.

Usa CloudWatch Investigations para acelerar

Amazon CloudWatch Investigations es un asistente que usa IA generativa para analizar la telemetria de tu sistema y sugiere posibles causas raiz. Esta disponible de forma general desde junio de 2025.
"CloudWatch investigations analyzes multiple metrics, logs, and deployment events to provide suggestions for remediation and root-cause analyses, reducing alarm resolution time." -  Streamline DevOps troubleshooting: Integrate CloudWatch investigations with Slack 
Puedes configurar tus alarmas de burn rate para que inicien automaticamente una investigacion cuando entran en estado ALARM:
"When you create a CloudWatch alarm, you can specify for it to automatically start an investigation when it goes into ALARM state. You can do this for both metric alarms and composite alarms." -  Investigate operational issues in your environment 
Esto significa que cuando llegas al Paso 4, CloudWatch Investigations ya lleva minutos analizando metricas, logs y eventos de despliegue relacionados con tu alarma. Revisa sus sugerencias antes de buscar manualmente.
Tiempo invertido: variable, pero llegas enfocado.

Paso 5: Decide -- paginar, investigar, o documentar?

Con la informacion de los pasos 1-4, toma una de tres decisiones:
Pagina al equipo si:
  • Burn rate > 100 (o tu umbral critico)
  • El SLI muestra degradacion sostenida (no un spike que ya se resolvio)
  • El SampleCount confirma que hay trafico suficiente para que la estadistica sea confiable
Abre un incidente e investiga si:
  • Burn rate entre 14 y 100
  • El SLI sigue en breach pero no es catastrofico
  • Tienes horas, no minutos, antes de agotar el presupuesto
Documenta y monitorea si:
  • El burn rate ya bajo a < 1 (el spike se resolvio solo)
  • El SampleCount era insuficiente (falso positivo estadistico)
  • Fila 1 volvio a verde
Cualquiera que sea la decision, documenta: hora de la alarma, SLO afectado, burn rate observado, accion tomada, resultado. Si usas CloudWatch Investigations, genera el reporte de incidente directamente desde la investigacion:
"You can generate incident reports from in-progress or completed investigations." -  Generate a report from an investigation 

Ejemplo completo: la alarma de las 3:12am

Juntemos todo con el escenario del inicio.
3:12am -- La alarma de fast burn suena. Abres el dashboard.
Paso 1 (10 seg): Fila 1 muestra el SLO de latencia en amarillo (99.2%). Los otros dos SLOs estan verdes.
Paso 2 (30 seg): Fila 2 muestra p99 de TargetResponseTime en 1,200ms. El umbral del SLO es 500ms. El SLI esta claramente en breach.
Paso 3 (1 min): Fila 3 muestra burn rate = 26.7. Presupuesto restante: 153 de 201.6 minutos. Tienes ~19 horas antes de agotar el presupuesto. Segun la tabla: severidad Alta (BR entre 14 y 100). No es una emergencia de 5 horas, pero necesita atencion hoy.
Paso 4 (5 min): Abres Fila 4. CloudWatch Investigations ya inicio analisis automatico cuando la alarma se disparo. Las sugerencias indican un despliegue reciente (hace 45 minutos) que cambio la configuracion de conexiones a RDS. ReadLatency de RDS salto de 5ms a 120ms despues del despliegue.
Paso 5: abres un incidente. No paginas a todo el equipo (BR < 100) pero contactas al ingeniero que hizo el despliegue. Revert en 15 minutos. El p99 baja a 380ms. Fila 1 vuelve a verde.
Total: 8 minutos desde la alarma hasta identificar la causa. Sin el dashboard SLO, habrias abierto 6 consolas, mirado 47 widgets, y tardado 30 minutos en llegar a la misma conclusion.

El runbook como template

Aqui esta el protocolo resumido para copiar en tu herramienta de runbooks:
Plain text
RUNBOOK: Respuesta a alarma de burn rate

PASO 1 -- Fila 1 del dashboard SLO
  - Cual SLO esta en breach?
  - Si todo esta verde: falso positivo. Documenta y cierra.

PASO 2 -- Fila 2 del dashboard SLO
  - Cual SLI esta fallando?
  - Prioridad: disponibilidad > latencia > saturacion

PASO 3 -- Fila 3 del dashboard SLO
  - Cual es el burn rate?
  - BR > 100: pagina inmediatamente
  - BR 14-100: abre incidente, investiga ahora
  - BR 1-14: investiga en horario laboral
  - BR < 1: monitorea
  - Verificar: SampleCount suficiente? (Blog 2, Error 2)

PASO 4 -- Fila 4 del dashboard SLO + CloudWatch Investigations
  - Revisa sugerencias automaticas de Investigations
  - Busca correlacion con despliegues recientes
  - Enfoca en metricas de servicio relevantes al SLI en breach

PASO 5 -- Decide
  - Paginar / Abrir incidente / Documentar y monitorear
  - Generar reporte de investigacion
  - Documentar: hora, SLO, BR, accion, resultado


Lo que este runbook no cubre (limitaciones honestas)

No reemplaza runbooks especificos de servicio. Si tu equipo tiene un runbook para "RDS ReadLatency alta," usalo despues del Paso 4. Este runbook te lleva del "la alarma sono" al "se donde buscar," no del "encontre RDS lento" al "aqui esta el fix."
No cubre alarmas que no son de burn rate. Si usas umbrales fijos (CPUUtilization > 80%), el Paso 3 no aplica. Pero si leiste el Blog 2, ya sabes por que deberias migrar a burn rate para alarmas de SLO.
La tabla de severidad es un punto de partida, no un estandar. Los umbrales (100, 14, 1) funcionan para un SLO de 99.5% en 28 dias. Si tu SLO es 99.9% (presupuesto = 40.3 minutos), los umbrales de burn rate cambian porque cada minuto de breach tiene mas peso. Calibra para tu contexto.
CloudWatch Investigations requiere configuracion previa. Para obtener sugerencias automaticas, tu cuenta necesita tener habilitados los permisos de Amazon Q Developer y la integracion con CloudWatch Application Signals o AWS X-Ray para mapeo de dependencias. Si no lo has configurado, el Paso 4 funciona igual -- solo que buscas manualmente en vez de revisar sugerencias.

Conclusion

Los cuatro blogs anteriores construyeron un pipeline: estadistica correcta (Blog 1) que alimenta un SLI correcto (Blog 2) calculado con Metric Math (Blog 3) y visualizado en un dashboard SLO-first (Blog 4). Este blog es el quinto paso: que haces cuando ese pipeline detecta un problema.
La respuesta no es "mira todo y busca algo raro." Es un protocolo de 5 pasos que usa la estructura del dashboard para tomar una decision informada en menos de 2 minutos. El burn rate te da un numero para decidir si es una emergencia o puede esperar. CloudWatch Investigations te da un punto de partida para la causa raiz.
La proxima vez que tu telefono vibre a las 3am, no te congeles. Abre Fila 1.

Recursos

# monitoring-observability# observability# monitoring# amazon-cloudwatch# aws-cloudwatch
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article