Quando scopri che il paracadute non è mai stato controllato

La domanda più spaventosa che si possa sentire durante una crisi informatica non è “Quanto tempo ci vorrà per ripararlo?” La domanda che fa gelare il sangue è: “Abbiamo i backup, vero?”

Seguita, inevitabilmente, da una pausa drammatica e dalla risposta: “Certo che li abbiamo. Solo che non li abbiamo mai testati, quindi non siamo sicuri che funzionino davvero.”

Quando il paracadute viene aperto per la prima volta

Il problema fondamentale del disaster recovery nella maggior parte delle organizzazioni non è l’assenza di un piano. I piani esistono, spesso dettagliati ed elaborati, con diagrammi di flusso colorati e procedure che sulla carta sembrano perfette. Il problema è che nessuno li ha mai testati in condizioni reali.

È l’equivalente tecnologico di saltare da un aereo con un paracadute mai aperto prima, confidando che le istruzioni sulla confezione siano accurate. Durante le presentazioni strategiche, i manager mostrano orgogliosi i loro schemi di ripristino: “Se succede questo, facciamo questo, poi questo, e voilà, siamo operativi in quindici minuti!”

Ma avete mai provato a eseguire quella procedura? “Beh, no, interromperebbe le operazioni normali.” Ed è qui che il castello di carte crolla. Si presume che un sistema funzioni senza mai verificarlo, si dà per scontato che in emergenza tutto filerà liscio, si ignora che la pressione e il caos di una vera crisi amplificano ogni debolezza del piano.

Le simulazioni di disaster recovery vengono rimandate, posticipate, cancellate. C’è sempre qualcosa di più urgente, una scadenza più pressante, un progetto che non può aspettare. Fino al giorno in cui l’emergenza diventa reale, e improvvisamente si scopre che il piano meraviglioso ha lacune grandi quanto voragini.

Il caos delle responsabilità fantasma

Durante una crisi vera, la frase “qualcuno dovrebbe fare qualcosa” non è esattamente un piano d’azione efficace. Eppure è quello che succede quando i ruoli e le responsabilità non sono mai stati definiti chiaramente.

Si verificano scene surreali: tre persone diverse che cercano di risolvere lo stesso problema in tre modi diversi, ognuna convinta di essere l’unica a occuparsene, mentre altre aree critiche rimangono completamente scoperte. Oppure il caso opposto: tutti che si guardano aspettando che qualcun altro prenda l’iniziativa.

I responsabili spariscono misteriosamente quando inizia la crisi, riemergendo solo quando la tempesta è passata, pronti a prendersi il merito della risoluzione. Altri si trasformano in micromanager d’emergenza, respirando sul collo di chi sta effettivamente lavorando al problema, chiedendo aggiornamenti ogni due minuti e intralciando più che aiutando.

Alcuni danno ordini contraddittori, cambiando direzione ogni cinque minuti, creando confusione e rallentando il recupero invece di accelerarlo. Il panico diventa contagioso, la comunicazione si frammentata, e quello che dovrebbe essere un intervento coordinato diventa un caos organizzativo.

La dipendenza fatale dal singolo individuo

“Chi si occupa dei backup?” “Il sistemista, ogni venerdì sera.” Questa risposta dovrebbe far scattare immediatamente un allarme rosso in qualsiasi organizzazione. Perché quella persona va in vacanza, si ammala, trova un altro lavoro, o semplicemente un venerdì si dimentica.

I processi manuali sono la porta d’ingresso perfetta per l’errore umano. Quella variabile imprevedibile che trasforma una procedura apparentemente semplice in un potenziale disastro. La persona che gestisce i backup ha configurato tutto secondo una logica che ha senso solo per lei, senza documentare nulla, senza formare nessuno.

Quando quella persona non c’è più, il sistema di backup diventa una scatola nera. Nessuno sa esattamente come funziona, dove sono conservate le copie, come ripristinarle. L’intera strategia di continuità aziendale dipende dalla disponibilità e dalla memoria di un singolo individuo.

È come costruire un’impresa su fondamenta che potrebbero svanire da un momento all’altro. Ma molte organizzazioni continuano a operare esattamente così, inconsapevoli del rischio che stanno correndo, fino al giorno in cui quella persona critica non è raggiungibile.

La documentazione che vive solo nella testa

“Certo che abbiamo un piano di disaster recovery!” assicura il responsabile IT con sicurezza. “È tutto qui,” indica toccandosi la tempia. Perfetto. E se quella persona viene investita da un autobus domani mattina? L’intera strategia di recupero dell’azienda finisce sotto le ruote insieme a lei?

La mancanza di un piano documentato e aggiornato è il peccato originale del disaster recovery. Le procedure esistono, ma solo nella memoria di chi le ha create. Le password critiche sono conosciute da una sola persona. Le configurazioni essenziali non sono mai state scritte da nessuna parte.

