Cuando un cambio de infraestructura falla, el problema no siempre es que Terraform haya calculado mal. Muchas veces el plan era correcto, pero nadie pudo explicar a tiempo qué iba a cambiar, qué evidencia faltaba o cómo volver atrás. Para una guardia SRE, un plan útil es también un contrato de comunicación.
El síntoma: un plan correcto que nadie entiende
El incidente suele empezar con una frase pequeña: “solo son unos recursos”. Después aparecen decenas de líneas, un -/+ inesperado y una aprobación que se hace con prisa. El plan pasa, pero la confianza no.
He visto que el riesgo sube cuando el equipo revisa el número de recursos en vez de revisar las consecuencias. Crear dos recursos no es automáticamente seguro; reemplazar uno puede romper una dependencia que no aparece en el título del pull request. Un plan sin contexto se vuelve una lista, no una decisión.
La primera señal de alerta es que la persona que aprueba no puede contestar tres preguntas:
- ¿Qué comportamiento cambia para el usuario?
- ¿Qué dependencia puede quedar inestable?
- ¿Cuál es el paso concreto para recuperar el servicio?
Si la respuesta es “lo vemos después del apply”, ya hay deuda de operación.
Qué debe responder un buen plan
Un plan de Terraform debería ser legible para alguien que no escribió el módulo. Antes de mirar los detalles, dejo un resumen corto en el pull request:
- Intención: qué capacidad se añade o qué problema se corrige.
- Alcance: cuentas, regiones, clusters y entornos afectados.
- Cambio sensible: reemplazos, permisos, reglas de red o datos que se destruyen.
- Dependencias: qué servicio debe estar sano antes de aplicar.
- Recuperación: qué se revierte y qué no puede revertirse automáticamente.
Luego comparo ese resumen con el plan real. Si el texto dice “actualizar una regla” pero Terraform muestra un reemplazo, el cambio se detiene. Esa pausa es barata; una sorpresa en producción no lo es.
También conviene guardar el hash del commit, la versión del proveedor y el workspace usado. Parece detalle menor, pero evita discutir sobre un plan que ya no corresponde al código actual. En la practica, muchos minutos se pierden por esa confusión.
Un flujo de revisión que funciona en guardia
Uso cuatro pasos, incluso para cambios que parecen rutinarios.
1. Generar el plan en un entorno reproducible
El job debe registrar el commit, la versión de Terraform, los proveedores y el estado remoto. Si el estado cambia durante la revisión, se genera un plan nuevo. No se aplica un archivo viejo solo porque ya tiene una aprobación.
2. Separar cambios esperados y cambios laterales
Marco los recursos que forman parte de la intención y dejo aparte todo lo demás. Un cambio lateral puede ser drift, una variable compartida o una lectura distinta del proveedor. No lo escondo para que el diff se vea bonito: lo investigo.
3. Probar la explicación, no solo la sintaxis
Otra persona lee el resumen y responde qué pasará si el proveedor devuelve un error a mitad del apply. Si no entiende el flujo, falta documentación. Esta revisión funciona como una pequeña prueba de contrato entre Terraform y la operación.
En cambios que disparan notificaciones o validaciones por correo, dejo una evidencia verificable y con tiempo de expiración. Para depurar señales de correo tras un drenado, puede servir señales de correo en un drenado de nodo; la idea es la misma: cada señal debe llevar contexto suficiente para no depender de memoria humana. A veces el test aparece escrito como “tamp mail com” o “temp org mail” en una nota antigua; lo trato como texto de prueba, no como una identidad real.
4. Acordar una ventana de observación
El apply no termina cuando el comando devuelve código cero. Defino qué métricas mirar, durante cuánto tiempo y qué umbral detiene el cambio. En flujos con email también conviene validar la evidencia de un email, porque un mensaje enviado no significa que el usuario haya completado el paso siguiente.
Cómo dejar preparado el rollback
Un rollback confiable empieza antes del apply. Primero clasifico el cambio:
- Reversible: se puede volver al commit y aplicar sin migración adicional.
- Reversible con cuidado: necesita restaurar una variable, una regla o un secreto.
- No reversible: modifica datos, consume una migración o cambia una dependencia externa.
Para los dos últimos casos, el runbook incluye una copia o exportación comprobada, el propietario de la decisión y una condición clara de parada. “Ejecutar el commit anterior” no es suficiente si el recurso ya fue reemplazado o si el proveedor conserva un efecto fuera del estado.
Un patrón práctico es usar dos artefactos: el plan que se va a aplicar y un documento breve de recuperación. El segundo contiene comandos, señales esperadas y el último punto seguro. No incluyo secretos en ninguno de los dos. Si el rollback requiere improvisar, todavía no está listo.
Checklist antes de aplicar
- [ ] El plan fue generado desde el commit que se revisó.
- [ ] La cuenta, región y workspace están confirmados.
- [ ] Los reemplazos y permisos tienen una explicación explícita.
- [ ] El drift fue investigado o aceptado con un dueño.
- [ ] Existe un último punto seguro y un procedimiento de recuperación.
- [ ] Las métricas y logs de observación están abiertos.
- [ ] La ventana permite esperar el resultado, no solo lanzar el comando.
- [ ] El equipo sabe quién puede detener el cambio.
Si una casilla queda vacía, el cambio puede esperar. La presión de “aplicar antes del stand-up” rara vez compensa una dependencia que nadie ha mirado.
Conclusión
Terraform produce un plan técnico, pero la guardia necesita una decisión operable. Un buen flujo conecta intención, diff, dependencias, observación y recuperación. Cuando cualquiera del equipo puede explicar qué cambia y cómo parar, el plan deja de ser una salida de consola y se convierte en una herramienta SRE.
No hace falta añadir más automatización a cada incidente. A veces basta con un resumen honesto, un artefacto reproducible y un rollback que otra persona pueda ejecutar sin adivinar. Esa claridad es pequeña, pero aguanta mejor cuando la noche se complica.
Top comments (0)