Come definire RTO e RPO per un’applicazione aziendale: guida pratica alla pianificazione

RTO e RPO rispondono a due diverse domande sul ripristino

L’obiettivo di tempo di ripristino (RTO) indica per quanto tempo un sistema o un processo aziendale può restare indisponibile prima che l’impatto diventi inaccettabile. L’obiettivo di punto di ripristino (RPO) indica quanti dati recenti l’azienda può permettersi di perdere, espresso come intervallo di tempo.

Immagina che un’applicazione smetta di funzionare dopo che il backup ripristinabile più recente è stato eseguito la sera precedente. L’RPO descrive la quantità di lavoro inserita dopo quel punto di ripristino che potrebbe andare persa. L’RTO descrive per quanto tempo l’azienda può tollerare che l’applicazione resti indisponibile durante il ripristino, fino a quando non torna utilizzabile.

I due obiettivi sono collegati, ma l’uno non determina l’altro. Un’azienda potrebbe aver bisogno di ripristinare rapidamente un’applicazione, pur potendo ricreare alcuni dati recenti; oppure potrebbe tollerare un’interruzione più lunga, ma avere pochissima tolleranza per la perdita di transazioni.

Parti dal flusso di lavoro aziendale, non dal server

Prima di discutere gli obiettivi di ripristino, elenca le attività supportate dall’applicazione. Un CRM può supportare le vendite e il servizio clienti; un negozio online può consentire di consultare i prodotti, effettuare ordini e gestire i pagamenti. La domanda importante è che cosa le persone non possono fare quando l’applicazione è indisponibile o i suoi dati non sono aggiornati.

Per ogni flusso di lavoro, individua chi ne subisce le conseguenze, se l’attività si interrompe del tutto e quali alternative sono disponibili. Per esempio, il personale potrebbe annotare temporaneamente le richieste in un altro sistema autorizzato, ma questa soluzione alternativa potrebbe essere lenta, limitata o inadatta per alcuni tipi di dati.

Un buon punto di partenza è una breve valutazione dell’impatto aziendale: individua i processi critici, i sistemi da cui dipendono e le conseguenze di un’interruzione. Coinvolgi le persone che svolgono il lavoro, non soltanto chi è responsabile dell’applicazione.

• Indica il flusso di lavoro e le funzionalità dell’applicazione da cui dipende.
• Individua il personale, i clienti o i partner interessati da un’interruzione.
• Registra eventuali procedure manuali o alternative, i loro limiti e chi può autorizzarne l’uso.
• Annota quali attività aziendali devono riprendere per prime.

Stima l’impatto dell’interruzione nei diversi intervalli di tempo

Non scegliere un RTO solo perché un determinato numero sembra rassicurante. Stima le conseguenze di un’interruzione su più intervalli, ad esempio per un breve periodo, per una parte della giornata lavorativa e per una interruzione più lunga. Gli intervalli appropriati dipendono dal funzionamento dell’azienda.

Considera le vendite perse, gli impegni di servizio non rispettati, il personale impossibilitato a lavorare, le decisioni rinviate e i clienti che potrebbero rivolgersi altrove. Chiediti quando l’impatto complessivo supera ciò che l’azienda è in grado di assorbire. Quel punto aiuta a definire l’obiettivo RTO, ma non dimostra che il ripristino sarà completato entro tale termine.

Distingui il tempo necessario per ripristinare l’accesso tecnico da quello necessario per riprendere il processo aziendale. Un’applicazione può essere in funzione mentre il personale deve ancora verificare i dati, confermare gli accessi o smaltire le attività arretrate.

• Descrivi le conseguenze di un’interruzione per ciascun intervallo di tempo scelto.
• Considera sia le difficoltà operative sia gli effetti finanziari diretti.
• Individua il momento in cui una procedura alternativa non è più accettabile.
• Definisci che cosa significa «ripristinato» per il flusso di lavoro, non soltanto per il server.

Scegli l’RPO valutando quali dati è possibile ricreare

Per ogni flusso di lavoro, individua i record creati o modificati durante le normali attività e chiediti quante di quelle informazioni potrebbero essere ricostruite dopo un’interruzione. Un catalogo prodotti potrebbe essere recuperabile da un’altra fonte, mentre ordini recenti, pagamenti o aggiornamenti dei clienti potrebbero essere difficili o impossibili da ricreare con precisione.

Il periodo di perdita di dati accettabile può variare tra le diverse parti della stessa applicazione. Valuta che cosa accadrebbe se l’azienda dovesse reinserire il lavoro recente e se tale reinserimento sarebbe completo, tempestivo e sicuro. Considera anche il rischio di record duplicati o incoerenti se, durante un’interruzione, le persone ricorrono a una procedura alternativa.

Esprimi l’RPO come una soglia di tolleranza aziendale, non come un’ipotesi sulla frequenza con cui vengono salvati i dati. Verifica poi che le misure di ripristino siano compatibili con quella soglia.

• Elenca i dati importanti per ciascun flusso di lavoro, incluse le transazioni, i file caricati e le modifiche ai record esistenti.
• Classifica ogni elemento come facile, difficile o impossibile da ricreare.
• Valuta quanto lavoro recente potrebbe essere ripetuto senza costi, confusione o rischi inaccettabili.
• Registra per ciascun flusso di lavoro l’età massima accettabile dei dati ripristinabili.

Mappa le dipendenze necessarie anche al ripristino

Un’applicazione è solo una parte del servizio. La pianificazione del ripristino dovrebbe includere le tecnologie e i servizi di supporto che influiscono sul processo aziendale, anche se normalmente non sono considerati critici da soli.

