Developers Italia

Finestre di manutenzione e livelli di servizio: l’importanza di pianificare il trasferimento di dati e applicativi in cloud

di Daniele Pizzolli, Team Cloud Italia del Dipartimento per la trasformazione digitale

“Siamo spiacenti, il servizio non è al momento disponibile”: quante volte ci siamo imbattuti in un messaggio di cortesia che ci avvisa dell’indisponibilità di un servizio online? Spesso i picchi di traffico, la manutenzione ordinaria, attacchi informatici o altre evenienze rendono difficile l’esperienza degli utenti. Garantire la continuità di servizio diventa così uno degli aspetti fondamentali da tenere in considerazione per la Pubblica Amministrazione che intende offrire servizi pubblici disponibili 24 ore su 24 per cittadini e imprese, come previsto dalla Strategia Cloud Italia. Bastano infatti pochi accorgimenti per azzerare i disservizi, massimizzando la soddisfazione degli utenti.

In particolare, il Piano nazionale di ripresa e resilienza (PNRR) prevede una serie di interventi per rafforzare le infrastrutture digitali e l’abilitazione al cloud nella Pubblica Amministrazione. Grazie ai fondi messi a disposizione dalla Misura 1.2 Abilitazione e facilitazione migrazione al Cloud, ad esempio, numerose amministrazioni italiane, in particolare Comuni e scuole, hanno così la possibilità di migrare e aggiornare i servizi offerti tramite internet.

Per rendere più efficace la migrazione in cloud di dati e servizi applicativi è però opportuno che, per ogni servizio erogato, le amministrazioni pongano attenzione alle finestre di manutenzione e ai livelli di servizio (ad esempio il tempo di disponibilità del servizio, il tempo medio che intercorre tra i guasti, il tempo di risposta e soluzione dei problemi ecc.), elementi che è necessario rispettare anche a seguito dei processi di migrazione.

_{^{Some rights reserved – Copyright gatus.io Apache License 2.0}}

Finestre di manutenzione e livelli di servizio

Le finestre di manutenzione di norma sono posizionate lontane dai picchi di richiesta del servizio e, nel caso siano straordinarie oltre che interessare la platea dei cittadini, è buona prassi che siano comunicate con largo anticipo. Per esempio per un servizio di protocollo, che avrà i picchi in orario di sportello e la maggioranza degli utenti attivi in orario d’ufficio, la finestra di manutenzione dovrebbe partire dopo la chiusura dell’ufficio.

Tra i livelli di servizio più importanti, invece, c’è la disponibilità del servizio, ovvero il tempo durante il quale un servizio è disponibile. Di norma si indica come percentuale su un intervallo temporale. Per esempio una disponibilità del 99.9% in orario 7-21, su base giornaliera significa che il servizio potrebbe essere indisponibile al massimo per 8 minuti e 24 secondi nelle 14 ore considerate. Questo vuol dire, per un servizio che prevede l’invio di un documento a un sistema di protocollazione, che il funzionario di un Comune potrà attendere al massimo poco più di 8 minuti consecutivi, prima che questo possa essere considerato un disservizio.

Con l’esclusione dei sistemi di emergenza, di comunicazioni istantanea e di raccolta dati in tempo reale, che già dovrebbero essere ridondanti – ovvero avere ogni componente del servizio disponibile in multiple istanze – oppure che necessitano di processare immediatamente i dati in locale, come ad esempio quelli degli ospedali e degli aeroporti, in generale i servizi della PA, e in particolare quelli rivolti al pubblico, non hanno bisogno di avere dei livelli di disponibilità così elevata da rappresentare un grave ostacolo alla migrazione. Anzi, è molto probabile che più un servizio sia organizzato per garantire alte disponibilità, maggiori siano le ridondanze previste per permettere di fare manutenzione e migrazione senza interrompere in maniera drastica il servizio.

_{^{Some rights reserved – Copyright Joel Carnat (joel at carnat dot net) www.tumfatig.net}}

Pianificazione della migrazione

Il modo di gestire la continuità di servizio è diverso a seconda della modalità di migrazione scelta, della maturità tecnologica del servizio di partenza e anche dalle competenze e dalla documentazione interna in uso in quella specifica amministrazione. La pianificazione della migrazione dovrà inoltre tenere in considerazione i livelli di servizio da rispettare e l’impatto che possono avere sulla strategia di migrazione.

Ad oggi, nel caso di Comuni e scuole, sono finanziate con i fondi del PNRR due modalità di migrazione, in linea con quanto previsto dal Regolamento cloud:

• il trasferimento in sicurezza dell’infrastruttura IT (Lift & Shift, anche detta Rehost);
• l’aggiornamento in sicurezza di applicazioni in Cloud (tramite repurchase/replace o replatform).

