La continuità operativa dei sistemi IT è l’insieme delle misure tecniche, logistiche ed organizzative predisposte da un’azienda per assicurare il corretto e continuo funzionamento dei sistemi informatici necessari per la stabilità del business. Predisporre un Piano di disaster recovery o DRP è come stipulare un’assicurazione a tutela dell’azienda poiché consente alla stessa di pianificare con precisione le azioni da intraprendere in caso di eventi dannosi al fine di garantire la normale continuità operativa e contenere i danni. Il Disaster Recovery fornisce, quindi, le procedure e l’infrastruttura tecnica per mantenere attivi i servizi critici in caso di indisponibilità della infrastruttura IT che li eroga. Anche la Pubblica Amministrazione seguendo le linee guida dell’AGID* per il Disaster Recovery ai sensi del c.3, lettera b) dell’art. 50bis del Codice dell’Amministrazione Digitale, deve dotarsi di soluzioni tecnologiche per garantire la continuità operativa dei processi che presiedono all’erogazione dei servizi pubblici.
Solitamente le fasi di implementazione di un progetto di DRP sono 5:
- Studio di fattibilità e stima di RPO e RTO
- Definizione della soluzione DR più adeguata
- Implementazione e rilascio della soluzione tecnica
- Test periodico di disaster recovery
- Manutenzione costante dei sistemi
1. Prima del piano di disaster recovery: studio di fattibilità
Le tecnologie a disposizione nello scorso decennio incidevano notevolmente sui costi di implementazione dei progetti di DR, limitando notevolmente la possibilità delle aziende di dotarsi di una soluzione di continuità operativa. L’ampia gamma di tecnologie odierne ha incrementato notevolmente la possibilità di accedere a queste soluzioni per proteggere la propria impresa. Lo studio di fattibilità preliminare, infatti, serve a identificare i livelli di rischio a fronte della condizione effettiva dell’impresa. In particolare, è fondamentale in questa fase l’individuazione dei target di Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Il primo indica il tempo che intercorre tra l’interruzione e il momento del ripristino, il secondo identifica la quantità massima di dati che si possono perdere a seguito dell’arresto.
2. Piano di disaster recovery, scegliere la soluzione
In genere, l’oscillazione del costo del servizio di disaster recovery è legata al parametro RPO, poiché una perdita dei dati tendente allo zero necessita di architetture di replica particolarmente onerose in termini economici. Non tutte le aziende tuttavia hanno questa esigenza (un conto è una banca, un altro è una catena di ristoranti).
Una solida politica di backup potrebbe non essere sufficiente ai fini del ripristino dei dati ma comunque è già un buon punto di partenza. Ad una politica di protezione del dato locale si può aggiunge un piano di disaster recovery che si basa sull’analisi della situazione preesistente per arrivare al desiderata dell’organizzazione:
- DR su infrastruttura fisica
- DR su infrastruttura virtuale
- DR in cloud come servizio (DRaaS).
La selezione dell’opzione migliore viene supportata dalla consulenza del vendor IT al fine di soddisfare il fabbisogno reale del cliente ed il rispetto dell’obbligo di assicurare la resilienza dei sistemi software, hardware e servizi di trattamento dei dati personali ai sensi dell’articolo 32 del “Regolamento Generale sulla Protezione dei Dati 2016/679/UE”.
3. Implementare il piano di disaster recovery
La fase di Implementazione e rilascio in produzione della soluzione tecnica individuata avviene dopo le operazioni di sizing & design dell’ambiente deputato a ospitare il sito secondario, operazioni che possono essere affidate ad un provider con il quale concordare SLA (Service Level Agreement) in caso di failover e failback. L’insieme di tecnologie, risorse e procedure adottate nella strategia di DR confluisce poi in un apposito piano formale, il DRP, ovvero il documento ufficiale che contiene le caratteristiche dell’ambiente di ripristino, policy, procedure relative al Test di DR e tutte le azioni da attuare in caso di interruzione del servizio. All’interno del documento, inoltre, sono elencate le figure coinvolte nel processo di ripristino nonché alcune raccomandazioni rivolte a tutto il personale dell’azienda al fine di proteggere i dati e le informazioni aziendali in caso di disastro.
4. Il piano di disaster recovery va testato
La predisposizione di un piano di disaster recovery non si conclude con la configurazione del sito di ripristino. I test periodici, a cadenza programmata, fanno parte integrante del piano e sono utili a verificare l’efficacia della soluzione di DR, il suo corretto funzionamento, i processi di interazione con il cliente, il rispetto dei valori di RTO/RPO nonché la conferma dell’effettiva compliance rispetto agli SLA contrattualizzati. Un occhio di riguardo viene dato al monitoraggio della consistenza dei dati di replica, verificandoli tramite l’effettivo ripristino di sistemi operativi, dati e applicativi. I test non devono soltanto attenersi agli SLA definiti con il provider per ottemperare ad un aspetto formale, ma hanno anche l’obiettivo di individuare possibili bug di programmazione e problemi da indirizzare mantenendo sempre aggiornato il documento stesso e le procedure.
5. Manutenzione costante dei sistemi
Oltre ai test periodici, con cui perfezionare nel tempo la qualità del disaster recovery, è fondamentale una manutenzione costante dei sistemi che tenga conto di eventuali aggiunte (software, mobile app ecc.) o di mutati scenari in termini di compliance. All’interno del processo di manutenzione rientra anche la gestione del ciclo di vita del trattamento dei dati in funzione del piano di disaster recovery.
Scritto da Claudio Rossi – Managed Services and Cloud Offering Manager 
{{cta(‘1c4ffef1-b213-48f3-bb0c-a42cb0ca5cbb’,’justifycenter’)}}
