Disaster Recovery per Piccoli Team Di Sviluppo

In un piccolo team il disaster recovery si riduce quasi sempre a una riga in un documento che nessuno ha mai aperto: i backup sono attivi. L’affermazione è vera e non è una risposta, perché non dice nulla su quanto sarebbero vecchi i dati recuperati, su quanto tempo richieda un ripristino, né su chi ne abbia mai portato uno a termine davvero.

È nello spazio fra avere i backup e saper ripristinare che la maggior parte dei disservizi si trasforma in incidente. Un backup che esiste, che è aggiornato e che non è mai stato ripristinato resta un’ipotesi, e il momento in cui la verifichi è il momento peggiore possibile per scoprire che era sbagliata.

Due numeri trasformano un’opinione in un piano. Quanti dati puoi permetterti di perdere e per quanto tempo puoi permetterti di stare fermo? Sono il tuo recovery point objective e il tuo recovery time objective. Finché nessuno sul lato business li dichiara, ogni discussione tecnica sulla frequenza dei backup resta irrisolvibile, perché manca il criterio rispetto a cui discutere.

RPO e RTO in parole semplici

Il recovery point objective, cioè l’RPO, è la quantità di dati che puoi perdere. Backup notturni significano un RPO di 24 ore: un guasto alle 17 si porta via tutto quello che è stato prodotto dalla notte precedente. Se questo è inaccettabile, allora è sbagliata la pianificazione dei backup, e nessuna cura riposta altrove riesce a compensarlo.

Il recovery time objective, cioè l’RTO, è il tempo per cui puoi restare fermo. Comprende tutto: accorgersene, decidere, fare il provisioning, ripristinare, verificare e riportare indietro il traffico. I team stimano il passaggio di ripristino e dimenticano gli altri cinque, ed è esattamente per questo che i recuperi reali richiedono un multiplo del tempo previsto.

Entrambi sono decisioni di business e non tecniche, ed entrambi costano denaro man mano che si stringono. Un RPO di cinque minuti richiede una replica continua. Un RTO di un’ora richiede un’infrastruttura ricostruibile in automatico, perché sotto pressione nessuno configura a mano un server in meno di un’ora.

La conversazione produttiva riguarda il compromesso. Di’ al business quanto costa ciascun livello e lascia che scelga, invece di fissare un numero in ingegneria sperando che coincida con aspettative che nessuno ha mai messo per iscritto.

Un backup mai testato non è un backup

I guasti che fanno male raramente sono l’assenza di backup. Sono i backup che si rivelano inutilizzabili proprio nel momento in cui servono.

Le cause ricorrenti, tutte visibili solo al ripristino: il job fallisce in silenzio da settimane perché nessuno sorveglia i successi con la stessa attenzione dei fallimenti. Il dump ha catturato lo schema ma non i dati, oppure un sottoinsieme di tabelle che qualcuno aveva aggiunto a una lista di esclusione. Il file è cifrato con una chiave conservata sulla macchina che è morta. Il backup vive nello stesso account o nella stessa regione della cosa che dovrebbe proteggere.

Quest’ultimo punto pesa più di quanto pesasse una volta. Un backup nello stesso ambiente della produzione è protetto contro il guasto hardware e contro nient’altro. Non sopravvive alla compromissione dell’account, a una cancellazione accidentale a livello di account, né a un ransomware che raggiunge tutto ciò che le stesse credenziali possono raggiungere.

L’unico modo di sapere che un backup funziona è ripristinarlo. Mettilo a calendario, fallo almeno una volta a trimestre e cronometralo. Quel cronometro è il tuo RTO reale, in contrapposizione a quello scritto nel documento.

Che cosa deve coprire il disaster recovery

I dati sono la parte ovvia e raramente la parte lenta. Ciò che allunga i recuperi sono quasi sempre le voci che nessuno aveva elencato.

Il database, che tutti ricordano. I file caricati dagli utenti, che stanno da un’altra parte e spesso non hanno alcun backup. Configurazione e segreti, che di frequente esistono solo sulla macchina in esecuzione. DNS e certificati, che non si ricreano in fretta se l’account che li custodisce è proprio ciò che hai perso. L’infrastruttura stessa, cioè server, reti e regole, veloce da ricostruire se è definita come codice e lentissima se è nata a forza di clic.

E la conoscenza di come tutto si incastra, che in un piccolo team è di gran lunga il primo fattore che determina il tempo di ripristino. Un sistema che una sola persona sa ricostruire a memoria ha un tempo di ripristino pari alla disponibilità di quella persona, e questo non è un piano.

