Una migración sin interrupciones no se limita a lanzar dos versiones detrás de un balanceador. Las versiones deben comprender los mismos datos, las tareas asincrónicas no deben duplicarse, las integraciones deben seguir siendo compatibles y el retroceso debe preservar las operaciones realizadas después del cambio.
El verdadero objetivo no siempre es "cero segundos". Es hacer que la interrupción sea previsible, limitada y sin pérdida, o mantener el servicio cuando el negocio lo exige. Una ventana corta y probada puede ser más segura que una coexistencia compleja mal controlada.
Definir la continuidad esperada
Los términos deben ser cuantificados:
- indisponibilidad máxima aceptable;
- funcionalidades que pueden pasar a solo lectura;
- volumen de datos que se puede reproducir;
- RTO y RPO ;
- horarios y poblaciones críticas;
- sistemas externos a coordinar;
- duración de la observación antes de la validación definitiva.
Un recorrido secundario puede ser desactivado temporalmente mientras la consulta permanece disponible. Esta degradación controlada a veces simplifica mucho la migración.
Cartografiar las compatibilidades
Para cada combinación, verificar:
- código antiguo con esquema antiguo;
- nuevo código con esquema antiguo;
- código antiguo con nuevo esquema;
- nuevo código con nuevo esquema.
Una migración progresiva a menudo exige que varias combinaciones funcionen durante un período. Los mensajes, cachés, archivos y API también son contratos que deben versionarse.
El método expandir, migrar, contraer
Expandir
Agregar los nuevos campos, tablas, endpoints o formatos sin eliminar los antiguos. Los cambios son compatibles y generalmente opcionales. El código nuevo sabe leer el estado antiguo.
Migrar
Desplegar el código compatible, empezar a escribir el nuevo formato, luego transformar progresivamente los datos existentes. Algunos controles comparan volúmenes, sumas, huellas o muestras.
Contrato
Cuando todos los consumidores utilicen el nuevo modelo y la observación sea concluyente, retirar el antiguo campo, el antiguo endpoint o el código de compatibilidad. Esta fase puede ocurrir varias entregas después.
Secuencia de expansión, migración, validación, conmutación, observación y retiro del antiguo esquema.
Diseñar las migraciones de base de datos
Las operaciones bloqueantes sobre grandes tablas deben medirse en una copia representativa. Algunas modificaciones pueden realizarse en línea, otras requieren una estrategia por lotes o una nueva estructura.
Un relleno resistente posee:
- lotes limitados ;
- un cursor o estado de reanudación;
- una idempotencia ;
- una limitación de carga;
- métricas;
- una validación empresarial;
- un procedimiento de detención.
No debe saturar la base ni impedir las escrituras normales.
Doble lectura y doble escritura
La doble escritura puede mantener dos modelos, pero introduce un riesgo de divergencia. Debe ser centralizada, idempotente y monitoreada. Una transacción distribuida no siempre es necesaria; una cola y un mecanismo de reparación pueden ser más realistas.
La doble lectura permite comparar los resultados o volver al sistema anterior. Debe definir qué fuente tiene autoridad y cómo tratar una discrepancia.
Las estrategias temporales tienen una fecha de retirada. De lo contrario, se convierten en la arquitectura permanente.
Azul-verde, canario y rodante
Azul verdoso
Dos entornos completos coexisten. El tráfico se traslada al nuevo después de la validación. El regreso es rápido mientras los datos sigan siendo compatibles. Se deben anticipar el costo de la infraestructura y la sincronización.
canaria
Una pequeña parte del tráfico utiliza la nueva versión. Las métricas permiten ampliar o detener. El enrutamiento debe preservar las sesiones y se deben comprender las diferencias de población.
Rodando
Las instancias se reemplazan progresivamente. La versión antigua y la nueva coexisten, lo que impone una compatibilidad estricta de los datos, cachés y mensajes.
Parada planificada
Para algunas transformaciones, una ventana de mantenimiento sigue siendo la solución más segura. Debe ser comunicada, repetida y acompañada de un plan de restauración.
Tareas programadas y colas de mensajes
Dos versiones pueden ejecutar la misma tarea o interpretar un mensaje de manera diferente. Los consumidores deben gestionar versiones de esquema, ser idempotentes y seguir el estado del procesamiento.
Durante un cambio, puede ser necesario suspender un productor, vaciar una cola, cambiar la ruta o mantener un consumidor de compatibilidad. Estas operaciones están en el manual de ejecución.
Sesiones, caché y archivos
Las sesiones deben ser compartidas o compatibles. Un cambio en el formato de la sesión puede desconectar a los usuarios o provocar errores. Las cachés deben incluir la versión del formato o ser invalidadas de manera controlada.
Las migraciones de almacenamiento de archivos requieren copia, verificación de integridad, sincronización de los archivos nuevos y estrategia de enlaces. Una redirección transparente puede permitir una transición progresiva.
Integraciones externas
Los socios no siempre cambian al mismo ritmo. Una fachada puede mantener el contrato antiguo mientras adapta el nuevo sistema. Los webhooks deben aceptar las reproducciones y distinguir las versiones.
Antes del cambio, confirmar certificados, listas de direcciones, cuotas, entornos, horarios y contactos de incidentes. Las dependencias humanas forman parte del plan.
El rollback no siempre es posible
Volver al código anterior es sencillo solo si los datos producidos siguen siendo comprensibles. Si el nuevo sistema crea estructuras u operaciones desconocidas para el anterior, el retroceso puede perder o enmascarar información.
Existen tres estrategias:
- retorno completo con restauración y reproducción controlada;
- retorno del tráfico en lectura, tratamiento manual de las escrituras;
- avance rápida con corrección.
La estrategia se elige antes de la migración y se repite.
Repetir con datos representativos
Una repetición debe medir la duración de cada etapa, el volumen, la carga, los controles y el retorno. Los datos sensibles se anonimizarán o serán sintéticos, pero la distribución y las anomalías deben seguir siendo realistas.
El runbook es ejecutado por las personas que intervendrán en producción. Los comandos, responsabilidades, umbrales y comunicaciones son explícitos.
Definir los criterios go/no-go
Antes del cambio, verificar:
- pruebas y receta terminadas;
- copia de seguridad y restauración validadas ;
- capacidad suficiente;
- métricas y alertas activas;
- datos sincronizados;
- socios disponibles;
- plan de retorno realizable;
- tomador de decisiones identificado.
Un criterio no satisfecho conduce a un aplazamiento o a una aceptación formal del riesgo.
Observar después del cambio
Las métricas técnicas deben estar relacionadas con el negocio: errores, latencia, colas, tasa de conexión, transacciones, montos, volúmenes y soporte. Los controles de coherencia comparan el sistema antiguo y el nuevo cuando es posible.
La migración solo se considera completada después de un período de observación, la resolución de las discrepancias y la retirada de los mecanismos temporales.
Documentar y limpiar
Las banderas, escrituras dobles, tablas antiguas, accesos y entornos temporales deben ser retirados. El esquema de arquitectura, los procedimientos y el inventario se actualizan.
El retorno de experiencia registra las duraciones reales, sorpresas y mejoras para la próxima migración.
La compatibilidad como estrategia
Las migraciones seguras se preparan mediante cambios pequeños, compatibles y observables. Esta disciplina permite modernizar sin concentrar todo el riesgo en una sola noche.
Partitech puede auditar las dependencias, diseñar los pasos, automatizar los controles y acompañar la migración de aplicaciones, de CMS, de bases de datos y de infraestructuras. El objetivo es una transición reversible y comprensible, adaptada a la criticidad del negocio.
Hablemos de su proyecto
Preparar una migración comprobable y reversible con Partitech. Contacte a Partitech.