Quando il responsabile IT della “ACME Limited” mi chiamò per parlare di Disaster Recovery…


…io ripassai tutte le definizioni di Continuità Operativa (BS25777, ISO27001, BS25999, ISO24762), per poi scegliere quella a mio avviso più sintetica e completa: “La gestione della continuità operativa comprende tutte le iniziative volte a ridurre a un livello ritenuto accettabile i danni conseguenti a incidenti e catastrofi che colpiscono direttamente o indirettamente un’azienda.” (“Normativa di vigilanza sulla continuità operativa delle banche” – Banca d’Italia).

Rimasi quindi spiazzato quando il cliente mi propose la sua definizione di Disaster Recovery: “Per me le soluzioni di Disaster Recovery costano troppo, soldi spesi per macchine di fatto inutilizzate; se malauguratamente se ne avrà bisogno non funzionerà, ma nonostante la bassissima probabilità che a noi possa accadere un incidente serio, dobbiamo comunque dimostrare di averla.”

“Ora, poiché l’Azienda mi ha chiesto di lavorare in questa direzione, ho deciso di studiare le esigenze di protezione (Analisi dei Rischi, Business Impact Analysis); una volta completate queste analisi, faremo partire lo studio dei modelli adottabili e la valutazione del budget da allocare per la soluzione.”

Quando tornai a trovarlo, mi mostrò l’output della Analisi dei Rischi che, con dovizia di particolari, spiegava qual’era la probabilità di poter incorrere in un incendio, di un allagamento, di un atto terroristico e via dicendo con decine di tipologie di eventi indesiderati.

Obiettai che un’analisi così corposa e dettagliata è sovradimensionata per la valutazione delle esigenze di Disaster Recovery se, come nel suo caso, non si dispone di nessuna protezione da disastro: “l’effetto di uno qualsiasi di questi eventi può potenzialmente portare alla perdita dei propri dati e alla prospettiva di dover interrompere i servizi IT per mesi: la probabilità di questi eventi moltiplicata per i danni potenziali (l’azienda può correre il rischio di perdere i dati e/o di interrompere per mesi l’erogazione dei servizi?) rende di fatto obbligatoria la soluzione DR, senza bisogno di analisi particolarmente profonde.”

“L’analisi dei rischi ha la sua utilità nel ridurre la probabilità di incorrere in eventi indesiderati irrobustendo la propria infrastruttura, ma poiché questa probabilità non può essere azzerata, la soluzione di Disaster Recovery si rende comunque necessaria.”

Mi richiamò 6 mesi dopo per analizzare l’output della Business Impact Analysis che aveva svolto nel frattempo.

Riguadagnai la sua stima quando affermai che la BIA è assolutamente necessaria perchè stabilisce formalmente l’impegno reciproco tra i responsabili del business e l’organizzazione IT: io pago affinchè tu protegga.

Quando però mi presentò lo studio, in cui erano elencati decine di processi di business con associati a ciascuno di essi le esigenze di continuità (RTO = tempo massimo di indisponibilità, RPO = perdita dati massima), mi chiese anche in questo caso la ragione del mio scetticismo.

“Tutti i processi che hanno relazioni applicative tra loro (e si scambiano dati) non possono essere assoggettati ad esigenze di continuità diverse, perchè si correrebbe il rischio di avere la copia dei dati (per DR) inconsistente dal punto di vista applicativo; quindi non decine di processi, ma poche isole di recovery (cioè aggregazioni di processi in relazione tra loro, accomunati dagli stessi livelli di continuità).”

“Le coppie di RTO ed RPO sostenibili dalla tecnologia sono poche; a titolo di esempio, i valori di RPO passano da una perdita dati di pochi minuti (mirroring asincroni) a valori superiori alle 24 ore (salvataggi con cadenza giornaliera più il tempo per la loro produzione ed allontanamento dalla sede di esercizio): in mezzo a questi due valori (pochi minuti, più di 24 ore) non ci sono soluzioni possibili (salvo rarissime eccezioni).”

“In conclusione, sapendo che i processi con relazioni tra loro devono essere aggregati e che i valori di RTO e RPO sostenibili dalla tecnologia sono pochi, la stessa analisi poteva essere fatta con lo stesso rigore spendendo molto meno tempo e soldi.”

