Consejos para un Plan B en Terraform: Estrategias de contingencia y recuperación ante desastres para IaC

Incluso los pipelines de Infraestructura como Código (IaC) bien diseñados fallan. Ya sea por una corrupción accidental del estado, un límite de peticiones (rate limit) del proveedor durante un incidente, una caída inesperada del pipeline en pleno apply o interrupciones del proveedor en la nube, depender únicamente del flujo ideal ("happy path") es una receta para un tiempo de inactividad catastrófico.

Cuando producción está caída y terraform apply finaliza con errores fatales, necesitas un Plan B accionable. Esta guía detalla consejos prácticos y probados en batalla para contingencias en Terraform, alternativas arquitectónicas y patrones de recuperación para proteger tus sistemas cuando la automatización principal falla.

---

1. Implementar el versionado de objetos en S3/GCS y snapshots automatizados del estado

El archivo de estado de Terraform (terraform.tfstate) es la única fuente de verdad que conecta tu configuración declarada con los recursos activos en la nube. Cuando ocurre una corrupción del estado, tu plan de recuperación predeterminado debe ser instantáneo y no destructivo.

Consejos prácticos:

• Habilitar el versionado de objetos: Asegúrate de que el bucket de tu backend remoto (AWS S3, Google Cloud Storage o Azure Blob) tenga el versionado de objetos habilitado de forma obligatoria.
• Snapshots en un punto temporal (Point-in-Time): Configura un trabajo programado en CI o un hook de ciclo de vida en el bucket para crear copias instantáneas con marca de tiempo antes de ventanas de despliegue de alto impacto.
• Aislar las tablas de bloqueo: Al utilizar AWS DynamoDB para el bloqueo de estado, configura la recuperación en un punto en el tiempo (PITR) automatizada para la tabla de bloqueo con el fin de sobrevivir al agotamiento o la corrupción de la tabla.

# Backend AWS S3 con versionado obligatorio y cifrado
resource "aws_s3_bucket" "terraform_state" {
  bucket        = "company-production-tfstate"
  force_destroy = false

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket_versioning" "state_versioning" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

---

2. Reducir el radio de impacto con arquitecturas de micro-estados

Los estados monolíticos son la causa principal de fallos irrecuperables en la infraestructura. Si tus redes, bases de datos, accesos de identidad y clústeres de contenedores residen en un único archivo de estado, un solo conflicto de bloqueo o la eliminación fallida de un recurso pueden paralizar toda tu cadena de entrega.

Estrategia del Plan B:

• Particionar por ciclo de vida y volatilidad: Segrega los recursos que cambian constantemente (por ejemplo, configuraciones de autoescalado, definiciones de tareas de ECS) de la infraestructura que rara vez cambia (por ejemplo, VPCs, subredes, tablas de enrutamiento, políticas de confianza de IAM).
• Referenciar salidas entre estados de forma segura: Utiliza fuentes de datos terraform_remote_state o referencias a almacenes de parámetros (AWS SSM, HashiCorp Vault) en lugar de acoplar los estados directamente entre sí.

# Leer atributos de red base sin compartir bloqueos de escritura
data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "company-production-tfstate"
    key    = "network/vpc/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_security_group" "app_sg" {
  name        = "application-sg"
  vpc_id      = data.terraform_remote_state.vpc.outputs.vpc_id
  description = "Allows ingress from VPC tier"
}

---

3. Preparar el playbook de emergencia ("Break-Glass") para resolver bloqueos de estado

Durante incidentes de alta gravedad, un ejecutor (runner) de CI/CD que falla suele dejar un archivo de bloqueo activo en la base de datos del backend. Los ingenieros que ejecutan comandos estándar se encuentran con:

Error: Error acquiring the state lock: ConditionalCheckFailedException
Lock Info:
  ID:        1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
  Path:      production-tfstate/terraform.tfstate
  Who:       runner@ci-agent-04
  Created:   2025-02-18 10:14:02 UTC

Si no dispones de un protocolo aprobado, los equipos pierden un tiempo de recuperación crucial debatiendo si deben forzar el desbloqueo.

Protocolo de contingencia:

1. Verificar el estado del proceso: Inspecciona tu agente de CI/CD o servidor de orquestación para comprobar que el proceso asociado con el Lock ID está realmente inactivo y no ejecutando una tarea lenta de aprovisionamiento.
2. Ejecutar un desbloqueo forzado específico: Evita eliminar registros de la base de datos manualmente. Ejecuta terraform force-unlock con el Lock ID específico:

   terraform force-unlock -force 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
   

3. Descargar y validar el estado de inmediato:

   terraform state pull > state-backup-$(date +%s).json
   terraform refresh
   

---

4. Diseñar reemplazos de recursos Blue/Green (El Plan B de Rollback)

Por defecto, Terraform intentará una modificación in situ o realizará un ciclo de Destruir y luego Crear (Destroy-then-Create) para recursos inmutables. Si el recurso de reemplazo experimenta un límite de cuota excedido, un rechazo de permisos o un error de sintaxis a mitad de la creación, tu recurso en funcionamiento previo ya habrá sido destruido.

La solución: create_before_destroy

Integra la gestión del ciclo de vida para garantizar que las instancias secundarias o de reemplazo superen la inicialización antes de que se desmantelen las instancias en funcionamiento.

resource "aws_launch_template" "core_service" {
  name_prefix   = "core-service-"
  image_id      = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true
  }
}

