La prova generale del piano che nessuno ha mai letto

Narratore: Allineiamoci Offline. Prima di iniziare, una premessa doverosa: tutte le voci di questo episodio sono generate sinteticamente. Nessun sviluppatore reale è stato costretto a leggerlo. Fortunatamente per loro. È mercoledì mattina. Il Junior apre la mail. C'è un invito ufficiale: la prova annuale del piano di disaster recovery, pianificata da mesi per dicembre, descritta come il giorno decisivo per la resilienza aziendale.

Junior Developer: Senior, ho ricevuto l'invito alla prova del disaster recovery. Dice: giornata full immersion sul piano di ripristino, roll-call dei team, simulazione del guasto, checklist di validazione. È in agenda da dicembre prossimo. C'è persino un logo.

Senior Developer: C'è un logo?

Junior Developer: Un logo. E un documento allegato: il piano DR, quarantadue pagine. Me lo stavo leggendo, e ho un paio di domande sul runbook. La procedura di ripristino dice di avviare il restore dalla console dell'ambiente di ripresa. Quel console non è l'ambiente che abbiamo dismesso l'anno scorso?

Senior Developer: Sì. È quello.

Junior Developer: Ma il piano dice che quella console è il punto di ingresso ufficiale del ripristino. Se il piano è sbagliato, come facciamo a essere resilienti a dicembre? Io pensavo che una prova annuale servisse proprio a scoprire queste cose in anticipo. Non a confermarle. E poi la checklist dei contatti di escalation. La prima persona in lista... ho cercato nella rubrica. Non esiste più. Nemmeno il reparto in cui lavorava esiste più.

Senior Developer: Il piano è stato scritto quando quell'infrastruttura c'era ancora. L'ultima prova vera è di diversi anni fa. Da allora è cambiato tutto: piattaforma, nomi, teams, backup. Ma nessuno ha mai aggiornato il piano. Si approva, si archivia, si riprova l'anno dopo.

Junior Developer: Ma se il piano descrive un ambiente che non c'è più, chi ha segnato le differenze?

Senior Developer: Nessuno.

Junior Developer: Quindi quarantadue pagine sono state approvate, firmate e archiviate da tutta la catena di comando. E l'unica persona che le sta leggendo fino in fondo... sono io. Stamattina. Per sbaglio.

Senior Developer: Benvenuto nel club. Sei in due, contando chi l'ha scritto.

Narratore: La riunione di preparazione della prova. Arriva anche il Software Architect.

Software Architect: Ho visto il piano DR. È monolitico, coerente con l'architettura di cinque anni fa. Se il piano non funziona, il problema non è il piano: è l'architettura. Io direi di usare la prova come catalizzatore: prima di testare il ripristino, ripensiamo il sistema come piattaforma event-driven, con domini disaccoppiati. In quel mondo, il disaster recovery diventa naturale, dichiarativo, quasi banale.

Junior Developer: Quindi... invece di testare il ripristino di dicembre, ripiattafomiamo tutto?

Software Architect: Non ripiattafomiamo. Evolviamo verso il target. La prova diventa il test di validazione della nuova architettura. Sono due passi, ma nel modello di maturità sono uno solo.

Senior Developer: Dobbiamo essere ripristinati entro dicembre.

Software Architect: Proprio per questo la ripiattaforma è urgente.

Narratore: Entra nella riunione il responsabile della sicurezza.

Security: Salve. Ho tre domande sul piano DR, prima della prova. Una: dove fisicamente sono i backup che il piano dice di ripristinare? Due: chi ha accesso alle procedure di ripristino? Tre: quali credenziali userete nel test?

Junior Developer: Domande giuste. Io le stavo facendo proprio ieri. Dove sono i backup?

Senior Developer: I backup del piano puntano al sistema dismesso. Su quello attuale, il backup sta... come sempre. In una cartella condivisa del mio account personale. Si chiama backup_finale_v3_conferma_def.zip.

