I de tidlige timer den 27. august 2026 oplevede Proton et udbredt nedbrud, der påvirkede tjenester for en række brugere. Den grundlæggende årsag var et totalt svigt i kølesystemet i vores datacenter i Frankfurt. Selvom alle systemer hos Proton er redundante, og vi har tilstrækkelig kapacitet til at modstå et komplet udfald af et datacenter, er der et lille antal scenarier, hvor failover kan tage længere tid og føre til afbrydelser for brugerne.

Her er en tidslinje over, hvad der skete, hvilke valg vi traf under hændelsen og hvorfor, samt hvordan det blev løst.

Tidslinje

Lige efter kl. 23.00 (centraleuropæisk tid) onsdag den 26. august opstod der en fejl i kølesystemet i hovedrummet i vores datacenter i Frankfurt. Omkring kl. 23.15 begyndte temperaturen at stige fra cirka 21,8 °C (nominel temperatur) til 51,9 °C på under en halv time, og visse målesonder rapporterede en lufttemperatur på 60 °C i rummet. I takt med at temperaturerne steg, begyndte server- og netværksudstyr i anlægget at gå ned ét efter ét.

Hændelsen, der påvirkede brugerne, begyndte omkring midnat den 27. august, da fejlene eskalerede til det punkt, hvor den kritiske redundans gik tabt. Dette skete, da både den primære netværksswitch og backup-switchen i et kritisk rack fejlede, og dette rack indeholdt desværre flere primære databasekopier. Selvom næsten alle Proton-systemer er redundante og foretager failover automatisk/øjeblikkeligt, udføres primære database-failovers ikke automatisk uden menneskeligt tilsyn.

Vi bevarer denne kontrol ud fra et ønske om at undgå såkaldte “split-brain”-situationer, hvor en midlertidig utilgængelighed af en primær database betyder, at replikakopierne går glip af visse opdateringer og bliver desynkroniserede på måder, der kan være svære at afstemme senere. Når der sker en primær database-failover, er standardproceduren desuden at foretage failover til en replika i samme datacenter af hensyn til svartider og ydeevne. Problemets specifikke karakter betød dog, at dette kunne være uklogt, eftersom vi potentielt kunne skifte over til noget, der også ville gå ned.

Beslutningerne

På dette tidspunkt var Protons vagthavende ingeniører nødt til at træffe et par afgørende beslutninger under ekstremt pres.

  • Skulle de prioritere at bringe tjenesten online igen, eller prioritere at løse køleproblemet og redde hardwaren i datacentret?
  • Skulle vi foretage failover til replikaer i samme bygning i Frankfurt (hurtigere og mindre forstyrrende, men muligvis en midlertidig løsning, hvis varmen ikke kunne bringes under kontrol), eller foretage failover til Zürich?
  • Skulle vi foretage failover på alt eller kun det, der var nede i øjeblikket? Vi har nødplaner for et komplet datacenter-udfald, hvor tingene skifter fuldstændigt og for det meste automatisk relativt hurtigt, men en situation, hvor tilfældige servere går ned én efter én, håndteres ikke godt af vores failover-logik.

I sidste ende tvang den hastighed, hvormed temperaturerne steg, os til at prioritere at redde hardwaren frem for at bringe tjenesterne online igen. Dette er ikke et valg, der typisk skal træffes, fordi kølesystemer normalt er redundante, og et fuldstændigt tab af køling er yderst sjældent, hvilket betyder, at der er en del tid, før temperaturerne bliver kritiske. Problemet forværres af den store stigning i serveres effekttæthed i de seneste år med mere strømkrævende CPU’er og GPU’er til AI. Som følge heraf blev det, der førhen tog 3-4 timer at nå et kritisk punkt, kritisk på 20 minutter.

Det vagthavende team fokuserede derfor deres opmærksomhed på at kommunikere med driftsteamet i det lokale datacenter for at genoprette kølingen, mens de slukkede for så mange servere som muligt for at beskytte dem. På grund af mangel på serverudstyr i forbindelse med det igangværende AI-boom, ville meget af dette udstyr – hvis det gik tabt – ikke kunne erstattes med kort varsel. Det var nødt til at være en prioritet at redde det, selv på bekostning af potentielt at forlænge nedetiden.

