Articoli

Disaster Recovery: miniguida a un approccio corretto

Il Disaster Recovery è quella procedura di emergenza che, in generale, permette di riattivare i servizi It di una azienda dopo un evento che ne ha determinato il blocco. La procedura deve essere applicabile indipendentemente dal tipo di evento e dall’obiettivo: il salvataggio di documenti cartacei dopo un incendio, la disinfestazione dopo una contaminazione o il riavvio di sistemi It e applicativi a causa di un malfunzionamento improvviso.

L’utilizzo sempre più diffuso della cloud come ambiente che ospita strutture e servizi It a cui l’azienda accede da remoto, ha comportato una forte richiesta di servizi di gestione dell’infrastruttura. Si tratta dei cosiddetti Managed Services che, nei loro diversi campi d’azione, comprendono la maggior parte dell’offerta di ITNet.

All’interno di un progetto di Managed Services la componente di Disaster Recovery è certamente la più importante. È fondamentale concordare insieme all’azienda cliente una procedura completa che preveda risorse, tempi e modi per ogni singola azione da intraprendere.

Nella fase preliminare del progetto si devono identificare il maggior numero di cause ed effetti possibili, calcolare la probabilità degli eventi, i tempi di ripristino e l’impatto economico degli effetti del fermo sul business. Importante, ancora, costruire una squadra interna che sia investita delle responsabilità della corretta implementazione del piano.

È altresì importante comprendere subito se l’azienda abbia bisogno di un piano di Disaster Recovery o di Business Continuity. Nel secondo caso, il Managed Services Provider può prevedere l’intervento di una infrastruttura It completa alternativa a tempo zero d’attesa.

Considerando una visione macro del progetto, il Managed Services Provider lavorerà su tre ambiti principali: data replication, connettività e infrastruttura. In particolare, negli ultimi tempi cresce l’esigenza della disponibilità di una struttura fisica in cui ospitare le risorse umane dell’azienda nella fase di gestione del disastro. La disponibilità degli spazi, dunque, diventa un plus da considerare in fase di scelta di un fornitore di servizi di Disaster Recovery.

IT.Net ha definito due check list dedicate all’azienda che si trova ad affrontare la definizione di un piano di Disaster Recovery. La prima comprende le riflessioni da porsi internamente, la seconda indica le domande da fare al fornitore in fase di selezione.

Le riflessioni preliminari:

1. Quali servizi fornisco ai miei dipendenti (accesso alla posta elettronica, utilizzo del software gestionale, accesso a risorse condivise)?
2. Attraverso quali servizi It interagisco con clienti, partner e fornitori (sito di eCommerce, eProcurement ecc.)?
3. Come sono distribuite le infrastrutture It?
4. Che Sla (Service Level Agreement) ho attivo con il mio fornitore di connettività, di servizi in outsourcing o in cloud?
5. Quanti e quali dati e risorse sono disposto a perdere in caso di disastro?
6. Quali sono i servizi il cui blocco porterebbe una perdita economica e di che entità?
7. Ho mai analizzato le capacità di backup e recovery dei dati del mio attuale fornitore It (in caso siano delocalizzati)?
8. Negli ultimi 5 anni che tipo di blocco ha subìto la mia infrastruttura It?
9. È corretto che il capo dei sistemi informatici debba essere considerato l’unico responsabile in caso di blocco dei sistemi?
10. Sono sicuro di non avere responsabilità nei confronti di nessuna entità esterna in caso di blocco dei miei sistemi It?

Le domande da fare al fornitore It:

1. Che esperienza ha in gestione dei progetti di Disaster Recovery (casi di successo)?
2. Su quali mercati verticali e su quali dimensioni aziendali?
3. Che tipo di infrastruttura hardware mi propone?
4. Che soluzioni software adotterebbe nel mio caso e perché?
5. Che tipo di Sla (Service Level Agreement) possiamo concordare?
6. Dove sono dislocati i suoi data center?
7. In che modo è ridondata la sua connettività?
8. Che tipo di supporto mi fornirebbe durante la fase di recovery?
9. Quanto dura l’implementazione del suo progetto di Disaster Recovery e quanto impatterebbe sull’operatività aziendale?
10. Quali sono le sue caratteristiche distintive rispetto alla concorrenza?

Disastery recovery: cosa sono RTO e RPO

