Il concetto di sicurezza è, come sappiamo, relativo. Mentre non esiste, né può esistere, una sicurezza assoluta, esiste invece un dato livello di sicurezza che si può considerare soddisfacente in relazione a una data minaccia. In altre parole: a ogni potenziale causa di pericolo corrisponde una misura di sicurezza atta a prevenirne l’effetto. Riguardo l’It in particolare, al pericolo di un evento che possa danneggiare o distruggere i dati, i sistemi e l’infrastruttura fisica necessaria ad erogare i servizi a supporto del business, o comunque dell’attività di una qualsiasi organizzazione, corrisponde un insieme di misure di sicurezza che va sotto il nome di Disaster recovery Plan, o semplicemente Disaster recovery (Dr) (vedi articolo "Business Continuity e Disaster Recovery: le basi della questione"). Abbiamo voluto dare questa definizione del Disaster recovery sia per precisarne l’ambito operativo, che comprende le attività per il recupero dei dati e il ripristino dei sistemi (Data e System recovery) ed è compreso in quelle per la Business continuity, di cui fa parte; sia per meglio comprendere l’oggetto di un’interessante indagine che Forrester Research (www.forrester.com) ha dedicato all’argomento.
Condotta su 248 responsabili delle operazioni di storage e Dr estratti da un universo di oltre 2.600 executive e decisori It di aziende di varie dimensioni distribuite in Nord America (Usa e Canada) e in Europa, l’indagine ha lo scopo di valutare il grado di preparazione che le imprese (in maggioranza grandi, ma anche small-medium business), hanno riguardo al Dr, con particolare attenzione alle differenze culturali e di approccio al problema tra il Vecchio e il Nuovo continente. Vediamone in breve i risultati, ricordando che si tratta di un’indagine motivazionale, svolta con interviste in profondità, dove più che i numeri valgono le conclusioni che gli analisti Forrester ne hanno tratto e che qui sintetizziamo.
Per cominciare, va detto che far approvare un progetto di Dr non è facile. Realizzare un sito di recovery e un’infrastruttura It ridondata, implementare soluzioni software specifiche e ricorrere, come talvolta è necessario, a consulenze e servizi esterni, costa. E sebbene certi costi (come quelli dell’hardware) siano calati, un progetto Dr resta un notevole investimento che, ed è questo il punto, non porta all’impresa né un ritorno economico né una maggiore efficienza operativa. Come tutti gli investimenti in sicurezza, è qualcosa che si fa per ridurre un rischio. La percezione che si ha di questo rischio è la spinta ad agire, e i fattori di spinta più citati da chi ha realizzato un progetto di Dr (214 intervistati su 248) sono, in ordine di importanza secondo le citazioni fatte dagli intervistati, i seguenti:
1) il costo di una caduta del sistema, sia in termini monetari (mancate vendite, ritardate fatturazioni, penalità per mancate o ritardate consegne e così via), sia in termini di customer satisfaction e d’immagine aziendale;
2) la perdita di competitività che ne deriva in un business globalizzato (dove un downtime notturno in Europa colpisce una filiale Usa all’inizio della giornata) e sempre più basato su attività on-line;
3) la responsabilità verso chi ha interessi legati all’impresa (dagli azionisti ai dipendenti, partner, clienti e fornitori);
4) il timore di disastri causati dalla natura o dagli uomini (dai terremoti agli atti di vandalismo o terrorismo);
5) la compliance normativa.
Quest’ultimo punto è importante soprattutto in Europa (con il 47% delle citazioni contro il 34% del Nord America), dove al complesso delle norme emesse dai singoli Stati e dagli enti di settore si sovrappongono quelle emesse dagli organi normativi dell’Ue. Ma i manager europei si mostrano molto sensibili anche alle prime due voci di rischio, che vengono citate con una frequenza oltre il 12% superiore a quella dei colleghi americani (63 e 56%, rispettivamente, per i costi e 56 e 49% per la competitività). Quanto al resto, il rischio di disastri naturali e di attentati è (come intuibile) meno sentito in Europa che in America (41 e 47% rispettivamente), mentre la responsabilità verso gli stakeholder non mostra differenze significative. Nel complesso, quindi, ed è una cosa che colpisce chi è abituato a vedere nell’America il modello da seguire per l’It, l’attenzione al DR è superiore dal nostro lato dell’Oceano.
Passando dalle motivazioni alla realizzazione, la grande maggioranza di chi ha un piano di Dr si ritiene al sicuro: il 70% degli intervistati dichiara infatti di essere pronto al recovery del data center in caso di disastro, avendo un sito dedicato al Dr, un’infrastruttura It parimenti dedicata e svolgendo frequenti test sulla procedura, come suggerito dalle best practices del settore (raccomandate, va detto, dalla stessa Forrester). Anche qui le aziende europee sono (o ritengono di essere) in condizioni migliori di quelle americane, con un quota di valutazioni positive (‘preparato’ e ‘molto preparato’) del 78% contro il 67% (figura 1).
Figura 1: Livello di “confidenza” dichiarato dalle aziende circa il proprio piano di disaster recovery (fonte: Forrester)
(Clicca sull’immagine per ingrandirla)
Ma non è detto che non si tratti invece di un eccesso di fiducia e gli analisti Forrester non esitano a mettere in guardia i responsabili It dal rischio di un pericoloso ottimismo, avendo rilevato, in base ad indagini precedenti e a domande di approfondimento in quella di cui stiamo parlando, come in molti casi i piani di Dr non vengano aggiornati e i test non siano né così frequenti né così approfonditi come dovrebbero essere.
In particolare, sono le procedure di test a essere messe in discussione e Forrester propone un programma in quattro punti sul quale i responsabili It possono confrontarsi:
– Revisione: tutte le figure aziendali coinvolte nel piano di Dr si incontrano per rivederne insieme i passi principali. Non è un vero test in grado di validare la bontà del piano e/o la tecnologia, ma è un buon esercizio per non essere colti alla sprovvista al momento di agire;
– Test ‘a tavolino’: funziona come la revisione, ma configurando uno scenario di pericolo, cioè immaginando un incendio, un attacco di virus o quant’altro, a fronte del quale tutti i partecipanti discutono e definiscono le proprie azioni;
– Simulazione: il piano di Dr viene provato in una situazione controllata che non impatta sul business, di solito inviando al sito di recovery delle copie dei dati. L’It sospende brevemente la replica dei dati tra il sito primario e secondario, crea una copia (con tecniche di snapshot o clonatura) dei dati di produzione e l’invia a server ridondati sul sito secondario, quindi i sistemi sono fatti ripartire usando questi dati replicati e vengono fatti i test di funzionalità;
– Test completo: l’It attua un reale blocco dei sistemi e li trasferisce sul sito di recovery. Ciò permette di provare effettivamente la bontà del piano di Dr, ma è chiaro che se c’è un problema questo va ad impattare la produzione. Inoltre, una volta che il test è fatto, bisogna anche tornare alla situazione di partenza senza problemi. Nonostante sia, come è ovvio, il test più valido, è difficile che l’It riesca a farlo accettare dai responsabili del business.
Sul fronte dei test la ricerca Forrester ha rilevato un netto miglioramento della situazione: rispetto ad un’analoga indagine svolta nel 2007, solo il 10% dei rispondenti ha ammesso di non condurre test completi, contro il 25% di due anni fa (figura 2).
Figura 2: Frequenza dei test di disaster recovery (fonte: Forrester)
(Clicca sull’immagine per ingrandirla)
C’è però da dire che il concetto di ‘test completo’ cambia da un’azienda all’altra e quelle che rispondono alla definizione data sono pochissime. Nella gran parte dei casi si tratta in realtà di simulazioni. Un programma di testing dovrebbe prevedere tutti e quattro i tipi descritti, con revisioni e prove a tavolino una volta al trimestre, simulazioni una volta ogni sei mesi (o quando c’è un cambiamento importante nella configurazione dei sistemi) e un test completo almeno una volta l’anno.
Per concludere, in base all’esperienza di chi ha realizzato un piano di Dr si possono dare alcune indicazioni sulla strada da seguire. In primo luogo, sebbene non esistano standard riconosciuti per il Disaster recovery né, in senso più ampio, per la Business continuity, il Bsi (British Standard Institution) sta lavorando sulle Pas (Publicly Available Specification) 77:2006 che riguardano l’ It Service Continuity Management (ItScm), cioè per l’appunto la gestione della continuità dei servizi It al business, di cui il DR è parte. Le Pas 77:2006 non sono un vero e proprio standard operativo, ma secondo Forrester danno una buona visione sulle best practices più seguite nel settore. In più, l’Itil fornisce un quadro di riferimento per i processi di ItScm, per cui i responsabili It possono usare entrambi questi documenti come base di partenza per il proprio piano di lavoro.
Un secondo fattore importante di successo è la capacità di sfruttare l’esperienza delle altre figure, o gruppi di lavoro, responsabili della gestione del rischio. E’ probabile infatti che alcuni degli aspetti inerenti il Dr siano stati affrontati da chi analizza problemi di sicurezza o di rischio operativo e che molte delle informazioni di cui si ha bisogno per un piano di Dr siano già state raccolte e disponibili. In ogni caso, anche se questo lavoro non fosse stato fatto, è importante che questi responsabili non siano esclusi dallo studio del progetto. Sempre in tema di rischio, è inoltre importante focalizzarsi subito sulla prevenzione di quello che appare come il rischio più probabile, senza cercare di prevenire ogni pericolo potenzialmente possibile. Infine, Forrester raccomanda all’It di non lavorare in isolamento, ma di tenere regolarmente al corrente il top management e i responsabili delle linee di business di quello che si va facendo, sviluppando delle metriche di valutazione delle attività di in corso che siano chiaramente riferibili ai vantaggi per il business. Si è detto, all’inizio, che il problema del Dr è che i progetti costano e non portano che vantaggi intangibili. Bisogna allora darsi da fare perché questi vantaggi diventino il più possibile evidenti.
