Terraform: una cola segura para alertas de prueba

Probar una alerta de infraestructura suele parecer fácil: cambiar un umbral, ejecutar terraform apply y esperar un mensaje. En la práctica, el mensaje llega mas tarde, llega duplicado o no llega nunca. Luego alguien mira el panel de métricas, otro revisa el proveedor de correo y la guardia termina discutiendo si el problema fue Terraform o la notificación.

En equipos SRE me ha resultado más útil tratar una alerta de prueba como una pequeña cadena de entrega. El objetivo no es solo comprobar que el recurso existe. Hay que demostrar que el evento se generó, que pasó por la ruta correcta y que una persona o un sistema pudo confirmarlo.

El síntoma: una alerta que llega tarde

Imaginemos un cambio sencillo en una regla de CPU. El plan se revisa bien y el apply termina sin errores. Sin embargo, el aviso aparece diez minutos después, cuando el valor ya volvió a la normalidad. El resultado visible es confuso: ¿la regla estaba mal, el canal estaba lento o el test usó un dato viejo?

El error habitual es comprobar solo el último salto. Si vemos un correo, marcamos la prueba como correcta. Si no lo vemos, aumentamos el timeout y repetimos. Eso tapa la causa real y vuelve más caro cada incidente.

Una buena prueba deja tres evidencias separadas:

1. Generación: la métrica o el evento cruzó el umbral esperado.
2. Entrega: el proveedor de alertas aceptó y envió la notificación.
3. Confirmación: el receptor encontró el mensaje correcto y pudo identificarlo.

Esta separación permite saber que parte falló. Tambien evita que un mensaje antiguo convierta una prueba roja en verde.

Separar generación, entrega y confirmación

Antes de tocar HCL, definiría un identificador de prueba. Puede ser un valor corto como tf-alert-20260929-01, incluido en las etiquetas del evento o en el asunto de la notificación. No hace falta meter datos privados; solo un correlativo que haga la evidencia buscable.

Después, guardaría un registro por cada etapa:

test_id=tf-alert-20260929-01
generated_at=2026-09-29T08:20:00Z
delivery_status=accepted
delivered_at=2026-09-29T08:20:18Z
confirmed_at=2026-09-29T08:20:24Z

El registro no tiene que vivir en Terraform. Terraform define la regla, el canal y las etiquetas; el script de verificación puede consultar el sistema de alertas y producir un recibo para CI. Así el código de infraestructura permanece declarativo y el test se concentra en el comportamiento.

Para el buzón de prueba conviene usar una dirección aislada por ejecución. Un servicio como tempmail so puede servir para una comprobación temporal, siempre que el contenido no tenga secretos ni datos de clientes. Para una prueba de producción, usaría un canal controlado por la organización y una política de retención explícita.

Una cola de prueba dentro del plan

No recomiendo cambiar el umbral real cada vez que alguien quiere verificar el canal. Es más seguro disponer de una regla o un destino de prueba claramente etiquetado. El cambio debe poder identificarse en el plan:

resource "example_alert_rule" "delivery_probe" {
  name      = "sre-delivery-probe"
  threshold = 1
  labels = {
    environment = "test"
    test_id     = "tf-alert-20260929-01"
  }
}

El proveedor concreto cambia, pero la idea se mantiene: una prueba pequeña, reversible y visible. En señales útiles en emails de prueba se explica una preocupación parecida desde el lado del producto: un mensaje tiene más valor cuando lleva contexto que cuando solo dice “llegó”.

También es importante que el test no dependa de un sleep fijo. Mejor hacer polling con un límite total, guardar cada intento y detenerse cuando el test_id aparece. Si el sistema usa una cola, registrar el momento de aceptación ayuda a distinguir retraso de entrega de retraso de consumo.

Los logs queda más utiles cuando incluyen la causa de salida: confirmed, timeout, wrong-recipient o stale-message. Un texto generico como “email no encontrado” obliga a repetir la investigación durante la guardia.

Cómo leer el resultado en una guardia

Cuando la prueba falla, el recibo debería responder cuatro preguntas sin abrir cinco paneles:

• ¿Qué cambio de Terraform activó el test?
• ¿Qué test_id esperaba el verificador?
• ¿En qué etapa dejó de avanzar la cadena?
• ¿Cuál fue el último timestamp observado?

Si la generación existe pero la entrega no fue aceptada, revisaría la integración o sus permisos. Si la entrega fue aceptada pero no hay confirmación, miraría el buzón, el filtro y la latencia de lectura. Si aparece un mensaje con otro identificador, probablemente hay contaminación entre ejecuciones. Depronto el sistema está sano, pero la prueba no está aislada.

Para no confundir al equipo, la salida de CI debe incluir un enlace al recibo y el estado final. Un fallo con evidencia es accionable; un fallo que solo dice “timeout” es otra tarea de detective.

Preguntas rápidas

¿Debo ejecutar estas pruebas en cada apply?

No necesariamente. En entornos tranquilos puede bastar con una ejecución programada o después de cambios en el canal. En incidentes, conviene lanzarla manualmente con un test_id nuevo.

¿Puedo reutilizar el mismo buzón?

Solo si cada ejecución tiene un identificador único y el verificador descarta mensajes viejos. Un buzón compartido sin limpieza hace que los resultados sean dificiles de interpretar.

¿Qué hago con errores como dummy e mail o tem email?

Trátalos como texto de entrada inválido, no como señal de entrega. Los términos raros pueden aparecer en datos de prueba, pero no deben convertirse en reglas de enrutamiento ni en anclas de enlaces.

Checklist antes de aplicar cambios

• [ ] La regla de prueba está separada de la alerta de producción.
• [ ] Cada ejecución tiene un test_id único.
• [ ] Generación, entrega y confirmación producen evidencia distinta.
• [ ] El polling tiene límite total y conserva sus intentos.
• [ ] El receptor no reutiliza mensajes viejos.
• [ ] El recibo indica la etapa exacta del fallo.
• [ ] El cambio se puede revertir sin tocar el tráfico real.

Conclusión

La prueba de una alerta no termina cuando Terraform dice que el recurso fue creado. Termina cuando podemos seguir el evento desde la condición inicial hasta una confirmación inequívoca. Separar esas etapas reduce los falsos positivos, hace más corta la investigación y deja un runbook que otro compañero puede seguir sin adivinar.

Si el equipo ya tiene pruebas sintéticas sin ruido en alertas, el siguiente paso natural es darles un recibo pequeño y reutilizable. No hace falta una plataforma nueva: basta un identificador, polling con límites y evidencia que cuente la historia completa.