Disaster Recovery - Non chiedetevi se accadrà, ma quando

All'inizio nessuno fu preso dal panico, presso una grande banca globale, quando durante l'abituale processo di back-up programmato del lunedì notte si verificò un problema su un sistema di back-office di importanza critica. Ma l'umore cambiò presto, non appena divenne evidente che il database multi-terabyte della banca si era danneggiato.

I tentativi di passare al sistema esterno di back-up "a caldo" furono inutili: anche il back-up aveva subito gli stessi danni. A quel punto era in atto una vera e propria crisi. Il gruppo dedicato alla gestione delle applicazioni IT sospese tutte le altre attività, mentre le quattro ore previste dalla finestra temporale target di ripristino trascorrevano e venivano superate senza nessuna indicazione della causa scatenante o di una rapida soluzione. Continuarono a consultarsi fino al giorno dopo, ben consci del fatto che reagire in modo avventato avrebbe solo potuto peggiorare le cose.

Nel frattempo, la banca proseguiva le sue operazioni di trading. Già solo cercare di tenere il passo causava grossi mal di testa ai gruppi IT. Per prima cosa dovettero trovare un back-up intatto: avevano scoperto che il danno si era probabilmente verificato quasi due giorni prima del crash, e l'unico modo per assicurarsi che le copie precedenti non fossero corrotte era avviare un controllo che avrebbe richiesto 36 ore.

I gruppi IT dovettero poi aggiornare il sistema di produzione: far girare nuovamente i file di log delle transazioni fino ad arrivare al momento del crash e processare numerose giornate di operazioni che si erano accumulate fino a quel momento. I responsabili dovettero riunirsi di continuo per prendere decisioni ad hoc su quali processi servivano subito e quali potevano essere temporaneamente posticipati per guadagnare tempo.

Arrivati a venerdì, i team di lavoro avevano recuperato quasi tutto. Tuttavia, non erano ancora sicuri che la banca potesse aprire al pubblico il lunedì seguente. I trader avrebbero potuto riprendere le operazioni, ma si temeva che fosse troppo rischioso andare avanti per più di cinque giorni senza accurate riconciliazioni bancarie. Le autorità competenti erano state allertate.

Anche se c'è un lieto fine (le operazioni di recupero furono terminate entro il week-end), la banca andò pericolosamente vicino al dover sospendere il trading per quello che si rivelò un minuscolo conflitto tra un bug di un pacchetto software e l'applicazione di gestione del server: qualcosa che nessuno avrebbe potuto prevedere, né tantomeno testare in anticipo. Le perdite furono modeste, ma se il danno si fosse verificato in un altro momento, per esempio alla fine dell'anno – periodo cruciale per il trading, quando gli investitori riordinano i propri portafogli – l'incidente sarebbe potuto costare alla banca milioni di dollari, scatenando le ispezioni degli organi di controllo e danneggiando la sua reputazione.

In breve: anche se la banca aveva rispettato scrupolosamente le politiche interne e le normative esterne, ed era preparata a fronteggiare la perdita di una sede o un sito o il guasto di un importante componente hardware, non era pronta a riprendersi da un problema che non era citato in nessun manuale standard di operazioni.

Luci puntate sul ripristino
E' stata un'emergenza isolata? Assolutamente no. I disastri sfiorati come questo capitano in continuazione nella gestione IT. Non molto tempo fa, le transazioni nei punti vendita di una catena internazionale di negozi rimasero congelate per 18 ore in periodo di shopping natalizio, a causa di un bug mai identificato nel software che gestiva il network storage dei dati. Neanche la migliore delle preparazioni avrebbe potuto evitare questa crisi. E il punto è proprio questo: la maggior parte delle aziende resta esposta a gravi interruzioni di servizi IT chiave per motivi che non possono mai prevedere adeguatamente.

Non importa che la vostra squadra IT analizzi i rischi con procedure di routine e utilizzi protocolli di test. Non conta che siano stati approntati piani infallibili per fronteggiare un disastro. E non importa che abbiate decentralizzato le maggiori strutture IT e speso milioni in siti remoti, o che aggiorniate ogni anno i vostri piani di business continuity. Oggi, l'unica strada sicura è essere coscienti che prima o poi, durante la vostra vita lavorativa, il peggio succederà.

