Disqus Comments Loading...
Il digitale ha rivoluzionato il nostro modo di vivere e di lavorare, ma a queste grandi novità corrispondono anche nuove sfide che non possono essere ignorate. Imparare a prevenire incidenti ed essere in grado di ritornare velocemente ad una situazione di normalità operativa in casi di errore umano, furto o catastrofe è di fondamentale importanza per le aziende. In questo senso, il cloud computing è il nostro miglior alleato nella definizione di un Disaster Recovery Plan, un piano B che ci mette al riparo da situazioni eccezionali.
Ma cos’è un Disaster Recovery Plan?
Per Disaster Recovery si intende quell’insieme di procedure che ha l’obiettivo di rimettere in moto nel più breve tempo possibile la continuità aziendale, nel caso in cui un evento disastroso la interrompa.
Queste procedure vengono generalmente definite all’interno di un Disaster Recovery Plan (DRP), un documento programmatico che prevede un livello decisionale e di interazione umana soltanto minimo e che è contenuto nel più ampio Business Continuity Plan (BCP).
Qual è la differenza tra Business Continuity e Disaster Recovery?
La differenza tra i due termini è il risultato di un’evoluzione avvenuta nel corso del tempo.
Nei primi anni settanta, in seguito all’adozione delle tecnologie digitali da parte delle grandi organizzazioni, emerse la necessità di mettere al riparo i data center da danni accidentali e disastri. In questo periodo, il termine Disaster Recovery indicava quindi la possibilità di ritornare ad una situazione di normale operatività dopo un’improvvisa interruzione, ed in questo senso era un sinonimo di Business Continuity.
Col passare degli anni ed in seguito alle rapide evoluzioni degli anni novanta, la disciplina della Business Continuity si è differenziata dal Disaster Recovery nel senso di aver ampliato il suo ambito di adozione anche ad imprese non strettamente legate al digitale. Business Continuity significava adesso ripristinare interi processi aziendali e non più soltanto sistemi informatici e data center.
Precisato questo, possiamo definire meglio i due termini in relazione all’attuale panorama.
La Business Continuity è un insieme di procedure atte a gestire eventi di qualsiasi dimensione in grado influenzare negativamente la normale continuità aziendale, ad esempio, la sostituzione di figure chiave all’interno dell’azienda. Spesso capita infatti che alcuni ruoli chiave vengano coperti da personale difficilmente sostituibile e la cui improvvisa assenza può causare interruzioni o rallentamenti nell’operatività aziendale.
Gli executive delle aziende devono dunque tenere conto anche di eventi di questo livello, ed a questo proposito il Business Continuity Plan è un documento ormai divenuto essenziale, quando non obbligatorio, per le imprese.
Il Disaster Recovery è un insieme di procedure atte a gestire eventi ad altissimo impatto che rischiano di soffocare il motore aziendale e di comprometterne gravemente la situazione economica, ad esempio, furti, errori umani o catastrofi naturali. In quest’ultima categoria rientrano eventi come l’attentato alle Twin Towers o il terremoto del marzo 2011, che indusse le imprese giapponesi a ripensare le loro tradizionali strategie di protezione in locale portandole in cloud.
Come anticipato sopra, in un Disaster Recovery Plan il livello di interazione umana deve essere il più possibile vicino allo zero, in modo che anche personale non qualificato possa eseguire in tranquillità la procedura prevista dal piano.
La redazione di questi piani prevede scrupolose analisi e valutazione dei rischi ed è definita da uno standard internazionale: l’ISO 22301.
Lo standard internazionale ISO 22301 descrive i requisiti che un’impresa deve soddisfare per garantire la continuità aziendale anche in seguito ad eventi in grado di minarla o interromperla. Questa norma definisce in sostanza un sistema di gestione della continuità aziendale, che nello specifico, prende il nome di Business Continuity Management System.
Possiamo sintetizzare lo standard analizzando tre dei suoi componenti:
La Business Impact Analysis stabilisce quali sono le priorità da tutelare per preservare la continuità aziendale; il Risk Assessment valuta quali sono gli eventi in grado di turbarla; il Risk Treatment definisce cosa fare per evitare le situazioni in grado di comprometterla e come agire per recuperarla nel minor tempo possibile.
Per una più precisa definizione dei nostri piani di Business Continuity e Disaster Recovery possiamo utilizzare alcuni indici quantitativi:
È qui che, come vedremo tra poco, il cloud computing fa la differenza con i tradizionali sistemi di disaster recovery in locale.
Ma cosa sono RPO, RTO e TCO?
Alcuni indici che ci aiutano a definire la nostra strategia di recupero:
Possiamo stabilire questi due parametri in funzione delle nostre esigenze aziendali e dei relativi costi, calcolati con il parametro TCO:
Per essere precisi, quest’ultimo parametro aumenta o diminuisce al variare:
Allo scopo di stabilire un TCO funzionale alle nostre esigenze possiamo valutare tre ulteriori parametri: MAO, MTPD ed MBCO.
Questi tre parametri ci permettono di definire il nostro piano in funzione di livelli minimi di operatività o assenza di operatività ritenuta accettabile o tollerabile. Nello specifico:
Quali sono allora i servizi che permettono un efficace piano di disaster recovery?
Possiamo distinguere due tipi di disaster recovery: on-premise e in cloud.
Le soluzioni di Disaster Recovery on-premise prevedono costose repliche dei nostri server su macchine locali geograficamente distanti, che comportano costi per l’acquisto, la manutenzione e la gestione dell’hardware.
Tenendo in considerazione gli indici di cui abbiamo parlato poco sopra, possiamo dunque affermare che a fronte di RPO vicini nel tempo ed RTO contenuti, le soluzioni on-premise comportano TCO molto elevati.
Infatti, nelle soluzioni on-premise, la replica dell’ambiente di produzione viene fatta catturando degli snapshot ad intervalli regolari, “fotografie” che catturano il sistema in un dato momento.
Al fine di ridurre i costi si ricorre quindi a soluzioni con RPO distanti nel tempo, ad esempio catturando uno snapshot ogni 24, 12 o 6 ore, rinunciando a porzioni significative di dati in caso di incidenti.
Questo sistema, ormai obsoleto, è stato superato dalla tecnologia cloud.
A differenza delle soluzioni on-premise, il cloud computing ci permette di configurare un sistema di Disaster Recovery con RPO vicinissimi nel tempo, RTO minimi ed un TCO molto basso.
Nello specifico, il servizio che permette di ottenere questo genere di prestazioni è CloudEndure, un servizio AWS fornito con l’aiuto di AWS Partner.
Scopriamo cos’è e come funziona.
CloudEndure è un servizio che crea una replica in tempo reale del nostro ambiente di produzione, garantendo RPO inferiori al secondo, RTO di pochi minuti e TCO inferiori del 95% rispetto alle soluzioni on-premise.
Questo vuol dire che se un guasto dovesse mettere fuori uso il nostro sito potremmo recuperarlo nello stato in cui si trovava meno di un secondo prima dell’interruzione e tornare online senza gravi danni in pochissimo tempo.
Ma come funziona CloudEndure?
Come si evince dall’infografica, la gerarchia di CloudEndure prevede due aree:
Quest’ultima viene poi suddivisa in due ambienti:
Il servizio che si occupa di far comunicare le due aree è il CloudEndure Agent.
Il CloudEndure Agent è il software che replica i dati tra l’area Sorgente e l’ambiente di Staging nell’area Target.
Come abbiamo anticipato, l’Agent garantisce un RPO inferiore al secondo. Infatti, a differenza di sistemi basati su snapshot, CloudEndure utilizza un sistema di replica continua ed in tempo reale che non influisce sulle prestazioni della struttura Sorgente.
Arriviamo quindi al segreto del successo di CloudEndure, l’ambiente di Staging.
L’ambiente di Staging utilizza istanze EC2 a basso costo ed è localizzato idealmente in una Region diversa dalla Sorgente per garantire il recupero anche in situazioni catastrofiche.
Come abbiamo anticipato sopra, rispetto ad una replica fisica dei server, lo Staging di CloudEndure ci permette di risparmiare fino al 95% dei costi.
L’area di Staging infatti non è pensata per reggere i carichi di lavoro dell’area Sorgente: è a tutti gli effetti una replica a basse prestazioni dell’infrastruttura originale. Utilizza risorse a basso costo per mantenersi costantemente pronta, in attesa di passare il testimone al più performante ambiente di Produzione in caso di incidenti.
Nel caso in cui un errore umano, un furto, un disastro o qualsiasi altro guasto interrompa il normale funzionamento del nostro sito o della nostra applicazione, l’ambiente di Produzione diventa interamente operativo in pochi minuti.
Come possiamo capire dal grafico, a differenza dell’ambiente di Staging, l’ambiente di Produzione utilizza risorse ad alte prestazioni stabilite da noi in grado di gestire gli stessi carichi dell’area Sorgente.
Ma la caratteristica principale di questo ambiente è che non incide sui costi, perché rimane spento fino al momento esatto in cui si verifica il guasto.
In sostanza, utilizziamo un ambiente (Staging) sottodimensionato a basso costo per replicare il nostro ambiente, ma possiamo mettere in produzione quasi istantaneamente un ambiente (Produzione) ad alte prestazioni capace di reggere i carichi di produzione.
Grazie ad AWS CloudEndure è possibile mettere in piedi un piano di disaster recovery veloce, automatizzato e conveniente.
Costruiamo insieme il tuo successo
Hai bisogno di un AWS Partner per il setup di CloudEndure? Riempi il form, siamo ansiosi di aiutarti!
| Ascolta l'articolo |