Quanti dati possiamo permetterci di perdere in caso di blocco dei sistemi informativi ed entro quanto tempo dobbiamo necessariamente ripartire? Scopriamo insieme cosa sono i parametri RPO e RTO e perché sono imprescindibili nell’elaborazione di un piano di IT Disaster Recovery che tenga in considerazione gli aspetti di business.
Per Disaster Recovery Plan si intende comunemente l’insieme delle attività volte a far ripartire l’operatività dei sistemi informatici e a rendere nuovamente disponibili i dati aziendali a fronte di un evento che ha causato un fermo dei servizi IT e/o la perdita di dati.
Il Disaster Recovery Plan è parte di una più ampia strategia di Data Protection & Availability aziendale, volta ad assicurare integrità, riservatezza e disponibilità dei dati.
Se stai leggendo questo articolo ti è probabilmente già chiaro che il funzionamento dei sistemi informatici e la disponibilità dei dati sono elementi imprescindibili per la tua attività aziendale. Vediamo quindi insieme come affrontare un piano di IT Disaster Recovery che tenga in considerazione gli aspetti di business.
Per prima cosa riflettiamo su quali dati/informazioni ci possiamo permettere di perdere e su quanto tempo possiamo far passare prima che i servizi siano ripristinati. I due fattori su cui stiamo riflettendo hanno un nome: RPO e RTO. Si tratta di due acronimi che significano rispettivamente e Recovery Point Objective (RPO) e Recovery Time Objective (RTO).
Si tratta sicuramente di una tematica tecnica, ma per analizzarla dobbiamo avere una visione globale dell’azienda, sia dal punto di vista dell’infrastruttura informatica, sia dal punto di vista dei processi e dei ruoli.
RTO - RECOVERY TIME OBJECTIVE: COS'É?
Con RTO intendiamo il tempo in cui un servizio può restare fermo o un dato può restare inaccessibile. Ossia quanto tempo ci possono mettere i nostri sistemi a ripartire dopo un “disastro”? Il valore dipenderà dal tipo di dato o servizio.
Se vivessimo in un mondo ideale, senza vincoli tecnici e di budget, diremmo tutti che RPO e RTO dovrebbero essere uguali a zero. Se però ci confrontiamo con la realtà e proviamo ad analizzare le reali esigenze, è evidente che il nostro obiettivo dipenderà dal tipo di business e varierà in funzione del servizio e del dato.
Per poter definire correttamente il nostro RTO è importante analizzare ruoli e processi aziendali, ma facciamo attenzione perché chiedere ai referenti che utilizzano i vari servizi le loro aspettative in termini di RTO potrebbe essere fuorviante. L’approccio più costruttivo è basarsi su dati oggettivi.
Per prima cosa facciamo un elenco di tutti i servizi, sistemi, applicazioni presenti in azienda e capiamo quale funzione svolgono e quali uffici/utenti sarebbero coinvolti da un loro blocco.
Calcoliamo poi l’impatto che un blocco di questi servizi comporterebbe, ovviamente questa analisi va fatta per ogni applicazione/servizio tenendo anche in considerazione l’eventuale stagionalità del nostro business: potrebbero ad esempio esserci particolari periodi dell’anno in cui un servizio è maggiormente strategico.
Ecco alcune domande a cui dobbiamo rispondere su ogni applicazione e su un suo eventuale fermo:
- Nell’applicazione conserviamo dei dati di nostri clienti? Che obblighi abbiamo nei loro confronti?
- Occorre accedervi in tempo reale?
- Ci sono interdipendenze? Quali altri servizi sarebbero colpiti in caso di fermo di questa applicazione?
- Quanto tempo impiego oggi a farla ripartire in caso di evento bloccante?
- Quali conseguenze avrei da un blocco dell'applicazione?
- Perdite finanziarie dirette?
- Un calo del fatturato?
- Un danno alla reputazione aziendale?
- Spese aggiuntive?
- Un blocco della produzione?
Se da questa analisi risulta che un’applicazione è particolarmente strategica, allora il nostro RTO dovrà coincidere con il tempo minimo necessario a ripristinare quest’ultima. Se da questa analisi risulta che tutte le applicazioni hanno un’incidenza simile sul business allora potremo calcolare una media matematica.
Ora confrontiamoci con la realtà e calcoliamo il nostro Recovery Time attuale (Recovery Time Actual -RTA) facendo un test di ripristino.
Se RTO ed RTA non si equivalgono dovremo correre ai ripari!
RPO - RECOVERY POINT OBJECTIVE: COS'É?
Con Recovery Point Objective (RPO) intendiamo la perdita di dati ammissibile.
La nostra situazione attuale (RPA: Recovery Point Actual) potrebbe discostarsi dal nostro obiettivo, ossia dal nostro RPO.
Se la nostra possibilità di ripristino dipende dai backup e questi sono giornalieri, allora il nostro RPA è di 24 ore. Corrisponde al nostro obiettivo?
Ipotizziamo ad esempio che siano le 17:00 e il nostro sistema vada in fiamme. Possiamo permetterci di perdere tutti i dati prodotti a partire dalle 20.00 di ieri sera (orario in cui è stato eseguito il backup giornaliero), quindi 21 ore fa?
Se la risposta è no, allora il nostro RPA e il nostro RPO non coincidono e dovremo porre rimedio. Nel farlo ricordiamoci che mettere in atto un IT Disaster Recovery Plan con un RPO uguale a zero potrebbe essere costoso. Accertiamoci quindi che sia realmente necessario.
Procediamo per gradi effettuando prima un’analisi accurata che ci permetta di determinare un RPO realistico. Proprio come abbiamo fatto per determinare il nostro RTO, anche nel calcolo del nostro RPO analizziamo le diverse tipologie di dato della nostra azienda e per ognuna chiediamoci se una perdita di dati nel corso della giornata può essere ragionevolmente neutralizzata dal backup del giorno prima. Quest’analisi ci aiuterà a capire quanto il nostro RPO debba realmente essere vicino allo zero.
BUSINESS IMPACT ANALYSIS: CARATTERISTICHE ED OBIETTIVI
Abbiamo già avuto modo di riflettere sulla correlazione tra business e IT in termini di dati e servizi e abbiamo visto come procedere nel definire RTO e RPO.
Se abbiamo la possibilità di estendere la visione ad un campo aziendale più ampio, coinvolgere tutti i reparti nell’esecuzione di una Business Impact Analysis è sicuramente un modo più corretto di procedere, che vede l’inserimento del nostro piano di IT Disaster Recovery all’interno di una strategia più completa di Business Continuity aziendale.continui
La BIA ci permette infatti di:
- valutare la criticità di ogni processo e il contributo che offre all'interno dell'organizzazione aziendale;
- stimare il tempo di sopravvivenza dell’organizzazione in caso di fermo di ciascun processo/applicazione;
- calcolare l’esposizione economica sostenuta annualmente dall’organizzazione per ciascun processo;
- identificare le funzioni organizzative includendo informazioni e risorse;
- verificare le interdipendenze (interne ed esterne all’organizzazione);
- definire degli obiettivi delle attività di recovery e delle finestre temporali di disponibilità (RTO e RPO);
- condividere il dettaglio delle evidenze e delle risultanze di RTO/RTA ed RPO/RPA con l’azienda e il Management.
Un’analisi così strutturata ci permette di sensibilizzare il management aziendale e di portare il nostro IT Disaster Recovery Plan ad un livello più strategico dell’organizzazione.
Autore dell'articolo:
Sara Mattioli
LinkedIn
Sono in Errevi System dal 2007, tanti anni in cui l'azienda e con lei il mio ruolo sono stati in continua evoluzione, ma una cosa è rimasta invariata: la sensazione di essere parte di un progetto da cui si possono attingere competenze utilissime per tante realtà, unita al senso di urgenza derivante dal desiderio di diffonderle. Con questo blog vogliamo fare proprio questo: condividere competenze, esperienze, stimolare la riflessione e il confronto per supportare le aziende che vorranno seguirci.