Naturalmente, la prevenzione è più che mai essenziale. Ora, però, i CEO e i manager IT devono rimboccarsi le maniche e studiare delle strategie intelligenti di disaster recovery. Il centro di gravità degli sforzi di business continuity deve spostarsi rapidamente verso la possibilità di garantire una recovery affidabile dopo qualsiasi tipo di possibile evento.

Un divario crescente
Negli ultimi anni, nella maggior parte delle grandi aziende le attività di pianificazione del disaster recovery e della business continuity hanno ottenuto maggiore visibilità e fondi. Calamità come l'uragano Katrina e gli attacchi dell'11 settembre negli Stati Uniti, l'ondata di caldo killer in Europa e lo tsunami in Indonesia hanno imposto migliori strategie di prevenzione alle aziende di qualsiasi dimensione. Queste società ora suddividono il rischio su reti geograficamente distribuite e flessibili di centri di elaborazione dati, call center, e impianti di operations e produzione (su questo tema, si veda l'articolo "Business a rischio" Outlook ed. italiana, n.1 - 2008).

Inoltre, intraprendono una revisione annuale strutturata e ampia dei processi critici di business, per comprendere come e in quale misura i processi siano vulnerabili rispetto a una serie di scenari di crisi. Preparano degli interventi per mitigare i rischi più gravi, sviluppano piani di continuità o, se necessario, di ripristino delle operazioni di business.

Mai come ora, la discussione su valutazione dell'impatto, attenuazione dei rischi, business continuity e recupero dei dati inizia fin dalle prime fasi della progettazione di nuovi processi, sistemi o sedi operative. Molte grandi aziende testano regolarmente i loro piani e centri di back-up. E quasi tutte ora hanno un chief risk officer, o altra figura preposta alla gestione dei rischi aziendali, con dipendenti o consulenti che definiscono gli standard, ne controllano l'osservanza e fanno rapporto agli stakeholder.

Per quanto queste pratiche siano migliorate, non bastano più. C'è un divario crescente tra ciò che è e ciò che dovrebbe essere.

Molte grandi aziende sono ormai così dipendenti da una perfetta capacità operativa dei loro sistemi da diventare pericolosamente vulnerabili a danni sostanziali, talvolta irreparabili, alle loro attività. Inoltre, hanno permesso a degli organismi di controllo, o ad altri stakeholder, di indirizzare gli sforzi per tutelare la continuità di business verso questo o quel sito di elaborazione, o componente. Nell'ansia di conformarsi, i leader aziendali hanno perso di vista gli altri rischi a cui vanno incontro: la miriade di piccoli incidenti che creano grosse perdite quando i server si arrestano, o i software decentrati si bloccano.

Quando il disastro colpisce, come inevitabilmente accade, non ha importanza che cosa ha causato il problema. Ciò che conta – e conta molto per la carriera di un CIO – è quanto velocemente e con quanta affidabilità si riesce a risolvere il problema, e che i danni per l'azienda derivanti dall'inattività del sistema siano limitati.

La guerra più recente
Il problema si compone di due parti. La prima è che molti addetti IT che hanno il compito di assicurare la business continuity tendono a reagire all'ultimo problema che si è verificato – combattono, cioè, la guerra più recente – anziché immaginare e pianificare attivamente per mettere in atto un recupero rapido dopo il prossimo conflitto software o attacco alla sicurezza.

Una grande società di servizi finanziari sta organizzando un reparto dedicato ai rischi informatici: si tratta di una mossa difensiva che l'aiuterà a conformarsi agli standard di business continuity richiesti dalle autorità, ma che non la aiuterà più di tanto a riprendersi quando si verificherà un problema di rilevanti proporzioni. I dirigenti stanno raccogliendo dati per gestire le aspettative e per prepararsi all'evento, ma niente di più.

