Un servizio «sempre disponibile» non esiste: ogni sistema, per quanto ben costruito, prima o poi si guasta. La domanda giusta non è «si guasterà?» ma «quanto tempo resterà fermo?» — e questa è una proprietà misurabile, chiamata disponibilità (availability). Questo calcolatore stima la disponibilità di un sistema a partire da due parametri fondamentali dell'ingegneria dell'affidabilità: l'MTBF (Mean Time Between Failures), il tempo medio di buon funzionamento tra un guasto e l'altro, e l'MTTR (Mean Time To Repair), il tempo medio per rimettere in funzione il sistema dopo un guasto. Da questi ottieni la disponibilità in percentuale, il celebre numero di «nove» (99,9% = «tre nove»), il downtime atteso nel periodo, e l'effetto dell'architettura: componenti in serie (che riducono la disponibilità) e ridondanza in parallelo (che la aumenta). È lo strumento di base di chi progetta e gestisce sistemi affidabili — dai team SRE e DevOps che gestiscono servizi cloud, agli ingegneri di sistemi industriali e infrastrutture critiche. Un modello parametrico e universale, valido in qualsiasi contesto. I risultati sono una stima: il modello assume guasti indipendenti e tassi costanti, ipotesi che nella realtà vanno considerate con attenzione.

Disponibilità di un sistema: MTBF, MTTR e i «nove»

La disponibilità è la percentuale di tempo in cui un sistema è funzionante e pronto all'uso. Sembra un concetto semplice, ma dietro nasconde una matematica sorprendente e implicazioni economiche enormi. Il punto di partenza sono due tempi medi. L'MTBF (Mean Time Between Failures) misura quanto a lungo, in media, il sistema funziona correttamente prima di guastarsi: più è alto, più il sistema è affidabile. L'MTTR (Mean Time To Repair) misura quanto tempo, in media, serve per riparare il sistema e rimetterlo in funzione dopo un guasto: più è basso, più in fretta ci si riprende. La disponibilità nasce dal rapporto tra questi due tempi: intuitivamente, è la frazione del tempo totale in cui il sistema «funziona» rispetto al ciclo completo «funziona + è in riparazione». Un modo comodo e diffuso di esprimere la disponibilità è contare i «nove»: 99% è «due nove», 99,9% è «tre nove», 99,99% è «quattro nove», e così via. Ogni nove aggiuntivo rappresenta una riduzione di dieci volte del tempo di fermo — un salto enorme di qualità (e di costo). Comprendere il legame tra MTBF, MTTR, nove e downtime è il fondamento della progettazione di sistemi affidabili. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Cos'è la disponibilità (availability)

Formalmente, la disponibilità di un componente è il rapporto tra il tempo in cui è operativo (uptime) e il tempo totale (uptime + downtime). Usando i tempi medi, si esprime come A = MTBF / (MTBF + MTTR). Vale la pena soffermarsi sul significato di questa formula, perché è più profondo di quanto sembri. Il denominatore, MTBF + MTTR, rappresenta la durata media di un ciclo completo: il sistema funziona per un tempo pari all'MTBF, poi si guasta e viene riparato in un tempo pari all'MTTR, poi riparte. La disponibilità è la frazione di questo ciclo in cui il sistema è utile. Da questa formula emerge un fatto controintuitivo ma cruciale: la disponibilità non dipende dai valori assoluti di MTBF e MTTR, ma dal loro rapporto. Un sistema che si guasta ogni 1.000 ore ma si ripara in 1 ora (A = 1000/1001 = 99,9%) ha la stessa disponibilità di uno che si guasta ogni 100 ore ma si ripara in 6 minuti (A = 100/100,1 = 99,9%). Questo ha un'implicazione pratica potente: se le riparazioni sono velocissime, puoi tollerare guasti frequenti; se le riparazioni sono lente, hai bisogno di guasti rari. La disponibilità è distinta dall'affidabilità (reliability), che riguarda la probabilità di non guastarsi in un dato intervallo: un sistema può essere poco affidabile (si guasta spesso) ma molto disponibile (si ripara istantaneamente). Il calcolatore lavora sulla disponibilità, la metrica più rilevante per i servizi che devono «esserci» quando servono. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Come si calcola: MTBF e MTTR