Questa situazione non è sostenibile, ma viene tollerata perché “funziona” fino a quando non funziona più. Il problema è che quando smette di funzionare, le conseguenze sono catastrofiche. Non c’è tempo per ricostruire la conoscenza perduta mentre i sistemi sono già fermi e i clienti stanno chiamando.

L’illusione del backup locale

Alcune pratiche di backup sfidano non solo le migliori pratiche tecnologiche, ma anche la logica più elementare. Come l’azienda che conserva i backup del suo sistema cloud su un disco rigido USB sulla scrivania dello sviluppatore. O quella che tiene il codice sorgente critico su un dispositivo impolverato invece che in un repository di versionamento.

È come conservare i documenti più importanti dell’azienda in una scatola di cartone sotto la scrivania della reception. Viola ogni principio basilare di sicurezza informatica e gestione del rischio. Eppure queste pratiche primitive sopravvivono con una tenacia impressionante, anche in organizzazioni che si considerano tecnologicamente avanzate.

Il motivo è sempre lo stesso: convenienza immediata. È più facile salvare su un disco locale che configurare correttamente un sistema di backup distribuito. È più veloce copiare su un disco USB che caricare su un repository remoto. Finché tutto va bene, la convenienza sembra giustificare il rischio. Poi arriva il giorno in cui quel disco si guasta, o quel disco USB sparisce, e l’intera azienda scopre quanto fossero fragili le sue difese.

Quando la ridondanza non basta

“I nostri dischi sono ridondanti, non abbiamo bisogno di backup.” Questa affermazione, pronunciata con sicurezza, rappresenta un fraintendimento fondamentale della differenza tra disponibilità e resilienza.

La ridondanza protegge dai guasti hardware. Ma non protegge dalla corruzione dei dati, dagli errori umani, dagli aggiornamenti andati male, dalle cancellazioni accidentali. Un database corrotto replicato su sistemi ridondanti è semplicemente corruzione distribuita, non un sistema recuperabile.

Quando un aggiornamento malfunzionante corrompe l’intero database, la ridondanza non aiuta. Serve un backup pulito, testato, verificabile. Ma per molte organizzazioni questa lezione viene appresa troppo tardi, dopo giorni passati a cercare di recuperare frammenti di dati da log parziali e copie frammentarie salvate sui computer degli sviluppatori.

La procrastinazione strategica

Il disaster recovery è come l’assicurazione sulla vita: tutti sanno che dovrebbero averla, nessuno vuole pensarci troppo a lungo, e la maggior parte spera di non doverla mai usare. È quella cosa di cui si parla con tono solenne nelle riunioni strategiche, annuendo gravemente, per poi prontamente dimenticarsene.

La strategia di backup viene posticipata, rimandata, de-prioritizzata. “Lo faremo il mese prossimo,” “Appena finito questo progetto urgente,” “Quando avremo più budget.” Il club degli “avrei dovuto” accoglie continuamente nuovi membri: avrei dovuto fare quel backup, avrei dovuto testare il ripristino, avrei dovuto non dare accesso in produzione al tirocinante.

Il problema è che i disastri non aspettano che tu sia pronto. Non arrivano quando hai completato tutti i test, aggiornato tutta la documentazione, formato tutto il personale. Arrivano nei momenti peggiori, quando sei meno preparato, quando le risorse sono già scarse.

La cultura che fa la differenza

Le aziende che gestiscono bene le crisi non sono quelle che non hanno mai problemi. Sono quelle che hanno accettato l’inevitabilità dei problemi e si sono preparate di conseguenza. Hanno piani dettagliati ma flessibili, testati regolarmente in condizioni simili alla realtà.

Hanno ruoli chiari ma anche la flessibilità per adattarsi a situazioni impreviste. Hanno sistemi di comunicazione ridondanti e processi per assicurare che le informazioni fluiscano dove e quando servono. Soprattutto, vedono il disaster recovery non come un fastidioso requisito di compliance da soddisfare col minimo sforzo, ma come una componente fondamentale della loro operatività.

Un approccio strutturato e proattivo non è un lusso, è una necessità assoluta per qualsiasi organizzazione che voglia sopravvivere nel lungo termine. I progressi tecnologici non si traducono automaticamente in evoluzione delle pratiche professionali, soprattutto quando la cultura aziendale rimane ancorata a metodologie obsolete.

La prossima volta che qualcuno suggerisce di rimandare l’aggiornamento del piano di disaster recovery perché ci sono cose più urgenti, ricordate che è esattamente questa mentalità che trasforma piccoli inconvenienti in catastrofi aziendali. Non c’è niente di più urgente che assicurarsi di avere ancora un’azienda domani.

Il disaster recovery è come la salute: lo apprezzi veramente solo quando non ce l’hai più. E a quel punto, potrebbe essere troppo tardi.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT