Corregir drift con Terraform suele sentirse como tarea de higiene: comparas estado, aplicas el cambio y sigues con lo siguiente. En produccion no siempre sale tan limpio. Varias veces he visto un terraform apply resolver el desvio tecnico y, cinco minutos despues, dejar dudas sobre si las alertas, las suscripciones o los checks externos siguen contando la historia correcta. El plan salio bien, pero la confianza del equipo no quedo tan bien.
Para mi, ese es el punto clave: un drift fix no termina cuando el recurso vuelve a coincidir con el codigo. Termina cuando observabilidad, automatizaciones y evidencia operativa siguen intactas. Si cambias una ruta de SNS, una policy, un webhook o una variable que toca notificaciones, el riesgo no es solo "romper infra". El riesgo real es perder señal justo cuando piensas que ya cerraste el tema.
Segun el State of DevOps Report, los equipos con procesos mas estandarizados recuperan servicio con menos friccion y menos retrabajo (https://cloud.google.com/devops/state-of-devops/). En la practica, eso significa validar el cambio y tambien validar el contexto alrededor del cambio. Parece obvio, pero en guardia se olvida bastante facil.
El drift fix que parecia inocente
El caso tipico arranca con algo menor: una suscripcion recreada a mano, un secreto rotado fuera del flujo normal, una policy ajustada por consola. Terraform detecta drift, alguien prepara el plan y todo indica que el apply es seguro. El error aparece despues, cuando una alerta ya no llega, un correo de verificacion usa la ruta vieja o un sistema externo deja de confirmar el evento esperado.
Eso pasa porque el drift casi nunca vive solo. Suele tocar bordes entre infraestructura y producto: colas, topics, webhooks, reglas IAM, dominios, DNS o jobs de apoyo. Cuando esos bordes cambian, yo prefiero buscar una evidencia externa pequeña. A veces basta con una prueba controlada hacia una direccion de correo desechable para confirmar que el evento realmente salio del sistema correcto y no de una ruta vieja que sobrevivio por casualidad.
Tambien conviene mirar el historial reciente del equipo. Si ya tuviste problemas esperando eventos asincronos, ideas como esperar eventos de correo sin bloquear procesos sirven mucho porque fuerzan a pensar en tiempos, retries y puntos de observacion antes de declarar exito.
Que revisar antes de aplicar
Mi preflight para estos cambios es corta y poco elegante, pero funciona:
- ¿Que recurso esta en drift y que dependencias laterales toca?
- ¿Que alertas o automatizaciones dependen de ese recurso?
- ¿Que evidencia externa voy a usar despues del apply?
- ¿Que señal me obliga a pausar aunque Terraform termine sin error?
No hace falta burocracia larga. Hace falta dejar escrito que vas a comprobar. Si el drift toca correo transaccional, login magic links o aprobaciones por email, me gusta anotar una prueba simple con change_id, hora del apply y destino esperado. En algun runbook viejo llegue a ver texto basura tipo tamp mail com mezclado en ejemplos, y eso me recordó algo muy de SRE: si la evidencia es ambigua, la conclusion tambien lo sera.
Otro detalle util es revisar outputs y tags antes de aplicar. Muchos equipos vigilan el recurso principal, pero no los labels o metadatos que consumen otros sistemas. Ahi nacen los falsos verdes: la infraestructura converge, pero la alerta o la auditoria empieza a mirar el sitio equivocado. Es un fallo pequeño, medio tonto, pero caro.
Como valido alertas y evidencia despues del apply
Despues del terraform apply, intento hacer tres validaciones en este orden:
- Confirmar que el recurso converge sin cambios pendientes.
- Verificar una señal interna: logs, metricas o una alerta de prueba.
- Verificar una señal externa que no dependa del mismo camino.
Si el cambio toca un flujo de notificaciones, una opcion rapida es disparar un evento controlado y observarlo de punta a punta. En algunos equipos uso un inbox temporal de temp mail so solo como evidencia complementaria, no como pieza central del sistema. Lo importante no es la herramienta exacta. Lo importante es tener una prueba visible, repetible y facil de explicar a la persona de guardia que llega despues.
Cuando el equipo ya trabaja con procedimientos mas ordenados, ideas como runbooks de correo que si escalan ayudan bastante. No por el correo en si, sino porque fuerzan una disciplina sana: definir entradas, salida esperada y criterio de fallo. Esa estructura baja mucho la discusion rara de "creo que quedo bien".
Este bloque simple suele alcanzarme:
terraform plan -refresh-only
terraform apply
terraform output
Y al lado dejo una nota operativa:
- evento disparado
- hora esperada de entrega
- evidencia interna revisada
- evidencia externa revisada
Suena basico, lo se, pero en cambios de drift la claridad gana. He visto equipos muy buenos perder media hora porque nadie dejó escrito cual era la verificacion final. Cuando eso pasa, todo el mundo reabre dashboards, mira logs viejos y empieza a adivinar. Es justo lo que queriamos evitar.
Un checklist corto para el siguiente cambio
- El plan identifica dependencias laterales, no solo el recurso en drift.
- Hay una prueba externa definida antes del apply.
- Las alertas o suscripciones afectadas tienen dueño claro.
- La evidencia posterior al cambio queda anotada en el runbook.
- Existe una condicion concreta para pausar o revertir.
- La persona on-call puede entender el resultado sin pedir contexto extra.
Preguntas frecuentes
¿Esto aplica solo a cambios grandes?
No. En realidad los cambios pequeños engañan mas. Como parecen seguros, nadie prepara validacion suficiente y el hueco se nota despues.
¿Siempre necesito una prueba externa?
No siempre, pero ayuda mucho cuando el drift toca notificaciones, identidad o integraciones. Si todo se valida desde el mismo plano que acabas de cambiar, te puedes mentir sin querer.
¿Hace falta automatizar cada paso?
Tampoco. Primero haria el checklist manual y estable. Cuando veas el patron repetido, automatizas la mitad util. Intentar automatizar todo desde el dia uno aveces mete mas ruido del que quita.
Top comments (0)