La tabella mostra il calcolo nel caso di default — MTBF 8.760 ore (un guasto all'anno in media), MTTR 4 ore, un singolo componente senza ridondanza:

Il calcolo è diretto. Con un MTBF di 8.760 ore, il sistema in media funziona bene per un anno intero prima di un guasto. Quando si guasta, ci vogliono 4 ore (MTTR) per ripararlo. La disponibilità è quindi 8.760 / (8.760 + 4) = 8.760 / 8.764 = 99,9544%. Tradotto in downtime concreto: su un anno (8.760 ore), un'indisponibilità dello 0,0456% significa circa 4 ore di fermo — che, non a caso, coincide con l'MTTR, perché in media ci si aspetta un guasto all'anno. In termini di «nove», 99,9544% corrisponde a circa 3,34 nove: siamo oltre i «tre nove» (99,9%) ma non ancora ai «quattro nove» (99,99%). Da qui puoi esplorare le due leve architetturali. Se aggiungi componenti in serie — parti che devono funzionare tutte perché il sistema funzioni — la disponibilità complessiva scende, perché aumentano i modi in cui il sistema può guastarsi. Se aggiungi ridondanza — unità in parallelo che si sostituiscono a vicenda — la disponibilità sale, spesso in modo spettacolare. Cambia i valori nel calcolatore per vedere questi effetti sul tuo sistema. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

I «nove» e il downtime: cosa significano davvero

Parlare di «nove» è comodo, ma è facile sottovalutare quanto sia grande la differenza tra un nove e il successivo. La tabella traduce ogni livello di disponibilità in downtime concreto:

La tabella rivela la natura esponenziale dei nove, e spiega perché sono diventati il linguaggio universale della disponibilità. La differenza tra 99% e 99,9% non è «un po' meglio»: è passare da 3,65 giorni di fermo all'anno a meno di 9 ore, una riduzione di dieci volte. Ogni nove aggiuntivo divide il downtime per dieci. Questo ha due conseguenze pratiche enormi. Primo, ogni nove è drasticamente più difficile e costoso del precedente: passare da due a tre nove può richiedere un buon monitoraggio e procedure ordinate; passare da quattro a cinque nove richiede ridondanza completa, failover automatico in secondi, e team operativi che rispondono 24/7 — un investimento di ordini di grandezza superiore. Secondo, la scelta del target di disponibilità è una decisione economica: bisogna bilanciare il costo di ogni nove aggiuntivo contro il costo del downtime che evita. Per un blog personale, «due nove» vanno benissimo; per un sistema di pagamento o un servizio cloud critico, anche «cinque nove» possono non bastare. Questi valori sono universali: 99,9% significa 8,76 ore all'anno ovunque nel mondo, il che rende i nove un linguaggio comune tra ingegneri di ogni paese. Usa questa tabella per tradurre un obiettivo di disponibilità in un budget di downtime concreto. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

MTBF vs MTTR: due leve diverse

Per migliorare la disponibilità hai due leve indipendenti, e capire la differenza tra loro è essenziale per intervenire in modo efficace. La prima leva è aumentare l'MTBF, cioè far guastare il sistema meno spesso. Si ottiene con componenti di qualità migliore, manutenzione preventiva, eliminazione delle cause ricorrenti di guasto, riduzione dello stress sui componenti, e buona progettazione. È una leva «di prevenzione»: agisce sulla frequenza dei problemi. La seconda leva è ridurre l'MTTR, cioè riparare più in fretta quando il guasto avviene. Si ottiene con monitoraggio che rileva subito il problema, allarmi efficaci, diagnostica rapida, automazione delle riparazioni, pezzi di ricambio pronti, procedure rodate e team preparati. È una leva «di reazione»: agisce sulla durata dei problemi. Ecco il fatto matematico chiave che guida la scelta: poiché la disponibilità dipende dal rapporto MTBF/(MTBF+MTTR), dimezzare l'MTTR ha lo stesso effetto che raddoppiare l'MTBF. Ma nella pratica le due leve hanno costi molto diversi. Aumentare l'MTBF (rendere le cose più affidabili) è spesso difficile e costoso: richiede componenti migliori o riprogettazioni. Ridurre l'MTTR (riparare più in fretta) è spesso più facile ed economico: un investimento nel monitoraggio e nell'automazione può abbattere l'MTTR rapidamente. Per questo, nella cultura SRE moderna, si dà grande enfasi alla riduzione dell'MTTR — «i guasti sono inevitabili, ciò che conta è quanto in fretta ti riprendi». Il calcolatore ti fa vedere l'effetto di entrambe le leve: prova a variarle. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Componenti in serie: l'anello debole

Pochi sistemi reali sono fatti di un solo componente. La maggior parte è una catena di componenti che devono funzionare tutti perché il sistema nel suo insieme funzioni: un'applicazione web dipende dal server, dal database, dalla rete, dal load balancer, dallo storage. Questa è una configurazione in serie, e ha una proprietà cruciale: il sistema si guasta se anche uno solo dei componenti si guasta. È il principio dell'«anello debole della catena». Matematicamente, la disponibilità di componenti in serie è il prodotto delle singole disponibilità. E qui si nasconde una trappola controintuitiva: mettere insieme componenti affidabili produce un sistema meno affidabile di ciascuno di essi. Un esempio concreto: se hai 5 componenti ciascuno con una disponibilità del 99,9% («tre nove»), la disponibilità del sistema non è 99,9%, ma 0,999⁵ = 99,5% — sei sceso sotto i «tre nove». Con 10 componenti al 99,9%, scendi al 99% («due nove»). Ogni componente aggiunto in serie erode la disponibilità complessiva, perché aggiunge un altro modo in cui il tutto può rompersi. Questa è una delle ragioni per cui i sistemi distribuiti moderni, fatti di decine o centinaia di microservizi, faticano a raggiungere alta disponibilità: la lunga catena di dipendenze abbassa il risultato. Le contromisure sono due: ridurre il numero di dipendenze critiche in serie (semplificare l'architettura), oppure — dove serve alta disponibilità — introdurre la ridondanza sui componenti critici, trasformando i singoli anelli deboli in blocchi ridondati. Il calcolatore ti mostra questo effetto: aumenta i componenti in serie e osserva la disponibilità scendere. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

La ridondanza: come aggiungere nove

Se la serie erode la disponibilità, la ridondanza (o parallelo) la moltiplica. La tabella mostra l'effetto di unità ridondanti su un componente con disponibilità di partenza del 99,9544% (MTBF 8.760, MTTR 4):

Il risultato è spettacolare e spiega perché la ridondanza è il pilastro dell'alta disponibilità. Con una sola unità di backup (2 unità in parallelo), la disponibilità passa da 3,34 a 6,68 nove: il downtime annuo crolla da 4 ore a circa 7 secondi. La ragione è matematica: perché il blocco ridondato si guasti, devono guastarsi contemporaneamente tutte le unità in parallelo, e la probabilità che due eventi indipendenti e rari accadano insieme è il prodotto delle loro probabilità — un numero molto più piccolo. In pratica, la ridondanza eleva a potenza l'affidabilità: aggiungere unità in parallelo può raddoppiare o triplicare i nove. È il principio dietro RAID per i dischi, cluster di server, sistemi di alimentazione doppi, data center multipli. Attenzione però a due condizioni fondamentali, senza le quali la magia svanisce. Primo, le unità ridondanti devono essere davvero indipendenti: se condividono un punto di guasto comune (la stessa alimentazione, la stessa rete, lo stesso bug software), un singolo evento le abbatte tutte insieme e la ridondanza non serve. Secondo, il meccanismo di failover (il passaggio automatico all'unità di riserva) deve funzionare: una riserva che non si attiva quando serve è inutile. La ridondanza reale richiede indipendenza e failover affidabile. Il calcolatore assume ridondanza ideale; nella pratica valuta sempre i punti di guasto comuni. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Availability, reliability e SLA

Nel campo dell'affidabilità si usano termini che è facile confondere, ma che hanno significati precisi e distinti. La disponibilità (availability), di cui si occupa questo calcolatore, è la percentuale di tempo in cui il sistema è operativo. È la metrica giusta quando ciò che conta è «il sistema c'è quando mi serve?». L'affidabilità (reliability) è un concetto diverso: è la probabilità che il sistema funzioni senza guastarsi per un intero intervallo di tempo. Un sistema può avere alta disponibilità ma bassa affidabilità: se si guasta spesso ma si ripara in un lampo, è quasi sempre disponibile ma poco affidabile. Al contrario, un componente monouso (come un fusibile) può essere molto affidabile in una singola missione ma, una volta guasto, avere disponibilità zero perché non si ripara. La distinzione conta: per un sito web è cruciale la disponibilità; per una sonda spaziale che non può essere riparata è cruciale l'affidabilità. Un terzo concetto è lo SLA (Service Level Agreement): l'impegno contrattuale che un fornitore prende sulla disponibilità (per esempio «garantiamo il 99,9%»), spesso con penali se non viene rispettato. Lo SLA è un obiettivo di business, mentre la disponibilità calcolata qui è una stima ingegneristica di ciò che l'architettura può realisticamente offrire. Il ruolo dell'ingegnere dell'affidabilità è progettare un sistema la cui disponibilità stimata superi con margine lo SLA promesso. Nella cultura SRE si parla anche di SLO (objective) e SLI (indicator): l'obiettivo interno e la misura effettiva. Questo calcolatore ti aiuta a capire se la tua architettura può reggere l'obiettivo. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Ridurre l'MTTR: rilevare, diagnosticare, riparare

Poiché ridurre l'MTTR è spesso la leva più efficace e conveniente per migliorare la disponibilità, vale la pena scomporlo. L'MTTR non è solo «il tempo di riparare»: è l'intero intervallo tra il momento in cui il guasto avviene e il momento in cui il servizio è di nuovo operativo. Si può scomporre in fasi. La prima è il tempo di rilevamento: quanto passa prima che qualcuno (o qualcosa) si accorga del guasto. In molti sistemi mal monitorati, questa è la fetta più grande dell'MTTR — il guasto avviene alle 3 di notte e nessuno se ne accorge fino alla mattina. Un buon monitoring con allarmi automatici può ridurre il rilevamento da ore a secondi, ed è spesso l'investimento con il miglior ritorno. La seconda fase è la diagnosi: capire cosa è andato storto e perché. Sistemi osservabili (log, metriche, tracce) e strumenti di debug accorciano questa fase. La terza è la riparazione vera e propria: rimettere in funzione il sistema. Automazione (riavvii automatici, rollback, auto-scaling), runbook chiari, pezzi di ricambio pronti e team addestrati la accorciano. Una quarta componente, spesso trascurata, è il tempo di attivazione: quanto ci vuole perché la persona giusta riceva l'allarme e inizi a lavorarci (turni di reperibilità, escalation). La cultura SRE moderna investe pesantemente su tutte queste fasi, perché parte dal presupposto che i guasti siano inevitabili e che la vera differenza la faccia la velocità di ripristino. Ridurre l'MTTR non solo migliora la disponibilità, ma riduce anche l'impatto e lo stress di ogni incidente. Il calcolatore ti mostra quanto pesa l'MTTR sulla disponibilità: provalo. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

High availability: architetture e pattern

Raggiungere l'alta disponibilità (high availability, HA) — tipicamente «quattro nove» o più — non è questione di un singolo trucco, ma di un insieme di pattern architetturali che tutti mirano a eliminare i «single point of failure» (SPOF), cioè i componenti il cui guasto ferma l'intero sistema. Il pattern fondamentale è la ridondanza, già vista: duplicare (o triplicare) i componenti critici in modo che il guasto di uno non fermi il servizio. Ma la ridondanza da sola non basta: serve il failover, il meccanismo che rileva il guasto di un'unità e sposta automaticamente il carico su quelle sane, idealmente in secondi e senza intervento umano. Un pattern importante è la distribuzione geografica: replicare il sistema in data center o regioni diverse, così che un disastro locale (incendio, alluvione, blackout) non lo abbatta — è la ragione delle «availability zone» e «region» dei cloud provider. C'è poi la distinzione tra ridondanza attiva-attiva (tutte le unità lavorano e si dividono il carico) e attiva-passiva (una lavora, l'altra è in standby pronta a subentrare), ciascuna con i suoi compromessi di costo e complessità. Altri elementi dell'HA includono il bilanciamento del carico, i controlli di salute (health check) che rilevano le unità malate, il disaccoppiamento dei componenti (perché il guasto di uno non si propaghi), e la capacità di degradare con grazia (offrire un servizio ridotto invece di crollare del tutto). Costruire HA è complesso e costoso, e va giustificato dal valore del servizio: non tutto merita cinque nove. Questo calcolatore ti aiuta a stimare quanta disponibilità porta una data scelta architetturale. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Errori comuni nel calcolo della disponibilità

Calcolare la disponibilità è semplice, ma interpretarla e applicarla bene richiede di evitare alcune trappole. Il primo errore è ignorare le dipendenze in serie: stimare la disponibilità di un componente e presentarla come quella del sistema, dimenticando che il sistema è una catena e che ogni dipendenza abbassa il totale. Il secondo è assumere che la ridondanza sia perfetta: contare due unità in parallelo come indipendenti quando in realtà condividono un punto di guasto comune (stessa alimentazione, stesso rack, stesso bug, stesso operatore). I guasti correlati sono il nemico numero uno dell'alta disponibilità e la ridondanza «di carta» non protegge. Il terzo è dimenticare il tempo di rilevamento e attivazione nell'MTTR: contare solo il tempo di riparazione vera e propria e ignorare le ore perse ad accorgersi del guasto e a mobilitare le persone. Il quarto è usare l'MTBF nominale del produttore come se fosse la realtà del proprio ambiente, che può essere molto diverso (stress, temperatura, carico). Il quinto è confondere disponibilità e affidabilità, applicando la metrica sbagliata al problema. Il sesto è assumere tassi di guasto costanti quando molti componenti hanno una «curva a vasca da bagno» (più guasti all'inizio e alla fine della vita). Il settimo è trascurare la manutenzione pianificata: gli aggiornamenti e le manutenzioni programmate sono downtime, e vanno considerati (o evitati con tecniche come i deploy senza interruzione). Evitare questi errori richiede rigore e conoscenza del proprio sistema reale. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Limiti del calcolo

Questo calcolatore fornisce una stima parametrica della disponibilità, non un'analisi di affidabilità professionale né una garanzia di servizio. Le formule usate (A = MTBF/(MTBF+MTTR), prodotto per la serie, complemento per la ridondanza) sono standard e corrette, ma poggiano su ipotesi semplificatrici importanti. Primo, e più importante: assume che i guasti dei diversi componenti (e delle unità ridondanti) siano statisticamente indipendenti. Nella realtà i guasti correlati — un aggiornamento sbagliato che rompe tutte le repliche, un'alimentazione condivisa che salta, un bug software comune, un errore umano — sono frequenti e vanificano gran parte del beneficio della ridondanza; il modello li ignora e quindi tende a sovrastimare la disponibilità dei sistemi ridondanti. Secondo: assume tassi di guasto e riparazione costanti (distribuzione esponenziale), mentre molti componenti invecchiano o hanno una mortalità infantile. Terzo: la qualità della stima dipende interamente dall'accuratezza dei tuoi MTBF e MTTR, che sono spesso incerti o basati su dati di produttore non rappresentativi del tuo ambiente. Quarto: il modello di serie/parallelo è semplificato; i sistemi reali hanno topologie complesse (k-su-n, dipendenze condivise) che richiedono metodi più avanzati (alberi dei guasti, catene di Markov, simulazione). Quinto: non considera la manutenzione pianificata né la capacità di degradare con grazia. Soprattutto, questo strumento non sostituisce un'analisi di affidabilità (RAMS) condotta da un ingegnere specializzato con metodi rigorosi e dati specifici. Usa il risultato per capire gli ordini di grandezza e l'effetto delle scelte architetturali, non come garanzia di disponibilità reale. Questo non è un parere professionale.

Esempio: quanto costa il downtime

La disponibilità non è solo un numero tecnico: si traduce direttamente in denaro. La tabella mostra, per un ipotetico costo del fermo di 1.000 (valuta-neutra) per ogni ora di indisponibilità, quanto ti costa ogni livello di disponibilità in un anno:

La tabella rende concreta la decisione economica dietro la scelta del target di disponibilità. Passare da «due nove» a «tre nove» fa risparmiare, in questo esempio, quasi 80.000 all'anno in costi di fermo. Ma ogni nove aggiuntivo costa anche di più da realizzare: la logica corretta è confrontare il risparmio di downtime evitato con il costo dell'investimento necessario per ottenerlo. Il target giusto è quello in cui il costo marginale del nove successivo eguaglia il beneficio marginale del downtime evitato. Questo spiega perché servizi diversi hanno target diversi: se un'ora di fermo ti costa 100.000 (un sistema di trading, un e-commerce nei giorni di picco), «cinque nove» sono facilmente giustificati; se ti costa 100, «due nove» sono più che sufficienti. Il costo del downtime non è solo il ricavo perso durante il fermo: include anche il danno di reputazione, i clienti persi, le penali contrattuali (SLA), il lavoro straordinario per il ripristino, e a volte conseguenze normative. Una stima onesta del costo orario del tuo downtime è il punto di partenza per decidere quanto investire in disponibilità. Questa è una stima parametrica.

Cluster e sistemi k-su-n

La ridondanza semplice («basta 1 unità di N») è solo un caso particolare di una famiglia più ampia: i sistemi k-su-n, in cui servono almeno k unità funzionanti su n totali. La tabella confronta alcune configurazioni con componenti da 99,9544% ciascuno:

La tabella illustra la ricchezza dei pattern di ridondanza. La configurazione 1-su-2 è la classica ridondanza «attiva-passiva» o «attiva-attiva»: basta che una delle due unità funzioni, e la disponibilità sale a quasi cinque nove. La configurazione 2-su-3 è tipica dei sistemi che richiedono un quorum o una maggioranza per funzionare — molto comune nei sistemi distribuiti che devono votare per prendere decisioni coerenti (database replicati, sistemi di consenso): serve che almeno 2 dei 3 nodi siano vivi. Nota un fatto interessante: 2-su-3 dà una disponibilità leggermente inferiore a 1-su-2, perché è una condizione più stringente (tollera un solo guasto su tre invece di uno su due), ma resta molto alta. All'estremo opposto, 2-su-2 è in realtà una serie: entrambe le unità devono funzionare, e la disponibilità scende sotto quella del singolo componente. Questo mostra che «più unità» non significa automaticamente «più affidabile»: dipende da quante ne servono per funzionare. Il calcolatore modella il caso più comune (ridondanza «1-su-n»); per configurazioni k-su-n più complesse servono formule combinatorie o metodi dedicati. Ma il principio è chiaro: la topologia — chi deve funzionare perché il tutto funzioni — determina la disponibilità tanto quanto l'affidabilità dei singoli pezzi. Questa è una stima parametrica.

Il paradosso della ridondanza

La ridondanza sembra magica — abbiamo visto che una sola unità di backup può portare da tre a quasi sette nove — ma nella pratica delude spesso le aspettative, per una ragione fondamentale: la sua efficacia dipende interamente da un'ipotesi che il calcolo assume ma che la realtà spesso viola, l'indipendenza dei guasti. La formula della ridondanza funziona perché moltiplica probabilità di guasto molto piccole: se un'unità ha una probabilità di essere giù dello 0,05%, due unità indipendenti sono entrambe giù con probabilità 0,05% × 0,05% = 0,000025%, un numero minuscolo. Ma questo vale solo se i due guasti sono davvero scorrelati. Nella realtà, moltissimi guasti sono correlati: un aggiornamento software difettoso viene distribuito su tutte le repliche e le rompe tutte insieme; un guasto all'alimentazione o al raffreddamento condivisi abbatte l'intero rack; un bug latente si manifesta contemporaneamente su tutte le istanze allo stesso input; un errore di configurazione umano viene applicato a tutte le unità. In questi casi, la ridondanza «di carta» non protegge: due unità che condividono un punto di guasto comune si comportano, per quel guasto, come una sola. Questo è il paradosso della ridondanza: proprio i sistemi progettati per essere ultra-affidabili possono cadere per un singolo evento correlato che aggira tutta la ridondanza. Le contromisure sono l'indipendenza reale: alimentazioni separate, reti separate, data center diversi, versioni software sfalsate (per non propagare lo stesso bug), procedure che evitano di toccare tutte le repliche insieme. Progettare per l'indipendenza è più difficile che aggiungere copie, ed è ciò che distingue l'alta disponibilità vera da quella solo apparente. Il calcolatore assume indipendenza ideale: nella realtà, valuta sempre cosa condividono le tue unità ridondanti. Questa è una stima parametrica.

Manutenzione pianificata e disponibilità

Il modello di disponibilità basato su MTBF e MTTR cattura il downtime non pianificato, cioè i guasti. Ma nella vita reale di un sistema c'è un'altra fonte di indisponibilità che va considerata: la manutenzione pianificata. Aggiornamenti software, patch di sicurezza, upgrade hardware, migrazioni, riavvii programmati: tutte queste attività, se richiedono di fermare il sistema, sono downtime a tutti gli effetti, anche se «volontario». Storicamente si distingueva tra downtime pianificato (escluso dagli SLA, perché concordato in finestre di manutenzione notturne) e non pianificato (quello che conta per l'affidabilità). Ma per un servizio globale, «di notte» non esiste — è sempre giorno da qualche parte — e gli utenti non distinguono un fermo pianificato da un guasto: per loro il servizio è comunque giù. Per questo la tendenza moderna, soprattutto nel mondo cloud e SRE, è puntare a zero downtime pianificato, con tecniche che permettono di aggiornare e manutenere senza fermare il servizio: deploy graduali (rolling update, dove si aggiornano poche istanze alla volta mentre le altre servono il traffico), blue-green deployment (due ambienti che si alternano), canary release (rilascio a una piccola frazione di utenti prima di generalizzare), e la ridondanza stessa (si manutiene un'unità mentre le altre lavorano). Queste tecniche trasformano la manutenzione da fonte di downtime a operazione trasparente. Quando calcoli o prometti una disponibilità, chiediti sempre: include o esclude la manutenzione pianificata? E il tuo sistema è progettato per manutenersi senza fermarsi? Questo calcolatore modella il downtime da guasto; aggiungi mentalmente l'eventuale downtime di manutenzione se il tuo sistema lo richiede. Questa è una stima parametrica.

Domande da porsi prima di fissare un target

Prima di impegnarti su un target di disponibilità (o di prometterlo in uno SLA), poniti alcune domande che trasformano un numero in una decisione consapevole. Quanto costa davvero un'ora di downtime? Somma ricavi persi, danno di reputazione, penali, costo del ripristino: è il parametro che giustifica ogni investimento in affidabilità. Ho considerato tutte le dipendenze in serie? La disponibilità del sistema è quella della catena completa, non del singolo componente migliore. La mia ridondanza è davvero indipendente? Cosa condividono le unità di backup — alimentazione, rete, software, operatori? I punti di guasto comuni vanificano la ridondanza. I miei MTBF e MTTR sono realistici? Sono misurati sul mio ambiente o presi dai datasheet ottimistici del produttore? Sto includendo la manutenzione pianificata? Il mio sistema si aggiorna senza fermarsi? Il mio MTTR include il tempo di rilevamento? Spesso accorgersi del guasto è più lento che ripararlo. Il target è giustificato dal valore del servizio? Non tutto merita cinque nove; ogni nove costa esponenzialmente di più. Ho un piano per i guasti correlati e i disastri? La distribuzione geografica e i test di resilienza (chaos engineering) contano quanto la ridondanza. Rispondere a queste domande trasforma il calcolo in una strategia di affidabilità. Per un target critico, affidati a un ingegnere dell'affidabilità e a un'analisi RAMS rigorosa. Questa è una stima parametrica, non un'analisi di affidabilità professionale.

Domande frequenti

Cos'è la disponibilità di un sistema?

È la percentuale di tempo in cui un sistema è operativo e pronto all'uso. Si calcola come A = MTBF / (MTBF + MTTR), cioè il tempo di buon funzionamento diviso il tempo totale (funzionamento + riparazione). Si esprime in percentuale o in numero di «nove»: 99,9% = «tre nove». È la metrica chiave per i servizi che devono essere disponibili quando servono, dai servizi cloud alle infrastrutture critiche.

Cosa sono MTBF e MTTR?

L'MTBF (Mean Time Between Failures) è il tempo medio di buon funzionamento tra un guasto e l'altro: più è alto, più il sistema è affidabile. L'MTTR (Mean Time To Repair) è il tempo medio per riparare il sistema dopo un guasto: più è basso, più in fretta ci si riprende. La disponibilità dipende dal loro rapporto, non dai valori assoluti.

Cosa sono i «nove»?

Sono un modo comodo di esprimere la disponibilità contando le cifre 9: 99% è «due nove», 99,9% è «tre nove», 99,99% è «quattro nove». Ogni nove aggiuntivo riduce il downtime di dieci volte: 99% = 3,65 giorni di fermo all'anno, 99,9% = 8,76 ore, 99,99% = 52,6 minuti. Sono un linguaggio universale tra ingegneri di ogni paese.

Perché componenti in serie riducono la disponibilità?

Perché in una configurazione in serie tutti i componenti devono funzionare: il sistema si guasta se anche uno solo si guasta («anello debole»). La disponibilità complessiva è il prodotto delle singole, quindi mettere insieme componenti affidabili produce un sistema meno affidabile di ciascuno. Esempio: 5 componenti al 99,9% danno 0,999⁵ = 99,5%, sotto i «tre nove».

Come funziona la ridondanza?

La ridondanza mette unità in parallelo che si sostituiscono a vicenda: il blocco si guasta solo se si guastano tutte le unità contemporaneamente. Poiché la probabilità di guasti simultanei indipendenti è il prodotto delle probabilità (un numero molto piccolo), la ridondanza «eleva a potenza» l'affidabilità. Nel default, aggiungere una sola unità di backup porta da 3,34 a 6,68 nove: il downtime crolla da 4 ore a ~7 secondi l'anno.

Meglio aumentare l'MTBF o ridurre l'MTTR?

Matematicamente sono equivalenti: dimezzare l'MTTR ha lo stesso effetto che raddoppiare l'MTBF, perché la disponibilità dipende dal loro rapporto. Ma nella pratica ridurre l'MTTR (riparare più in fretta con monitoring e automazione) è spesso più facile ed economico che aumentare l'MTBF (rendere i componenti più affidabili). Per questo la cultura SRE moderna enfatizza la velocità di ripristino.

Qual è la differenza tra disponibilità e affidabilità?

La disponibilità è la percentuale di tempo in cui il sistema è operativo. L'affidabilità è la probabilità di funzionare senza guastarsi per un intero intervallo. Un sistema può avere alta disponibilità ma bassa affidabilità (si guasta spesso ma si ripara in un lampo). Per un sito web conta la disponibilità; per una sonda spaziale non riparabile conta l'affidabilità.

Cos'è un SLA e come si lega alla disponibilità?

Lo SLA (Service Level Agreement) è l'impegno contrattuale che un fornitore prende sulla disponibilità (es. «garantiamo il 99,9%»), spesso con penali se non rispettato. È un obiettivo di business, mentre la disponibilità calcolata qui è una stima ingegneristica di ciò che l'architettura può offrire. Un buon progetto ha una disponibilità stimata che supera con margine lo SLA promesso.

Perché ogni «nove» in più è così costoso?

Perché ogni nove riduce il downtime di dieci volte, e ridurre il fermo esponenzialmente richiede investimenti crescenti. Passare da due a tre nove può bastare un buon monitoraggio; passare da quattro a cinque nove richiede ridondanza completa, failover automatico in secondi e team 24/7. La scelta del target è una decisione economica: bilanciare il costo di ogni nove contro il costo del downtime evitato.

Il calcolo considera i guasti correlati?

No, ed è il suo limite principale. Il modello assume guasti indipendenti. Nella realtà i guasti correlati — un aggiornamento sbagliato che rompe tutte le repliche, un'alimentazione condivisa che salta, un bug comune, un errore umano — sono frequenti e vanificano gran parte del beneficio della ridondanza. Per questo il modello tende a sovrastimare la disponibilità dei sistemi ridondanti: valuta sempre i punti di guasto comuni.

Come si riduce l'MTTR nella pratica?

Scomponendo il tempo di ripristino: (1) rilevamento — un buon monitoring con allarmi automatici riduce il tempo per accorgersi del guasto da ore a secondi; (2) diagnosi — log, metriche e tracce accorciano il capire cosa è successo; (3) riparazione — automazione, runbook e team addestrati; (4) attivazione — turni di reperibilità ed escalation efficaci. Spesso il rilevamento è la fetta più grande e più facile da ridurre.

Che valore di disponibilità dovrei puntare?

Dipende dal valore del servizio e dal costo del downtime. Per un blog personale, «due nove» (99%) vanno benissimo. Per un'applicazione aziendale, «tre nove» (99,9%) è lo standard comune. Per sistemi di pagamento, servizi cloud critici o infrastrutture, servono «quattro o cinque nove». Non esiste un valore giusto universale: bilancia il costo di ogni nove aggiuntivo contro il costo del fermo che eviti.

Questo calcolatore sostituisce un'analisi di affidabilità professionale?

No. Fornisce una stima parametrica basata su formule standard (serie, parallelo), utile per capire gli ordini di grandezza e l'effetto delle scelte architetturali. Ma assume guasti indipendenti e tassi costanti, non modella topologie complesse (k-su-n, dipendenze condivise) né la manutenzione pianificata. Per un'analisi RAMS ufficiale servono metodi rigorosi (alberi dei guasti, catene di Markov, simulazione) e un ingegnere specializzato con dati specifici.

Aggiornato a luglio 2026