La seconda parte del problema è che quando gli informatici pianificano e testano le procedure di disaster recovery, propendono per le catastrofi immediate e ovvie, gli scenari del tipo "perdita di un intero edificio", che toccano a un livello molto umano (e molto comprensibile) dirigenti e autorità. Tuttavia, molti dei problemi reali, come evidenziato dalla precedente storia della banca e del bug imprevisto nel software, sono molto meno spettacolari, per lo meno all'inizio (vedi Fig.1). E anche se questi problemi non necessariamente paralizzeranno intere aziende e non raggiungeranno proporzioni di crisi dalla sera alla mattina, possono danneggiare la performance IT al punto da avere un impatto sostanziale sul business tra cui, non da ultimo, disturbare considerevolmente le attività gestionali.

Il danno può iniziare in modo impercettibile, e non necessariamente a causa del guasto di un componente informatico. Recentemente, l'eccezionale espansione di un provider di telecomunicazioni leader nel settore ha impressionato gli investitori, ma a costo di un'eccessiva sollecitazione di alcune aree di business. In particolare, l'architettura dei sistemi aziendali era stata messa sotto pressione e le interruzioni non pianificate avevano raggiunto livelli allarmanti. Alcuni data center lavoravano al 99% della loro capacità totale, e un back-up su otto non riusciva. Il personale IT rispondeva sempre più in ritardo ai messaggi di allerta del sistema. Inoltre, il "tempo in rosso", quando l'inoperatività dei sistemi coinvolgeva direttamente i clienti, era pericolosamente alto.

Per fortuna si trattava di problemi risolvibili. Il punto, però, è che erano comparsi all'improvviso e apparentemente dal nulla.

Che la causa scatenante sia piccola e graduale o significativa e improvvisa, per i leader aziendali il messaggio non cambia: spesso il personale IT non riesce a erogare i livelli di continuità di business per cui si è impegnato. Potrà magari mantenere le promesse di recupero per i guasti hardware, ma non per i problemi software. In sostanza, sta dicendo ai dirigenti: "Fidatevi di noi".

Rischi in aumento
Non aspettatevi che queste minacce diminuiscano nel prossimo futuro. Anzi, le probabilità di interruzione del servizio nei sistemi IT sono in aumento. Perché? Perché in molti casi i professionisti chiave dello staff IT sono vicini al pensionamento, i sistemi legacy pieni di patch sono ancora in piena attività, e le nuove architetture (come le Service-Oriented Architecture, o SOA), anche se promettono una migliore efficacia nello sviluppo dei sistemi, sono intrinsecamente complesse e richiedono molti "strati" di nuovo software.

I partecipanti a una recente conferenza di manager IT hanno sottolineato che entro il 2015 quasi il 20% del loro personale avrà 55 anni o più – mentre negli anni Novanta era inferiore all'11%. Sostituire i membri dello staff non risolverà il problema: con il pensionamento dei baby boomer, un patrimonio decennale di conoscenze di business e sulle applicazioni uscirà dalla porta insieme a loro.

Allo stesso tempo, molte aziende spendono l'80% circa dei loro budget IT per mantenere operative le applicazioni esistenti e i loro componenti di elaborazione, lasciando ben poche risorse per i nuovi progetti di sviluppo. E i reparti IT stanno rapidamente automatizzando molti dei loro processi di supporto interno, aggravando il fardello dell'affidabilità dei sistemi ed esponendo le aziende alla probabilità che a risolvere i problemi non ci sia più nessuno con un'esperienza abbastanza ampia e approfondita.

Le cose si fanno anche più complesse quando quelle che una volta erano applicazioni monolitiche, che supportavano un unico processo di business, ora sono tipicamente combinazioni stratificate di pacchetti e applicazioni custom, spesso sviluppati da molti fornitori diversi. Ormai il punto di ebollizione si avvicina, dato che le architetture come le SOA stanno guadagnando terreno, aumentando la probabilità che compaiano dei bug nei software e che si verifichino interazioni timing-specific tra software che neanche i migliori test engineer potrebbero mai essere in grado di riprodurre, e che in qualche caso potrebbero anche non accadere mai più.

A cosa porta questa convergenza di fattori? Più downtime nel vostro futuro, e meno probabilità di capire rapidamente che cosa l'ha causato. Se ora i CEO non fanno domande scomode su questi problemi ai loro responsabili IT, presto potrebbe giungere il momento in cui saranno gli azionisti e il CdA a farle a loro (vedi Box 1)

