Per anni, la pianificazione del Recovery ha seguito uno schema ben noto: elaborare il piano, documentarne le fasi e dare per scontato che funzionerà quando necessario. Per molto tempo, quell’approccio ha funzionato. Guasti hardware, interruzioni isolate, persino disastri naturali: erano scenari che le organizzazioni potevano prevedere e pianificare con un certo grado di sicurezza. Ma la situazione è cambiata.
In questa puntata di STRIVE, ho intervistato Jason Cray, Principal Product Experience di Commvault, per approfondire una realtà che continuiamo a riscontrare nelle organizzazioni di ogni dimensione: la maggior parte di esse non fallisce perché manca di un piano di ripristino, ma perché non ha mai verificato che tale piano regga sotto pressione. Guarda l’episodio completo.
Punti chiave: Perché i piani di ripristino falliscono
- Un piano documentato non equivale a un piano collaudato. Se non è stato testato in condizioni realistiche, rimane comunque un’ipotesi.
- Il ripristino è un lavoro di squadra. Sicurezza, infrastruttura e operazioni devono essere coordinate, altrimenti il ripristino subisce un rallentamento.
- La maggior parte degli investimenti avviene ancora “prima del boom”. La prevenzione è importante, ma spesso si trascura la preparazione al ripristino.
- I test mettono in luce le lacune e rafforzano la fiducia. Senza di essi, le organizzazioni finiscono per affidarsi alla speranza.
- La resilienza è una disciplina operativa. Richiede iterazione, comunicazione e miglioramento continuo.
Il problema del «dovrebbe funzionare»
Sulla carta, il ripristino sembra semplice. Si definisce il momento in cui effettuare il ripristino, quali dati devono essere recuperati e dove devono essere ripristinati. Il processo appare logico, strutturato e gestibile. Ma, come sottolinea Jason, quella semplicità raramente regge alle condizioni del mondo reale.
I piani vengono redatti in ambienti controllati, ma vengono eseguiti nel caos. Quando si verifica un incidente, i team non seguono con calma la documentazione: reagiscono, risolvono i problemi e cercano di coordinarsi in tempo reale. È qui che emerge il divario. Non tra strumenti e tecnologia, ma tra aspettative ed esecuzione.
Anteprima: Perché i piani falliscono sotto pressione
A questo punto della conversazione, Jason e io analizziamo perché avere un piano non basta – e cosa serve davvero per sapere se un piano funzionerà quando sarà davvero importante.
L’abbiamo già visto in passato
La cosa interessante è che non si tratta di un problema nuovo; è un problema già noto, solo che si presenta in un contesto diverso. Se si torna ai primi tempi del disaster recovery, le organizzazioni seguivano uno schema simile. I piani esistevano, ma i test erano, nel migliore dei casi, incostanti. Jason ha raccontato di aver trascorso un’intera notte ad aiutare un cliente a superare un test di disaster recovery per il quale pensava di essere pronto. Il piano sembrava solido. L’esecuzione, invece, raccontava una storia diversa.
Nel corso del tempo, le organizzazioni si sono adattate. Hanno effettuato test con maggiore frequenza, introdotto esercitazioni di failover e, in alcuni casi, hanno persino gestito la produzione da ambienti secondari per dimostrare la propria prontezza. Questo passaggio dal presupposto alla verifica è esattamente ciò che la cyber-resilienza richiede oggi.
Il primo ostacolo: la comunicazione
Se c’è una questione che emerge costantemente, è proprio quella della comunicazione. In molte organizzazioni, le responsabilità sono chiaramente definite: il reparto sicurezza si occupa della prevenzione, quello delle infrastrutture gestisce i sistemi e quello delle operazioni è responsabile del ripristino. Presi singolarmente, ciascun team potrebbe svolgere esattamente il proprio compito. Ma il ripristino non avviene in modo isolato. Dipende da quanto bene quei team riescano a collaborare quando qualcosa va storto.
Come descrive Jason, troppo spesso si finisce per adottare un modello di “passaggio di consegne”: “Abbiamo fatto la nostra parte, ora tocca a qualcun altro”. Questo approccio comporta ritardi, confusione e, in ultima analisi, rischi. Durante un evento informatico, il coordinamento conta più dell’attribuzione delle responsabilità.
Il problema del “Left of Boom”
Un altro fenomeno che continuiamo a osservare è lo squilibrio nella distribuzione degli sforzi da parte delle organizzazioni. Si registrano investimenti significativi nella prevenzione: strumenti di sicurezza, piattaforme di rilevamento e strategie difensive volte a bloccare un attacco prima ancora che si verifichi. Si tratta di investimenti necessari, che svolgono un ruolo fondamentale. Ma si presta molta meno attenzione a ciò che accade dopo l’evento.
Si parte dal presupposto che, se si dedica uno sforzo sufficiente alla prevenzione, Recovery diventi una preoccupazione secondaria. In realtà, è vero il contrario. A un certo punto, qualcosa riesce a sfuggire ai controlli. E quando ciò accade, Recovery diventa il fattore determinante nel modo in cui un’organizzazione reagisce.
Dalla speranza alla prova
È proprio qui che occorre cambiare mentalità. Non si tratta di aggiungere altri strumenti o di riscrivere la documentazione. Si tratta piuttosto di passare da un modello basato sulla speranza a uno fondato su dati concreti.
Jason sottolinea un’osservazione fondamentale: le organizzazioni che gestiscono bene i momenti di crisi non sono quelle che evitano gli incidenti, ma quelle che subiscono un impatto minore quando tali incidenti si verificano. Hanno testato i propri processi. Hanno verificato le proprie ipotesi. Comprendono dove si trovano le loro lacune. Ma soprattutto, hanno conquistato la fiducia degli altri – non credendo che il piano funzionasse, ma dimostrandolo.
Inizia in piccolo, crea slancio
Per molti team, la sfida non sta nel comprendere il problema, ma nel capire da dove cominciare. La soluzione non è quella di rivoluzionare tutto in una volta. Bisogna iniziare con piccoli passi e partire da lì.
Concentrati su uno o due servizi critici. Cerca di capire cosa serve per ripristinarli. Riunisci i team responsabili di quei sistemi e testa il processo dall’inizio alla fine. Da lì, amplia l’ambito e continua a perfezionare. Questo approccio non si limita a migliorare il ripristino: favorisce l’allineamento, rafforza la comunicazione e getta le basi per una resilienza più ampia.
La realtà: nessun piano sopravvive al primo impatto
Uno dei momenti più sinceri della nostra discussione è stato questo: anche il piano migliore non funzionerà esattamente come previsto. Non è un fallimento: è proprio quello che ci si aspetta. Jason lo spiega in modo semplice: se non hai un piano, fallirai. Ma anche se ne hai uno, non andrà tutto liscio come l’olio sul momento.
Ciò che conta è quanto i tuoi team siano pronti ad adattarsi. I test creano questa capacità di adattamento. Sviluppano la memoria muscolare necessaria per reagire in modo efficace quando le condizioni non corrispondono alle aspettative.
Guarda l’episodio completo
In questa conversazione STRIVE affrontiamo molti altri argomenti, tra cui:
- Perché i piani di ripristino spesso falliscono nonostante siano ben documentati.
- Cosa contraddistingue le organizzazioni che riescono a riprendersi in modo efficace.
- In che modo le lacune comunicative influenzano l’esecuzione.
- Da dove iniziare per migliorare la preparazione al ripristino.
- Perché i test sono alla base della resilienza.
Guardalo subito. Se ti sei mai chiesto se il tuo piano di ripristino funzionerebbe davvero, questa conversazione merita la tua attenzione.
Domande frequenti
D: Perché non basta avere un piano di ripristino?
R: Perché la maggior parte dei piani non viene mai verificata in condizioni reali. Senza test, rimangono semplici ipotesi anziché strategie comprovate.
D: Quali sono le cause del fallimento dei piani di ripristino?
R: I problemi più comuni nei piani di ripristino sono la mancanza di test, una comunicazione insufficiente tra i team e le discrepanze tra i processi documentati e l’effettiva esecuzione.
D: Cosa significa “a sinistra del boom”?
R: Il concetto di “Left of Boom” si riferisce all’attenzione rivolta alla prevenzione degli incidenti prima che si verifichino. Molte organizzazioni investono ingenti risorse in questo ambito, ma non investono abbastanza nelle capacità di ripristino.
D: Con quale frequenza dovrebbero essere testati i piani di ripristino?
R: I piani di ripristino dovrebbero essere testati regolarmente e in condizioni diverse. I test dovrebbero simulare scenari realistici, non limitarsi a semplici esercitazioni controllate.
D: Da dove dovrebbero partire le organizzazioni?
R: Iniziare con un numero limitato di servizi critici, coordinare i team responsabili e testare il processo di ripristino end-to-end prima di procedere all’espansione.
D: Qual è il cambiamento di mentalità fondamentale?
R: Passare da una pianificazione basata sulla speranza a una convalida basata su dati concreti.
Chris Mierzwa è direttore senior del marketing di portafoglio presso Commvault.