Kl. 00.45 CEST lykkedes det os at genoprette kølingen, og temperaturerne i anlægget begyndte at falde, hvorefter det vagthavende team skiftede fokus til genopretning af tjenesterne. På dette tidspunkt traf vi beslutningen om at foretage failover af de primære databaser til Frankfurt, hvis en replika stadig var i live, og til Zürich i de tilfælde, hvor der ikke var en aktiv replika i Frankfurt, for at undgå at ændre vores trafikflow for meget og potentielt skabe ny ustabilitet. Denne løsning blev valgt, fordi vi antog, at nu hvor vi havde styr på kølingen, ville det være relativt let at bringe Frankfurt online igen og hurtigere end at skifte over til Zürich.

Desværre viste det sig ikke at være tilfældet. Under hændelsen nåede mange netværkskort i Frankfurt-infrastrukturen en temperatur på 105 °C (normal driftstemperatur er 45 °C), hvilket udløste en særlig temperaturbeskyttelsestilstand og fik netværkskortene til at blive deaktiveret, indtil der blev foretaget en kold systemnulstilling. Vores sikkerhedsopsætning begrænser muligheden for at få adgang til out-of-band-controlleren for vores systemer, hvilket krævede, at vi vækkede yderligere medarbejdere for at assistere med genopretningen.

Omkring kl. 01.30 CEST var vi i stand til at bringe de fleste tjenester online igen for de fleste brugere. Visse mindre kritiske systemer, såsom push-notifikationer eller betalingsbehandling, var dog først genoprettet omkring kl. 02.00 CEST.

Som vi oplyste i den indledende hændelsesrapport, gik ingen e-mails tabt, men e-maillevering i begge retninger var forsinket under hændelsen.

Selvom de brugervendte tjenester var fuldt genoprettet, var natten ikke forbi for vores ingeniører, især databaseteamet. Vores infrastruktur efterlod en yderst unormal tilstand med nogle primære databaser i Zürich og andre i Frankfurt, og flere af dem kørte med reduceret redundans og/eller nedsat ydeevne. Vores team arbejdede natten igennem for at løse de mest presserende af disse problemer, og arbejdet fortsatte hele dagen den 27. august for at genoprette fuld redundans.

Selvom det lykkedes os at redde næsten hele infrastrukturen, bukkede nogle servere desværre under for varmen, og vi ved endnu ikke, om varmehændelsen vil påvirke levetiden for det overlevende udstyr.

Grundlæggende årsag og næste skridt

En efterfølgende undersøgelse den 27. august sporede den grundlæggende årsag til kølesvigtet tilbage til en udskiftning af luftfiltre på begge de redundante luftkompressorer, der driver kølesystemet. Desværre udførte datacenteroperatøren denne handling midt om natten uden forudgående varsel og undlod desuden at give besked om kølesvigtet, da det skete, hvilket reducerede den tid, vi havde til at reagere, drastisk. Vi arbejder tæt sammen med operatøren for at forhindre en gentagelse af denne hændelse.

Det er dog også en kendt begrænsning ved vores nuværende databaseinfrastruktur, at et nedbrud af denne type kan føre til en længere genopretningsproces end normalt. Den række af begivenheder, der førte til denne hændelse, er yderst usandsynlig – men ikke desto mindre skete de.

Arbejdet med databasens robusthed, som er nødvendigt for at håndtere denne fejltilstand, er allerede i gang og forventes fortsat afsluttet ved udgangen af året. Yderligere infrastrukturkapacitet, herunder ny datacenterplads, er også ved at blive idriftsat og forventes at blive tilgængelig inden for de næste par uger, hvilket yderligere vil reducere vores afhængighed af et enkelt datacenter.

Desværre indtraf denne hændelse, før disse forbedringer var fuldt implementeret. Vi undersøger nu, hvor vi sikkert kan fremskynde det resterende arbejde, samtidig med at vi opretholder det nødvendige niveau af omhu ved ændringer i den kritiske databaseinfrastruktur.

Vi anerkender, at vores brugere forventer et meget højt niveau af pålidelighed fra Proton, og denne hændelse forstærker vigtigheden af at fuldføre dette arbejde og fortsætte med at hæve vores standarder for robusthed. Vi undskylder igen uden forbehold over for enhver bruger, der blev berørt.