Una migrazione senza interruzioni non si riduce a lanciare due versioni dietro a un bilanciatore. Le versioni devono comprendere gli stessi dati, i compiti asincroni non devono essere duplicati, le integrazioni devono restare compatibili e il rollback deve preservare le operazioni effettuate dopo il passaggio.
Il vero obiettivo non è sempre «zero secondi». È rendere l’interruzione prevedibile, limitata e senza perdite, o mantenere il servizio quando il lavoro lo richiede. Una finestra breve e testata può essere più sicura di una coesistenza complessa mal gestita.
Definire la continuità attesa
I termini devono essere quantificati:
- indisponibilità massima accettabile;
- funzionalità che possono diventare di sola lettura;
- volume di dati che può essere riprodotto;
- RTO e RPO ;
- orari e popolazioni critiche;
- sistemi esterni da coordinare;
- durata di osservazione prima della convalida definitiva.
Un percorso secondario può essere temporaneamente disattivato mentre la consultazione rimane disponibile. Questo degrado controllato semplifica talvolta notevolmente la migrazione.
Mappare le compatibilità
Per ogni combinazione, verificare:
- vecchio codice con vecchio schema;
- nuovo codice con vecchio schema;
- vecchio codice con nuovo schema;
- nuovo codice con nuovo schema.
Una migrazione progressiva richiede spesso che diverse combinazioni funzionino per un periodo. I messaggi, le cache, i file e le API sono anche contratti da versionare.
Il metodo espandere, migrare, contrarre
Espandi
Aggiungere i nuovi campi, tabelle, endpoint o formati senza rimuovere il precedente. Le modifiche sono compatibili e generalmente opzionali. Il nuovo codice sa leggere il vecchio stato.
Migrare
Distribuire il codice compatibile, iniziare a scrivere il nuovo formato, poi trasformare gradualmente i dati esistenti. Dei controlli confrontano volumi, somme, impronte o campioni.
Contratto
Quando tutti i consumatori utilizzano il nuovo modello e l'osservazione è conclusiva, rimuovere il vecchio campo, il vecchio endpoint o il codice di compatibilità. Questa fase può avvenire diverse consegne dopo.
Sequenza di espansione, migrazione, validazione, commutazione, osservazione e rimozione del vecchio schema.
Progettare le migrazioni del database
Le operazioni bloccanti su grandi tabelle devono essere misurate su una copia rappresentativa. Alcune modifiche possono essere realizzate online, altre richiedono una strategia a lotti o una nuova struttura.
Un backfill robusto possiede:
- lotti delimitati ;
- un cursore o stato di ripresa;
- un'idempotenza ;
- una limitazione di carico;
- delle metriche;
- una validazione aziendale ;
- una procedura di arresto.
Non deve saturare la base né impedire le scritture normali.
Doppia lettura e doppia scrittura
La scrittura doppia può mantenere due modelli, ma introduce un rischio di divergenza. Deve essere centralizzata, idempotente e monitorata. Una transazione distribuita non è sempre necessaria; una coda e un meccanismo di riparazione possono essere più realistici.
La doppia lettura permette di confrontare i risultati o di tornare al vecchio sistema. Deve definire quale fonte fa autorità e come trattare una discrepanza.
Le strategie temporanee hanno una data di ritiro. Altrimenti, diventano l'architettura permanente.
Blu-verde, canarino e rotolante
Blu-verde
Due ambienti completi coesistono. Il traffico passa al nuovo dopo la convalida. Il ritorno è rapido fintanto che i dati rimangono compatibili. Il costo dell'infrastruttura e la sincronizzazione devono essere anticipati.
Canarino
Una piccola parte del traffico utilizza la nuova versione. Le metriche permettono di estendere o fermare. Il routing deve preservare le sessioni e le differenze di popolazione devono essere comprese.
Rotolando
Le istanze vengono sostituite progressivamente. La vecchia e la nuova versione coesistono, il che impone una compatibilità rigorosa dei dati, delle cache e dei messaggi.
Arresto pianificato
Per alcune trasformazioni, una finestra di manutenzione resta la soluzione più sicura. Deve essere comunicata, ripetuta e accompagnata da un piano di ripristino.
Attività pianificate e code di messaggi
Due versioni possono eseguire la stessa attività o interpretare diversamente un messaggio. I consumatori devono gestire le versioni dello schema, essere idempotenti e seguire lo stato di elaborazione.
Durante un cambio, può essere necessario sospendere un produttore, svuotare una coda, cambiare il instradamento o mantenere un consumatore di compatibilità. Queste operazioni sono riportate nel runbook.
Sessioni, cache e file
Le session devono essere condivise o compatibili. Un cambiamento del formato della sessione può disconnettere gli utenti o provocare errori. Le cache devono includere la versione del formato o essere invalidate in modo controllato.
Le migrazioni di archiviazione dei file richiedono copia, verifica dell'integrità, sincronizzazione dei nuovi file e strategia di collegamenti. Una reindirizzamento trasparente può permettere una transizione graduale.
Integrazioni esterne
I partner non cambiano sempre allo stesso ritmo. Una facciata può mantenere il vecchio contratto pur adattando il nuovo sistema. I webhook devono accettare le ripetizioni ed distinguere le versioni.
Prima del passaggio, confermare certificati, elenchi degli indirizzi, quote, ambienti, orari e contatti per gli incidenti. Le dipendenze umane fanno parte del piano.
Il rollback non è sempre possibile
Tornare al codice precedente è semplice solo se i dati prodotti rimangono comprensibili. Se il nuovo sistema crea strutture o operazioni sconosciute al precedente, il rollback può perdere o nascondere informazioni.
Esistono tre strategie:
- ritorno completo con ripristino e rigioco controllato;
- ritorno del traffico in lettura, trattamento manuale delle scritture;
- roll-forward rapido con correzione.
La strategia viene scelta prima della migrazione e ripetuta.
Ripetere con dati rappresentativi
Una ripetizione deve misurare la durata di ciascuna fase, il volume, il carico, i controlli e il ritorno. I dati sensibili sono anonimizzati o sintetici, ma la distribuzione e le anomalie devono rimanere realistiche.
Il runbook è eseguito dalle persone che interverranno in produzione. I comandi, le responsabilità, le soglie e le comunicazioni sono espliciti.
Definire i criteri go/no-go
Prima del ribaltamento, verificare:
- test e ricetta completati;
- backup e ripristino convalidati;
- capacità sufficiente;
- metriche e avvisi attivi;
- dati sincronizzati ;
- partner disponibili;
- piano di ritorno realizzabile;
- decisore identificato.
Un criterio non soddisfatto comporta un rinvio o un'accettazione formale del rischio.
Osservare dopo il ribaltamento
Le metriche tecniche devono essere collegate al business: errori, latenza, code, tassi di connessione, transazioni, importi, volumi e supporto. Controlli di coerenza confrontano il sistema vecchio e quello nuovo quando possibile.
La migrazione non è completata che dopo un periodo di osservazione, la risoluzione delle discrepanze e il ritiro dei meccanismi temporanei.
Documentare e pulire
Le bandiere, le doppie scritture, le tabelle antiche, gli accessi e gli ambienti temporanei devono essere rimossi. Lo schema architettonico, le procedure e l'inventario sono aggiornati.
Il ritorno d’esperienza registra le durate reali, le sorprese e i miglioramenti per la prossima migrazione.
La compatibilità come strategia
Le migrazioni sicure sono preparate da cambiamenti piccoli, compatibili e osservabili. Questa disciplina permette di modernizzare senza concentrare tutto il rischio in una notte.
Partitech può controllare le dipendenze, progettare le fasi, automatizzare i controlli e accompagnare il passaggio di applicazioni, CMS, database e infrastrutture. L’obiettivo è una transizione reversibile e comprensibile, adattata alla criticità del business.
Parliamo del tuo progetto
Preparare una migrazione testabile e reversibile con Partitech. Contatta Partitech.