Scrivi l’inventario prima del piano. Quasi tutti i team, mentre compilano quella lista, scoprono almeno un componente che non ha alcun backup, e scoprirlo così costa molto meno dell’alternativa.

Un piano che sta in una pagina

I documenti lunghi non vengono letti durante un incidente. Punta a qualcosa che una persona stanca possa seguire alle tre di notte senza doverci ragionare sopra.

Deve contenere: chi decide che il ripristino è iniziato, perché l’esitazione sul fatto che questo conti o meno come disastro è una fonte di ritardo molto comune. Dove sono i backup e come raggiungerli, comprese credenziali che non dipendano dal sistema caduto. I passaggi di ripristino in ordine, abbastanza precisi da essere eseguiti senza improvvisare. Come verificare che abbia funzionato, cioè un controllo concreto e non l’impressione che il sito si carichi. E chi avvisare, dentro e fuori dall’azienda.

Tienilo in un posto che sopravviva al guasto. Un piano di ripristino conservato solo nel sistema che dovrebbe ripristinare è un errore ricorrente e del tutto evitabile.

Lo stesso ragionamento vale per gli accessi. Se una sola persona detiene le credenziali dell’account di hosting, il tuo tempo di ripristino è limitato dal fatto che quella persona risponda o meno al telefono. La nostra guida all’hardening del server Linux copre i controlli di accesso da cui tutto questo dipende.

Proporzionato, non perfetto

Un piccolo team non ha bisogno di un hot standby in una seconda regione. Il costo è reale e la complessità introduce modalità di guasto tutte sue.

Quello di cui la maggior parte dei piccoli team ha bisogno costa molto meno: backup in un account separato con credenziali che la produzione non può usare, un ripristino testato e cronometrato con regolarità, un’infrastruttura definita come codice così da poter essere ricreata senza archeologia, e un piano di una pagina che qualcuno abbia davvero letto.

Questo insieme copre guasto hardware, cancellazione accidentale, compromissione dell’account e ransomware, cioè la gran parte di ciò che accade realmente. Tutto quello che va oltre è una decisione su quanto valga un’ulteriore riduzione del tempo di fermo, e quella è una domanda per il business e non per l’ingegneria.

Mecanik verifica e realizza tutto questo come parte della nostra analisi sicurezza server . La prima domanda è sempre la stessa e non riguarda la tecnologia: per quanto tempo puoi stare fermo, e chi lo ha deciso?

Post correlati: SLA di uptime che contano davvero , Sicurezza della supply chain software per piccoli team , Agenti IA in azienda: costi e punti di rottura e Sviluppo software fintech in UK: FCA, rails e costi .

Domande frequenti

Che cosa significano RPO e RTO? Il recovery point objective è la quantità di dati che puoi permetterti di perdere, quindi backup notturni implicano un RPO di 24 ore. Il recovery time objective è il tempo per cui puoi permetterti di stare fermo, incluso accorgersene, decidere, fare il provisioning, ripristinare, verificare e riportare indietro il traffico. Entrambi sono decisioni di business ed entrambi costano di più man mano che si stringono.

Perché un backup mai testato non è un backup? Perché le modalità di guasto sono visibili solo al ripristino. I job falliscono in silenzio per settimane quando nessuno sorveglia i successi quanto i fallimenti, i dump catturano lo schema senza i dati oppure omettono le tabelle escluse, le chiavi di cifratura stanno sulla macchina che è morta e le copie vivono nello stesso account della cosa che proteggono. Ripristina ogni trimestre e cronometra.

Dove vanno conservati i backup? In un account o in una regione separati, con credenziali che la produzione non può usare. Un backup nello stesso ambiente protegge dal guasto hardware e da nient’altro: non sopravvive alla compromissione dell’account, a una cancellazione a livello di account né a un ransomware che raggiunge tutto ciò che le stesse credenziali possono raggiungere.

Che cosa ci si dimentica di includere nel disaster recovery? I file caricati e conservati separatamente dal database, configurazione e segreti che esistono solo sulla macchina in esecuzione, DNS e certificati custoditi in un account che può a sua volta essere perso, l’infrastruttura nata a forza di clic invece che definita come codice, e la conoscenza di come si incastra il tutto quando la possiede una sola persona.

Un piccolo team ha bisogno di un hot standby? Di norma no. Il costo è reale e la complessità aggiuntiva porta modalità di guasto tutte sue. Backup in un account separato, un ripristino testato e cronometrato, un’infrastruttura definita come codice e un piano di una pagina che qualcuno abbia letto copriranno guasto hardware, cancellazione accidentale, compromissione dell’account e ransomware, cioè la gran parte di ciò che accade.