Una nuova mentalità
Alcune aziende, nel tentativo di affrontare questo problema, stanno sperimentando nuovi approcci al recovery. Lavorando con loro, Accenture ha scoperto sette punti critici comuni a tutti questi approcci. Ognuno di essi richiede ai manager IT un cambio di mentalità, ma non un importante investimento di capitale. Tutti insieme, costituiscono un utile punto di partenza per una più dettagliata strategia e azione di business continuity.

1. Iniziate a parlare di valore del business – E di rischi di business.
Osserviamo in modo consistente una riluttanza diffusa a parlare dei rischi che corre il valore del business, a immaginare (se non proprio identificare) quali clienti sarebbero coinvolti nel caso di un rallentamento o guasto del sistema, e in che modo. Un po' come la gente in generale evita di parlare troppo in dettaglio della morte, il personale IT in particolare si sente a disagio nel chiedere agli utenti business che cosa perderebbero se determinati processi IT fossero non disponibili o gravemente compromessi.

Questo argomento non può essere un tabù. Qualsiasi strategia di recovery deve essere basata sulle risorse richieste, costi compresi (vedi Box 2). La velocità con cui le operazioni di business possono essere ripristinate, sia dall'interno che con l'aiuto di terzi, è direttamente correlata alla volontà di destinare risorse a una specifica strategia di recovery (vedi Fig.2).

2. Fate più "giochi di guerra".
Quando la banca citata all'inizio del nostro articolo ha individuato il problema e ripristinato il database, ha dovuto escogitare un modo per elaborare rapidamente le transazioni di diversi giorni. Se il personale IT avesse fatto in precedenza una simulazione di ripristino per quel problema di archiviazione – indipendentemente dalla causa - probabilmente non avrebbe dovuto prendere decisioni ad hoc, svegliando i dirigenti nel cuore della notte e contattando fornitori dall'altra parte del mondo.

In gran parte delle organizzazioni, la pianificazione tramite scenari è ancora arretrata. Nella banca che abbiamo descritto, gli esperti di tecnologia sapevano che i database avevano un rischio di danneggiarsi statisticamente basso e si sentivano tranquilli perché avevano costruito un buon sistema di back-up. Durante l'evento, però, hanno scoperto di non essere abbastanza preparati per gestire il recupero, perché non avevano mai simulato quel particolare scenario. Di conseguenza, poiché complesse decisioni di business che avrebbero potuto essere prese in anticipo non erano invece state prese, il ripristino ha richiesto un tempo molto più lungo di quanto immaginato.

Fare dei giochi di guerra, ovvero delle simulazioni di scenari di recupero, costa relativamente poco. Aiutano a rompere la mentalità della condiscendenza, e rendono visibile il valore della pianificazione e della gestione del ripristino. Questo aiuta i leader IT a creare una cultura di responsabilità personale, in cui non esiste lo scaricabarile. I giochi di guerra aiutano anche a chiarire i ruoli, le responsabilità e le catene di comando. Inoltre, aiutano a rimuovere le sanzioni sociali per coloro che portano cattive notizie.

L'obiettivo di ogni simulazione dovrebbe essere il ripristino più veloce e affidabile dal peggior danno possibile: una rapida ripresa delle normali operazioni con il minor impatto possibile su clienti, guadagni, costi e tempo. Notate l'enfasi sull'affidabilità: è meglio prevedere un ripristino affidabile da qualsiasi possibile danno in un giorno, piuttosto che pianificare un ripristino in quattro ore, ma solo per un sottoinsieme di possibili cause.

3. Siate sempre pronti ad analizzare i fatti.
I gruppi di professionisti IT dovrebbero disporre di processi per esaminare in modo approfondito gli eventi ogni volta che un'azienda importante sfiora il disastro. Solo analizzando i problemi nei sistemi altrui, oltre che nei propri, si possono cogliere le lezioni più importanti, e catalogarle. Per effettuare questa raccolta di conoscenze. i gruppi IT dovrebbero avere ruoli di leadership ben definiti. E, idealmente, dovrebbero anche avere accesso a meccanismi di scambio di conoscenze per integrare informazioni esterne e prospettive di terze parti.

