Reemplazar servidores a partir de imágenes en lugar de parchearlos in situ reduce los hallazgos de deriva de configuración

Hipótesis

Infraestructura inmutable significa que una instancia en ejecución nunca se modifica después de lanzarse: un cambio es una imagen nueva, construida con una herramienta como Packer (citado: imágenes de máquina idénticas a partir de una única configuración fuente) o con una compilación de contenedor, seguida del reemplazo de la instancia. La documentación de Terraform sobre apply (citada) recomienda, para los apply automatizados con -auto-approve, asegurarse de que nadie pueda cambiar la infraestructura fuera del flujo de trabajo de Terraform, porque así se minimizan los cambios impredecibles y la deriva de configuración. La hipótesis es que la disciplina de solo reemplazar reduce la deriva no solo en los recursos que gestiona el código de infraestructura, sino también dentro de las instancias, porque las operaciones que provocan deriva (arreglos urgentes por SSH, ejecuciones de configuración parciales, actualizaciones de paquetes que tienen éxito solo en algunos hosts) no tienen dónde aplicarse.

Predicción

En servicios comparables, un terraform plan -refresh-only programado (o el equivalente en otra herramienta) detectará deriva en menos ejecuciones y afectando a menos recursos en las flotas que operan solo con reemplazo que en las que se parchean in situ. Dentro de una flota con parcheo in situ, el número de atributos con deriva se correlacionará con la antigüedad de la instancia; en una flota de solo reemplazo no lo hará, porque ninguna instancia es antigua. Los incidentes cuyo postmortem mencione "este host era distinto" serán menos frecuentes en las flotas de solo reemplazo.

Prueba propuesta

1. Seleccionar servicios de la misma organización que difieran en su forma de operar (solo reemplazo frente a parcheo in situ) pero que usen la misma herramienta de infraestructura como código y la misma nube.
2. Ejecutar un plan de solo refresco a diario, durante al menos un trimestre por servicio, y registrar: ejecuciones con alguna deriva, recursos con deriva, atributos con deriva y antigüedad de cada instancia implicada.
3. En las instancias, añadir una auditoría periódica interna (lista de paquetes, hashes de los archivos de configuración) comparada con el manifiesto de la imagen; contar los archivos que difieren por instancia y la antigüedad de la instancia.
4. Comparar las distribuciones entre ambos estilos; informar de los recuentos por servicio y no solo de los totales, ya que un único servicio con mucho ruido puede dominar el resultado.
5. Registrar los factores de confusión: tamaño del equipo, prácticas de guardia, volumen de cambios y si las flotas con parcheo in situ ejecutan la gestión de configuración de forma programada o solo bajo demanda.

Estado

No se afirma ningún resultado. La operación de solo reemplazo tiene costes que la hipótesis no pondera: mayor plazo de entrega para correcciones pequeñas, pipelines de construcción de imágenes que mantener y un estado que debe residir fuera de la instancia. La deriva detectada por la API de la nube y la deriva dentro del sistema operativo son mediciones distintas y deben informarse por separado.