Il test di disaster recovery: il piano che funziona solo finché non lo si prova
Giovedì mattina Security annuncia che la nuova policy di continuità operativa impone di testare il piano di disaster recovery entro fine mese. Il Junior legge il documento datato due anni fa: ruoli assegnati a persone uscite, un numero con prefisso estero e un server di backup che il Senior riconosce come il proprio piano provvisorio scritto dopo un blackout, mai aggiornato dopo la dismissione del server. Entra il Software Architect, che trasforma il test in una roadmap pluriennale di resilienza con multi-region ed event sourcing. Nel laboratorio il backup si restaura con successo, ma contiene dati di un mercato abbandonato, e ripristinarli viola la stessa policy di Security. Il Junior nota il paradosso: il test riuscito è per la documentazione un fallimento. Il Senior propone la via pragmatica: 'test eseguito con riserve', piano aggiornato caricato nella solita cartella condivisa. Tre settimane dopo il modulo è verde: test superato, sulla carta.
Voci, personaggi e contenuti creativi generati con strumenti di intelligenza artificiale e approvati prima della pubblicazione.
Trascrizione
Narratore: Allineiamoci Offline è prodotto interamente con voci sintetiche e musica originale. Giovedì mattina, in ufficio. Il team sta lavorando in silenzio, e il silenzio, in questo ufficio, è il segnale che sta per succedere qualcosa.
Narratore: Entra Security. Ha in mano una policy appena pubblicata e l'espressione di chi porta notizie di lavoro, non sue.
Security: Nuova policy di continuità operativa. Il piano di disaster recovery va testato entro fine mese. Non è una proposta, è un adempimento.
Junior Developer: Adempimento. Ok. Ma se il piano funziona, perché serve un adempimento per testarlo? O il piano funziona e il test è una formalità, oppure non funziona, e allora sono due anni di documentazione che descrivono qualcosa che non è vero.
Senior Developer: Sei già al terzo livello del ragionamento. Fermati al primo: prima leggiamo il piano.
Junior Developer: Piano di disaster recovery... eccolo, nella cartella condivisa. Ultima modifica due anni fa. Leggiamo: procedure chiare, ruoli assegnati... coordinatore, Marco. Responsabile comunicazioni, Marco. Responsabile ripristino... Marco. Chi è Marco?
Senior Developer: Consultente. Uscito tre anni fa. Guarda pure il numero di telefono sotto: prefisso di un altro paese.
Junior Developer: Allora riproviamo: chi è l'owner del piano, oggi? C'è una firma qui, in fondo. Un consulente. Non esiste una persona interna che risponde di questo documento?
Senior Developer: L'owner è il documento. Da due anni si gestisce da solo, e finora se n'è uscito bene.
Junior Developer: E qui indica il server di backup. ES-BACKUP-01. Esiste ancora?
Senior Developer: Quel piano lo conosco. Lo scrissi io, in una settimana, dopo un blackout che ci tenne via un pomeriggio intero. Sul documento c'è scritto 'provisorio'. Dismettemmo quel server l'anno dopo. Il documento non l'abbiamo aggiornato, perché sulla carta funzionava.
Junior Developer: Riassumo, per capire se ho capito: il piano provvisorio è diventato quello ufficiale, il server dentro il piano non esiste più, e la verifica sul documento è... nessuna. Ma al tempo del blackout, come vi siete accorti che il piano funzionava, se non l'avete mai provato?
Senior Developer: Non ci siamo accorti. Abbiamo sperato. E per due anni non abbiamo avuto modo di scoprire se avevamo ragione.
Narratore: Arriva il Software Architect, convocato per valutare l'architettura di ripristino. Fino a questo momento il problema riguardava un server.
Software Architect: Il problema non è ripristinare i dati. Il problema è che non abbiamo un'architettura target per la resilienza. Parliamo di multi-region, event sourcing, failover automatico. Standard industriale. Vi preparo una roadmap pluriennale con fasi, milestone e una governance dedicata.
Security: Domanda semplice. La roadmap pluriennale prevede anche il backup attuale, quello che dobbiamo restaurare venerdì? Perché la policy scade fine mese.
Junior Developer: E il failover automatico, per il test di venerdì... immagino che arrivi in fase tre.
Software Architect: Esatto, fase tre. Ma vediamo il venerdì come un'occasione: raccogliamo i requisiti, facciamo una sessione di discovery, e i risultati alimentano la fase uno. Il test diventa un input, non un output. Come approccio è molto più scalabile.
Senior Developer: Venerdì proviamo a riaccendere un server. Il test andrebbe fatto venerdì.
Software Architect: Appunto. Meglio partire subito con la fase zero: la definizione della visione.
Narratore: Venerdì pomeriggio, il laboratorio. Security ha prenotato la stanza, isolata dalla rete di produzione. Sul tavolo, un foglio con le procedure originali.
Security: Il backup c'è. È completo, integro, con verifiche periodiche. Lo restauriamo su questa macchina. Via.
Junior Developer: Barra di avanzamento... verifiche di integrità... è finito. Il restauro è riuscito. Al primo colpo!
Senior Developer: Non festeggiare. In dodici anni non ho mai visto un restauro finire senza conseguenze.
Security: Ha ragione. Guarda l'elenco dei dati che abbiamo appena ripristinato. Sì. E adesso il problema. Dentro il backup ci sono i dati dei clienti di un mercato che l'azienda ha abbandonato. Secondo la mia stessa policy, quei dati non si possono ripristinare. Non dovevamo farlo. L'abbiamo appena fatto, davanti a tutti.
Junior Developer: Aspetta. Per dimostrare che il ripristino funziona, abbiamo violato una policy di retention. Quindi il test riuscito è, per la documentazione, un fallimento. Come lo chiudo sul modulo ufficiale? 'Esito': sì o no?
Security: Sul modulo c'è un campo note, un campo azioni correttive e un checkbox per l'eventuale ripetizione del test. Il sistema prevede che il test possa fallire. Non prevede che possa riuscire male.
Junior Developer: E chi compila quei campi?
Security: Chi ha eseguito il test. Cioè noi, adesso.
Senior Developer: Sul modulo si segna 'test eseguito con riserve'. Si allega il piano aggiornato, con il server attuale, e il resto lo assorbe la roadmap dell'Architect. Poi carichi tutto nella stessa cartella condivisa, accanto a quello di due anni fa. Dove nessuno lo cercherà mai più.
Junior Developer: E il piano vecchio, quello di due anni fa, lo eliminiamo dalla cartella?
Senior Developer: No. Lo lasciamo lì. Se lo eliminiamo, qualcuno nota che il nuovo è diverso, e si aprono domande. I documenti legacy non si cancellano: si affiancano.
Junior Developer: Capito. Quindi il piano nuovo funziona, il piano vecchio esiste ancora, e il test è riuscito e fallito insieme. Domande così non le facevo il primo giorno.
Narratore: Tre settimane dopo, il modulo ufficiale è verde: test superato. Il piano di disaster recovery è tornato a funzionare perfettamente. Sulla carta. In attesa del prossimo test obbligatorio.