4. Nominate un ombudsman per i rischi IT.
Anche se è importante avere un chief risk officer, o qualcuno che abbia una responsabilità sui rischi a livello dirigenziale, secondo alcune organizzazioni vale anche la pena di considerare un ruolo di ombudsman per i rischi IT: una figura dirigenziale rispettata, con cui lo staff IT possa esprimere le proprie preoccupazioni senza timore di esporsi personalmente. L'ombudsman, oltre a individuare i problemi senza legami o finalità occulti, deve anche essere un tecnologo esperto, che conosce profondamente l'intera architettura IT dell'azienda.

L'ombudsman deve essere la figura di riferimento per la filosofia di ripristino, con l'obiettivo di mantenere il valore del business, e non semplicemente essere il manager della business continuity. Questa figura può anche farsi promotore di una diagnosi completa che prepari la strada a un'iniziativa più ampia di gestione del ripristino.

5. Ripensate il concetto di solidità.
La "solidità", in termini di performance del ripristino informatico, non è semplicemente un prodotto della quantità di livelli di back-up. Deve essere considerata anche in termini di disponibilità di forza lavoro e di capacità dei partner: quasi in termini di "biodiversità". Nella sede centrale di una grande società di elaborazione dati per carte di credito, i call center sono stati chiusi dopo un uragano perché il personale non aveva accesso all'acqua potabile. Eppure, dal punto di vista operativo, l'azienda è riuscita a scongiurare l'inattività smistando parte delle chiamate ai propri centri in outsourcing.

6. Non limitatevi alle "medie".
Non è prudente lavorare con medie statistiche, quando si tratta di tempi di reazione o probabilità di downtime. Al cliente non interessano le medie, quando i sistemi sono compromessi da un problema che si verifica nel peggiore dei momenti. Usando le medie, è come se diceste che poiché l'evento è improbabile, è accettabile essere poco preparati. La lezione è questa: i leader IT devono operare all'interno di fasce di rischio, con massimi e minimi ben definiti.

7. Ripristinate tutto l'insieme, non gli elementi isolati.
Abbiamo spesso osservato che l'approccio tipico delle squadre IT dopo il verificarsi un problema è di tentare di ricostruire le capacità di elaborazione un'applicazione per volta, per poi chiedersi perché con questo processo non si riesce mai a ripristinare in tempo il centro di elaborazione dati (il problema si ripropone negli scenari di disaster recovery). Ma ogni applicazione è collegata ad almeno una piattaforma tecnologica e ad applicazioni correlate, spesso integrate. Tutte devono essere identificate e ripristinate in modo che funzionino insieme.

Allargare i propri orizzonti per arrivare a concepire un recupero fatto con intelligenza è una sfida senza fine. Finché i processi di business, le organizzazioni, le applicazioni e le infrastrutture continueranno a crescere e a evolversi, emergeranno sempre nuovi scenari di interruzioni e ripristino. Una strategia di recupero efficace richiede un cambio di mentalità permanente che, dalla semplice condiscendenza e noncuranza del rischio, si sposti verso un più elevato grado di capacità di reazione. Anche se non significa comportarsi come se ogni momento dovesse essere l'ultimo, è necessario essere pronti a percepire ed affrontare i pericoli imminenti ed essere pronti a risolverli, cosa che normalmente non succede a chi non è addetto ai servizi di emergenza.

Un recupero fatto bene presuppone anche che ci siano, o siano in preparazione, i giusti modelli operativi e processi di business coordinati. A meno che non ci siano ruoli designati, e a meno che il personale non sia addestrato e non si eserciti in scenari di ripristino completi, i minuti di downtime si trasformeranno in ore, e le ore in giorni, con la crescente probabilità che ciò si ripercuota sui clienti. E che questi se ne accorgano.

Per un CEO non potrebbe esserci motivo migliore per agire.

Box 1
Tredici domande che i CEO devono porre ai propri CIO
Un solido piano di disaster recovery non deve mancare nell'ordine del giorno di un CdA. Ma il CEO non può dare agli altri membri risposte definitive se prima non ne discute a lungo con il responsabile IT. Ecco alcune delle domande più importanti.

