Quando un Servizio Esterno si Degrada, la Segnalazione di Bug Arriva a Te

Poco dopo la mezzanotte del 27 agosto 2026, la temperatura nella sala del datacenter principale di Proton a Francoforte è salita da 21,8 °C a 51,9 °C in meno di trenta minuti. Un sistema di raffreddamento aveva fallito e l’apparecchiatura di rete che aveva raggiunto 105 °C si è messa in modalità di protezione che l’ha disabilitata fino a un reset a freddo. Proton è stata offline per circa due ore.

Vale la pena leggere non che è successo - l’infrastruttura di tutti fallisce prima o poi - ma il rapporto dell’incidente che Proton ha pubblicato in seguito, che è specifico in un modo che la maggior parte non è. Nomina la causa: una sostituzione del filtro dell’aria nei compressori d’aria ridondanti, effettuata dall’operatore del datacenter “nel mezzo della notte, senza preavviso”, che “ha anche mancato di comunicare il guasto di raffreddamento quando è successo”. Spiega perché il recupero è stato lento piuttosto che istantaneo - il team ha scelto di salvare l’hardware piuttosto che ripristinare il servizio rapidamente, perché sostituirlo è difficile “con il boom dell’AI in corso” che mette a dura prova l’offerta. Un postmortem così specifico è un favore a chiunque faccia funzionare qualcosa, e vale la pena dirlo.

Ma c’è una seconda cosa in esso degna dell’attenzione di chiunque riceva rapporti di bug, ed è facile perderla. Il sintomo visibile all’utente non era un messaggio che diceva “Proton è down”. Era questo, nelle loro parole: “Nessun’email è stata persa, ma la consegna delle email in entrambe le direzioni è stata ritardata.”

Il guasto che non si annuncia

Un’interruzione totale è il caso facile. Il sito restituisce un 503, la pagina non si carica, tutti capiscono nel giro di un minuto che il problema non è loro.

Una degradazione è il caso difficile. Qualcosa da cui dipendi diventa lento, oppure perde una richiesta su venti, oppure ritarda una consegna - e rimane abbastanza attivo che nulla annunci il guasto. Il sintomo non emerge nel punto in cui si trova il guasto. Emerge nel sistema successivo, che molto spesso è il tuo, indossato da un utente che non ha alcuna ragione di sospettare un datacenter a Francoforte e ogni ragione di sospettare l’app davanti a loro.

Quindi il rapporto che ricevi non dice “il mio provider sta avendo un incidente di raffreddamento”. Dice “la tua app è lenta”, oppure “non ha inviato”, oppure “ha funzionato stamattina e ora no” - e trascorri la prima ora guardando nel posto in cui il problema non è, perché è lì che la persona ha indicato.

Distinguere la loro interruzione dal tuo bug, mentre sta accadendo

La distinzione è solitamente visibile in pochi minuti se sai cosa guardare, e questo è all’incirca l’ordine.

È solo quella dipendenza? Una degradazione upstream fallisce in un modello: le richieste che toccano quel servizio sono lente o stanno fallendo, e tutto il resto sulla pagina va bene. Un bug di tua proprietà è raramente così ordinato. Apri la scheda Network e guarda quali richieste sono rosse o lente. Se vanno tutte verso un host e nient’altro è interessato, stai guardando il pomeriggio di qualcun altro.

Qual è la forma del guasto? Un 504 Gateway Timeout è un server davanti a un altro server che non ha mai risposto - un’impronta specifica di un upstream che è attivo ma non sta rispondendo, che è esattamente come una degradazione sembra da fuori. Una richiesta che si blocca e poi va in timeout, piuttosto che una che restituisce un errore che il tuo codice ha prodotto, punta nella stessa direzione.

La pagina di stato del provider è d’accordo? Spesso ritarda l’incidente di parecchi minuti, quindi una pagina di stato verde all’inizio non prova nulla - il guasto ti ha raggiunto prima che raggiungesse la loro dashboard. Ma una volta che cambia, risolve la questione. Controllala, e verifica i timestamp rispetto a quando i tuoi rapporti hanno iniziato.

Hai cambiato qualcosa di tuo? Se non hai effettuato un deploy, e il codice che ora sta fallendo ha funzionato un’ora fa e non è stato toccato, la cosa che è cambiata è più probabile che sia dall’altro capo del filo piuttosto che in un file che puoi vedere.

La versione completa di questo - il ragionamento per ogni controllo e come eseguirlo sotto pressione - è in È un Tuo Bug o Loro Interruzione.

Cosa catturare così non stai discutendo di questo dopo

Il problema con una degradazione upstream è che è sparita nel momento in cui qualcuno ti chiede di provare che non era colpa tua. Il provider si recupera, la pagina di stato diventa verde, il postmortem appare una settimana dopo, e quello che hai è un ricordo di un brutto pomeriggio e nessun record.

Quindi mentre sta accadendo, cattura le prove che legano il sintomo all’esterno: le richieste fallite con i loro codici di stato e i tempi, i timestamp, la risposta che l’upstream ha effettivamente restituito. Questa è la differenza tra “pensiamo fosse il nostro provider” e un rapporto con i 504 e i ritardi di consegna seduti accanto alla timeline dell’incidente del provider. Uno è una discussione; l’altro è chiuso.

Il log di rete che cattura è il record di esattamente quali richieste hanno fallito e quanto tempo hanno impiegato, salvato nel momento in cui è andato male piuttosto che ricostruito in seguito. Quando la domanda è se il guasto era tuo o loro, quel log è quello che lo risponde - e non si dissolve quando il provider si recupera.