Segui il percorso che un utente compie per portare a termine il lavoro. A seconda dell’applicazione, quel percorso può coinvolgere un database, file caricati, identità o autenticazione, DNS, instradamento, certificati TLS, e-mail o altri servizi esterni. Verifica quali dipendenze sono essenziali, chi le gestisce e che cosa deve succedere prima che gli utenti possano tornare al lavoro.

Considera anche le integrazioni e i partner esterni. Un’applicazione ripristinata potrebbe non supportare il flusso di lavoro se un servizio connesso essenziale non è disponibile o se è necessario intervenire sulla connessione.

• Elenca l’applicazione, il database e i file necessari per il flusso di lavoro.
• Includi, dove pertinente, le dipendenze relative agli accessi, ai nomi di dominio e alle connessioni.
• Registra i servizi esterni e i partner da cui dipende l’applicazione.
• Individua un responsabile o un referente per ogni dipendenza e annota l’ordine di ripristino.

Definisci obiettivi distinti quando varia la criticità aziendale

Definire un unico RTO e RPO per tutte le applicazioni può nascondere differenze importanti. Stabilisci gli obiettivi per ciascuna applicazione o flusso di lavoro in base all’impatto aziendale, alla tolleranza alla perdita di dati e alle alternative disponibili.

Per esempio, il flusso di lavoro che accetta gli ordini dei clienti può avere esigenze di ripristino diverse da quelle di un flusso di rendicontazione interna che usa la stessa applicazione. Documenta il motivo di ogni differenza, così che gli obiettivi rispecchino le priorità aziendali e non una classificazione informale dei software.

Se più flussi di lavoro dipendono dalla stessa applicazione, annota quale determina la priorità di ripristino. Assicurati che i responsabili di quei flussi di lavoro concordino con gli obiettivi proposti.

• Raggruppa applicazioni o flussi di lavoro in base all’impatto aziendale, non soltanto alla comodità tecnica.
• Assegna un RTO e un RPO a ciascun gruppo o caso d’uso pertinente.
• Spiega le ragioni aziendali alla base di ogni obiettivo.
• Esamina i conflitti quando un’applicazione supporta flussi di lavoro con priorità diverse.

Verifica che gli obiettivi siano raggiungibili

Un obiettivo è utile solo se l’ambiente di distribuzione e le misure di ripristino scelte possono ragionevolmente supportarlo. Confronta ogni obiettivo con le modalità effettive di ripristino dell’applicazione e dei suoi dati. Considera le dipendenze, i tempi decisionali, l’accesso alla procedura di ripristino e le attività necessarie per verificare il servizio ripristinato.

Non dare per scontato che la pianificazione dei backup equivalga all’RPO, né che la disponibilità di un backup dimostri che sia possibile rispettare l’RTO. L’organizzazione deve capire che cosa include il ripristino, come vengono recuperati i dati e i servizi necessari e come si verifica la prontezza operativa.

Airbip gestisce le distribuzioni delle applicazioni del catalogo come carichi di lavoro Docker sui propri server cloud, automatizza l’instradamento e i certificati TLS tramite Traefik e Let’s Encrypt e offre controlli DNS, gestione del ciclo di vita dei servizi e backup configurabili giornalieri, settimanali e mensili. Queste funzionalità non garantiscono il raggiungimento di uno specifico RTO o RPO. Prima di decidere se la soluzione è adeguata, consulta i dettagli del servizio aggiornati e valuta le esigenze di ripristino della tua specifica applicazione.

Se le misure di ripristino non sono in grado di supportare gli obiettivi proposti, rivedi gli obiettivi, la procedura alternativa aziendale o l’approccio di distribuzione. Non presentare come garanzia un obiettivo che non è stato verificato.

• Conferma quali dati e dipendenze sono coperti dalle misure di ripristino.
• Verifica come viene avviato il ripristino e chi dispone dell’accesso e dell’autorità necessari.
• Confronta la frequenza dei backup e le procedure di ripristino con gli obiettivi RPO e RTO.
• Individua lacune, ipotesi e decisioni da convalidare prima di fare affidamento sugli obiettivi.

Trasforma gli obiettivi in un piano di ripristino assegnato e testato

Documenta più dei soli RTO e RPO. Un piano pratico indica chi decide di avviare il ripristino, chi esegue ogni passaggio, chi verifica che l’applicazione sia utilizzabile e chi comunica con il personale, i clienti o i partner.

Definisci chiaramente i momenti decisionali: come viene riconosciuto un incidente, chi è autorizzato a dichiarare un’interruzione, quando usare una procedura alternativa e quali verifiche sono necessarie prima di riprendere le normali attività. Includi l’ordine di ripristino delle dipendenze e la procedura per gestire il lavoro svolto durante l’interruzione.

Esegui test del piano e registra i risultati. Un obiettivo di ripristino è un traguardo da convalidare, non la prova che il ripristino lo rispetterà. Le esercitazioni possono far emergere responsabilità poco chiare, accessi mancanti, dipendenze trascurate o uno scarto tra l’obiettivo dichiarato e la procedura di ripristino.

Dopo un test o un’interruzione reale, aggiorna gli obiettivi e le procedure, se necessario. Le modifiche ai flussi di lavoro, all’importanza dei dati, alle integrazioni o alle modalità operative possono rendere impreciso un piano di ripristino precedente.

• Indica chi prende le decisioni, chi è responsabile del ripristino e chi gestisce le comunicazioni.
• Descrivi i passaggi di ripristino e l’ordine delle dipendenze con un linguaggio comprensibile a chi interviene.
• Definisci le verifiche che consentono di stabilire se il servizio e il flusso di lavoro aziendale sono utilizzabili.
• Testa il piano, registra i risultati e monitora le lacune non risolte.
• Rivedi gli obiettivi quando cambiano i processi aziendali o le dipendenze dell’applicazione.