La continuità operativa non dipende solo dalla capacità di ripristinare rapidamente sistemi, applicazioni o processi critici dopo un incidente. Un aspetto altrettanto decisivo riguarda quanto lavoro, informazioni o transazioni l’azienda è disposta a perdere nel momento in cui si verifica un’interruzione. In molti casi, infatti, il problema non è tanto quando si torna operativi, ma da quale punto si riparte. Ed è qui che entra in gioco uno degli acronimi più rilevanti per i team IT: RPO, Recovery Point Objective.
L’RPO indica la quantità massima di dati / informazioni, espressa come intervallo di tempo, che un’organizzazione è disposta a perdere a seguito di un’interruzione dei sistemi IT. Un RPO di un’ora, ad esempio, significa che l’azienda accetta di ripristinare i sistemi a uno stato risalente a un’ora prima dell’evento.
Sebbene venga spesso percepito come un parametro tecnico, l’RPO è in realtà una decisione di business, poiché stabilisce il livello di rischio che l’azienda è disposta ad assumersi in termini di perdita di informazioni, impatto operativo e potenziali conseguenze economiche, legali o reputazionali. Non a caso, viene quasi sempre affiancato ad altri indicatori chiave della continuità operativa, come l’RTO (Recovery Time Objective) con cui concorre a definire il perimetro complessivo della resilienza dei processi critici.
Non esiste un valore RPO corretto in termini assoluti. Ogni workload, applicazione e tipologia di dato risponde a logiche differenti che dipendono principalmente da due fattori: la criticità del processo supportato e il quadro normativo di riferimento.
Esistono dati e informazioni che non si possono perdere in nessun caso, nemmeno a fronte di un blocco totale del sistema o del processo. È il caso, ad esempio, delle transazioni dei pagamenti o di flussi finanziari regolati; al contrario, altri ambiti consentono una maggiore flessibilità, come la reportistica interna o informazioni di supporto che, pur essendo importanti, possono tollerare una perdita limitata senza compromettere la continuità del business.
Quando si affronta il tema dell’RPO, la tentazione è puntare a una condizione in cui non si perde nessun dato anche in caso di incidente. In teoria, è l’obiettivo ideale; in pratica, non è quasi mai una scelta neutra né automaticamente corretta.
Garantire un RPO pari a zero significa implementare architetture di replica continua e sincrona dei dati in grado di mantenere allineati ambienti diversi in tempo reale. Questo comporta costi infrastrutturali elevati, maggiore complessità architetturale, vincoli stringenti sulla latenza e, non di rado, un aumento del rischio operativo se la soluzione non è progettata in modo impeccabile. In altri termini, RPO zero significa non potersi mai permettere una perdita di dati, e questo ha un costo elevato.
Il calcolo dell’RPO non dovrebbe mai avvenire in modo astratto. Al contrario, occorre una strategia differenziata, costruita per singolo workload, applicativo o processo, a seconda – come si è visto - del livello di criticità e del contesto normativo.
Il punto di partenza è l’analisi dei processi di business: capire quali attività l’applicazione supporta, quali sarebbero le conseguenze operative, economiche o legali di una perdita di dati e quale arco temporale di rollback è realisticamente accettabile. Di fatto, si esegue una Business Impact Analysis (BIA) per tradurre esigenze di business in requisiti tecnici su cui costruire la soluzione di continuità (backup, data protection, disaster recovery) in grado di minimizzare il rischio.
Si costruisce dunque l’RPO target, che va poi confrontato con l’RPO tecnicamente realizzabile, con l’obiettivo di ottenere un valore magari non perfetto ma sostenibile, coerente con l’architettura e allineato al reale profilo di rischio dell’organizzazione.
Una volta definito l’RPO per i diversi applicativi, dati e/o carichi di lavoro, il passaggio successivo è trasformare quel valore in una soluzione tecnica in grado di garantirlo nel tempo. È qui che l’RPO smette di essere un esercizio concettuale e diventa un tema architetturale e operativo.
Il primo elemento da considerare è il modello di protezione del dato. Backup tradizionali, repliche asincrone o sincrone, siti secondari, architetture active-active: ogni approccio offre livelli di protezione diversi e abilita RPO differenti. Backup periodici possono essere sufficienti per applicativi meno critici, mentre RPO molto spinti richiedono meccanismi di replica continua e ambienti pronti a subentrare in tempi rapidi, con un impatto diretto su complessità e costi.
Un secondo fattore riguarda il perimetro dell’infrastruttura e gli attori coinvolti. Alcune organizzazioni scelgono di gestire tutto internamente, mantenendo il pieno controllo su tecnologie e processi, ma assumendosi anche l’onere della progettazione, della manutenzione e del testing continuo delle soluzioni di continuità. Altre preferiscono affidarsi a provider specializzati che, attraverso la propria infrastruttura, personalizzano ed erogano servizi come Backup as a Service (BaaS) o Disaster Recovery as a Service (DRaaS). In questo modo, le aziende delegano la complessità tecnica al provider e beneficiano sia di piattaforme già strutturate che di competenze dedicate.
È importante ricordare che nessuna scelta è definitiva. Nel tempo possono cambiare i carichi applicativi, il modello di business, i requisiti normativi o il livello di criticità dei processi, rendendo necessario rivedere non solo la soluzione tecnica adottata, ma anche lo stesso valore di RPO.
Per questo, governare l’RPO significa monitorarlo e riesaminarlo periodicamente, testare con continuità i meccanismi di ripristino e verificare che le ipotesi iniziali siano ancora valide, ovvero allineate al contesto reale dell’azienda.