L’MTTR (mean time to recovery, o repair) è il tempo medio che passa dall’inizio di un incidente al ripristino del servizio. L’MTTA (mean time to acknowledge) è il tempo medio che passa da un avviso al momento in cui qualcuno conferma di starci lavorando. L’MTBF (mean time between failures) è il tempo medio in cui un servizio funziona regolarmente tra un incidente e l’altro. Insieme descrivono l’affidabilità: l’MTBF dice quanto spesso qualcosa si guasta, l’MTTA quanto velocemente reagisci e l’MTTR per quanto tempo i clienti ne risentono.
Questa guida tratta le definizioni, le formule, un esempio svolto con i numeri, quali timestamp raccogliere e le modifiche pratiche che migliorano ciascuna metrica.
Le metriche e cosa misurano
MTTR: quattro significati, un solo acronimo
L’MTTR è la metrica sugli incidenti più citata e anche la più ambigua, perché la R indica cose diverse a seconda di chi la usa:
Mean time to repair (tempo medio di riparazione): dall’inizio dell’intervento di riparazione a quando la correzione è applicata. Diffuso nell’hardware e nella manutenzione.
Mean time to recovery, o restore (tempo medio di ripristino): dall’inizio del disservizio a quando il servizio torna a funzionare per gli utenti. La versione più utile per siti web e API.
Mean time to respond (tempo medio di risposta): dall’avviso a quando il team inizia ad agire. Molto vicino all’MTTA.
Mean time to resolve (tempo medio di risoluzione): fino alla chiusura completa dell’incidente, comprese le azioni successive che ne impediscono la ripetizione.
Nessuna è sbagliata. L’importante è sceglierne una, mettere la definizione per iscritto e usarla in modo coerente. Confrontare il tuo dato di “ripristino” con il dato di “riparazione” di qualcun altro non ti dice nulla. In questo articolo, MTTR significa mean time to recovery: da quando il servizio si è guastato a quando è tornato a funzionare.
MTTD e MTTA: la reazione prima della riparazione
L’MTTD (mean time to detect) è il tempo che passa dall’inizio di un incidente a quando il monitoraggio lancia un avviso. L’MTTA è il tempo che passa da quell’avviso a quando una persona lo prende in carico. Entrambi rientrano nell’MTTR, ed è per questo che contano tanto: nessuno può risolvere un problema di cui non è stato informato.
MTBF: quanto spesso qualcosa si guasta
L’MTBF è l’uptime medio tra un incidente e l’altro. Più è alto, meglio è. La metrica affine MTTF (mean time to failure) si usa per componenti che vengono sostituiti anziché riparati, come i dischi; per i servizi online, quella che ti serve è l’MTBF.
Le formule
MTTD = tempo totale dall’inizio dell’incidente all’avviso / numero di incidenti
MTTA = tempo totale dall’avviso alla presa in carico / numero di incidenti
MTTR = tempo totale dall’inizio dell’incidente al ripristino / numero di incidenti
MTBF = tempo totale di funzionamento senza incidenti / numero di incidenti
Disponibilità = MTBF / (MTBF + MTTR)
L’ultima riga mostra perché contano entrambi i lati. Puoi migliorare la disponibilità con meno incidenti (MTBF più alto) o accorciandoli (MTTR più basso). Accorciarli costa spesso molto meno.
Un esempio svolto
Ecco un mese di esempio per un negozio online, con quattro incidenti. I numeri sono inventati a scopo illustrativo, ma i timestamp sono quelli che ti fornisce qualsiasi strumento di monitoraggio.
IncidenteInizioAvvisoPresa in caricoRipristinoRilevamentoPresa in caricoRipristinoCheckout 50303:1203:1303:1603:191 min3 min7 minTimeout API10:0510:0610:0810:411 min2 min36 minErrori di login14:3014:3114:4515:021 min14 min32 minRicerca non disponibile22:5022:5122:5623:151 min5 min25 min
Ora applica le formule:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minuto.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minuti.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minuti.
MTBF: un mese di 30 giorni ha 43.200 minuti. Togliendo 100 minuti di downtime ne restano 43.100. Diviso per 4 incidenti, l’MTBF è di 10.775 minuti, circa 7,5 giorni.
Disponibilità = 10.775 / (10.775 + 25) = 99,77%.
Saltano all’occhio due cose. I 14 minuti di presa in carico sull’incidente di login fanno salire l’MTTA da circa 3 a 6 minuti, quindi vale la pena chiedersi perché nessuno abbia raccolto quell’avviso. E con il 99,77% questo negozio è ben lontano da un obiettivo del 99,9%, che concede solo 43 minuti al mese. Se stai definendo obiettivi di questo tipo, leggi SLA, SLO e SLI a confronto per capire come si collegano.
Ora immagina lo stesso mese con controlli ogni cinque minuti e nessun passaggio di conferma. Il rilevamento potrebbe richiedere fino a cinque minuti invece di uno, aggiungendo fino a quattro minuti a ogni incidente. L’MTTR sale da 25 fino a 29 minuti prima ancora che qualcuno abbia fatto qualcosa di diverso.
Quali timestamp raccogliere
Ti servono quattro timestamp per incidente. La maggior parte arriva direttamente dal monitoraggio:
Inizio: il primo controllo fallito. Il monitoraggio esterno lo registra anche quando i tuoi server non registrano nulla.
Avviso: quando il guasto è stato confermato ed è partita la notifica.
Presa in carico: quando una persona ha detto “ci penso io”. Se non hai uno strumento di reperibilità, va bene una risposta nel canale degli incidenti; annota l’orario. In Uptimecheck prendi in carico l’incidente nell’app oppure, con l’app Slack, con un pulsante in Slack, e l’orario viene registrato.
Ripristino: il primo controllo riuscito dopo l’incidente, che è anche il momento in cui parte la notifica di ripristino.
Con Uptimecheck ogni incidente ha una timeline: quando è iniziato, chi è stato avvisato e quando, le prese in carico (anche con un pulsante in Slack se usi l’app Slack), le note e il ripristino. MTTA e MTTR vengono calcolati per te, e l’esportazione CSV del report riporta per ogni monitor il numero di incidenti, il downtime e l’incidente più lungo, pronti per un foglio di calcolo. Aggiungi ciò che hai imparato in un postmortem.
Un avvertimento pratico: le medie nascondono i valori anomali. Un incidente di sei ore e nove interruzioni di un minuto danno una media di circa 37 minuti, che non descrive né l’uno né le altre. Guarda la mediana e l’incidente più lungo insieme alla media, e analizza uno per uno gli incidenti più lenti.
Come ridurre il tempo di rilevamento
Controlla ogni minuto
L’intervallo di controllo è il limite massimo del tuo tempo di rilevamento. Controlli ogni minuto su tutto ciò che genera fatturato o serve i clienti sono il miglioramento più economico in assoluto per l’MTTR. Usa il monitoraggio uptime a 1 minuto per ogni pagina ed endpoint critico.
Controlla ciò che si rompe, non solo ciò che si carica
Gli incidenti che il monitoraggio non vede vengono scoperti dai clienti, spesso ore dopo. Verifica il contenuto delle pagine importanti, monitora gli endpoint API su cui si basano le app e aggiungi heartbeat ai job pianificati. Ogni incidente segnalato per primo da un cliente è una lacuna nel tuo monitoraggio.
Come ridurre il tempo di presa in carico
Invia solo avvisi confermati
Una presa in carico lenta è di solito un problema di fiducia. Se metà degli avvisi sono falsi, le persone imparano ad aspettare e vedere. Conferma ogni guasto con un secondo controllo prima di avvisare, e rimuovi i monitor che inviano avvisi senza che nessuno debba intervenire. La nostra guida per ridurre i falsi allarmi entra nei dettagli.
Indirizza gli avvisi sul canale giusto
Un’email delle 03:12 verrà letta alle 07:30. Invia i monitor critici a un canale che arrivi sul telefono della persona reperibile e a una chat di team per tutti gli altri, e lascia sull’email i monitor meno urgenti. Uptimecheck ti permette di scegliere i canali di avviso per ogni monitor: email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhook e notifiche push sul telefono, su ogni piano. L’escalation può trattenere un canale da 5 a 60 minuti e avvisare solo se il disservizio è ancora in corso e nessuno l’ha preso in carico.
Chiarisci le responsabilità
Un avviso inviato a cinque persone spesso non viene preso in carico da nessuna. Nomina un responsabile per servizio e una persona reperibile per turno. Tutti gli altri ricevono l’informazione, non la responsabilità. Con i turni di reperibilità di Uptimecheck le persone si alternano, con sostituzioni per un giorno di malattia o uno scambio, e gli avvisi push raggiungono chi è reperibile in quel momento.
Come ridurre il tempo di riparazione
Scrivi dei runbook per i guasti noti
La maggior parte degli incidenti si ripete. Il disco si riempie, un pool di worker si esaurisce, il rinnovo di un certificato fallisce. Un breve runbook per monitor trasforma un’indagine fatta nel dormiveglia in una checklist:
Runbook: il checkout restituisce 503
1. Controlla la dashboard del server: CPU, memoria, disco su web-01 e web-02.
2. Controlla lo stato di PHP-FPM: sudo systemctl status php8.3-fpm
3. Se i worker sono esauriti: sudo systemctl restart php8.3-fpm
4. Cerca job di lunga durata: ps aux –sort=-%cpu | head
5. Ancora in errore dopo 10 minuti? Coinvolgi il lead developer.
Tieni il link al runbook dove arriva l’avviso, per esempio fissato nel canale degli incidenti, così è a portata di tap.
Metti causa e sintomo fianco a fianco
Quando il controllo di un sito fallisce, la prima domanda di solito è se il server ha esaurito memoria, CPU o disco. Avere le metriche del server accanto ai controlli uptime riduce questo passaggio da una sessione SSH a un’occhiata.
Rendi semplice il rollback
Molti incidenti iniziano con un deploy. Se il rollback è un solo comando, il ripristino richiede minuti. Se serve una riunione, richiede un’ora.
Aggiorna subito la pagina di stato
Una pagina di stato non accorcia il disservizio in sé, ma accorcia la parte che i clienti vivono peggio: non sapere. Evita anche che il supporto venga sommerso mentre il team risolve il problema. Una pagina di stato collegata ai tuoi monitor mostra il componente interessato non appena si apre l’incidente; aggiungi una breve nota su cosa stai facendo e su quando darai il prossimo aggiornamento.
Migliorare l’MTBF
Gli incidenti diminuiscono imparando da quelli già avvenuti. Dopo ogni incidente significativo, scrivi un postmortem senza colpe, concorda una o due azioni correttive e seguile fino al completamento. Nel giro di qualche mese gli stessi guasti smettono di ripresentarsi e l’MTBF sale.
Inizia a misurare con timestamp reali. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.