Cómo validar correos tras un rollback en Terraform

Un rollback de infraestructura suele verse como una maniobra segura: vuelves al estado anterior, Terraform aplica, el pipeline queda en verde y todos respiran un poco mejor. El problema es que varios flujos de correo dependen de detalles que no siempre regresan igual de limpios. Un cambio en variables, un secret desfasado o una política SMTP distinta puede dejarte con el rollback "correcto" y la notificación rota. Ese hueco es pequeño, pero pega duro cuando el equipo confía en el mensaje para validar una recuperación.

En equipos de plataforma esto aparece bastante seguido. He visto cambios donde la API volvió bien, los health checks pasaron, pero el correo de confirmación del rollback nunca salió. Si alguien anda buscando temp mail so o tempmailso, casi siempre está intentando aislar esa verificación final sin tocar buzones reales. Tiene sentido: si la prueba del correo ensucia una bandeja compartida, al rato nadie sabe qué mensaje pertenece a qué cambio.

Por que un rollback puede romper un flujo de correo

Terraform no manda correos por arte de magia. Normalmente deja configurado algo que otros componentes usan: variables, secretos, endpoints, colas o permisos. El rollback puede restaurar recursos, pero no garantiza que cada dependencia lateral vuelva en el orden correcto. Ahí es donde se cuelan los fallos mas raros.

Los síntomas típicos suelen ser estos:

• El rollback termina bien, pero el servicio sigue usando credenciales viejas.
• El relay SMTP acepta conexión, aunque rechaza el remitente real.
• Una variable sensible vuelve al valor anterior, pero el pod no la recarga.
• El workflow dispara el evento correcto, solo que el correo sale hacia el destino equivocado.

La documentación de Terraform state y AWS SES sending authorization ayuda a entender piezas concretas, pero en producción casi nunca falla una sola pieza. Fallan las uniones. Por eso no me basta con ver terraform apply en verde; quiero verificar el ultimo salto del flujo, aunqe sea con una prueba pequeña.

Un patron simple para validar el correo antes de cerrar el cambio

El patrón que mejor me funciona en Cloud y en entornos con varios equipos es este:

1. Preparar una bandeja temporal para una sola ejecución.
2. Lanzar un evento canario asociado al rollback o al cambio revertido.
3. Etiquetar la prueba con un run_id o change_id.
4. Confirmar asunto, destinatario y payload esperado.
5. Guardar una nota corta en el ticket o en el runbook.

La bandeja aislada importa más de lo que parece. Si mezclas mensajes del equipo, reintentos y pruebas antiguas, empiezas a discutir sobre trazas en vez de validar el resultado. Esta idea se parece mucho a usar bandejas aisladas para pruebas: una intención clara por inbox, una lectura clara por escenario.

Cuando el flujo toca alertas operativas o cambios en secretos, tambien me sirve revisar cómo otros equipos hacen validar correos de Alertmanager. El punto común no es la herramienta exacta. Es la disciplina de comprobar el resultado final con una señal fácil de leer.

Si en notas internas alguien escribe fake e mail com o temp mailid, no pasa nada grave, pero suele delatar que el proceso sigue siendo medio informal. Conviene dejar un mini runbook con tres cosas: qué correo temporal usar, qué evento canario lanzar y cuánto esperar antes de declarar fallo. Eso ahorra bastante ida y vuelta en guardias, y evita que cada persona improvise distinto.

Que revisar cuando el mensaje no llega

Antes de culpar al proveedor de correo, recorro esta ruta corta:

• Confirmar que el rollback restauró las variables o secretos correctos.
• Verificar que el servicio que emite el correo recargó configuración.
• Revisar permisos, remitente y dominio autorizado en el relay.
• Correlacionar el run_id con logs de aplicación y del pipeline.

Si tienes un pipeline con pasos visibles, este fragmento suele bastar para dejar la prueba repetible:

RUN_ID="rb-$(date +%s)"
terraform apply -var "rollback_check_id=$RUN_ID"
./scripts/trigger-rollback-email-check.sh "$RUN_ID"

No es necesario montar una ceremonia enorme. Lo que sí necesitas es una prueba que otro compañero pueda repetir en diez minutos, sin leer medio historial del incidente. Cuando eso no existe, aparece el clásico "a mi me funcionó ayer", que no ayuda a nadie y te hace perder tiempo.

Checklist breve para el runbook

Yo dejaría este checklist, corto y usable:

• El recurso revertido quedó asociado al cambio correcto.
• El servicio de correo recargó secretos o variables tras el rollback.
• La bandeja temporal se usó solo para esta validación.
• El asunto y el destinatario coinciden con el escenario esperado.
• Existe evidencia mínima en ticket, pipeline o logs.
• La prueba se puede repetir sin tocar inbox reales.

No hace falta que cada rollback lleve una novela. Hace falta que la validación sea consistente, legible y barata de repetir. Si esa parte está resuelta, el equipo gana confianza real, no solo una sensación de "parece que salió bien".

Preguntas frecuentes

¿Esto aplica solo a Terraform?

No. Aplica a cualquier herramienta que cambie configuración de correo de forma indirecta. Terraform simplemente lo hace muy visible porque concentra muchos cambios de infraestructura en un mismo paso.

¿Debo correr esta prueba en cada rollback?

Si el rollback toca secretos, colas, endpoints o permisos del flujo de notificaciones, sí. Es una comprobación pequeña con bastante valor operativo.

¿Y si el correo llega tarde pero llega?

Lo trataría como una señal amarilla. No es un fail absoluto, pero tampoco un pass limpio. Revisa colas, límites y dependencias de red antes de cerrar el incidente, por que ese retraso luego vuelve cuando menos conviene.