Disaster recovery 2.0, l’evoluzione guarda in faccia costi e benefici

Big DataCloudCloud managementData storage

Uno spaccato ‘storico’ dell’evoluzione del disaster recovery passando per la business continuity. Evoluzioni nel cloud e nel business ‘Always on’ commentati da Alfredo Nulli, Emea Cloud Architect di Pure Storage

Una delle maggiori sfide tecnologiche per le aziende, indipendentemente dal settore di business, è il blackout del sistema informatico; ciò non sorprende se si pensa che l’81% di esse dichiara una perdita media di 300 mila dollari per un’ora di downtime. Alcune ricerche stimano inoltre che l’interruzione improvvisa di corrente rappresenti il terzo maggiore rischio di fermo aziendale. Nel 2017 abbiamo potuto osservare i reali effetti del downtime, quando i clienti di alcune grandi banche del Regno Unito hanno avuto problemi tecnici nell’accedere ai loro conti e molti pagamenti non sono stati finalizzati. Al di là dell’impatto nell’immediato, i danni maggiori sono stati rilevati nel lungo periodo, nell’ambito della reputazione, con un calo di fiducia da parte dei clienti. Ristabilire il legame fiduciario con la propria clientela può richiedere anche anni di lavoro da parte di una banca.

Negli anni ‘70, quando venne creata la figura dei responsabili dei data center, questi manager intuirono subito quanto i computer sarebbero diventati vitali per le aziende. Nacque così l’idea del “disaster recovery”, una specie di assicurazione nel caso applicazioni, database e componenti dello storage o del network non fossero più stati disponibili.

In quegli anni, capitava spesso che arrivassero messaggi dal dipartimento informatico per comunicare ad esempio che le email non sarebbero state disponibili per 3 ore, il tempo necessario a ripristinare la corrente; o che il database dei clienti non sarebbe stato accessibile per un giorno o per estendere la capacità di archiviazione. Con gli sviluppi dell’informatica negli anni ‘90 e l’inizio dell’era di internet, la connettività ai sistemi IT e la dipendenza delle aziende e di tutta la società da essi è cresciuta enormemente.

Alfredo Nulli

Con lo sviluppo progressivo della capacità dei computer di elaborare i dati in tempo reale, non solo di processarli in batch, divenne sempre più chiaro che non ci si poteva più permettere interruzioni di servizio. Mentre le grandi catastrofi mondiali erano causate da terremoti, inondazioni e calamità naturali, i downtime dei sistemi IT erano più che altro legati a problemi con le utility, agli aggiornamenti tecnologici e all’errore umano.

Si delinearono così due ambiti distinti ma affini: la business continuity (BC), per continuare a erogare beni e servizi in caso d’incidente, e il disaster recovery (DR), ovvero la capacità di ripristinare l’operatività di un ambiente informatico in seguito al verificarsi di un problema.

La mancanza di soluzioni praticabili determinò una situazione per cui, nei primi anni ‘90, la connessione continua a banda larga era ancora un problema. I responsabili IT costruivano repliche degli ambienti informatici, come sistemi ridondanti in aggiunta all’infrastruttura di supporto dei sistemi locali. Questa scelta non era solo legata a esigenze di business; le autorità avevano disposto che le aziende operanti in settori chiave, come i servizi finanziari, prevedessero piani d’emergenza all’interno del proprio ambiente informatico. Le procedure per ripristinare i sistemi dovevano essere definite, condivise all’interno dell’azienda e, soprattutto attuate.

Fu così che il disaster recovery divenne un business molto profittevole, con esiti evidenti sul budget IT. La pianificazione del DR restava legata a parametri di Service Level Agreement che includevano Recovery Point e Recovery Time Objective e tracciavano componenti specifici dell’infrastruttura informatica.

Nonostante queste cautele, in caso di emergenza le aziende provavano quasi sempre a “mettere una pezza” invece che seguire la procedura completa di disaster recovery. Anche qualora avessero condotto con successo un test per il DR, le implicazioni di un failover per l’ecosistema informatico erano tali per cui le procedure di disaster recovery venivano viste come l’ultima possibilità, data la difficoltà di ripristinare il sistema dopo che il problema era stato risolto. Il dilemma era tra “fare o non fare”, e ciò comportava ritardi nella risoluzione delle criticità.

La situazione rimase invariata fino all’avvento del cloud e del business “Always on”, che hanno portato ad enfatizzare l’importanza di poter accedere in tempo reale ai dati.

Il disaster recovery fatto con gli strumenti tradizionali, in particolare il recupero dei dati in caso di emergenza, con i costi e i ritardi che questo comporta, è un problema per quasi tutte le aziende. Oggi è impensabile continuare a usare tecniche di recovery ormai superate, quando il mondo richiede una business continuity praticamente illimitata. Non c’è ragione per cui le aziende dovrebbero pagare per avere sistemi totalmente ridondanti che vengono usati poco, specialmente se si considera che è possibile tagliare i costi se si abbandona l’approccio del disaster recovery per adottarne invece uno di business continuity. Perché sprecare tempo, denaro e risorse per mantenere processi rigidi di recupero dati in caso di emergenza, quando esistono oggi tecniche più moderne, agili e dinamiche?

Le aziende dovrebbero cercare soluzioni efficaci che permettano loro di adottare un approccio corretto alla business continuity. Attraverso la replica sincrona, i dati vengono resi disponibili in due ambienti simultaneamente, con il vantaggio di poter creare dataset multipli distribuiti. Anche se uno di questi ambienti dovesse arrestarsi, non si avrebbe alcun downtime. Il risultato è una user experience unica, abilitata da processi distribuiti che re-instradano automaticamente il traffico in caso di incidente. Le nozioni di Recovery Point Objective (RPO) e Recovery Time Objective (RTO), quindi, non sono più soltanto materia da CIO.

Una volta implementato questo approccio, gli IT manager non dovranno far altro che confermare che tutte le istanze siano ancora online e in vigore – è l’unica cosa che serve attualmente per il disaster recovery abilitato dal nuovo paradigma tecnologico.

a cura di Alfredo Nulli, Emea Cloud Architect di Pure Storage

Autore
Scopri di più 
Scopri di più