La percentuale di uptime è il tempo in cui un servizio è stato attivo diviso per il tempo totale, moltiplicato per 100. Un mese di 30 giorni ha 43.200 minuti; con 27 minuti di downtime, l’uptime è (43.200 − 27) ÷ 43.200 × 100 = 99,9375%.
La formula è semplice. Ottenere un numero che regga è più difficile: devi decidere qual è il tempo totale, cosa conta come downtime, cosa escludere e come combinare più parti di un sistema. Questa guida affronta ogni punto con esempi, poi spiega in cosa l’uptime differisce da disponibilità e affidabilità.
Per una risposta rapida, il calcolatore di uptime converte il downtime in percentuale e la percentuale in downtime consentito.
La formula dell’uptime
Uptime % = (Total time − Downtime) ÷ Total time × 100
Tempo totale e downtime devono essere nella stessa unità. Per un mese la scelta pratica sono i minuti, i secondi se ti serve più precisione.
PeriodoMinutiSecondiGiorno1.44086.400Settimana10.080604.800Mese di 30 giorni43.2002.592.000Mese di 31 giorni44.6402.678.400Mese medio (30,4375 giorni)43.8302.629.800Anno (365,25 giorni)525.96031.557.600
Usa la durata reale del periodo quando fai report su un contratto, perché la maggior parte degli SLA si misura per mese solare. Il calcolatore usa il mese medio, così gli obiettivi sono confrontabili in modo equo: per questo mostra 99,938% per gli stessi 27 minuti.
A partire dai controlli invece che dai minuti
Se i tuoi dati sono un elenco di controlli anziché di tempi di disservizio, l’uptime è la quota di controlli riusciti:
Uptime % = Successful checks ÷ All checks × 100
Con un controllo al minuto, un mese di 30 giorni ha 43.200 controlli. Se 40 sono falliti, l’uptime è 43.160 ÷ 43.200 × 100 = 99,907%. Funziona solo quando i controlli vengono eseguiti a intervallo fisso, e considera ogni controllo fallito come un intero intervallo di downtime. Con controlli ogni cinque minuti, un disservizio di 30 secondi conta come cinque minuti oppure per niente.
Esempi svolti
Più incidenti nello stesso mese
Un negozio ha avuto tre incidenti in un mese di 30 giorni: 12 minuti il 4, 7 minuti il 15 e 24 minuti il 27. Prima sommali: 43 minuti. Poi (43.200 − 43) ÷ 43.200 × 100 = 99,9005%. Un mese di 30 giorni al 99,9% consente 43 minuti e 12 secondi, quindi il negozio è rimasto nell’obiettivo con 12 secondi di margine.
Escludere la manutenzione programmata
Se il tuo SLA esclude la manutenzione, togli il tempo di manutenzione dal totale, non solo dal downtime:
Uptime % = (Total time − Maintenance − Downtime) ÷ (Total time − Maintenance) × 100
Un esempio: un mese di 30 giorni con una finestra di manutenzione di 2 ore e 30 minuti di downtime non pianificato. Escludendo la manutenzione: (43.200 − 120 − 30) ÷ (43.200 − 120) × 100 = 99,930%. Contando invece la manutenzione come downtime: (43.200 − 150) ÷ 43.200 × 100 = 99,653%. Stesso mese, due numeri molto diversi: ecco perché lo SLA deve dire quale si applica.
Il monitoraggio in pausa funziona allo stesso modo. Se nessuno stava misurando, quel tempo non è né uptime né downtime, e va escluso dal totale.
Combinare l’uptime di più componenti
La maggior parte dei servizi dipende da più di un elemento. Come combinarne l’uptime dipende dal fatto che siano in serie o ridondanti.
Componenti in serie
Quando ogni componente deve funzionare, moltiplica i loro uptime. Un sito che ha bisogno sia di un application server al 99,9% sia di un database al 99,9% può arrivare al massimo a 0,999 × 0,999 = 99,8%, supponendo che si guastino in momenti diversi. Aggiungi un provider di pagamento al 99,9% e il checkout scende a circa il 99,7%. Ogni dipendenza in più abbassa il tetto.
Componenti ridondanti
Quando uno qualsiasi di due componenti può svolgere il lavoro, il servizio è down solo quando lo sono entrambi. Due server al 99% ciascuno danno in teoria 1 − (0,01 × 0,01) = 99,99%. In pratica spesso condividono una rete, un deploy o un errore di configurazione, quindi si guastano insieme più spesso di quanto preveda il calcolo. Considera il risultato un limite superiore, non una promessa.
Non fare la media tra i monitor
Se la homepage ha avuto il 100% e il checkout il 99,0%, una media del 99,5% non descrive nulla di ciò che i clienti hanno vissuto. Riporta ogni componente separatamente e definisci in anticipo quali compongono “il servizio” nel tuo SLA.
Uptime, disponibilità e affidabilità
Le tre parole sono spesso usate come sinonimi. Misurano cose diverse, e sapere quale intendi rende il numero più utile.
Uptime è la quota di tempo in cui il servizio era raggiungibile e rispondeva. È ciò che calcola la formula qui sopra, e ciò che intende la maggior parte degli SLA.
Disponibilità è la quota di tempo in cui il servizio era utilizzabile: raggiungibile, corretto e abbastanza veloce. Una pagina che si carica in 40 secondi è attiva ma non disponibile. Se conti come errori le risposte lente o sbagliate, stai misurando la disponibilità.
Affidabilità è per quanto tempo il servizio funziona senza guasti, di solito misurata come MTBF (mean time between failures, tempo medio tra i guasti). Indica quanto spesso le cose si rompono, non per quanto restano rotte.
La disponibilità collega gli altri due numeri con una formula classica:
Availability = MTBF ÷ (MTBF + MTTR)
MTTR è il tempo medio di ripristino. Un servizio che si guasta in media ogni 720 ore (una volta al mese) e impiega un’ora a riprendersi ha una disponibilità di 720 ÷ 721 = 99,86%. La formula mostra anche i due modi per migliorarla: guastarsi meno spesso o ripristinare più in fretta. MTTR, MTTA e MTBF spiegati illustra come misurare e migliorare ciascuno.
Due servizi con lo stesso uptime possono dare sensazioni molto diverse. Un disservizio di 43 minuti al mese e 43 disservizi di un minuto al mese danno la stessa percentuale, ma il secondo interrompe ogni giorno il lavoro dei tuoi utenti. Per questo conviene monitorare il numero di incidenti accanto alla percentuale di uptime.
Errori comuni
Misurare dall’interno. I log del server non possono registrare una richiesta che non è mai arrivata. Problemi DNS, certificati scaduti e guasti di rete emergono solo con controlli esterni.
Contare ogni minimo intoppo. Un singolo controllo fallito spesso dipende dalla rete, non dal tuo servizio. Conferma gli errori con un secondo controllo prima di contarli come downtime, altrimenti i tuoi numeri saranno più bassi di quanto vissuto dagli utenti.
Arrotondare per eccesso. 99,896% non è 99,9%. Quando confronti con un obiettivo, arrotonda per difetto, o mostra abbastanza decimali per distinguerli.
Controllare troppo di rado. L’intervallo dei controlli determina la risoluzione. Controllando ogni 5 o 10 minuti non puoi sapere se hai rispettato un mese al 99,95%, che consente 22 minuti.
Controllare solo la homepage. Una homepage in cache può restare online mentre login o checkout non funzionano. Monitora i percorsi da cui dipendono gli utenti.
I numeri senza un foglio di calcolo
Uptimecheck calcola l’uptime come descritto in questa guida. Il monitoraggio uptime esegue controlli fino a ogni minuto da Stoccolma, Londra e New York, e conferma ogni controllo fallito da una seconda località. L’uptime è la quota del periodo senza un disservizio confermato; le finestre di manutenzione e il tempo in pausa non vengono conteggiati contro di esso.
I report mostrano uptime, downtime e incidenti per monitor relativi a questo mese, al mese scorso o agli ultimi 7, 30 o 90 giorni, rispetto a un obiettivo SLA dal 99% al 99,99%, con download in CSV. Vedi come generare report rispetto a un obiettivo SLA.
I report per i clienti inviano gli stessi numeri alle persone per cui lavori. Vedi report per i clienti.
Le pagine di stato mostrano ai clienti 90 giorni di cronologia dell’uptime per componente. Vedi pagine di stato.
Per vedere cosa consente un obiettivo prima di impegnarti, leggi cosa significa un uptime del 99,9% o prova il calcolatore di SLA e uptime.
Smetti di calcolare l’uptime a mano. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.