Un’interruzione dei sistemi core può mettere in crisi anche l’azienda più solida. Il cloud ha reso disponibili strumenti potenti, scalabili e a consumo, ma senza un piano che definisca procedure, ruoli e tempi di intervento, anche l’infrastruttura più evoluta rischia di non poter garantire la continuità operativa che l’azienda, i partner, i clienti e il legislatore si aspettano.
Oggi, il vero fattore di differenziazione non è quindi disporre di soluzioni di ripristino dei sistemi, ma poter contare su un disaster recovery plan aggiornato, testato e integrato nei processi aziendali.
Il cloud e la nuova prospettiva sul Disaster Recovery
L’avvento del cloud ha rivoluzionato il modo di concepire un Disaster Recovery Plan e, più in generale, tutta la tematica della business continuity.
In passato, tecnologie come la replica geografica e l’alta disponibilità erano appannaggio di poche grandi aziende, capaci di sostenere investimenti infrastrutturali di alto profilo. Grazie al cloud, tutti questi strumenti sono diventati accessibili con risorse attivabili on demand e un modello di costo proporzionale alle risorse impiegate, cosa che ha esteso la capacità di difesa a un numero molto ampio di imprese.
DRaaS e automazione “as-code”
Alcuni passaggi significativi dell’evoluzione descritta sono stati il Disaster Recovery as a Service (DRaaS) e l’impiego dell’approccio IaC (Infrastructure as-code).
Il primo, in particolare, consente di trasformare il Disaster Recovery da progetto rigido e costoso a servizio modulare e scalabile, mentre grazie all’approccio IaC l’infrastruttura — snapshot di configurazioni, reti, ambienti — viene gestita tramite codice, e questo consente di automatizzare backup, provisioning dell’ambiente di recovery e failover. In questo modo, il DR diventa più flessibile, veloce da attivare e affidabile, perché unisce la scalabilità alla certezza di procedure automatizzate e replicabili.
Disaster Recovery Plan: oltre la tecnologia
Senza un approccio strategico e operativo ben definito, tutta l’evoluzione tecnologica legata al cloud rischia di essere inefficace. È per questo che il Disaster Recovery Plan, ovvero la traduzione degli obiettivi di continuità operativa in procedure concrete e testate, è in ogni caso il punto di partenza di un processo efficace.
- Un piano moderno considera sì l’evoluzione tecnologica sottostante, ma parte in ogni caso dall’assessment dei rischi, che deve includere quelli tipici dell’era del cloud: attacchi alla supply chain, compromissione di configurazioni condivise, errori o corruzione dei dati replicati.
- Restano fondamentali i parametri di RTO (Recovery Time Objective) e RPO (Recovery Point Objective), che devono essere calibrati sul business e non solo sulle potenzialità tecniche. La complessità che circonda l'argomento dipende dal fatto che non tutti i processi e gli applicativi aziendali richiedono gli stessi livelli di continuità operativa e di protezione del dato, da cui procedure differenziate (che devono emergere nel plan) cui far fronte con il possibile ricorso all'automazione.
- Parte integrante del piano sono i runbook operativi, ovvero le procedure che assegnano responsabilità, descrivono modalità operative di failover e failback per tornare il prima possibile all’operatività regolare.
- Il piano va testato e migliorato continuamente. Nel cloud, la possibilità di clonare ambienti e condurre simulazioni permette di validare il piano con regolarità.
Come il Disaster Recovery Plan riduce i tempi di inattività
La differenza tra un’azienda che riparte in pochi minuti e una che resta ferma per ore o addirittura giorni si gioca tutta sulla preparazione.
Un Disaster Recovery Plan ben strutturato permette innanzitutto di predisporre l’infrastruttura a gestire eventi imprevisti che possono comprometterne l’operatività e, soprattutto, di reagire seguendo procedure già definite, senza dover improvvisare sotto pressione. Sapere in anticipo chi deve fare cosa, con quali strumenti e in quali tempi, riduce drasticamente i tempi morti che si accumulano quando si brancola nel buio.
Unire prevenzione e conoscenza delle procedure rappresenta un passo avanti importante rispetto all’assenza di un piano. Una svolta ulteriore arriva quando all’interno delle procedure si insinua – quanto meno, parzialmente – l’automazione, che elimina la variabilità legata al fattore umano, accelera le operazioni e garantisce ripetibilità.
Per esempio, c’è differenza tra dover avviare manualmente un ambiente secondario, riconfigurando reti e applicazioni, e affidarsi a un failover automatico che gestisce in autonomia il provisioning dell’infrastruttura e il riallineamento dei dati. In entrambi i casi la procedura esiste, ma nel primo il downtime si misura in ore, nel secondo in minuti. Non a caso, il cloud sta rendendo più accessibili servizi avanzati di DR proprio grazie all’automazione.
Un ulteriore livello di efficienza si ottiene grazie a strategie di resilienza proattiva. Non sempre, infatti, il piano si limita a intervenire dopo l’incidente: in scenari ben progettati, è possibile mantenere attivi i servizi core anche durante un guasto, degradando temporaneamente quelli non essenziali. In altri casi, soprattutto nell’ambito del mission critical, si ricorre a modelli active-active, in cui i workload sono già distribuiti su più ambienti e uno può subentrare immediatamente all’altro senza interruzioni percepibili.
