Terraform: prueba alertas sin romper guardias

Una alerta puede estar bien escrita y aun así no llegar a la persona de guardia. En una migración de Terraform vimos el síntoma clásico: el plan no tenía cambios raros, el monitor pasó a estado crítico y el equipo descubrió el fallo varios minutos después, al mirar el panel manualmente.

La lección no fue “revisar mejor el YAML”. Fue tratar la notificación como una ruta completa: regla, proveedor, secreto, buzón o canal de destino y evidencia de entrega. Cuando cada pieza tiene una prueba pequeña, una modificación de infraestructura deja de ser una apuesta.

El síntoma: una alerta correcta que no llega

Primero separo dos preguntas que suelen mezclarse:

1. ¿La regla se activa con el evento correcto?
2. ¿El mensaje llega al destino correcto y se puede demostrar?

Un alert firing en Prometheus responde la primera pregunta. No demuestra que el receptor aceptó el mensaje, que el webhook no devolvió un 429, o que el correo no terminó en una carpeta distinta. En una guardia nocturna, esa diferencia pesa bastante.

También conviene no probar contra una cuenta personal. Para una prueba corta se puede validar correos de mantenimiento en Kubernetes con un buzón aislado y datos que no sean de clientes. Si el equipo necesita un destino efímero, puede crear correo temporal para separar la prueba del correo real; aun así, hay que confirmar la política de retención y no enviar secretos en el mensaje.

Separar infraestructura, regla y entrega

En el repositorio dejo tres capas visibles:

• Infraestructura: Secret, ConfigMap, receptor y permisos.
• Regla: condición, ventana, severidad y etiquetas.
• Entrega: plantilla, reintentos, timeout y respuesta del proveedor.

Esto hace más fácil leer el diff. Si cambia solo el receptor, no debería aparecer una modificación accidental de la ventana de evaluación. Si cambia una credencial, el valor debe venir del gestor de secretos, no del archivo de Terraform ni de un log de CI.

Una plantilla mínima debería tener nombre de servicio, entorno, severidad, enlace al panel y un identificador de incidente. Evito poner el contenido del secreto, tokens o la dirección completa del usuario. En una ocasión el cuerpo decía dummy e mail porque venía de un fixture antiguo; no rompió la entrega, pero sí confundió el diagnóstico hasta que lo corregimos.

Probar el cambio con Terraform

El plan es una revisión de intención, no una prueba de entrega. Antes de aplicar, uso una revisión con estas preguntas:

¿Qué receptor cambia?
¿Qué secreto lee el workload?
¿Qué evento sintético dispara la alerta?
¿Dónde queda la evidencia de aceptación?
¿Cómo se revierte sin editar a mano?

Para cambios sensibles, guardo el plan y exijo una aprobación del equipo propietario. Después del apply, una prueba sintética envía un evento con una etiqueta de entorno de pruebas. El receptor debe responder dentro del timeout y la plataforma de correo debe dejar un identificador de entrega. La prueba no necesita ser grande; necesita ser repetible.

Si la notificación depende de un secreto rotado, conviene probar la rotación de secretos por correo por separado. Mezclar rotación, cambio de plantilla y cambio de receptor en un mismo despliegue crea demasiadas causas posibles cuando algo falla.

Crear una prueba reproducible en Kubernetes

En Kubernetes prefiero un Job de corta duración que publique el evento sintético y escriba un resultado pequeño. El resultado puede contener test_id, hora, entorno, código del receptor y estado final. No debe guardar el token ni el contenido completo del correo.

El flujo de CI queda más o menos así:

terraform plan -> aprobación -> terraform apply
        -> Job de alerta sintética
        -> comprobar respuesta del receptor
        -> comprobar evidencia de entrega
        -> guardar veredicto y limpiar

El paso de limpieza importa. Un Job olvidado genera ruido y un buzón lleno puede ocultar el siguiente mensaje. También fijo un límite de tiempo: si no hay evidencia dentro de, por ejemplo, dos minutos, la prueba falla. No conviene convertir un timeout en un éxito parcial solo porque el monitor llegó a firing.

Qué registrar durante un incidente

Cuando la alerta real no llega, recojo la misma evidencia en cada capa:

• versión del despliegue y hash del plan aplicado;
• hora del evento y zona horaria;
• estado de la regla y etiquetas recibidas;
• código y latencia del receptor;
• identificador de entrega, sin datos personales innecesarios;
• último cambio de secreto o plantilla.

Un pequeño runbook SRE evita que cada ingeniero invente una investigación bajo presión. También ayuda a distinguir “la regla nunca disparó” de “el proveedor rechazó el mensaje”. Son incidentes distintos y tienen rollback distinto.

Checklist antes de tocar el canal de guardia

• [ ] El terraform plan fue revisado y guardado.
• [ ] La regla sintética tiene un identificador único.
• [ ] El secreto se inyecta desde el gestor aprobado.
• [ ] El receptor devuelve una respuesta verificable.
• [ ] Existe evidencia de entrega sin tokens ni direcciones expuestas.
• [ ] El Job de prueba tiene timeout y limpieza.
• [ ] El rollback está probado en un entorno seguro.

Probar alertas no es mandar un correo y mirar si aparece. Es comprobar una cadena operativa completa, con límites claros y una evidencia que otro compañero pueda revisar. Terraform ayuda a hacer reproducible la infraestructura, Kubernetes ofrece un lugar controlado para ejecutar la prueba y SRE aporta la pregunta importante: ¿cómo sabremos que la guardia quedó realmente protegida?