En varios equipos de plataforma, el primer aviso de drift en Terraform no falla por deteccion. Falla por lenguaje. Llega un correo con demasiado diff, poco contexto y cero prioridad operativa. La persona de guardia ve cambios, pero no entiende si debe actuar ahora, abrir ticket o simplemente observar. Ese hueco entre ver y decidir es lo que termina costando mas.
Me ha pasado en cambios pequeños y en cambios delicados: una policy editada fuera del flujo, un security group tocado a mano, una variable cambiada desde consola, o una rotacion hecha deprisa antes de cerrar el dia. Terraform detecta bien el desvio, pero el correo resumen muchas veces llega torcido, muy tecnico para quien solo necesita una respuesta clara y muy vago para quien si tiene que intervenir.
Por que el drift genera correos que nadie sabe leer
El problema no suele ser el plan. El problema es mandar el plan casi crudo y esperar que haga de alerta ejecutiva. En guardia, un diff largo no responde tres preguntas basicas:
- que recurso cambio realmente
- que riesgo introduce ese cambio
- cual es la siguiente accion recomendada
Cuando eso falta, el equipo rellena el resto con suposiciones. A veces alguien piensa "seguro era un cambio esperado", y otras veces se escala algo menor como si fuera incidente. Ninguna de las dos salidas es buena, la verdad.
Tambien ayuda recordar que las alertas por correo compiten con otras notificaciones. Si el mensaje no trae un contexto minimo, termina enterrado. Por eso me gusto leer sobre aprobaciones por email con contexto minimo: la idea central no es solo aprobar mejor, sino darle al lector lo justo para decidir sin abrir cinco pestañas.
Que contexto minimo debe traer una alerta
Para mi, un correo de drift util en Terraform tiene que traer un bloque pequeño pero completo. No mas cosas. Solo las que cambian la decision:
- workspace o stack afectado
- recurso principal con drift
- tipo de cambio detectado
- riesgo esperado si no se corrige
- accion sugerida
- ventana o plazo recomendado
Un ejemplo sencillo seria algo asi:
[drift] cambio manual detectado en prod-network
recurso: aws_security_group.api_edge
tipo: regla de ingreso agregada fuera de Terraform
riesgo: exposicion mayor a la definida por baseline
accion sugerida: revisar diff y reconciliar en menos de 30 min
ticket/runbook: net-sec-12
Con ese formato, la persona on-call ya puede clasificar. No necesita leer un mar de atributos antes de saber si esta frente a seguridad, capacidad o solo higiene operativa.
Un formato pequeno que si ayuda en guardia
Lo que mejor me funcionó fue separar el correo en tres capas:
- resumen en una linea
- impacto operativo en dos o tres frases
- enlace al diff completo o al runbook
Si el resumen dice "drift detectado" pero no nombra entorno ni recurso, el mensaje arranca mal. Si el impacto solo dice "revisar cambios", tambien. Lo util es escribir algo como: "se detecto un cambio manual en una regla de red de prod; no hay corte ahora mismo, pero el baseline de acceso ya no coincide". Eso ya orienta bastante mejor.
Cuando ademas quieres validar asunto, formato o deduplicacion sin ensuciar bandejas reales, un correo temporal gratis puede servir para pruebas internas cortas. No arregla el criterio operativo, obvio, pero si evita que acabes revisando mensajes de ensayo mezclados con notificaciones reales.
Otra cosa que procuro evitar es meter todo el diff dentro del cuerpo. El diff es soporte, no portada. Lo principal del correo debe leerse bien en movil y en menos de 20 segundos. Luego si hace falta, que haya enlace al detalle completo.
Como validar el mensaje antes de confiar en el
Una alerta de drift no se valida solo porque "salio". Se valida cuando otra persona entiende la situacion sin ayuda del autor. Mi prueba favorita sigue siendo bastante simple:
- genero un caso de drift controlado en staging
- envio el correo de prueba a una bandeja aislada
- le pido a alguien del equipo que me diga que haria en los proximos 10 minutos
- comparo su respuesta con la accion que realmente espero
Ese paso expone enseguida si escribiste un correo tecnico pero no accionable. Tambien te deja detectar tonterias comunes: subjects duplicados, enlaces rotos, variables sin renderizar, e incluso textos raros como dummy e mail o temp gamil com que a veces se cuelan desde fixtures o datos de prueba. Parece bobo, pero pasa mas de lo que nos gusta admitir.
Para la parte de pruebas, me resulta util pensar en aislamiento desde el inicio. Esta guia sobre probar emails transaccionales sin mezclar bandejas viene desde FastAPI, pero la idea cruza bien a operaciones: si no aislas el canal de prueba, luego nadie confia en lo que ve.
Checklist para dejar de mandar ruido
Antes de activar correos de drift en produccion, yo repasaria esto:
- el asunto nombra stack, entorno y tipo de drift
- el cuerpo explica riesgo y accion, no solo diff
- el mensaje incluye un plazo claro para revisar
- el enlace al runbook funciona desde movil
- el correo de prueba no comparte bandeja con alertas reales
- el diff completo queda fuera del resumen principal
No hace falta un sistema perfecto. Hace falta uno que ayude a decidir sin friccion de mas. Si la alerta reduce incertidumbre, ya está haciendo su trabajo. Si solo mueve texto de un sistema a otro, pues no.
Preguntas rapidas
¿Debo enviar un correo por cada drift detectado?
No siempre. Si el mismo recurso genera varios eventos seguidos, conviene agrupar o aplicar una ventana corta de consolidacion. Si no, la bandeja se vuelve puro ruido y el equipo deja de mirar.
¿Que drift merece prioridad alta?
Los cambios que afectan seguridad, rutas criticas, politicas de acceso o componentes compartidos. Un tag fuera de sitio importa menos que una regla de red abierta, aunqe ambos salgan del mismo detector.
¿El diff completo deberia ir adjunto?
Yo prefiero enlazarlo. El adjunto envejece rapido y hace pesado el correo. El mensaje principal deberia mantenerse corto, estable y facil de escanear.
Una buena alerta de drift no intenta impresionar con detalle. Intenta que la siguiente decision sea un poco mas rapida y bastante menos confusa. En SRE y DevOps, eso ya es una mejora muy real.
Top comments (0)