Nelle prime ore del 27 agosto 2026, Proton ha riscontrato un disservizio esteso che ha impattato i servizi per diversi utenti. La causa principale è stata un guasto totale del sistema di raffreddamento nel nostro data center di Francoforte. Sebbene tutti i sistemi di Proton siano ridondanti e disponiamo di una capacità sufficiente per sopportare il guasto completo di un data center, esiste un numero ridotto di scenari in cui il failover può richiedere più tempo e causare disagi agli utenti.

Ecco una cronologia di quanto accaduto, delle decisioni che abbiamo preso durante l’incidente, delle relative motivazioni e di come è stato risolto.

Cronologia

Poco dopo le 23:00 (ora dell’Europa centrale) di mercoledì 26 agosto, si è verificato un guasto al sistema di raffreddamento nella sala principale del nostro data center di Francoforte. Verso le 23:15, la temperatura ha iniziato a salire da circa 21,8 °C (temperatura nominale) a 51,9 °C in meno di mezz’ora, con alcune sonde di misurazione che rilevavano una temperatura dell’aria di 60 °C nella stanza. Con l’aumento delle temperature, i server e gli apparati di rete all’interno della struttura hanno iniziato a cedere uno dopo l’altro.

L’incidente con impatto sugli utenti è iniziato intorno alla mezzanotte del 27 agosto, quando i guasti si sono intensificati al punto da causare la perdita della ridondanza critica. Ciò è avvenuto quando sia lo switch di rete principale che quello di backup su un rack critico hanno smesso di funzionare; purtroppo, questo rack conteneva diverse copie di database principali. Sebbene quasi tutti i sistemi Proton siano ridondanti ed eseguano il failover automaticamente e immediatamente, i failover dei database principali non vengono eseguiti automaticamente senza supervisione umana.

Manteniamo questo controllo per evitare le cosiddette situazioni di “split brain”, in cui una temporanea indisponibilità di un database principale fa sì che le copie di replica perdano alcuni aggiornamenti e si desincronizzino in modi che possono essere difficili da riconciliare in seguito. Inoltre, quando si verifica il failover di un database principale, la procedura operativa standard prevede il failover su una replica nello stesso data center per motivi di latenza e prestazioni. Tuttavia, la natura specifica del problema faceva sì che questa potesse essere una scelta sconsigliabile, poiché avremmo potuto potenzialmente eseguire il failover verso qualcosa che avrebbe a sua volta smesso di funzionare.

Le decisioni

A questo punto, i tecnici reperibili di Proton hanno dovuto prendere un paio di decisioni importanti operando sotto estrema pressione.

  • Dare la priorità al ripristino del servizio online oppure concentrarsi sulla risoluzione del problema di raffreddamento per salvare l’hardware all’interno del data center?
  • Eseguire il failover sulle repliche nello stesso edificio a Francoforte (più rapido e meno dirompente, ma potenzialmente una soluzione temporanea se il calore non fosse stato riportato sotto controllo) oppure eseguire il failover su Zurigo?
  • Eseguire il failover di tutto o solo di ciò che è attualmente inattivo? Abbiamo piani di emergenza per il guasto completo di un data center, in cui il failover dei componenti avviene in modo completo e per lo più automatico e piuttosto rapido, ma una situazione in cui server casuali cedono uno dopo l’altro non è gestita in modo ottimale dalla nostra logica di failover.

Alla fine, la velocità con cui le temperature salivano ci ha costretto a dare priorità al salvataggio dell’hardware rispetto al ripristino dei servizi online. Non è una scelta che si deve fare di solito, poiché i sistemi di raffreddamento sono in genere ridondanti e la perdita totale del raffreddamento è piuttosto rara, il che significa che solitamente c’è parecchio tempo prima che le temperature diventino critiche. Il problema è stato aggravato dal notevole aumento della densità di potenza dei server negli ultimi anni, con CPU e GPU più potenti destinate all’IA. Di conseguenza, ciò che in passato avrebbe impiegato 3-4 ore per diventare critico, lo è diventato in soli 20 minuti.

Il team di reperibilità si è quindi concentrato sulla comunicazione con il team operativo in loco del data center per ripristinare il raffreddamento, spegnendo al contempo il maggior numero possibile di server per proteggerli. A causa della carenza di apparati server legata al boom dell’IA in corso, molti di questi componenti, se persi, non sarebbero stati sostituibili in tempi brevi. Salvarli doveva essere una priorità, anche a costo di prolungare potenzialmente il tempo di inattività.

