Escenario: necesitas un SO más reciente, un kernel nuevo, un hipervisor actualizado o simplemente una línea base de seguridad que deje de poner nerviosos a los auditores. Además necesitas que el equipo siga sirviendo tráfico, que sus datos se mantengan y que la semana no se convierta en una hoja de cálculo de vergüenza.
La pregunta suena simple—¿actualizar in situ o hacer una instalación limpia?—pero la respuesta se trata sobre todo de cómo falló tu sistema la última vez, no de lo que diga la página de marketing del proveedor.
El verdadero equilibrio: tiempo en el calendario vs tiempo en el canal de incidentes
“Más rápido” no es tiempo de CPU. Es tiempo en el calendario: cuánto falta hasta que el sistema vuelva a estar en servicio de forma segura y predecible. “Menos propenso a errores” no significa menos bugs upstream; significa menos sorpresas causadas por tu propio entorno: configuraciones antiguas, deriva, paquetes huérfanos, controladores obsoletos y esa regla de udev que alguien escribió en 2019 y dejó fosilizar.
Las actualizaciones y las instalaciones limpias fallan de formas distintas:
- Actualizaciones preservan el estado. Eso es tanto el objetivo como la trampa. Suelen fallar por bordes de compatibilidad: cambios en el formato de configuración, conflictos de dependencias, incompatibilidades ABI, módulos de kernel de terceros, o “arranca pero la mitad de servicios está silenciosamente roto”.
- Instalaciones limpias reinician el estado. Suelen fallar por estado faltante: configuración olvidada, certificados ausentes, permisos incorrectos, montajes que faltan, o “funciona, pero no es tu sistema”.
Como SRE, lo diré sin rodeos: si no puedes describir tu sistema como código (o al menos como un runbook repetible), las actualizaciones in situ son básicamente arqueología. Si puedes describirlo, las instalaciones limpias se vuelven aburridas, y eso es el mayor cumplido en operaciones.
Una cita, porque sigue siendo el modelo mental correcto: La esperanza no es una estrategia.
(idea parafraseada, a menudo atribuida a liderazgo de ingeniería en círculos de operaciones)
¿Cuál es realmente más rápido (y cuándo)?
Cuando las actualizaciones son más rápidas
Las actualizaciones suelen ser más rápidas cuando:
- La máquina es con estado y no puedes mover los datos fácilmente (datasets locales grandes, almacenamiento conectado directamente sin replicación, controladores de hardware especiales).
- Estás siguiendo un camino menor-a-menor o LTS-a-siguiente-LTS que el proveedor realmente soporta. Las rutas de actualización soportadas son carreteras pavimentadas; las no soportadas son trochas en el bosque.
- Tu superficie de configuración es enorme y está mal documentada. Actualizar mantiene tu desorden intacto, lo cual a veces es la opción menos mala bajo una fecha límite.
- Las ventanas de mantenimiento son cortas y puedes aceptar un rollback a snapshot/imagen en lugar de reprovisionar.
Pero la parte “rápida” es engañosa. Una actualización in situ es rápida hasta que deja de serlo, y entonces estás depurando en el peor entorno posible: un sistema medio cambiado donde los logs y los servicios discrepan sobre en qué siglo estamos.
Cuando las instalaciones limpias son más rápidas
Las instalaciones limpias suelen ser más rápidas cuando:
- El servicio es sin estado o puede hacerse efectivamente sin estado (datos externalizados a BD gestionada, almacenamiento replicado, objeto, o un volumen separado).
- Tienes automatización (PXE/Kickstart/Preseed, cloud-init, Terraform + gestión de configuración, imágenes golden).
- Estás saltando entre versiones mayores donde las configuraciones y los valores por defecto cambiaron de forma material.
- Has acumulado deriva—y tienes razones para creer que la tienes, lo cual es la mayoría de entornos con más de un año.
La velocidad de la instalación limpia viene de la paralelización: puedes construir un nodo nuevo mientras el antiguo aún sirve tráfico, validarlo y luego cambiar. Las actualizaciones suelen ser seriales: debes tocar el nodo en vivo (o su clon) y esperar.
Mi regla opinada
Si puedes construir un nodo nuevo y hacer el corte sin tocar el plano de datos de formas arriesgadas, la instalación limpia gana en velocidad y en errores en la mayoría de entornos de producción reales. Si el nodo es un copo de nieve con datos “pet” en discos locales y restricciones desconocidas, una actualización cuidadosamente escalonada suele ser más segura que pretender que puedes reconstruirlo de memoria.
Broma #1: Una actualización in situ es como cambiar una llanta mientras el coche está en movimiento—a veces funciona, y aprendes mucho sobre física.
¿Cuál es menos propensa a errores (y por qué “erróneo” suele ser “estado desconocido”)?
Los “bugs” tras un cambio suelen ser uno de estos:
- Colisiones por deriva de configuración: tus overrides antiguos chocan con los nuevos valores por defecto. El sistema “funciona” pero no de la forma que crees.
- Grafo de dependencias fuera de control: paquetes antiguos fijan versiones, repos de terceros inyectan sorpresas o un cambio ABI rompe un binario.
- Incompatibilidad controlador/kernel: GPU, NIC offload, HBA de almacenamiento o módulos DKMS no se construyen tras un salto de kernel.
- Transiciones de formato de estado: actualización de formato en disco de bases de datos, flags de características del sistema de ficheros, cambios en el bootloader.
- Huecos de observabilidad: no sabes qué cambió porque no capturaste el estado previo, así que no puedes probar causalidad.
Actualizaciones: menos trabajo inicial, más riesgo en las costuras
Una actualización preserva tu baseline conocido-bueno—más tu basura desconocida-mal. Si tu sistema está limpio y bien gestionado, las actualizaciones están bien. Si es un servidor de larga vida con ediciones manuales, agentes de proveedor y “workarounds” temporales, las actualizaciones amplifican la incertidumbre. El sistema arranca, pero arranca en una vitrina de museo.
Instalaciones limpias: más trabajo al principio, menos entropía
Una instalación limpia te obliga a redeclarar la intención: paquetes, configuración, servicios, montajes, usuarios, secretos, parámetros de kernel, tuning. Eso es molesto exactamente una vez. Después es una receta repetible. La mayor parte de la “reducción de bugs” tras una instalación limpia es simplemente eliminar estado antiguo que ni recuerdas haber añadido.
Broma #2: Una instalación limpia es genial porque borra todos tus problemas—hasta que borra la configuración que realmente necesitabas.
Datos interesantes y contexto histórico (la versión corta y útil)
- Las actualizaciones in situ se hicieron comunes en flotas solo después de que la gestión de paquetes fiable y las ideas de actualizaciones transaccionales maduraran; las primeras tiendas Unix solían reconstruir desde medios porque las actualizaciones eran una ruleta.
- Las herramientas de “repair install” y actualizaciones in situ de Windows se diseñaron para preservar el estado del usuario, porque el mundo de escritorio trata la pérdida de datos como pecado cardinal y la fricción de reinstalar como coste de soporte.
- Las distros Linux históricamente preferían instalaciones limpias para grandes saltos porque los sistemas init, el layout de ficheros y los daemons por defecto cambiaban; el concepto de “ruta de actualización soportada” se fue endureciendo con el tiempo.
- ZFS y sistemas de ficheros modernos introdujeron flags de características que pueden activarse tras la actualización; una vez activadas, volver atrás a versiones antiguas es más difícil o imposible sin planificación cuidadosa.
- UEFI reemplazó supuestos de arranque BIOS heredados; las actualizaciones que tocan bootloaders pueden fallar de nuevas formas (entradas EFI incorrectas, ESP no montada) que las instalaciones limpias tienden a manejar de forma más consistente.
- La gestión de configuración (CFEngine, Puppet, Chef, Ansible) movió la industria hacia reconstruir y reemplazar porque redujo la dependencia del “conocimiento tribal”.
- Enfoques de imagen inmutable (imágenes golden, AMIs, imágenes de contenedor) hicieron que la “instalación limpia” fuese efectivamente la opción por defecto en organizaciones cloud-native, porque instanciar algo nuevo es más barato que depurar lo viejo.
- El ecosistema de módulos de kernel (DKMS, drivers de proveedores) se expandió; las actualizaciones son más frágiles si dependes de módulos fuera del árbol, especialmente para almacenamiento y redes.
- El auge de systemd cambió la gestión de servicios y expectativas de logging; las actualizaciones a través de ese límite fueron famosas por “arranca, pero no como antes”.
Tres micro-historias corporativas (porque la teoría miente)
Micro-historia 1: El incidente causado por una suposición equivocada
Tenían un pequeño clúster de servidores de aplicación que “no almacenaban nada importante localmente”. Esa línea apareció en un documento de planificación y vivió allí durante años, ganando autoridad como un fósil que se vuelve placa de museo.
Durante un trimestre ajetreado, eligieron instalaciones limpias por velocidad. Nuevas imágenes, kernels nuevos, todo nuevo. El plan de cutover era simple: drenar tráfico, terminar el nodo viejo, levantar el nodo nuevo, repetir. Iba bien—hasta que el primer nodo volvió y empezó a servir 500s para un pequeño porcentaje de las peticiones.
La suposición equivocada: el disco local sí contenía estado importante. No datos de clientes, pero sí una caché de plantillas precomputadas más un conjunto de certificados cliente TLS por nodo usados para autenticación mutua hacia un downstream legado. Esos certificados se habían emitido años atrás, copiado manualmente y nunca rotados porque “lo arreglaremos luego”. Los nodos nuevos no los tenían.
El outage no fue dramático. Fue peor: intermitente. Solo las peticiones que tomaban ciertas rutas golpeaban la dependencia downstream rota, y solo algunos de los nodos nuevos estaban afectados mientras el despliegue continuaba.
Solución: pausaron el rollout, extrajeron el estado faltante de un nodo viejo, lo instalaron en los nodos nuevos y luego—esto es lo importante—movieron esos certificados a un mecanismo de distribución de secretos apropiado para que la próxima reconstrucción no dependiera de arqueología.
Micro-historia 2: La optimización que salió mal
Otra compañía quería “actualizaciones sin downtime” en réplicas de base de datos. Construyeron una tubería ingeniosa: snapshot de la VM, hacer una actualización in situ del SO sobre el snapshot, arrancarlo en aislamiento y luego intercambiarlo. ¿Listo?
En su mayoría. La optimización fue saltarse validaciones profundas de almacenamiento porque “ralentizan la tubería”. No ejecutaron scrubs de filesystem ni comprobaron SMART; asumieron que el snapshot era un punto seguro.
Tras unos ciclos, se toparon con un modo de fallo desagradable: la réplica actualizada funcionaba bien durante horas y luego hacía panic bajo carga I/O. No era el SO. El almacenamiento subyacente tenía un SSD marginal que corregía errores y que se volvió incorregible bajo escrituras sostenidas, y el programador de I/O del kernel nuevo expuso la debilidad antes.
La tubería se llevó la culpa, luego el SO, y finalmente el equipo de almacenamiento recibió pings a las 3 a.m. La causa raíz fue poco glamorosa: habían optimizado fuera las comprobaciones aburridas que habrían mostrado el dispositivo degradándose.
Solución: reintrodujeron puertas de salud pre-upgrade (SMART, mdadm, ZFS pool status, antigüedad del scrub) y la “tubería rápida” volvió a ser rápida porque dejó de producir artefactos rotos.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Una organización SaaS corría una flota mixta: algunos nodos eran mascotas viejas, otros eran cattle nuevos. Necesitaban un salto mayor de SO más un upgrade de kernel por cumplimiento de seguridad. Todos esperaban dolor.
Pero un equipo tenía una costumbre anodina: antes de cualquier cambio, capturaban un artefacto “contrato del sistema”—lista de paquetes, servicios habilitados, puertos en escucha, tabla de montajes, deltas de sysctl y un pequeño conjunto de pruebas de humo funcionales. Lo almacenaban junto con la solicitud de cambio. Nada sofisticado, solo consistente.
Eligieron instalación limpia para la mayoría de nodos. Durante la validación notaron una discrepancia: los nodos nuevos no montaban un volumen secundario que contenía logs de auditoría. El servicio funcionaba, pero el cumplimiento no. Porque tenían el artefacto contrato, detectaron el montaje faltante en minutos, no después de que un auditor formulase una pregunta punzante.
Arreglaron el provisioning para montar y etiquetar correctamente el volumen, volvieron a ejecutar la construcción y siguieron adelante. Sin heroísmos. Sin conjeturas a medianoche. Solo evidencia.
Playbook de diagnóstico rápido: encuentra el cuello de botella antes de cambiar de plan
Si ya estás a mitad de una actualización (o reconstrucción) y va mal, no te desgastes. Diagnostica en una secuencia que estreche rápido el problema.
Primero: ¿es capa de arranque/SO, configuración de servicio o camino de datos?
- Capa de arranque/SO: kernel, initramfs, bootloader, drivers. Síntomas: no arranca, cae a initramfs, no encuentra root filesystem, kernel panic.
- Capa de servicios: unidades systemd, configs, permisos, secretos. Síntomas: arranca bien, pero los servicios no inician, errores de bind, fallos de auth.
- Camino de datos: montajes de almacenamiento, integridad de sistema de ficheros, rutas de red, DNS, balanceador. Síntomas: los servicios arrancan pero hacen timeout, alta latencia, errores intermitentes.
Segundo: clasifica la falla como determinista o heisenbug
- Determinista: falla siempre, misma línea de log. Normalmente configuración, dependencia faltante, ruta de fichero incorrecta, módulo incompatible.
- Heisenbug: intermitente, relacionado con carga. Normalmente límites de recursos, cambios en comportamiento del kernel/driver, problemas latentes de hardware, condiciones de carrera expuestas por diferencias de temporización.
Tercero: decide si hacer rollback, pausar o continuar
- Rollback si: no puedes explicar el modo de fallo en una hora, o la solución es “probar paquetes al azar.”
- Pausar y clonar si: necesitas tiempo forense. Haz snapshot/clone del disco/VM, depura offline y mantiene producción estable.
- Continuar si: el error está bien acotado, puedes validar con tests y puedes revertir.
Tareas prácticas: comandos, salida y la decisión que tomas
Estos son los chequeos que realmente ejecuto. No porque me guste teclear, sino porque adivinar es caro.
Tarea 1: Confirma qué estás ejecutando realmente (kernel + SO)
cr0x@server:~$ uname -r
6.5.0-21-generic
cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
VERSION_ID="22.04"
Qué significa: No estás depurando “Linux.” Estás depurando este kernel y esta versión de la distro.
Decisión: Si el objetivo de la actualización salta versiones mayores, asume que la configuración y los valores por defecto cambiaron. Favorece instalación limpia a menos que tengas un runbook de actualización probado.
Tarea 2: Ve qué cambió recientemente (paquetes)
cr0x@server:~$ grep " install \| upgrade " /var/log/dpkg.log | tail -n 5
2026-02-03 10:14:22 upgrade openssl:amd64 3.0.2-0ubuntu1.15 3.0.2-0ubuntu1.16
2026-02-03 10:14:28 upgrade systemd:amd64 249.11-0ubuntu3.12 249.11-0ubuntu3.13
2026-02-03 10:14:31 upgrade linux-image-6.5.0-21-generic:amd64 6.5.0-21.21~22.04.1 6.5.0-21.21~22.04.2
Qué significa: Una regresión que empezó “después de la actualización” suele correlacionar con una lista corta. Esta es tu lista de sospechosos.
Decisión: Si cambió un componente central (kernel/systemd/openssl), valida servicios y drivers explícitamente. No asumas “está bien”.
Tarea 3: Comprueba servicios fallidos rápidamente
cr0x@server:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● nginx.service loaded failed failed A high performance web server and a reverse proxy server
● myapp.service loaded failed failed MyApp API Service
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB = The low-level unit activation state.
Qué significa: Si systemd dice que falló, deja de debatir arquitectura. Lee los logs.
Decisión: Si múltiples servicios no relacionados fallan tras la actualización, sospecha montajes faltantes, permisos o rotura de librerías; considera rollback o pasar a instalación limpia con captura controlada de configuración.
Tarea 4: Extrae logs de servicio con límites útiles
cr0x@server:~$ journalctl -u nginx.service -b --no-pager | tail -n 12
Feb 03 10:16:02 server nginx[1123]: nginx: [emerg] cannot load certificate "/etc/nginx/tls/api.pem": BIO_new_file() failed
Feb 03 10:16:02 server systemd[1]: nginx.service: Failed with result 'exit-code'.
Feb 03 10:16:02 server systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Qué significa: El SO está bien; el estado requerido por la app (cert) falta o los permisos cambiaron.
Decisión: Modo de fallo típico de instalación limpia: secretos/config faltantes. Arregla el provisioning/distribución de secretos, no copies a mano “solo esta vez”.
Tarea 5: Valida montajes y fstab
cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | head
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda2 ext4 rw,relatime
/boot /dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022
/data /dev/sdb1 ext4 rw,relatime
Qué significa: El volumen de datos está montado donde los servicios lo esperan.
Decisión: Si faltan montajes esperados, para. Arregla almacenamiento/montajes antes de diagnosticar errores de aplicación.
Tarea 6: Confirma salud de filesystem y dispositivo de bloque (SMART)
cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.5.0-21-generic] (local build)
SMART overall-health self-assessment test result: PASSED
Qué significa: “PASSED” no es garantía, pero “FAILED” es fuego.
Decisión: Si SMART falla o muestra errores de medio, no sigas con upgrade/rebuild hasta que el hardware esté abordado. De lo contrario atribuirás corrupción de datos al cambio de SO.
Tarea 7: Si usas mdadm RAID, asegúrate de que los arrays estén limpios
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[0] sdb3[1]
976630336 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Qué significa: [UU] significa que ambos miembros están arriba. Cualquier otra cosa implica degradado.
Decisión: Si está degradado, evita grandes cambios. Repara el array primero o convertirás “actualización” en “restaurar desde backup”.
Tarea 8: Si usas ZFS, comprueba estado del pool y flags de características
cr0x@server:~$ sudo zpool status
pool: tank
state: ONLINE
scan: scrub repaired 0B in 00:12:11 with 0 errors on Sun Feb 2 01:10:33 2026
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
errors: No known data errors
Qué significa: Scrub reciente, sin errores. Buen baseline.
Decisión: Si el scrub es antiguo o existen errores, scrubea y remedia antes de cualquier trabajo de SO. Los problemas de almacenamiento se harán pasar por regresiones de actualización.
Tarea 9: Compara deltas de sysctl (atrapa sorpresas de rendimiento)
cr0x@server:~$ sysctl -a 2>/dev/null | grep -E 'net.core.somaxconn|vm.swappiness'
net.core.somaxconn = 4096
vm.swappiness = 10
Qué significa: Estos valores afectan colas y comportamiento de memoria. Las actualizaciones pueden resetear tunings personalizados.
Decisión: Si los valores volvieron a defaults (o difieren de tu baseline), reaplica tuning vía gestión de configuración, no ediciones ad-hoc.
Tarea 10: Detecta un conflicto de dependencias antes de que te queme
cr0x@server:~$ sudo apt-get -s dist-upgrade | tail -n 12
The following packages will be REMOVED:
vendor-agent dkms-nvidia
The following packages will be upgraded:
libc6 openssl systemd
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Qué significa: La simulación muestra eliminaciones. Eliminar módulos de kernel o agentes de proveedor puede romper red/almacenamiento o cumplimiento.
Decisión: Si la actualización quiere eliminar módulos/agent críticos, para y planifica: fija versiones, actualiza el repo del proveedor o elige instalación limpia con drivers soportados embebidos en la imagen.
Tarea 11: Comprueba lo básico del bootloader/EFI (trampa común en upgrades)
cr0x@server:~$ mount | grep -E ' /boot | /boot/efi '
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077)
Qué significa: La partición del sistema EFI está montada. Las actualizaciones de bootloader pueden escribir en ella.
Decisión: Si /boot/efi no está montada durante una actualización que actualiza grub/systemd-boot, arriesgas que el sistema actualice bien y luego no arranque. móntala y vuelve a ejecutar los pasos del bootloader.
Tarea 12: Valida identidad de red y rutas (clásico post-reinstalación)
cr0x@server:~$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens160 UP 10.20.30.41/24
cr0x@server:~$ ip route
default via 10.20.30.1 dev ens160
10.20.30.0/24 dev ens160 proto kernel scope link src 10.20.30.41
Qué significa: Nombres de interfaz y ruteo coinciden con lo esperado. Las instalaciones limpias a veces renombran NICs o pierden configuración VLAN.
Decisión: Si la IP/subred/ruta por defecto difiere del baseline, arregla la configuración de red antes de culpar cambios en la aplicación.
Tarea 13: Confirma DNS y comportamiento del resolvedor (porque todo es “la red”)
cr0x@server:~$ resolvectl status | sed -n '1,20p'
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
DNS Servers: 10.20.0.53 10.20.0.54
Qué significa: Estás usando systemd-resolved en modo stub, con los servidores DNS esperados.
Decisión: Si cambió el modo del resolvedor (común tras actualizaciones), ajusta tu imagen base y monitorización. Las regresiones DNS parecen timeouts de aplicación.
Tarea 14: Compara puertos y listeners abiertos (contrato funcional)
cr0x@server:~$ sudo ss -lntp | head -n 10
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1201,fd=6))
LISTEN 0 4096 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=1302,fd=5))
Qué significa: Los servicios escuchan donde esperas. Después del cambio, “está arriba” debería significar “acepta conexiones”.
Decisión: Si faltan listeners o están ligados a localhost inesperadamente, arregla configs de servicio, firewalls o overrides de systemd.
Tarea 15: Detecta deriva de permisos/propiedad en directorios de estado
cr0x@server:~$ sudo namei -l /var/lib/myapp
f: /var/lib/myapp
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwx------ root root myapp
Qué significa: El directorio es propiedad de root con 0700. Si el servicio corre como myapp, no puede escribir aquí.
Decisión: Arregla propiedad/permisos en el provisioning (systemd tmpfiles, package postinst o gestión de configuración). No hagas chmod al azar bajo presión.
Tarea 16: Sanidad de rendimiento: ¿es CPU, memoria o I/O?
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 521124 80340 942112 0 0 15 38 210 480 3 1 95 1 0
2 0 0 498300 80344 951020 0 0 12 2100 320 620 5 2 70 23 0
Qué significa: Un wa alto (I/O wait) sugiere cuello de botella de almacenamiento. Kernels y drivers nuevos pueden cambiar comportamiento de I/O.
Decisión: Si I/O wait sube, inspecciona latencia de disco y ajustes del scheduler antes de culpar a la aplicación.
Errores comunes: síntomas → causa raíz → solución
1) “Actualización completada, pero los servicios no arrancan”
Síntomas: systemctl muestra fallos; los logs mencionan ficheros faltantes, directivas desconocidas o permiso denegado.
Causa raíz: cambios en el formato de configuración, módulos eliminados o directorios de estado con propiedad incorrecta tras cambios de paquetes.
Solución: Haz diff de la configuración contra los defaults del proveedor; ejecuta herramientas de validación de configuración (p. ej., nginx -t); aplica propiedad de directorios vía provisioning. Si más de dos servicios críticos fallan, considera rollback y rebuild con configuración controlada.
2) “La instalación limpia funciona, pero hay fallos intermitentes de autenticación”
Síntomas: algunas peticiones fallan mTLS, tokens API inválidos, upstream rechaza solo ciertos nodos.
Causa raíz: secretos no distribuidos correctamente, certificados/keys cliente faltantes, sincronización horaria errónea o mismatch de identidad de host.
Solución: valida inyección de secretos y sincronización horaria; asegúrate de que hostnames y SANs de certificados coincidan; evita copias manuales y usa un mecanismo de distribución único.
3) “Tras la actualización, rendimiento de disco empeoró”
Síntomas: mayor latencia, aumento de I/O wait, paradas de base de datos, fsync más lento.
Causa raíz: cambios en el scheduler de I/O del kernel, diferencias de drivers, cambios en política de write cache o un problema de hardware latente expuesto por patrones nuevos.
Solución: compara scheduler y settings de cola; revisa SMART/ZFS/mdadm; ejecuta benchmarks dirigidos con la misma carga; si el hardware está marginal, reemplázalo antes de tunear.
4) “El sistema no arranca tras la actualización”
Síntomas: cae a initramfs, no encuentra root, grub rescue, entrada EFI faltante.
Causa raíz: initramfs sin drivers de almacenamiento, /boot o ESP no montados durante la actualización del bootloader, cambios de UUID o fstab incorrecto.
Solución: asegura que /boot y /boot/efi se monten durante la actualización; regenera initramfs; verifica UUIDs; mantén una entrada de kernel conocida-buena; prueba reinicios en ventana de mantenimiento, no a las 14:00.
5) “La actualización eliminó un driver/agent de proveedor”
Síntomas: módulo DKMS falla, offload de NIC desaparece, rutas de almacenamiento cambian, agente de cumplimiento ausente.
Causa raíz: repo de terceros no soportado, conflictos de paquetes, salto ABI del kernel que rompe la compilación del módulo.
Solución: alinea el repo del proveedor con el SO objetivo; fija paquetes; o elige instalación limpia con la versión del driver soportada embebida en la imagen.
6) “La instalación limpia tardó más que la actualización… porque olvidamos la mitad del sistema”
Síntomas: retrasos repetidos en el cutover, cron jobs faltantes, rotación de logs ausente, sysctl perdidos, ulimits incorrectos.
Causa raíz: no capturaron un baseline; la configuración existía como conocimiento tribal y ediciones sin seguimiento.
Solución: crea un contrato del sistema: lista de paquetes, servicios, montajes, puertos, sysctl, cron, usuarios/grupos, reglas de firewall, certificados. Úsalo como criterio de aceptación.
Listas de verificación / plan paso a paso
Lista de decisión: ¿actualizar o instalación limpia?
- Localidad de datos: ¿Hay datos críticos en disco local sin replicación o snapshots fiables? Si sí, inclínate por actualización (o planifica una migración de datos cuidadosa primero).
- Madurez de automatización: ¿Puedes provisionar un nodo nuevo a “ready” en menos de una hora con mínimos pasos manuales? Si sí, inclínate por instalación limpia.
- Soporte de la ruta de actualización: ¿Tu salto está soportado por herramientas del proveedor/distro? Si no, inclínate por instalación limpia.
- Módulos kernel de terceros: ¿Dependes de DKMS/módulos fuera del árbol (almacenamiento/NIC/GPU)? Si sí, prueba agresivamente; la instalación limpia con drivers validados suele ganar.
- Capacidad de rollback: ¿Puedes snapshot/rollback rápido? Si sí, el riesgo de actualizar baja. Si no, prefiere rebuild y cutover.
- Deriva de configuración: ¿Sospechas años de ediciones manuales? Si sí, la instalación limpia paga deuda técnica—siempre que puedas reconstruir el estado requerido.
Paso a paso: actualización in situ más segura (mentalidad de producción)
- Captura baseline: SO/kernel, lista de paquetes, montajes, listeners, estado de servicios, deltas de sysctl.
- Puertas de salud: salud de almacenamiento (SMART/ZFS/mdadm), espacio libre en filesystem, presión de memoria, logs de errores.
- Simula la actualización: dry-run de operaciones de paquetes; anota eliminaciones y transiciones de versiones mayores.
- Escenario en un clon: snapshot VM/disco; ejecuta la actualización en el clon; ensaya el reboot.
- Valida: arranque de servicios, puertos, pruebas de humo funcionales, saneidad de logs, línea base de latencia.
- Ejecuta en ventana: actualiza producción, reinicia, valida rápidamente y luego monitoriza al menos un ciclo de carga.
- Criterios de rollback: define un límite de tiempo estricto y fallos específicos que disparan rollback.
Paso a paso: instalación limpia con cutover (el enfoque “aburrido es bueno”)
- Inventario de estado: qué debe persistir (volúmenes de datos, secretos, certificados, identidad del host, reglas de firewall).
- Construye la imagen: SO base, paquetes, kernel, drivers, monitorización/agentes.
- Aplica configuración: desde código o un runbook estricto; evita “ssh y hacerlo a mano”.
- Adjunta o monta datos: asegura etiquetas/UUIDs correctos; valida permisos.
- Prueba funcional: endpoint de salud, conexiones BD, jobs en background, handshake TLS, flujos de autorización.
- Tráfico en sombra (si es posible): duplica peticiones de solo lectura o ejecuta canary.
- Cutover: intercambia detrás del balanceador/DNS; conserva el nodo viejo para backout rápido.
- Auditoría post-cutover: compara listeners, logs, métricas y ruido de alertas; luego desmantela el nodo viejo.
Preguntas frecuentes
1) ¿Una instalación limpia siempre tiene menos bugs?
No. Tiene menos bugs si puedes recrear el estado requerido correctamente. Si no, es una instalación limpia de un diseño roto, que es notablemente eficiente en fallar.
2) ¿Las actualizaciones in situ siempre son arriesgadas?
No siempre. Son razonables para rutas soportadas en sistemas bien gestionados con mínima deriva y buen rollback. El riesgo aumenta con módulos de terceros, servidores de larga vida y ediciones manuales desconocidas.
3) ¿Qué hay de “reinstalar pero conservar /home” (o preservar particiones de datos)?
Es un híbrido y puede funcionar bien. Obtienes una capa de SO limpia manteniendo datos. La arista afilada es permisos, consistencia de UID/GID y expectativas de montaje. Valida eso explícitamente.
4) Para bases de datos: ¿actualizar o reconstruir?
Prefiere reconstrucción de réplicas y failover controlado en lugar de actualizar el primario in situ. Para bases de datos en nodo único, las actualizaciones pueden estar bien, pero solo con backups verificados y un rollback probado.
5) ¿Cuál es el mayor sumidero de tiempo oculto?
Secretos e identidad: certificados, claves API, autenticación basada en host y el fichero aleatorio en /etc que hace tu sistema “especial”. Mételos en un sistema gestionado o tus reconstrucciones serán lentas y propensas a errores.
6) ¿Cómo decido rollback vs seguir depurando?
Si no puedes formular una hipótesis falsable a partir de logs y diffs en una hora, revierte. Depurar un sistema medio actualizado bajo presión es cómo se crea folclore en lugar de soluciones.
7) ¿La contenedorización cambia la respuesta?
Sí. Si la app corre en contenedores y el host es solo un sustrato, la instalación limpia (o reemplazo inmutable del host) se vuelve la opción por defecto. Las actualizaciones de host siguen importando para kernel, almacenamiento y red, pero el estado de la app está menos enredado.
8) ¿Y si los drivers de hardware son el problema?
Entonces necesitas un plan de compatibilidad más que un debate filosófico. Para HBAs de almacenamiento y NICs, valida soporte de drivers en el SO/kernel objetivo primero; si el soporte es incierto, la instalación limpia no te salvará.
9) ¿Cuál es la forma más segura de manejar saltos de versión mayores?
Construye nuevo, prueba duro, corta gradualmente. Los saltos mayores son donde el comportamiento por defecto cambia y configuraciones depreciadas mueren. Trátalos como migraciones, no como “actualizaciones”.
10) ¿Cómo evito que las instalaciones limpias se vuelvan lentas?
Haz el sistema describible: gestión de configuración, pipelines de imágenes y un artefacto contrato del sistema para validación. La primera vez es trabajo; la segunda vez es velocidad.
Próximos pasos que puedes hacer esta semana
Si quieres velocidad y menos bugs, deja de tratar las actualizaciones y reinstalaciones como rituales. Trátalas como transiciones de estado controladas.
- Crea un script de captura de baseline que registre SO/kernel, lista de paquetes, servicios fallidos, montajes, listeners y sysctls clave. Guárdalo con tus tickets de cambio.
- Añade puertas de salud antes de cualquier cambio mayor: checks SMART/ZFS/mdadm y requisitos de “scrub reciente”.
- Escoge un servicio y hazlo reconstruible de extremo a extremo con mínimos pasos manuales. Mide el tiempo. Arregla las tres principales fricciones (normalmente secretos, montajes e identidad).
- Define criterios de rollback para actualizaciones: límites de tiempo, presupuestos de error y qué significa “terminado” en métricas, no en sensaciones.
- Para sistemas con estado, diseña la próxima arquitectura para que reinstalar sea fácil: externaliza estado, replica datos y mantiene hosts desechables.
Mi opinión final: si tu entorno lo permite, por defecto opta por instalación limpia con cutover. Reserva las actualizaciones in situ para estados realmente difíciles de migrar o para rutas soportadas y bien probadas. La producción no recompensa la valentía; recompensa la repetibilidad.