Piani di disaster recovery che non funzionano: come trasformare la documentazione in operatività reale

Esiste una categoria di rischio che molti responsabili IT conoscono bene ma raramente ammettono apertamente: il piano di disaster recovery che giace in una cartella condivisa, aggiornato l'ultima volta durante un audit di conformità, mai verificato in condizioni reali. È un documento che infonde una sensazione di sicurezza del tutto infondata, perché la distanza tra ciò che è scritto e ciò che accadrebbe davvero in caso di incidente può essere abissale.

In Italia, questa situazione è più diffusa di quanto si creda. Le PMI — ma anche molte medie imprese strutturate — investono tempo e risorse nella produzione di documentazione DR per soddisfare requisiti normativi o contrattuali, senza mai mettere alla prova concreta le procedure descritte. Il risultato è un'infrastruttura che si percepisce protetta ma che, nei fatti, non ha mai dimostrato di sapersi riprendere da un guasto.

Il problema non è la mancanza di consapevolezza

Sarebbe semplicistico attribuire questo fenomeno alla disattenzione o alla negligenza. I team IT sono spesso sotto pressione: gestiscono quotidianamente incidenti, aggiornamenti, richieste degli utenti e progetti di trasformazione. Il disaster recovery, per sua natura, riguarda scenari che non si verificano — o almeno, si spera non si verifichino. È comprensibile che venga sistematicamente posticipato.

Il vero problema è strutturale: le organizzazioni non hanno costruito una cultura e un processo che rendano il testing del DR una componente ordinaria della gestione infrastrutturale. Il piano esiste, ma non è mai diventato operativo. Non è mai stato eseguito, cronometrato, corretto sulla base degli esiti.

Questo genera quello che potremmo chiamare il paradosso della documentazione: più il documento è dettagliato e ben scritto, più tende a essere percepito come sufficiente, riducendo ulteriormente la probabilità che venga effettivamente testato.

Cosa succede quando il DR viene attivato per la prima volta in emergenza

Le conseguenze di un piano mai testato emergono in modo brutale durante un'interruzione reale. I runbook fanno riferimento a sistemi che nel frattempo sono stati sostituiti. Le credenziali di accesso ai backup sono cambiate. I responsabili indicati nel documento hanno lasciato l'azienda. I tempi di ripristino stimati non tengono conto dei colli di bottiglia reali della rete o dei tempi di avvio delle applicazioni.

In scenari di questo tipo, il team IT non sta eseguendo un piano: sta improvvisando sotto pressione, con la direzione aziendale che chiede aggiornamenti ogni quindici minuti e i clienti che segnalano disservizi. È esattamente la situazione che il disaster recovery dovrebbe prevenire.

Un'analisi degli incidenti reali mostra che le aziende che non effettuano test periodici impiegano in media il doppio del tempo per ripristinare i servizi rispetto a quelle che conducono esercitazioni regolari. E in molti casi, i dati recuperati non corrispondono allo stato atteso: le procedure di backup erano attive, ma nessuno aveva mai verificato che i restore funzionassero correttamente.

Come costruire un programma di test sostenibile

La soluzione non consiste nell'organizzare un grande esercizio annuale che richiede settimane di preparazione e coinvolge l'intera organizzazione. Questo approccio, pur avendo un suo valore, è spesso percepito come eccessivamente oneroso e viene rimandato indefinitamente.

Un approccio più efficace è costruire un programma di test graduali e frequenti, integrati nel ciclo operativo normale:

Test di restore dei singoli componenti: almeno una volta al mese, selezionare un sistema o un dataset e verificare che il ripristino da backup funzioni correttamente. Questo non richiede interruzioni del servizio e fornisce dati concreti sulla qualità dei backup.

Failover parziale in ambiente staging: creare un ambiente di test che replichi la topologia produttiva e condurre failover controllati su sottosistemi specifici. Questo permette di individuare dipendenze nascoste e configurazioni errate senza rischi per l'operatività.

Simulazioni tabletop: esercitazioni basate su scenari ipotetici, condotte con i responsabili chiave, che permettono di verificare la chiarezza delle procedure decisionali e la catena di comunicazione senza toccare i sistemi.

DR drill completo: almeno una volta l'anno, un test end-to-end che simuli un'interruzione significativa e misuri i tempi effettivi di ripristino rispetto agli obiettivi RTO e RPO dichiarati.

Automatizzare il failover: quando l'intervento umano è il collo di bottiglia

Uno degli errori più comuni nella progettazione dei piani DR è sovrastimare la capacità del team di intervenire rapidamente in condizioni di stress. Le procedure manuali richiedono tempo, attenzione e coordinamento — risorse che in un'emergenza sono sempre scarse.

L'automazione del failover non è un lusso riservato alle grandi aziende: oggi esistono strumenti accessibili anche per infrastrutture di medie dimensioni che permettono di definire politiche di failover automatico, attivare ambienti di recovery senza intervento manuale e notificare i responsabili con aggiornamenti in tempo reale sullo stato del ripristino.

Integrare questi meccanismi nell'infrastruttura significa ridurre il rischio di errori umani durante le fasi più critiche e garantire che i tempi di ripristino siano effettivamente quelli previsti, non quelli ottimistici scritti in un documento.

La dimensione organizzativa: chi è responsabile del DR?

Un piano di disaster recovery che non ha un proprietario chiaro è destinato a invecchiare nei cassetti. La responsabilità del DR deve essere assegnata esplicitamente, con obiettivi misurabili e revisioni periodiche documentate.

Questo significa designare un DR owner che non sia semplicemente il responsabile IT generico, ma una figura con mandato specifico: pianificare i test, raccogliere i risultati, aggiornare la documentazione, comunicare lo stato di preparazione alla direzione.

Means anche creare incentivi organizzativi corretti. Se i test DR vengono percepiti come attività extra che sottraggono tempo ai progetti prioritari, non verranno mai eseguiti con la frequenza necessaria. Devono essere parte integrante del piano di lavoro del team, con slot dedicati nel calendario e budget assegnato.

Metriche che contano davvero

Un piano DR efficace si misura su pochi indicatori fondamentali:

• RTO effettivo vs. dichiarato: quanto tempo impiegano realmente i sistemi a tornare operativi durante un test, rispetto all'obiettivo scritto nel piano.
• RPO effettivo vs. dichiarato: quanti dati vengono effettivamente persi in un ripristino, rispetto alla finestra di perdita accettabile definita.
• Frequenza dei test: quante volte nel corso dell'anno sono stati condotti test di restore, failover parziale o drill completi.
• Tasso di successo dei restore: percentuale di test di ripristino che si concludono con successo senza interventi manuali correttivi.

Questi numeri devono essere visibili alla direzione aziendale, non solo al team tecnico. La resilienza infrastrutturale è una variabile di business, non solo una questione tecnologica.

Dalla carta alla realtà

Il disaster recovery non è un progetto che si completa: è una pratica continua che richiede manutenzione, attenzione e risorse. Un piano scritto bene è un punto di partenza, non un traguardo.

Le aziende che investono nella verifica sistematica dei propri piani di ripristino non stanno solo proteggendo i dati: stanno costruendo fiducia operativa, riducendo il rischio di interruzioni prolungate e dimostrando ai propri clienti e partner di essere un'organizzazione che prende sul serio la continuità del servizio.

Il momento di testare il piano di disaster recovery non è durante un'emergenza. È adesso, in condizioni controllate, con il tempo e la lucidità necessari per imparare da ciò che non funziona e correggerlo prima che il problema diventi reale.