Entro le 00:45 CEST siamo riusciti a ripristinare il raffreddamento e le temperature nella struttura hanno iniziato a scendere, consentendo al team di reperibilità di concentrarsi sul ripristino del servizio. A questo punto, abbiamo preso la decisione di eseguire il failover dei database principali su Francoforte se una replica era ancora attiva, e su Zurigo nei casi in cui non vi fossero repliche attive a Francoforte, per evitare di alterare eccessivamente i flussi di traffico e generare potenzialmente nuova instabilità. Questa opzione è stata scelta perché abbiamo ipotizzato che, con il raffreddamento sotto controllo, riportare Francoforte online sarebbe stato relativamente semplice e più veloce rispetto al passaggio a Zurigo.

Purtroppo, le cose non sono andate così. Durante l’incidente, molte schede di rete nell’infrastruttura di Francoforte hanno raggiunto una temperatura di 105 °C (la normale temperatura di esercizio è di 45 °C), che attiva una speciale modalità di protezione termica e causa la disattivazione delle schede di rete fino a un riavvio a freddo del sistema. I nostri criteri di sicurezza limitano la possibilità di accedere al controller out-of-band dei nostri sistemi, il che ci ha costretto a mobilitare ulteriore personale per contribuire al ripristino.

Entro le 01:30 CEST, siamo riusciti a riportare online la maggior parte dei servizi per la maggior parte degli utenti. Tuttavia, alcuni sistemi meno critici, come le notifiche push o l’elaborazione dei pagamenti, non sono stati ripristinati fino alle 02:00 CEST circa.

Come segnalato nel resoconto iniziale sull’incidente, nessuna email è andata persa, ma la consegna delle email in entrambe le direzioni ha subito ritardi durante l’incidente.

Sebbene i servizi destinati agli utenti siano stati completamente ripristinati, la notte non era ancora finita per i nostri ingegneri, in particolare per il team dei database. La nostra infrastruttura si trovava in uno stato fortemente anomalo, con alcuni database principali a Zurigo e altri a Francoforte, e molti di essi funzionanti con ridondanza e/o prestazioni ridotte. Il nostro team ha lavorato tutta la notte per risolvere i problemi più urgenti, e i lavori sono proseguiti per tutta la giornata del 27 agosto per ripristinare la completa ridondanza.

Sebbene siamo riusciti a salvare quasi tutta l’infrastruttura, purtroppo alcuni server sono rimasti irrimediabilmente danneggiati dal calore e non sappiamo ancora se l’incidente termico influirà sulla durata dei componenti superstiti.

Causa principale e prossimi passi

Una successiva indagine condotta il 27 agosto ha ricondotto la causa principale del guasto al raffreddamento alla sostituzione dei filtri dell’aria su entrambi i compressori ridondanti che alimentano il sistema di raffreddamento. Purtroppo, il gestore del data center ha eseguito questa operazione nel cuore della notte, senza preavviso, e non ha comunicato il guasto al raffreddamento al momento del suo verificarsi, riducendo drasticamente il tempo a nostra disposizione per intervenire. Stiamo collaborando a stretto contatto con il gestore per evitare che un incidente simile si ripeta.

Tuttavia, è anche un limite noto della nostra attuale infrastruttura di database il fatto che un disservizio di questo tipo possa comportare un processo di ripristino più lungo del normale. La serie di eventi che ha portato a questo incidente è altamente improbabile, eppure si è verificata.

I lavori sulla resilienza del database necessari per far fronte a questa modalità di guasto sono già in corso e il loro completamento rimane previsto entro la fine dell’anno. Inoltre, è attualmente in fase di implementazione ulteriore capacità infrastrutturale, compreso nuovo spazio nei data center, che dovrebbe rendersi disponibile nelle prossime settimane, riducendo ulteriormente la nostra dipendenza da un singolo sito.

Purtroppo questo incidente si è verificato prima che tali miglioramenti fossero pienamente implementati. Ora stiamo valutando in quali ambiti accelerare in sicurezza i lavori rimanenti, mantenendo al tempo stesso il livello di attenzione necessario per le modifiche all’infrastruttura critica dei database.

Riconosciamo che i nostri utenti si aspettano un livello di affidabilità molto elevato da Proton, e questo incidente rafforza l’importanza di completare questi lavori e continuare a innalzare i nostri standard di resilienza. Ci scusiamo nuovamente, senza riserve, con ogni utente coinvolto.