Las alertas de drift en Terraform suelen fallar de una forma muy discreta. El detector corre, encuentra diferencia entre el estado y la realidad, manda un correo, y en teoria ya esta. En la practica, muchas veces el mensaje llega sin decir que recurso cambio, que workspace esta afectado o si el desvio aparecio tras un deploy legitimo. He visto equipos perder una hora por eso, facil.
Cuando la alerta no trae contexto, la guardia termina abriendo consola, historial de cambios y logs al mismo tiempo. Eso desgasta bastante, y lo peor es que el problema no esta en Terraform sino en como contamos el incidente. Mi regla suele ser simple: si el correo no ayuda a decidir el siguiente paso en menos de un minuto, el alerta esta medio rota aunque haya salido bien.
Por que tantas alertas de drift se vuelven ruido
Lo comun es implementar el check de drift como una tarea programada y dejar la notificacion para el final. Funciona al principio, pero luego aparecen pequeños defectos que se acumulan:
- asuntos genericos como "drift detected"
- cambios reales sin nombre de workspace o cuenta cloud
- enlaces a dashboards que ya no apuntan al entorno correcto
- correos duplicados por reintentos mal cerrados
- mensajes que dicen que hubo drift pero no separan cambio esperado de cambio peligroso
Ese ultimo punto importa mucho. Un drift despues de una accion manual de emergencia no se interpreta igual que un drift en una politica IAM tocada fuera de pipeline. Si el mensaje no marca esa diferencia, el on-call hace trabajo de detective a las 3 AM, y nadie quiere eso la verdad.
Tambien conviene pensar en la parte humana. En notas internas he visto a gente buscar cosas con palabras raras como temp mailid o tempail porque recuerdan a medias la herramienta o el flujo usado para validar emails. No es elegante, pero asi trabaja la gente cuando va rapido.
El contexto minimo que una alerta debe traer
Para mi, una alerta de drift util deberia responder estas cinco preguntas sin obligarte a abrir otras tres pantallas:
- Que workspace, stack o modulo disparo el hallazgo.
- Que recurso concreto cambio o al menos que tipo de recurso esta afectado.
- En que cuenta, region y entorno aparecio.
- Si el drift viene de una lectura periodica, de una aprobacion manual o de una ejecucion fallida reciente.
- Cual es el primer enlace util: plan, PR, runbook o dashboard.
Ese formato parece muy basico, pero cambia bastante la calidad operativa. En un articulo anterior sobre rotar secretos sin romper alertas comentaba algo parecido: la alerta debe reducir ambiguedad, no solo demostrar que existe un sistema de avisos.
Si tu equipo ya valida correos en otros flujos, como aprobaciones o upgrades, te puede servir esta guia sobre probar upgrades por email sin ruido. Aunque venga de un contexto SaaS, la idea de aislar una corrida y revisar un mensaje con criterios claros encaja muy bien en DevOps tambien.
Una prueba corta antes de confiar en ella
No hace falta montar una suite enorme para estas alertas. Yo prefiero una prueba corta, repetible y con evidencia minima:
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
WORKSPACE="network-prod"
INBOX="tf-drift-$RUN_ID@example.test"
trigger_drift_check \
--workspace "$WORKSPACE" \
--region "ap-southeast-1" \
--expect-resource "aws_security_group_rule" \
--recipient "$INBOX"
wait_for_message "$INBOX" 120
assert_message_count "$INBOX" 1
assert_subject_contains "$INBOX" "$WORKSPACE"
assert_body_contains "$INBOX" "aws_security_group_rule"
assert_body_contains "$INBOX" "$RUN_ID"
Lo importante no es el inbox en si, sino que la corrida quede aislada. Si el equipo usa un generador de correo falso o una bandeja descartable, bien. Si usa otra cosa interna, tambien vale. Lo que no conviene es reutilizar la misma bandeja entre corridas y luego discutir si el correo visto era de hoy o del miercoles pasado.
En esta parte suelo guardar un paquete de evidencia pequeño:
run_id- workspace y region
- recurso esperado
- destinatario usado
- host del enlace principal
- tiempo hasta recepcion
Eso alcanza para separar problemas bastante distinto entre si. Si el mensaje llega una vez pero sin region, la plantilla esta floja. Si llega dos veces con el mismo run_id, probablemente hay reintentos sin cierre. Si trae recurso y region pero enlaza al plan equivocado, el bug esta en el mapeo entre pipeline y notificacion. Parece obvio escrito asi, pero en incidentes reales ayuda un monton tenerlo ordenado.
La checklist que deja menos dudas
Antes de dejar activa una alerta de drift, reviso esto:
- el asunto nombra workspace o stack
- el cuerpo menciona recurso, region y entorno
- el mensaje distingue drift esperado de drift sospechoso, aunque sea con una nota corta
- el enlace principal abre el panel o runbook correcto
- no hay duplicados para la misma corrida
- el correo incluye una accion siguiente razonable
Si quieres agregar una mejora mas, añade un resumen corto del impacto. Algo como "regla de ingreso abierta a 0.0.0.0/0" orienta mucho mejor que "policy changed". No hace milagros, pero ahorra varias preguntas en Slack y un par de vueltas innecesarias.
Preguntas frecuentes
Conviene correr esta prueba en cada PR?
Solo si el cambio toca plantillas, routing de alertas, politicas IAM relacionadas o la logica que arma el contexto. Para cambios normales de modulos, una corrida programada suele ser suficiente.
Hace falta mostrar el diff completo en el correo?
Normalmente no. Prefiero una version corta con el tipo de recurso, el atributo sensible y un enlace al detalle. Un correo larguisimo se vuelve dificil de leer y casi nadie lo procesa bien bajo presion.
Cual es el error mas comun?
Mandar una alerta correcta pero inutil. Es decir: sale a tiempo, tiene buen asunto, pero no dice que hacer despues. Ese hueco parece menor, pero es donde mas se pierde tiempo cuando hay guardia de verdad.
Top comments (0)