Il sito funziona? Monitoraggio uptime e incidenti
Quanto velocemente un'azienda si accorge che il proprio sito è down; come impostare monitoraggio uptime, catena di allerta e un post mortem utile.
Team rabbitclipPubblicato: 5 min di lettura
In breve
Il monitoraggio uptime è un controllo esterno che gira secondo un calendario e registra se un sito o un'app risponde davvero. Un controllo di base guarda solo se la homepage si carica; una configurazione più affidabile testa una transazione reale, checkout, login, invio di un modulo, con la stessa frequenza. Lo scopo è notare un'interruzione prima che lo faccia un cliente, e questo funziona solo se un'allerta è definita in anticipo: chi raggiunge, su quale canale, entro quanto tempo.
Se la pagina di checkout di un produttore di abbigliamento da lavoro inizia a dare errori una domenica mattina, la cosa può passare inosservata per ore se un reclamo del cliente ne è il primo segnale. Un controllo che monitora il flusso di checkout stesso rileva lo stesso guasto in pochi minuti e avvisa la persona giusta; la differenza sta tra una perdita di ore e una reazione di pochi minuti.
Cosa misura davvero il monitoraggio uptime?
Il monitoraggio uptime è la registrazione del fatto che un server o una pagina, interrogato da un punto di controllo esterno secondo un calendario, di solito ogni uno-cinque minuti, risponda affatto. La risposta deve sia esistere sia portare il contenuto atteso, il codice di stato corretto, un testo specifico sulla pagina; che il server sia semplicemente raggiungibile non basta da solo, la pagina deve davvero funzionare.
Questo tipo di controllo rileva bene un server completamente down o che ha smesso di rispondere, ma non sempre coglie un rallentamento, un errore parziale, o un problema che appare solo in un browser. Per questo il monitoraggio uptime si affianca al tracciamento degli errori e al monitoraggio delle prestazioni, non li sostituisce.
Quale controllo rileva quale problema?
Diversi tipi di controllo coprono rischi diversi; sceglierne uno non rende gli altri inutili.
- controllo ping/HTTP: se il server risponde affatto, in pochi secondi
- controllo di contenuto: se la pagina si è caricata correttamente, in base a un testo specifico o a un codice di stato
- controllo sintetico: se un processo multi-step come checkout, login o invio di un modulo funziona end to end
- controllo del certificato SSL: quanto manca alla scadenza del certificato
Come costruire una catena di allerta
Un'allerta che non raggiunge nessuno, o che raggiunge tutti insieme così che nessuno se ne fa carico, è dove il monitoraggio fallisce più spesso nella pratica. Un'escalation a gradini riduce questo rischio.
- rilevamento iniziale: il controllo automatico conferma il guasto su 2-3 tentativi consecutivi, così un semplice intoppo di rete non viene scambiato per un'interruzione
- 0-5 minuti: notifica immediata alla persona reperibile, in-app o via email
- 5-15 minuti: senza risposta parte un SMS o una chiamata, e viene avvisata una seconda persona
- dopo 15 minuti: interviene un responsabile, la pagina di stato viene aggiornata
Cosa succede durante un'interruzione?
Il primo compito appena viene rilevata un'interruzione non è risolverla ma capirne la portata: è down tutto il sito o solo una parte, quanti utenti sono colpiti, quando è iniziata. Agire senza questa informazione rischia di correggere la cosa sbagliata mentre si perde di vista la causa reale.
Una pagina di stato pubblica si rivela utile in questo momento; permette al supporto di indirizzare ogni cliente verso un'unica pagina aggiornata invece di rispondere a ciascuno singolarmente. La pagina va aggiornata fino alla fine dell'interruzione, e chiusa una volta risolta.
Perché la revisione post incidente non va mai saltata
Una volta risolta l'interruzione, si scrive una breve revisione: cosa è successo, quando è stata notata, quanto tempo ha richiesto risolverla, cosa cambierà perché non accada di nuovo. Il documento esiste per prevenire una ripetizione, non per assegnare colpe.
Se il sistema di prenotazione di una catena di spa si blocca due volte di fila per la stessa ragione, il problema non è tecnico ma procedurale; quanto la prima revisione aveva chiesto di correggere non è mai stato davvero applicato. Una seconda interruzione per la stessa causa merita di essere presa più sul serio della prima, non meno.
Errori frequenti
Il monitoraggio uptime può trasformarsi in uno strumento impostato una volta e poi dimenticato; questo accade quasi tanto spesso quanto le interruzioni che dovrebbe rilevare.
- monitorare solo la homepage lasciando checkout o login senza sorveglianza
- inviare le allerte a una sola persona, così che nessuno nota la sua assenza
- controllare troppo di rado, per esempio ogni trenta minuti, perdendo del tutto le interruzioni brevi
- passare direttamente alla crisi successiva senza fare una revisione post incidente
Il monitoraggio uptime non previene un'interruzione; fa sì che venga notata prima di un cliente e gestita in modo ordinato. Una catena di allerta ben costruita e l'abitudine a una breve revisione post incidente accorciano la durata della prossima. Una prima chiamata con rabbitclip è un buon punto per rivedere insieme la vostra attuale configurazione di monitoraggio.
Domande frequenti
Il monitoraggio uptime si può fare con strumenti gratuiti?
Sì, un controllo ping/HTTP di base è coperto da molti piani gratuiti. Il monitoraggio sintetico e controlli più frequenti si trovano di solito nei piani a pagamento.
Con quale frequenza dovrebbero girare i controlli?
Uno-cinque minuti è comune per le pagine critiche. Controlli più frequenti rilevano prima i problemi, ma aggiungono anche carico al server.
Ogni sito ha bisogno di una pagina di stato?
Vale la pena averla per i siti con forte interazione con i clienti e per l'e-commerce. Un sito vetrina a basso traffico può farne a meno.
La revisione post incidente serve ad assegnare colpe?
No. Lo scopo è evitare una ripetizione; la revisione esamina il processo e il sistema, non una persona.
