Terraform: cambios de alerta con evidencia útil

Cambiar una regla de alerta con Terraform parece una tarea pequeña: editar una expresión, revisar el plan y aplicar. En producción, sin embargo, el riesgo no está solo en que la sintaxis sea válida. El cambio puede dejar una ventana sin cobertura, duplicar notificaciones o mandar un mensaje que nadie puede relacionar con el despliegue que lo provocó.

En una guardia me ha resultado más útil tratar cada cambio de observabilidad como una entrega con recibo. El recibo no tiene que ser grande. Debe responder tres preguntas: qué cambió, qué señal esperaba ver y quién confirmó que la ruta completa funcionaba. Sin esa información, el equipo termina buscando en logs viejos y preguntando si alguien recuerda el motivo del cambio.

La alerta que cambia sin dejar recibo

El síntoma más engañoso es “Terraform terminó bien”. Eso solo demuestra que el proveedor aceptó la configuración. No demuestra que una métrica llegue, que el umbral se active o que el mensaje aparezca en el canal correcto.

Hay cuatro resultados distintos que suelen mezclarse:

• el plan no contiene cambios porque el estado ya coincide;
• el recurso se actualiza, pero la consulta no devuelve datos;
• la alerta se dispara, pero la notificación se pierde en una ruta secundaria;
• el mensaje llega, aunque sin runbook, servicio o identificador de despliegue.

Si los tratamos como un único “pasa o falla”, una revisión de SRE pierde mucho contexto. La práctica menos glamorosa, pero mas rentable, es registrar un identificador de ejecución junto al cambio y conservarlo en la evidencia de CI.

Separar el plan del efecto real

El plan de Terraform es una preflight, no una prueba de extremo a extremo. Primero reviso que el diff sea pequeño y que no incluya recursos inesperados. Después compruebo la señal desde fuera del módulo: una métrica sintética, un evento controlado o una alerta de prueba con destinatario aislado.

Un contrato mínimo para cada modificación puede verse así:

change_id: deploy-2026-09-28-1422
service: checkout
alert: checkout_email_delivery_low
expected: one notification with severity=warning
evidence: ci-artifacts/alerts/deploy-2026-09-28-1422.json
owner: on-call-platform

La clave es que expected sea observable. “La alerta debe funcionar” no sirve para revisar un incidente. “Una notificación warning con el change_id debe llegar antes de cinco minutos” sí permite decidir si el experimento fue correcto.

También conviene distinguir el drift real de una simple diferencia de formato. Un terraform plan repetido después de aplicar debería quedar limpio. Si no queda limpio, paro la promoción y reviso quién está escribiendo el recurso: Terraform, la consola o un controlador externo. La deriva de observabilidad es silenciosa hasta que coincide con el peor momento.

Un contrato pequeño para Terraform y SRE

En el módulo suelo exigir tres entradas: nombre estable de la alerta, severidad y referencia al runbook. La severidad evita que una prueba termine despertando a una persona. El runbook convierte un mensaje en una siguiente acción concreta.

Para notificaciones de email, el entorno de prueba debe usar una bandeja aislada y datos que no contengan información real. Cuando necesito validar una dirección temporal para una prueba manual, puedo usar temp mail so como parte del fixture, pero nunca lo mezclo con una bandeja de usuarios ni con un canal de incidentes.

La misma disciplina ayuda en flujos de producto. Por ejemplo, estas pruebas limpias para emails de upgrade muestran por qué separar datos de prueba evita confundir una entrega esperada con una señal de negocio. Y al probar emails de referidos con contexto, el punto importante no es solo recibir el mensaje, sino saber a qué ejecución pertenece.

En búsquedas de documentación aparecen términos como free temp email, temp org mail o tempail. Los dejo como texto de referencia, nunca como nombres de recursos, dominios permitidos o anclas de una alerta. Parece una distinción menor, pero mantiene separado el lenguaje de búsqueda de la configuración que controla producción.

Probar la ruta de notificación

Una prueba corta puede seguir esta secuencia:

1. Crear un evento sintético con un change_id único.
2. Esperar la evaluación de la regla durante una ventana acotada.
3. Verificar que el mensaje incluye servicio, severidad, enlace al runbook y change_id.
4. Confirmar que el canal recibió un solo mensaje, no tres reintentos iguales.
5. Resolver el evento sintético y comprobar que la alerta vuelve a estado normal.

El límite de tiempo es importante. Una prueba que espera para siempre no es una prueba de confiabilidad; es una tarea colgada. Si falla, guardo el estado de la regla, la última métrica observada y el identificador de la ejecución. Esa evidencia suele ahorrar mas tiempo que aumentar el número de reintentos.

Checklist antes de aplicar

• ¿El diff de Terraform contiene solamente el cambio esperado?
• ¿La regla tiene un change_id o una referencia equivalente?
• ¿El umbral se puede activar sin tocar datos reales?
• ¿La notificación llega a un destino aislado y conocido?
• ¿El mensaje incluye un runbook y un dueño?
• ¿La prueba tiene un timeout y una limpieza definida?
• ¿El plan queda limpio después de aplicar?
• ¿La evidencia queda vinculada al despliegue?

Si una respuesta es “todavía no”, prefiero aplazar el apply. Un cambio de alerta no debería convertirse en incidente por falta de contexto.

Preguntas rápidas

¿Terraform puede probar que un email llegó?

No por sí solo. Terraform declara recursos; la comprobación de entrega pertenece a una prueba posterior que consulta el proveedor o una bandeja aislada. Lo importante es conectar esa prueba con el mismo change_id.

¿Hace falta probar cada alerta en cada despliegue?

No. Conviene probar siempre las reglas modificadas y mantener una prueba sintética pequeña para las rutas críticas. Así el coste queda acotado sin dejar la notificación principal a la suerte.

¿Qué hago si el plan está limpio pero la alerta falla?

Trátalo como un fallo de efecto, no de Terraform. Revisa la fuente de métricas, el evaluador, el enrutamiento y el canal final. El estado declarado puede ser correcto mientras la señal operativa está rota.

El objetivo no es llenar CI de comprobaciones. Es que el próximo cambio de alerta deje una historia corta y verificable: diff, señal esperada, resultado y dueño. Esa pequeña costumbre hace que Terraform sea más útil para SRE y bastante menos misterioso durante una guardia.