Le due direzioni condividono un'unica formula. Parti da una percentuale SLA e ottieni il downtime che consente (è quello che fa il nostro calcolatore uptime). Parti dal downtime che hai avuto, come fa questa pagina, e ottieni la percentuale di uptime che ne è risultata: (finestra − downtime) ÷ finestra × 100. Noi aggiungiamo i due numeri che un foglio di calcolo non ti dà: quanto è costato e dove sono finiti i minuti.

Dividi il downtime per la finestra, per 100. Un'interruzione di 43m 48s in un mese di 30,42 giorni: 2.628 s ÷ 2.628.000 s × 100 = 0,1% di downtime — cioè 99,9% di uptime. Due regole: somma ogni incidente nella finestra (non fare la media), e misura dalla prima richiesta fallita al ripristino verificato.

Tra due e tre nove è la fascia normale per servizi in produzione di piccole e medie dimensioni — da 43 minuti a 7 ore al mese. Tre nove (43m 48s al mese) è il target di riferimento: raggiungibile con un buon hosting, rollback rapidi e qualcuno in reperibilità. Se il tuo mese supera le 7 ore, la tabella dei danni qui sopra mostra la valutazione che stai ottenendo — e la sezione della cronologia nel risultato mostra dove recuperare minuti per primo.

Lascia perdere le cifre-al-minuto sbandierate dalle survey enterprise — mettono nella stessa media banche e panetterie. Il tuo tetto massimo è la tua aritmetica: ricavi orari × ore offline, più le persone che hanno lasciato tutto, più eventuali penali contrattuali. La sezione costi del risultato lo calcola in tempo reale con i tuoi numeri. Due avvertenze. Alcuni acquirenti interrotti tornano più tardi, quindi il ricavo perso è un tetto massimo. E alcuni costi non entrano proprio nel foglio di calcolo: fiducia, SEO, arretrato di supporto.

Contano come hai deciso che contano — prima dell'incidente. Prassi comune: un percorso critico rotto (checkout, login) conta per intero anche se la homepage si carica; il funzionamento degradato conta a parte o non conta affatto. Scrivi la definizione e applicala sempre allo stesso modo. Le discussioni sugli SLA riguardano questo paragrafo, non l'aritmetica.

MTTR è il tempo medio di ripristino: downtime totale ÷ numero di incidenti. È la tua leva migliore, perché dimezzarlo dimezza il downtime senza prevenire un solo incidente. MTBF è il tempo medio tra i guasti, cioè quanto spesso le cose si rompono. Dipende dall'architettura e dalla disciplina nei cambiamenti, non dalla velocità di risposta. Insieme danno la disponibilità: MTBF ÷ (MTBF + MTTR). RTO è l'MTTR che hai promesso — per quanto tempo un'interruzione può durare prima che il piano di ripristino sia considerato fallito. Mettilo alla prova prima che lo faccia un incidente.

Attacca prima l'MTTR e poi l'MTBF — ripristinare più in fretta costa meno che guastarsi di meno. E dentro l'MTTR, attacca prima il rilevamento: è l'unica fase che uno strumento può ridurre da solo, in modo diretto. Nel nostro esempio pratico, il rilevamento ha richiesto 11 minuti e la correzione 4. Controlli ogni trenta secondi limitano il silenzio prima del primo controllo fallito a mezzo minuto — non possono accorciare la consegna dell'avviso né il tempo che qualcuno impiega a rispondere al telefono, ed è per questo che qui il rilevamento si riduce di quattro minuti, non di undici. La diagnosi si riduce con le prove (risultati multi-località, timestamp precisi); la correzione si riduce con rollback provati — quella parte tocca a te.

Non puoi calcolare quello che non hai notato — il riavvio delle 3 di notte nel nostro registro di giugno esiste solo perché qualcosa lo stava osservando. Un monitoraggio indipendente ti dà gli input di cui questo calcolatore ha bisogno: orari di inizio e fine esatti, dall'esterno della tua infrastruttura. Questo copre ogni incidente, compresi quelli per cui nessuno era sveglio. Uptimia monitora da oltre 171 località in oltre 70 paesi — ogni 60 secondi nel piano Basic, ogni 30 dal piano Professional in su — e tiene quel registro al posto tuo.