Piano di migrazione al cloud: inventario, ordine, ritorno
Un piano di migrazione al cloud ha quattro parti: inventario, ordine di spostamento, ambiente di prova e via di ritorno. Cosa causa i disservizi.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Un piano di migrazione al cloud consiste nel fare l'inventario del sistema attuale, ordinare le parti in base a ciò che dipende da cosa, testare ogni passaggio senza toccare il sito online e lasciare una strada di ritorno verso la vecchia impostazione nel caso in cui qualcosa vada storto. Se a un piano mancano questi quattro passaggi, il trasloco non è una migrazione ma una scommessa. Il segno di uno spostamento riuscito non è la velocità, ma il fatto che gli utenti non si accorgano di nulla.
La maggior parte dei problemi di migrazione non nasce dalla difficoltà tecnica, ma da un pezzo dimenticato: un'attività pianificata che gira sul vecchio server, una regola di posta o un'impostazione che conosceva una sola persona. Per questo la parte più preziosa di un piano non è l'elenco dei lavori da fare, ma un resoconto onesto di ciò che esiste.
Da dove si comincia: come si compila un inventario?
Un inventario è un elenco scritto di tutto ciò che verrà spostato: siti, applicazioni, database, archiviazione di file, attività pianificate, nomi di dominio, certificati SSL, account di posta e collegamenti con terze parti. Per ogni voce lei annota chi ne è responsabile, quanto è critica e da cosa dipende.
La domanda che in questa fase lavora di più è cosa succede se questo pezzo si ferma. Se si ferma un modulo di prenotazione, si perdono ricavi; se si ferma uno strumento interno di report, un report arriva con un giorno di ritardo. Questa distinzione decide l'ordine dello spostamento e il tempo di interruzione che lei può accettare.
- Siti, applicazioni e i database che utilizzano.
- Attività pianificate e script che girano in background.
- Record di dominio, impostazioni DNS e certificati.
- Account di posta e gli inoltri collegati.
- Collegamenti con terze parti come pagamenti, mappe e analisi.
In quale ordine vanno spostate le parti?
La regola generale è spostare per primo ciò che ha poche dipendenze e poco rischio. Un ambiente di prova o uno strumento interno si presta a un primo tentativo, perché un errore costa poco e il team impara il processo. I sistemi che toccano direttamente i clienti vengono dopo, quando la routine si è consolidata.
Le parti che dipendono l'una dall'altra vanno pensate insieme. Se un'applicazione e il suo database girano in posti diversi, il ritardo fra i due può causare problemi di velocità. Per questo spostare un sistema in un solo passaggio, con le sue parti collegate, è spesso la strada più sicura.
Come si testa senza toccare il sito online?
Un ambiente di prova è una copia costruita sulla nuova infrastruttura e non ancora aperta agli utenti. Si prende una copia aggiornata del database, si esegue l'applicazione nel nuovo ambiente e si prova a mano ogni flusso importante: accesso, invio di moduli, pagamento, notifica via e-mail, caricamento di file.
Poi si osserva il comportamento sotto carico. Se il catalogo prodotti di un produttore di pavimentazioni riceve molte visite al mattino, quel carico va simulato anche nell'ambiente di prova. Le misurazioni di velocità hanno senso come confronto solo se vengono fatte allo stesso modo prima e dopo lo spostamento.
Infine si sceglie l'ora del passaggio. Uno spostamento fatto nella fascia più tranquilla del traffico riduce l'effetto di qualsiasi intoppo. Poiché le modifiche DNS richiedono tempo per diffondersi, abbassare il valore del TTL prima dello spostamento è un passaggio preparatorio a parte.
- Costruire il nuovo ambiente con una copia aggiornata dei dati.
- Provare a mano i flussi di accesso, modulo, pagamento ed e-mail.
- Simulare il comportamento in un'ora di punta.
- Misurare la velocità allo stesso modo prima e dopo lo spostamento.
Perché la via di ritorno si scrive per prima?
Un piano di rientro è il resoconto scritto di quali passaggi la riportano alla vecchia impostazione, e quanto tempo richiedono, se qualcosa va storto durante lo spostamento. Si prepara prima dello spostamento, perché ragionare con calma è difficile una volta arrivato il problema. Mantenere il vecchio sistema in funzione, invariato, per un periodo dopo lo spostamento è il fondamento di questo piano.
Una decisione importante per il rientro riguarda dove vengono scritti i dati. Gli ordini o i moduli creati nel nuovo sistema dopo lo spostamento possono andare persi se lei torna al vecchio. Per questo si stabilisce prima come i dati verranno mantenuti allineati durante la finestra di migrazione, o quando la scrittura verrà congelata.
Quando passare al cloud è la scelta sbagliata?
Se il sistema è piccolo, il traffico è regolare e l'hosting attuale funziona senza problemi, uno spostamento spesso non porta alcun vantaggio. Restano la fatica dello spostamento, l'onere di gestire la nuova impostazione e il rischio di errore, mentre il ritorno è incerto. Uno spostamento ha bisogno di un motivo: un limite di capacità, un'esigenza di continuità o un fornitore attuale inadeguato.
Spostarsi poco prima di una campagna importante o di una stagione intensa è anche un cattivo momento. Per un gruppo di spa, le settimane prima della corsa alle prenotazioni estive sono un periodo in cui il team non avrà tempo di risolvere i problemi. Collocare lo spostamento in un periodo tranquillo conta quanto il piano.
Quali errori sono frequenti in una migrazione?
L'errore più comune è saltare l'inventario e passare direttamente allo spostamento. Un pezzo dimenticato salta fuori giorni dopo lo spostamento, in un momento che nessuno si aspettava. Il secondo errore è testare sul sito online anziché in un ambiente di prova, il che trasforma i suoi utenti nel team di collaudo.
Il terzo errore è spegnere il vecchio sistema subito dopo lo spostamento. Un vecchio sistema che non viene mantenuto in parallelo per un po' elimina la possibilità di tornare indietro. Il quarto è lasciare lo spostamento nella conoscenza di una sola persona; se il processo non è scritto, nessuno può subentrare quando quella persona è assente.
- Iniziare a spostare senza inventario.
- Testare sul sito online anziché in un ambiente di prova.
- Spegnere il vecchio sistema subito dopo lo spostamento.
- Lasciare il processo nella memoria di una sola persona.
Un piano di migrazione al cloud inizia con un inventario, si ordina secondo le dipendenze, si testa in un ambiente separato e si mette in sicurezza con una via di ritorno. Quando questi quattro passaggi vengono saltati, il rischio di interruzione diventa maggiore dello spostamento stesso. Se desidera parlare di se il suo sistema attuale meriti il cloud e di come pianificare lo spostamento, può fissare un colloquio conoscitivo con rabbitclip.
Domande frequenti
Quanto dura una migrazione al cloud?
Dipende dalle dimensioni del sistema, dal numero di dipendenze e dall'ampiezza dei test. Un piccolo sito può spostarsi in un giorno o due; un sistema fatto di molte parti collegate può richiedere settimane.
Il sito andrà offline durante lo spostamento?
In uno spostamento ben pianificato gli utenti non notano alcuna interruzione. Il nuovo ambiente viene costruito e testato in anticipo, e la modifica DNS viene fatta in un momento di poco traffico.
Un piano di rientro è davvero necessario?
Sì. Decidere con calma è difficile una volta arrivato il problema. Tenere in funzione il vecchio sistema per un po' e scrivere i passaggi del ritorno impedisce che un intoppo diventi una crisi.
Devo spostare tutto in una volta?
Di solito no. Iniziare dalle parti a basso rischio permette di imparare il processo e di individuare gli errori su piccola scala. Le parti strettamente collegate vanno però spostate insieme.
