RTO e RPO spiegati a chi firma il budget

Quando si parla di disaster recovery, prima o poi qualcuno chiede: “Ma se va giù tutto, quanto ci mettiamo a ripartire?”. La risposta giusta non è un servizio AWS. Sono due numeri, e conviene sceglierli prima di sapere quanto costano.

I due numeri

RTO, Recovery Time Objective: quanto tempo può restare fermo il sistema prima di tornare a funzionare. Se l’RTO è di quattro ore, il piano deve riportare il servizio online entro quattro ore dal guasto.

RPO, Recovery Point Objective: quanti dati si possono perdere, misurati in tempo. Se l’RPO è di un’ora, dopo il ripristino è accettabile aver perso al massimo l’ultima ora di ordini, modifiche o messaggi.

RPO dati persiRTO sistema fermo

1. 10:00Ultimo backup, o ultima replica arrivata
2. 10:40Il guasto: regione giù, database corrotto, errore umano
3. 13:40Il sistema è di nuovo online

Il primo parla del fermo, il secondo della perdita. Sono indipendenti:

Sistema	Fermo accettabile (RTO)	Dati persi accettabili (RPO)
Report e analisi	un giorno	nessuno, i dati si ricaricano
Sito vetrina	qualche ora	nessuno, si rifà il deploy
Pagamenti	pochi minuti	nessuna transazione

Esempi indicativi: i numeri giusti dipendono da ogni azienda.

Da dove vengono

Non dalla tecnologia. Vengono da una domanda che di solito sa rispondere chi firma il budget, non chi gestisce i server.

Nel costo entrano gli incassi persi, le persone ferme, le penali dei contratti, i clienti che non tornano, e a volte un obbligo di legge. Se un’ora di fermo costa poche centinaia di euro, spenderne migliaia al mese per evitarla non ha senso. Se costa decine di migliaia, il conto si ribalta.

Per questo i due numeri si fissano sistema per sistema. Il sito vetrina, il gestionale e la piattaforma degli ordini hanno quasi sempre obiettivi diversi, e trattarli tutti allo stesso modo vuol dire pagare troppo per alcuni o troppo poco per altri.

Quattro strategie, quattro prezzi

AWS descrive quattro strategie di disaster recovery, in ordine di costo crescente. Valgono anche fuori da AWS.

Fermo (RTO)Dati persi (RPO)Costo

1. 01Backup e ripristinoCopie di dati e configurazioni in un'altra regione. In caso di disastro si ricostruisce tutto.AWS Backup, copie cross-region, Terraform
   Fermoore
   Dati persiore
   Costo€
2. 02Pilot lightDati già replicati e aggiornati, server applicativi spenti o al minimo. Si accendono e si scalano.Repliche RDS o Aurora cross-region, AMI pronte
   Fermodecine di minuti
   Dati persiminuti
   Costo€€
3. 03Warm standbyUna copia completa ma piccola del sistema, già accesa. Si scala e si sposta il traffico.Auto Scaling ridotto, Route 53 con health check
   Fermominuti
   Dati persisecondi
   Costo€€€
4. 04Multi-site attivo/attivoDue regioni servono traffico ogni giorno. Se una cade, l'altra continua.Aurora Global Database, DynamoDB global tables
   Fermoquasi zero
   Dati persiquasi zero
   Costo€€€€

Nel backup e ripristino l’RPO dipende da quanto spesso si fa il backup e l’RTO da quanto si impiega a ricreare l’infrastruttura. Se l’infrastruttura è scritta come codice, con Terraform o CloudFormation, quel tempo si accorcia molto. Nel pilot light si paga soprattutto la replica dei dati. Nel warm standby si paga un secondo ambiente sempre acceso. Il multi-site costa di più, ma richiede anche un’applicazione progettata per scrivere i dati in due posti.

Perché l’ultimo minuto costa così tanto

Ogni passo verso lo zero non costa “un po’ di più”: cambia proprio il tipo di lavoro da fare.

1. 24 ore →fino a 1 oraBackup più frequenti. Un problema di configurazione.
2. 1 ora →fino a 1 minutoReplica continua dei dati in un'altra regione, per esempio con Aurora Global Database, che di solito replica con meno di un secondo di ritardo.
3. 1 minuto →fino a zeroOgni dato scritto in due regioni prima di confermarlo. Cambia l'architettura dell'applicazione, non solo l'infrastruttura.

Lo stesso vale per l’RTO. Ripartire in un giorno è un problema di procedure. Ripartire in un minuto è un problema di infrastruttura già accesa, già testata, pronta a ricevere traffico.

Un piano mai provato non è un piano

L’errore più comune non è scegliere la strategia sbagliata. È non provarla mai. Si scopre durante l’incidente che manca un permesso, che una chiave di cifratura non è stata copiata nell’altra regione, che il ripristino del database richiede tre volte il tempo previsto.

Una prova si può programmare, almeno una volta l’anno e dopo ogni cambiamento importante: si spegne davvero la regione principale, o la si simula, e si misura quanto ci vuole a ripartire e quanti dati mancano. AWS Fault Injection Service aiuta a farlo in modo controllato. Il risultato della prova è l’RTO e l’RPO reali, ed è l’unico numero da scrivere nel documento.

Le domande da portare alla prossima riunione

1. Quanto ci costa un’ora di fermo di questo sistema? E un giorno?
2. Quanti dati possiamo perdere senza conseguenze serie? Un giorno, un’ora, niente?
3. Ci sono obblighi di legge o di contratto su fermo e dati?
4. Quando abbiamo provato l’ultima volta a ripartire da zero, e quanto ci abbiamo messo?

Con queste risposte, la scelta della strategia diventa un conto. Senza, diventa un’opinione, e di solito vince quella più cara.