Come calcolare il tuo RTO reale (non quello dichiarato)

TL;DR

Calcolare un RTO realistico richiede tre input: costo del fermo per ora, dipendenze tecniche del processo e tempo di ripristino misurato in test. Il numero che esce è quasi sempre 2-3 volte quello che la direzione si aspetta. Meglio scoprirlo prima del disastro.

Il metodo in 4 passaggi

1. Quantifica il costo del fermo

Per ogni processo critico, calcola il danno in euro per ogni ora di fermo, considerando:

• mancato fatturato (per processi che generano direttamente vendite);
• perdita di produttività interna (numero di persone × costo orario);
• penali contrattuali verso clienti (SLA);
• danno reputazionale (più qualitativo, ma vale).

Esempio: un'azienda manifatturiera da 80 dipendenti con 50 in produzione ferma per problema MES = ~3.000 €/ora di costo del personale + ~12.000 €/ora di mancata produzione = 15.000 €/ora.

2. Mappa le dipendenze

Un sistema non riparte da solo. Per il sistema X servono:

• autenticazione (Active Directory, identity provider);
• DNS interno;
• storage e database;
• rete (firewall, switch, routing);
• software di gestione dipendente (es. ERP che richiede CRM).

Disegna la mappa. Il restart richiede l'ordine corretto. Il tuo RTO è la somma dei tempi di restart in ordine di dipendenza, non il tempo del singolo sistema.

3. Misura, non stimare

Ogni stima fatta a tavolino è ottimistica del 30-50%. L'unico numero affidabile arriva da un test cronometrato:

• tabletop drill: stima conservativa, va benissimo come baseline;
• failover parziale di un workload: numero più affidabile;
• full failover di tutto lo stack: il numero vero.

In genere si parte dal tabletop, si fa un partial drill in 90 giorni, un full drill in 12 mesi.

4. Aggiungi i buffer

Tre buffer obbligatori al numero misurato:

• +15% per "imprevisti del giorno reale" (rete più lenta, persone non disponibili);
• +30 minuti per la chiamata di emergenza al supporto (riconoscimento del problema, autorizzazione del DR);
• +10 minuti per le verifiche post-restore prima della "riapertura".

Esempio numerico

Prendiamo un'azienda con ERP critico:

• Restart Active Directory cloud: 8 minuti (misurato in test);
• Restart database server: 12 minuti;
• Restart application server ERP: 6 minuti;
• Riconnessione client: 5 minuti;
• Totale tecnico: 31 minuti.
• Buffer +15%: 36 minuti.
• Riconoscimento problema (15 min) + autorizzazione (10 min) + verifica post (10 min): +35 minuti.
• RTO realistico: ~70 minuti.

Se la BIA dice "max 30 minuti", c'è un problema da risolvere prima del disastro, non durante.

Il foglio di calcolo che usiamo

Una struttura semplice in 5 colonne:

| Sistema | RTO target | Restart misurato | Buffer | Note | |---|---|---|---|---| | AD primario | 10 min | 8 min | +5 min | OK | | DB ERP | 20 min | 18 min | +5 min | Borderline | | App ERP | 10 min | 12 min | +5 min | Fuori target |

Fa il giro mensile alla revisione del piano. Le righe in rosso vanno discusse.

Tre errori da evitare

• partire dal target: se il management dice "voglio RTO 15 min", non assumetelo come dato. Misurate prima.
• ignorare il tempo umano: restart automatici sono pochi. La maggior parte richiede un sistemista che approva, verifica, monitora. Quel tempo va contato.
• dimenticare le dipendenze esterne: licenze software, KMS, autenticazione SaaS. Hanno il loro RTO che non controllate.

FAQ

Posso ridurre il RTO senza più budget?

Sì, in due modi: (1) riducendo le dipendenze (es. cache locale di KMS), (2) automatizzando il restart in sequenza con strumenti di orchestration.

L'RTO è uguale per tutti i processi?

No. Su 20 processi una PMI tipicamente ha 3-4 critici (RTO ≤ 30 min), 6-8 importanti (≤ 4 ore), il resto può aspettare (≤ 24 ore).

Quanto spesso ricalcolare l'RTO?

Almeno annualmente, e dopo ogni grande cambiamento dell'infrastruttura (migrazione, sostituzione vendor, nuovi sistemi).

Per capire come misurare RPO accanto a RTO, leggi RTO vs RPO: differenze. Per i metodi di test che producono il vero RTO, vedi Test di ripristino.