Il tuo sito è giù: che fare nei primi quindici minuti

Un sito che non risponde più si risolve raramente nel codice. Il riflesso è aprire l'editor: resisti dieci minuti. La colpa non è quasi mai dove avresti guardato per primo, e quei dieci minuti passati a circoscrivere il problema ti risparmiano un'ora di tentativi. L'ordine che funziona sta in cinque gesti: confermare che il guasto è reale, individuare il livello colpevole, cercare che cosa è cambiato, dire una parola a chi se ne accorgerà, e soltanto dopo riparare.

I quindici minuti, a colpo d'occhio

Questa scansione non ha nulla di militare. Serve a una cosa sola: impedirti di passare tutti e quindici i minuti sulla prima ipotesi che ti è venuta in mente, che è anche quella a cui hai più voglia di credere.

1. Confermare il guasto, dall'esterno

Il tuo browser mente. Mette in cache, conserva vecchie voci DNS, e la rete del tuo ufficio è forse l'unica al mondo interessata.

Bastano tre verifiche, e richiedono meno di un minuto:

• Il sito in rete mobile, Wi-Fi spento. Se la pagina si apre, il problema è la tua connessione, non il sito. È il test più redditizio dell'elenco.
• Una finestra di navigazione privata. Esclude una sessione scaduta, un'estensione, un service worker rimasto dopo un deploy.
• Qualcuno in un'altra città. Un guasto regionale dell'operatore somiglia in tutto e per tutto a un guasto del server, visto dalla tua scrivania.

Se falliscono tutte e tre, il guasto è reale, e lo sai prima di avere aperto un solo file. Se una funziona, ti sei appena risparmiato un'ora a cercare un guasto che non esisteva. Questo passaggio viene saltato di continuo perché sembra troppo semplice, ed è quello che ha evitato il maggior numero di mattinate perse.

2. Individuare il livello colpevole

Il messaggio di errore esatto vale più di qualsiasi intuizione. Annotalo parola per parola, con l'ora, prima di proseguire: tra mezz'ora non te ne ricorderai, ed è l'unica informazione che nessuno potrà ricostruire dopo.

I tre codici della famiglia 500 si distinguono male a occhio nudo e non si riparano affatto allo stesso modo: che cosa significa ciascun codice merita due minuti di lettura prima del primo comando.

3. Cinque comandi che rispondono in trenta secondi

Per questo passaggio un terminale vale più di un browser: non mette nulla in cache e ti restituisce il codice grezzo.

curl -I https://esempio.it           # il codice restituito, senza browser
dig +short esempio.it                # il dominio punta ancora dove deve
ping -c 3 esempio.it                 # la macchina è almeno raggiungibile
echo | openssl s_client -connect esempio.it:443 2>/dev/null | openssl x509 -noout -dates
tail -n 100 /var/log/nginx/error.log # oppure storage/logs/laravel.log secondo lo stack

La prima riga basta a separare «non risponde nulla» da «qualcosa risponde male», che sono due guasti senza alcun rapporto. La seconda intercetta il caso che nessuno sospetta abbastanza presto: un record DNS modificato la settimana scorsa e propagato solo adesso. L'ultima è quella che si salta sempre, ed è quasi sempre quella che contiene la risposta.

4. Chiedersi che cosa è cambiato

Quasi ogni guasto segue un cambiamento, e il cambiamento non è sempre il tuo.

• Un deploy stamattina, per quanto minuscolo e «senza rischi».
• Un aggiornamento automatico stanotte: sistema, estensione o dipendenza.
• Un certificato scaduto alle due del mattino.
• Un nome a dominio arrivato a scadenza.
• Un addebito rifiutato presso l'hosting, con l'avviso finito nello spam.
• Una API di terzi che ha cambiato versione senza avvisare nessuno.

Nel raro caso in cui da te non si sia mosso nulla, il cambiamento è avvenuto altrove, e nessun messaggio te lo porterà: il tuo hosting non ti avvisa, e non è cattiva volontà, è il modo in cui sono pensati i suoi avvisi.

5. Dire una parola, prima che te la chiedano

Se il guasto supera i dieci minuti, tre righe sul canale che i tuoi clienti leggono davvero valgono più di una spiegazione perfetta pubblicata tre giorni dopo.

Il sito non è raggiungibile dalle 14:20. Abbiamo individuato la causa e ci stiamo lavorando. Prossimo aggiornamento alle 15, nello stesso posto.

Quel messaggio dice tre cose e non una di più: da quando, a che punto sei, quando ne riparlerai. Non promettere un orario di ripristino finché la causa è sconosciuta: una promessa mancata costa più del silenzio. Per un cliente sotto contratto, l'incidente finirà comunque nel report del mese; meglio che ci arrivi con le tue parole invece che con le sue.

6. I cinque gesti che peggiorano la situazione

• Riavviare il server prima di avere letto il log. Il riavvio cancella spesso la traccia di ciò che si è rotto. Il guasto torna due ore dopo, e non ne sai di più.
• Toccare il DNS. Una modifica di zona impiega ore a propagarsi, e così aggiungi un guasto al guasto.
• Rilasciare una correzione non testata. Sotto pressione, la probabilità di peggiorare supera ampiamente quella di riparare.
• Svuotare tutte le cache insieme. Perdi l'informazione che ti avrebbe detto quale fosse in causa, e carichi il database nel momento peggiore.
• Annunciare un orario di ripristino. Finché la causa è sconosciuta, ogni scadenza annunciata è una scadenza che verrà mancata.

7. Poi, l'unica domanda che conta

Non perché si è rotto: adesso lo sai. La vera domanda è: quanto ci ho messo a saperlo?

Se la risposta è «me l'ha detto un cliente», il guasto non era l'incidente. L'incidente era essere l'ultimo informato. E il conto non è simbolico: quanto costa davvero un'ora di disservizio si può calcolare, anche per un sito che online non vende nulla.

Questa parte si sistema in pochi minuti: una verifica che gira da sola, una email appena il sito smette di rispondere, un'altra al ritorno alla normalità. Restano due regolazioni che contano quanto lo strumento, ogni quanto controllare e che cosa trasforma una verifica in un avviso, senza le quali avrai soltanto sostituito il silenzio con il rumore. E se sei ancora indeciso tra uno script fatto in casa e un servizio esterno, il confronto onesto è in monitoraggio interno o servizio esterno.

Quando non è un guasto

Un caso merita un riflesso tutto suo, perché somiglia a un guasto senza esserlo: un certificato scaduto. Il server risponde perfettamente, è il browser che si rifiuta di mostrare la pagina. Nulla nei tuoi log applicativi lo segnalerà, riavviare qualsiasi cosa non cambierà niente, e l'unico indizio è quell'avviso rosso che i tuoi visitatori vedono prima di te.