Recentemente una scimmia ha fatto notizia, meritando addirittura una pagina sul sito della Cnn. La Kenya Electricity Generating Company proprietaria di una centrale elettrica che approvvigiona circa l’80% del fabbisogno del paese africano, ha reso noto che il black out totale che ha coinvolto l’intero stato – quasi 5 milioni tra abitazioni e aziende – è stato provocato da una scimmia che si era introdotta all’interno della centrale.

La scimmia è sopravvissuta, ma nulla si sa sulla perdita dei dati che un evento simile possa aver provocato alle strutture informatiche delle aziende coinvolte. Il black out è durato da 15 minuti fino a 3 ore a seconda delle zone.

La notizia fa capire come un danno rilevante a un’azienda non sempre debba essere imputato a una catastrofe naturale, o a un evento di proporzioni notevoli e, inoltre, pone l’accento sul fatto che un’interruzione, seppur breve, può provocare danni irreparabili ai dati di un’azienda.

Uno Sla (Service Level Agreement) relativo a un managed service non prevedere ogni tipo di eventualità, piuttosto si ragiona sulle garanzie da dare in caso di interruzione, qualsiasi essa sia e sui tempi di ripristino.

Molto semplicemente, l’azienda cliente pagherà una cifra più o meno alta a seconda di quanto tempo si possa permettere di tenere inattivo un servizio (business continuity) o di quanti dati si possa permettere di perdere durante un black out dello storage.

Un piano di Disaster Recovery, dunque, non deve essere progettato considerando i possibili eventi ma, piuttosto, ragionando su cosa ci si può permettere di perdere in caso di interruzione momentanea e su quanto tempo possa passare prima di ripristinare i servizi.

È molto importante sottolineare che non si può ragionare in questi termini se non si ha una fotografia precisa dell’infrastruttura informatica aziendale, hardware e software, e una precisa ripartizione dei ruoli, garantita dal fornitore del servizio, in caso di intervento.

In questo contesto entrano in gioco due parametri fondamentali: il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO).

RTO e RPO: su quale puntare

Diciamo subito che non si tratta di due caratteristiche che si escludono vicendevolmente, perché sono diverse, si applicano a ecosistemi diversi e possono aver senso per business e mercati diversi.

L’RPO definisce la perdita di dati ammissibile. Per esempio, un’azienda che concentra la sua attività in orario standard, che non ha una produzione h24, e che subisce una perdita dei dati di notte, dopo l’ultimo backup impostato dal fornitore, probabilmente non avrà conseguenze gravi dal danno.

Ripristinare l’ultimo backup permetterà all’azienda di tornare operativa (quasi) come se niente fosse.

Se, invece, il flusso di dati da memorizzare è continuo, 24×7 365 giorni all’anno, pensiamo per esempio a una realtà come Visa, allora il cliente chiederà al suo fornitore di servizi gestiti una certa business continuity perché un’interruzione equivale a una notevole perdita economica.

L’RTO, invece, considera il tempo come parametro. Molto semplicisticamente ragiona sulla continuità di un certo servizio, per esempio un servizio applicativo, sul tempo che ci si può permettere che passi da un’interruzione del servizio alla sua ripresa. Anche in questo caso molto dipende dall’attività dell’azienda, i servizi bancari, ancora una volta chiedono un RTO vicino a zero.

Quanto tempo ci si può permettere di avere un servizio bloccato? È questa la domanda che il fornitore di managed services vi farà durante la fase di progettazione del servizio di disaster recovery. Sarà la sua struttura a garantire la ripresa a seguito di un danno.

Insomma, per avere un’idea molto semplice del concetto alla base di RPO e RTO, si può pensare a un Pc, un tablet o uno smartphone e a quando il sistema operativo chiede ogni quanto effettuare il backup dei dati in cloud, Se si rompe il tablet, perderemo i dati memorizzati sullo stesso dal momento dell’ultimo backup.

ITnet è un Internet Service Provider che può contare su tre data center tra Milano e Roma, l’accesso a due backbone distinti, uno di Telecom Italia e uno di Wind e allo snodo Milan Internet eXchange (MIX), un Toc – una centrale di controllo competente e attrezzata – operativo 24x7x365 e una serie di servizi best-in-class che vanno dalle reti private (Vpn) ai firewall di ultima generazione, dai servizi cloud alla configurazione e il monitoraggio dei servizi sui server con funzionalità avanzate di Disaster Recovery e Business Continuity.