Parliamo dei nostri piani di simulazione delle reazioni e delle nostre attività di addestramento periodico. Quand'è stata l'ultima volta che abbiamo svolto una simulazione di ripristino da disastro informatico su vasta scala?
Che cosa abbiamo imparato dalla simulazione?
Come possiamo imparare dagli errori nella business continuity commessi dagli altri?
In che modo il piano di ripristino può aiutare l'azienda dal punto di vista finanziario?
Le nostre attività di pianificazione del ripristino hanno reso la nostra azienda più resiliente?
In che modo il management può sapere con quanta rapidità stiamo reagendo a un'emergenza?
Che tipo di sistema di monitoraggio degli eventi abbiamo allestito per ricevere segnali precoci che evitino di ricorrere ai piani di emergenza?
Chi è il responsabile per il disaster recovery?
Come possiamo essere sicuri che il nostro personale sia addestrato a reagire efficacemente?
Quali altre risorse per il ripristino abbiamo a disposizione, oltre al nostro staff?
So che siamo preparati per i guasti dell'hardware, ma a che livello siamo preparati per un attacco su ampia scala da virus o malware?
Quali sistemi automatici abbiamo a disposizione per comunicare rapidamente lo stato del problema e iniziare a implementare la reazione?
I nostri piani di ripristino si estendono alle capacità di supporto al business, oltre che alle capacità tecnologiche?

Box 2
Tolleranza al rischio e velocità di ripristino
Lo sviluppo di un piano di ripristino richiede una valutazione accurata dei vari tipi di rischio, oltre che una conoscenza del loro livello di tolleranza e del potenziale impatto sul business. Ci sono quattro fattori pratici da ricordare.

La velocità con cui le operazioni di business possono essere ripristinate, sia dall'interno che con l'aiuto di terzi, è direttamente correlata alla volontà di destinare risorse a una specifica strategia di ripristino.
Una specifica strategia di ripristino dovrebbe essere selezionata in base alle esigenze del business, e non soltanto in base alle capacità tecniche dei produttori, o ai consigli dei fornitori esterni.
Analizzando su un grafico le perdite di business possibili rispetto ai costi del ripristino, il punto di intersezione delle linee non rappresenta necessariamente la strategia più prudente in assoluto. In altre parole, il risultato matematico non è sempre la risposta migliore.
Per supportare la strategia di ripristino scelta bisogna sapere quale risorsa verrà sacrificata: tempo o denaro.

Gli autori
Gil Brodnitz è un senior executive nella divisione Accenture Strategic IT Effectiveness. Da oltre 15 anni, Brodnitz serve clienti dei principali istituti finanziari, concentrandosi sulla creazione di una migliore integrazione e allineamento tra strategia di business e l'IT. È stato direttore dell'e-commerce e CIO di un'importante società di servizi di marketing nel settore farmaceutico.Vive e lavora a Washington D.C.

Gary A. Curtis è condirettore globale di Accenture Technology Consulting. Affianca da oltre 25 anni i dirigenti di numerose banche d'investimento globali, grandi società di comunicazione e aziende hi-tech. È specializzato nella valutazione del valore di business di applicazioni informatiche su larga scala e del portafoglio infrastrutture, nonché nella creazione di programmi per migliorarne il valore nel tempo. Vive a San Francisco e siede nell'Advisory board di varie aziende che sviluppano nuove tecnologie.

Robert Emmel è il direttore globale della divisione Business Continuity Planning di Accenture, e vive a Chicago. Con oltre 20 anni di esperienza in ruoli di supporto e direzione in aziende di vari settori, nel risk management e nei processi operativi e dei servizi informatici, ha partecipato a oltre 80 progetti di recovery planning, 30 progetti di valutazione e miglioramento di centri di elaborazione dati (CED) e numerosi progetti di migrazione o consolidamento di CED. Emmel ha scritto numerosi articoli sul recovery planning, risk management e supporto operativo di CED, pubblicati su diverse riviste di business e informatica.

Link correlati
Podcast: IT Disaster: It's Not a Matter of If—It's a Matter of When
Ascolta Gil Brodnitz di Accenture che discute sul tema del Disaster Recovery e di come i disastri IT siano diventati più frequenti nella situazione economica attuale (in inglese).

Inizio pagina

Scarica l'articolo in PDF (in inglese) [PDF, 215KB]
Supporto PDF

Non chiedetevi se accadrà, ma quando.