Un rollback de Terraform no deberia ser una frase que aparece cuando ya estamos nerviosos. En una guardia real, "vuelve al commit anterior" casi nunca alcanza: puede haber migraciones, cambios manuales, recursos compartidos o un provider que ya no calcula el mismo diff.
En equipos de plataforma he aprendido a tratar el rollback como un contrato operativo. El objetivo no es prometer que todo vuelve a ser igual, sino dejar claro que accion se puede ejecutar, que evidencia debemos guardar y como sabremos que la recuperacion termino bien. Parece menos heroico, pero ayuda bastante cuando el incidente ocurre a las tres de la mañana.
El rollback no empieza con terraform apply
El primer error suele ser correr terraform plan con prisa y asumir que el plan inverso es automaticamente seguro. Terraform conoce el estado que tiene registrado, pero no conoce toda la historia de las decisiones alrededor del recurso.
Antes de tocar nada, el on-call necesita responder cuatro preguntas:
- ¿Que cambio causo el problema y cual es su identificador de despliegue?
- ¿El rollback modifica solo infraestructura o tambien datos y contratos de aplicacion?
- ¿Que recursos fueron cambiados fuera de Terraform desde el ultimo apply?
- ¿Cual es la señal observable que confirma la recuperacion?
Si una respuesta depende de buscar en cinco canales, el procedimiento no esta listo. Las alertas de drift con contexto son utiles precisamente porque reducen esa reconstruccion manual.
Que debe contener un contrato de rollback
Un runbook pequeño puede incluir estos campos:
- Alcance: workspace, cuenta cloud, modulo y recursos afectados.
- Version conocida: commit, imagen o artefacto que queremos restaurar.
- Precondiciones: backups validos, lock de estado disponible y ausencia de migraciones pendientes.
- Comando de inspeccion: el plan que se debe guardar antes de aplicar.
- Señal de exito: metrica, health check o prueba funcional concreta.
- Punto de parada: condicion que obliga a escalar en vez de seguir probando.
Esta lista no elimina el riesgo. Lo hace visible. Un rollback que necesita borrar un recurso antes de recrearlo debe decirlo con claridad; esconderlo bajo un modulo "simple" es una mala sorpresa para el siguiente turno.
Un flujo seguro para ejecutar la vuelta atras
Un flujo pequeño, repetible y con evidencia se parece a esto:
terraform workspace select prod
terraform plan -out=rollback.tfplan
terraform show -no-color rollback.tfplan > rollback-plan.txt
terraform apply rollback.tfplan
terraform output -json > rollback-output.json
El comando no es la parte importante. Antes de apply, guarda el plan y confirma que el diff corresponde al incidente, no a un drift nuevo. Despues del cambio, registra el identificador del apply y ejecuta una comprobacion que atraviese la ruta critica.
Si el cambio afecta un servicio que envia correos, no uses la entrega de email como unica señal. Un chequeo de API, una metrica de errores y una prueba funcional dan mejor cobertura. Para interfaces de prueba, tambien conviene revisar que los estados de carga y error sean visibles; la validacion de email sin friccion visual recuerda que una señal que existe pero no se puede interpretar no ayuda mucho.
Pruebas de CI que realmente ayudan
El pipeline deberia probar el camino de recuperacion, no solo el camino feliz. Algunas comprobaciones razonables son:
- validar que el plan de rollback no cambia recursos fuera del alcance
- comprobar que el estado remoto puede bloquearse y desbloquearse
- probar un recurso efimero en un workspace aislado
- conservar el plan como artefacto durante la ventana del incidente
- verificar que el smoke test falla si el servicio sigue apuntando a la configuracion rota
En esa ultima prueba es normal necesitar datos de correo. Un generador de cuentas de correo temporal o un correo temporal gratis puede servir para validar el flujo en un entorno aislado, pero no debe convertirse en una identidad de produccion. Tampoco conviene guardar mensajes o tokens reales en los logs. He visto pipelines con fake e mail com escrito como dato de prueba; funciona como marcador, aunque es mejor documentar por que existe y cuando se elimina.
Checklist para el on-call
Antes de ejecutar la vuelta atras, revisaria esta lista:
- el incidente y el cambio tienen un ID comun
- el plan fue generado con el workspace correcto
- el diff no incluye recursos ajenos al incidente
- existe una copia del estado o un backup verificable
- alguien conoce el punto de parada y el canal de escalado
- la señal de exito esta definida antes del apply
- el smoke test cubre la dependencia mas importante
- el resultado queda adjunto al ticket, no solo en el chat
Un detalle que suele olvidarse: despues del rollback hay que explicar que queda pendiente. Si el cambio manual sigue presente o el modulo necesita una correccion, el incidente no termino del todo. La infraestructura puede estar estable y el sistema de delivery aun estar en una situacion incomoda.
Q&A
¿Hay que revertir siempre al commit anterior?
No. El commit anterior puede contener otro problema o no ser compatible con el estado actual. Elige la version que restaure el comportamiento y valida el plan antes de aplicar.
¿Un rollback debe ser automatico?
Solo cuando el alcance, las precondiciones y la señal de exito son muy claros. Para recursos con datos o permisos sensibles, una pausa humana sigue siendo una buena defensa.
¿Como se mide si el runbook funciona?
Mide el tiempo hasta la primera accion segura, el tiempo hasta recuperar la señal critica y cuantos pasos requieren conocimiento tribal. Si el runbook siempre necesita una llamada privada, todavia le falta contexto.
La meta no es que el on-call memorice Terraform. Es que pueda tomar una decision razonable con evidencia suficiente, incluso cuando el incidente llega en el peor momento.
Top comments (1)
The useful test for a rollback is not whether Terraform can apply the inverse, but whether the operator can make the right decision under partial failure. A runbook that names the blast radius, preconditions, observable success signal, and the point where automation must stop is much more valuable than a generic
terraform applyin reverse.