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?

Cos’è il Disaster Recovery

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?

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.

Business Continuity

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.

Disaster Recovery

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.

Le minacce alla continuità aziendale da prevenire con un Disaster Recovery Plan
Minacce alla continuità aziendale

La redazione di questi piani prevede scrupolose analisi e valutazione dei rischi ed è definita da uno standard internazionale: l’ISO 22301.

Lo standard internazionale per la Business Continuity

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;
  • Il Risk Assessment;
  • Il Risk Treatment.

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.

Una griglia di valutazione del rischio
Una griglia di valutazione del rischio

Per una più precisa definizione dei nostri piani di Business Continuity e Disaster Recovery possiamo utilizzare alcuni indici quantitativi:

  • il Recovery Point Objective (RPO);
  • il Recovery Time Objective (RTO);
  • il Total Cost of Owenership (TCO).

È 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?

Cosa sono RPO, RTO e TCO

Alcuni indici che ci aiutano a definire la nostra strategia di recupero:

  • Per Recovery Point Objective si intende il “punto di ripristino” della situazione aziendale. Un momento congelato nel tempo in cui l’operatività aziendale è ad un livello standard ed in cui poter ritornare in sicurezza in caso di incidenti.
  • Per Recovery Time Objective si intende il tempo necessario affinché questa situazione venga effettivamente ripristinata.

Possiamo stabilire questi due parametri in funzione delle nostre esigenze aziendali e dei relativi costi, calcolati con il parametro TCO:

  • Per Total Cost Of Ownership si intende il costo totale dell’infrastruttura adibita al mantenimento del punto di ripristino, ovvero la duplicazione dei dati.

Per essere precisi, quest’ultimo parametro aumenta o diminuisce al variare:

  • Della vicinanza nel tempo del punto di ripristino (RPO);
  • Della velocità con cui si ha bisogno di ripristinare l’operatività (RTO).

Allo scopo di stabilire un TCO funzionale alle nostre esigenze possiamo valutare tre ulteriori parametri: MAO, MTPD ed MBCO.

Cosa sono MAO, MTPD, 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:

  • Il Maximum Acceptable Outage (MAO) definisce il periodo di tempo massimo ritenuto accettabile che può trascorrere in assenza di operatività aziendale.
  • Il Maximum Tolerable Period of Disruption (MTPD) definisce il tempo massimo ritenuto tollerabile che può trascorrere in assenza di operatività aziendale in caso di incidenti.
  • Il Minimum Business Continuity Objective (MBCO) definisce il livello minimo di servizio ritenuto accettabile durante un incidente per il raggiungimento degli obiettivi aziendali.

Quali sono allora i servizi che permettono un efficace piano di disaster recovery?

Disaster Recovery on-premise e in cloud

Possiamo distinguere due tipi di disaster recovery: on-premise e in cloud.

Disaster Recovery on-premise

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.

Confronto tra Disaster Recovery on-premise ed in cloud
Confronto tra Disaster Recovery on-premise ed in cloud

Disaster Recovery in 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.

Cos’è CloudEndure

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 funziona CloudEndure

Uno scherma dell'architettura Disaster Recovery di CloudEndure
L’architettura Disaster Recovery di CloudEndure

Come si evince dall’infografica, la gerarchia di CloudEndure prevede due aree:

  • Sorgente;
  • Target.

Quest’ultima viene poi suddivisa in due ambienti:

  • Staging;
  • Produzione.

Il servizio che si occupa di far comunicare le due aree è il CloudEndure Agent.

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.

L’ambiente di Staging

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.

Confronto tra Staging e Produzione in CloudEndure
Confronto tra Staging e Produzione in CloudEndure

L’ambiente di Produzione

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.

Conclusioni

Grazie ad AWS CloudEndure è possibile mettere in piedi un piano di disaster recovery veloce, automatizzato e conveniente.

Hai bisogno di un AWS Partner  per il setup di CloudEndure? Riempi il form, siamo ansiosi di aiutarti!

CTMobi è AWS Partner

CTMobi AWS Partner

Costruiamo insieme il tuo successo

 

Ascolta l'articolo