Valutare la scelta migliore è un’attività che richiede vari passaggi. Il primo è una mappatura delle competenze interne e/o dei fornitori, in modo da avere un quadro realistico della padronanza, da parte del gruppo di lavoro, delle competenze necessarie per gestire una migrazione; il secondo è stabilire l’ordine di migrazione degli applicativi, che è parte integrante del processo di migrazione e può pregiudicarne il risultato.

Migrazione con trasferimento

È il caso più semplice: l’applicazione viene spostata in cloud con modifiche minime. La modalità più comune per effettuare una migrazione con trasferimento (lift & shift) è spegnere il servizio, trasferire software e dati, per poi riaccendere l’applicativo. Se le finestre di manutenzione previste per ogni servizio sono abbastanza ampie da permettere la sincronizzazione, il problema della continuità di erogazione può essere considerato inesistente.

Se le finestre di manutenzione sono invece troppo strette, o le dipendenze fra i servizi sono tali per cui non è possibile migrare più servizi in una finestra di manutenzione, si possono mettere in atto correttivi temporanei, per esempio mettendo in comunicazione il servizio locale (on premise) con quello remote (in cloud) tramite una rete privata temporanea (VPN), tramite un proxy o un sistema di reindirizzamento del traffico.

Il concetto di migrazione al cloud è ormai radicato, e per questo esistono soluzioni specifiche, sia prodotte direttamente dalle software house che titolari del software, sia dai cloud provider, sia da terzi e dalla comunità che agevolano e automatizzano gran parte della migrazione, e che prevedono anche passi graduali: dalla macchina fisica in locale si passa ad una macchina virtuale (VM) in locale che si avvale di dischi virtuali (chiamati volumi) per i quali esistono appositi strumenti di sincronizzazione con il corrispondente volume remoto in cloud. Suddividendo i passi nella migrazione si suddividono anche i tempi di fermo servizio ed i rischi, favorendo così la continuità del servizio.

Migrazione con aggiornamento

Nel caso di una migrazione con aggiornamento, la continuità del servizio dipende fortemente dalle condizioni di partenza e di arrivo, che possono essere molto diverse. Con questo tipo di migrazione, i casi di arrivo previsti sono due:

• repurchase/replace, ovvero ricomprare un servizio come rimpiazzo completo, ad esempio partendo da una soluzione di posta elettronica installata in casa si arriva a un servizio gestito in SaaS (Software as a Service);
• rearchitect, ovvero ri-fattorizzare il servizio per renderlo più aderente al modello cloud. In questo caso, partendo da un'applicazione monolitica si possono spacchettare le varie funzionalità anche in funzione delle caratteristiche del cloud, per esempio riprogettando l'applicazione per reagire ad i picchi di richiesta con un’elasticità orizzontale data dalle risorse del cloud provider.

In entrambe le modalità è possibile garantire una continuità di servizio senza grandi interventi, a patto che il nuovo sistema, il nostro punto di arrivo, sia anzitutto predisposto per importare in ogni momento i dati di quello “vecchio” e, contemporaneamente, che i dati presenti nel punto di partenza siano resi indisponibili oppure in sola lettura.

Un servizio che può essere facilmente migrato con l’export continuo è per esempio la posta elettronica. I messaggi che temporaneamente, durante la fase di passaggio dal vecchio al nuovo (di norma chiamata switchover), arrivano al vecchio sistema possono essere automaticamente importati nel nuovo. Nessun messaggio sarà perso, ma sarà disponibile nel nuovo punto di arrivo con un leggero ritardo temporale, misurabile in pochi minuti.

In ogni caso è buona prassi che le amministrazioni prevedano, in fase di redazione del piano di migrazione, anche una fase di dimensionamento e di test, in modo da evitare possibili “salti nel vuoto” e di stimare l’impatto della migrazione sull’effettiva disponibilità del servizio, prevedendo, dove necessarie, le opportune azioni di comunicazione.

Suggerimenti conclusivi

Il manuale di abilitazione al cloud è un’ottima fonte per familiarizzare con i vari aspetti della migrazione e può fornire lo spunto per approfondire numerosi temi offerti dal modello Cloud della PA. Il manuale offre una panoramica più fine di quella discussa qui delle modalità di migrazione, comprendendo ad esempio anche il replatform, che è qualcosa di intermedio fra il rehost e il rearchitect, una sorta di rifattorizzazione parziale.

In generale, comunque, nella fase di redazione del piano di migrazione si terrà conto dei livelli di continuità richiesti e si potranno indirizzare le criticità rilevate con diversi strumenti ed artifici tecnici che dipendono fortemente dalle tecnologie in uso. Un confronto con i fornitori attuali e futuri del servizio potrà fornire il quadro tecnico-pratico nel quale muoversi, con l’obiettivo, per ogni PA, di ridurre al minimo – se non azzerare – i messaggi di cortesia che invitano gli utenti di un servizio online a riprovare (tristemente) più tardi.

Approfondisci le prossime tappe della Strategia Cloud Italia e scopri come partecipare agli avvisi del PNRR per la migrazione al cloud dedicati alle amministrazioni.

Questo blog è redatto da Developers Italia