Security: Conferma_def nel nome di un backup? E le credenziali per il test?

Senior Developer: Le credenziali di test nel piano funzionano solo in produzione. Quindi per il test usiamo quelle di produzione. È il piano, lo leggete.

Security: Io non ho scritto nulla. Vi posso solo chiedere di non usare credenziali di produzione in un test. Ma se è l'unica cosa che funziona...

Junior Developer: Le credenziali di test che funzionano solo in produzione. È quasi elegante, se ci pensi.

Security: Scusate, torniamo indietro di una domanda. Il file backup_finale_v3_conferma_def: chi può scriverci? E chi può cancellarlo? Perché un piano di disaster recovery con un solo proprietario, che per giunta è un account personale, tecnicamente non è un piano. È una persona.

Senior Developer: È una persona con uno script.

Narratore: È il giorno della prova. La simulazione del guasto era prevista per le nove. Parte alle undici, perché l'ambiente di test è stato ricreato la notte stessa e somiglia al legacy solo a metà.

Junior Developer: Ok, simulazione avviata. Dichiaro il guasto secondo il piano: criterio di attivazione verificato, chiamo il runbook, punto uno. Riavvio il servizio primario nel... Senior, il punto uno dice di riavviare il nodo primario. Il nodo primario in test è metà legacy e metà nuovo. Cosa riavvio?

Senior Developer: Riavvia quello che si riavvia. Come ogni anno.

Junior Developer: Ok. Riavviato. Non si ripristina nulla. Il runbook al punto due dice di verificare lo stato dal pannello di monitoraggio legacy. Il pannello che, appunto, non c'è più.

Software Architect: Questo conferma la necessità di passare all'event-driven. Un sistema disaccoppiato non avrebbe questo problema.

Junior Developer: Stiamo testando il piano di ripristino, non quello target!

Senior Developer: Raga. Guardate. C'è una procedura manuale. La facevo io anni fa quando il backup automatico non girava. Si apre la cartella condivisa, si copia lo zip, si lancia lo script senza commenti, si aspetta. Funziona sempre. Come ogni anno.

Junior Developer: Quindi la procedura di ripristino vera è lo stesso workaround manuale degli anni scorsi.

Security: Solo una cosa, per il verbale. Se il piano validato è il runbook, ma il ripristino vero è una procedura manuale in una cartella personale, cosa stiamo dichiarando valido? Il documento o l'abitudine?

Senior Developer: L'abitudine. Il documento è la sua traduzione ufficiale. È il piano B. Ma è l'unico che funziona, quindi è il piano A.

Security: Un attimo. La procedura manuale usa le credenziali di produzione? E chi ha accesso alla cartella condivisa personale?

Senior Developer: Io. E ora, formalmente, anche il Junior. Aggiungilo alla cartella, così la conoscenza è condivisa.

Narratore: Due ore dopo, la call di chiusura della prova. È il momento della validazione formale.

Junior Developer: Quindi... formalmente il piano è stato validato? Il ripristino è avvenuto, sia pure con la procedura manuale, il roll-call è stato fatto, la checklist è firmata.

Software Architect: Esatto. Il piano è validato. Con due action item: aggiornare la procedura di ripristino e valutare la ripiattaforma event-driven. E una nota: considerare l'allineamento del piano all'architettura target. Trovo questa nota molto solida.

Junior Developer: Due action item e una nota. L'anno prossimo, alla prova, qualcuno riaprirà il piano da capo e si farà di nuovo le mie stesse domande?

Security: Spero di no. Sarebbe un segnale di mancata crescita organizzativa.

Senior Developer: Bene. Il prossimo anno, prima della prova, rileggete il piano. Tutto qui.

Junior Developer: E quando lo rileggeremo?

Narratore: Nessuno risponde. Il piano di disaster recovery viene dichiarato validato, archiviato, e programmato per la prossima prova annuale. Così come l'anno scorso. E l'anno prima.