Ma il colpo di grazia alle conclusioni della BIA arrivò da lì a poco, cioè quando fu analizzata la coerenza tra esigenze di continuità e budget stanziato per la soluzione.

Non avemmo subito la percezione del problema, perchè quando gli comunicai la stima dei costi per le soluzioni applicabili lui confermò che era in linea con il budget, salvo poi scoprire che io parlavo di costi annui e lui del budget per i cinque anni successivi…

E qui scattò la rincorsa al contenimento dei costi, giocata su due piani paralleli:

  • la riduzione del perimetro dei processi da proteggere e l’abbassamento dei livelli di continuità attesi (smantellando di fatto nel giro di poche ore i risultati della BIA…);
  • “l’ottimizzazione” della soluzione tecnologica.

Furono quindi identificati “i servizi critici” scegliendone un sottoinsieme da proteggere, come prima fase della soluzione.

Provai a sostenere i limiti di questo approccio: “se considerassimo lo scenario di disastro peggiore (quello che a mio avviso TUTTE le soluzioni di Disaster Recovery devono onorare), cioè un evento in grado di distruggere o rendere indisponibile per mesi il proprio centro di calcolo, avere o non avere una soluzione per alcuni dei servizi critici non è certo una soluzione di continuità; se fosse accettabile per un’azienda andare avanti per sei mesi solo con questi servizi, c’è un’alternativa migliore per tagliare i costi: spegnere da subito gli altri servizi, senza aspettare un disastro….”.

“Una soluzione di questo tipo sottintende in realtà un altro scenario di disastro: “speriamo che in una settimana riusciamo a risolvere il problema ed intanto andiamo avanti con alcuni servizi”; più che una soluzione di continuità, una soluzione “di agonia”.”

Alla sua obiezione che questa soluzione costituisce una prima fase, e che quindi successivamente la protezione sarebbe stata estesa al resto del perimetro dei servizi critici, risposi che forse è preferibile non spendere nulla piuttosto che spendere poco per una soluzione insufficiente.

A questo punto discutemmo le sue linee guida per “l’ottimizzazione tecnologica” della soluzione:

  • riutilizzo, per disaster recovery, di tecnologie dismesse in produzione;
  • riduzione della capacità di calcolo in recovery, rispetto a quella impiegata in produzione;
  • “alleggerimento” degli scenari di test, con conseguenti economie di scala;
  • uso della configurazione di disaster recovery per servizi “minori”, ritenuti sacrificabili in caso di indisponibilità dei servizi critici;
  • rinuncia ad interventi in ambiente di esercizio (razionalizzazione dei server e dello storage) perchè costosi, adottando di conseguenza un’eterogeneità di strumenti per alimentare il sito di disaster recovery.

Nessuna di queste linee guida è sbagliata “a priori”, ma molto spesso questo mix di interventi porta ad una soluzione di Disaster Recovery incompleta sul piano delle garanzie, con incertezza circa il reale funzionamento perchè non soggetta a test esaustivi.

Oggi la tecnologia ed il mercato offrono modalità per contenere i costi complessivi delle soluzioni DR, mantenendone l’affidabilità e la rispondenza alle esigenze di continuità:

  • l’uso di infrastrutture e risorse condivise, con le stesse certezze d’accesso in caso di bisogno rispetto alle soluzioni proprietarie;
  • l’efficientamento della produzione, laddove il contenimento dei costi e l’incremento di efficacia della soluzione DR è “solo” un beneficio accessorio, rispetto alla riduzione dei costi di gestione in esercizio;
  • l’adozione di architetture Cloud in recovery, con la possibilità di predisporre in tempi rapidissimi configurazioni ed ambienti in linea con le esigenze contingenti, rendendo dinamicamente redistribuibili gli ambienti operativi;
  • l’armonizzazione tra le contromisure di component recovery (cioè le ridondanze locali pensate per far fronte a problemi di componente, ad esempio i cluster) e le esigenze di Disaster Recovery.

Il responsabile IT della ACME si mostrò interessato ai punti da me sollevati, dicendo che sarebbero stati oggetto di approfondimenti nei nostri successivi incontri, ma sono passati più di 4 mesi e non mi ha ancora chiamato…..