Para transiciones en producción sin tiempo de inactividad, despliega configuraciones espejo secundarias usando flags de workspace o identificadores modulares distintos. Si el despliegue a la v2 falla en las comprobaciones de estado (health checks), el pipeline de CI/CD simplemente redirige los destinos de tráfico nuevamente a la v1 sin tener que ejecutar un apply inverso apresurado e impredecible.

---

5. Dominar los comandos específicos de refactorización: moved y state rm

Cambiar el nombre de los módulos o refactorizar la estructura de directorios sin una estrategia de contingencia puede hacer que Terraform programe la destrucción de cada recurso renombrado durante la siguiente ejecución.

El problema tradicional:

Anteriormente, renombrar requería invocaciones manuales y propensas a errores de terraform state mv ejecutadas en múltiples máquinas.

La defensa del Plan B: Bloques declarativos moved

Incluye siempre bloques declarativos moved en tu código base antes de refactorizar los identificadores de recursos. Esto garantiza que tanto los runners de CI/CD como las terminales locales de los desarrolladores ejecuten migraciones de estado idénticas sin problemas y sin recrear los recursos.

# Renombrar un módulo de forma segura sin destruir las bases de datos en ejecución
moved {
  from = module.legacy_database.aws_db_instance.main
  to   = module.primary_storage.aws_db_instance.postgres
}

Desacoplamiento de emergencia con state rm:

Cuando un recurso deba ser retirado de la gestión automatizada durante una interrupción sin provocar su eliminación real en el proveedor de nube, elimínalo del seguimiento de estado:

terraform state rm module.network.aws_route_table.critical_route

Esto aísla el recurso, permitiendo modificaciones manuales para resolver incidentes sin interferencias de las ejecuciones automatizadas.

---

6. Mantener la detección automatizada de desviaciones (Drift) y validación de planes offline

Cuando ocurre una emergencia inesperada, los equipos a menudo realizan acciones manuales dentro de las consolas de los proveedores de la nube. Esto introduce desviaciones en el estado (drift), lo que genera el riesgo de que las ejecuciones posteriores de Terraform reviertan hotfixes necesarios o fallen por completo.

Buenas prácticas:

• Pipelines nocturnos de detección de drift: Programa ejecuciones automatizadas en CI que ejecuten terraform plan -detailed-exitcode. Un código de salida 2 señala una desviación, activando alertas antes de que los ingenieros envíen cambios conflictivos.
• Planes especulativos en Pull Requests: Nunca fusiones pull requests sin probar los planes contra el estado real.
• Caché local de proveedores: Evita que caídas en las APIs de origen bloqueen las aplicaciones de contingencia configurando una caché compartida de plugins de proveedores en ~/.terraformrc:

plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"
disable_checkpoint = true

---

Referencia rápida: Lista de verificación de contingencia para Terraform

---

Resumen

Contar con un "Plan B" eficaz en Terraform consiste en sustituir el pánico por procedimientos definidos y auditables. Al implementar el versionado de estado, dividir raíces monolíticas en subestados delimitados, aprovechar las refactorizaciones declarativas con moved y preparar runbooks de emergencia para desbloquear estados, garantizas que los incidentes de infraestructura se puedan mitigar en cuestión de minutos en lugar de horas.