I de tidlige morgentimene 27. august 2026 opplevde Proton en omfattende nedetid som påvirket tjenestene for en rekke brukere. Hovedårsaken var en total svikt i kjølesystemet i datasenteret vårt i Frankfurt. Selv om alle systemer hos Proton er redundante og vi har nok kapasitet til å tåle en fullstendig datasentersvikt, finnes det et lite antall scenarioer der overtagelsen (failover) kan ta lengre tid og føre til forstyrrelser for brukerne.

Her er en tidslinje over hva som skjedde, hvilke valg vi tok under hendelsen og hvorfor, og hvordan det ble løst.

Tidslinje

Like etter kl. 23.00 (sentraleuropeisk tid) onsdag 26. august oppsto det en svikt i kjølesystemet i hovedrommet i datasenteret vårt i Frankfurt. Rundt kl. 23.15 begynte temperaturen å stige fra omtrent 21,8 °C (nominell temperatur) til 51,9 °C på under en halvtime, og enkelte målesonder rapporterte 60 °C lufttemperatur i rommet. Etter hvert som temperaturen steg, begynte tjener- og nettverksutstyr i anlegget å svikte ett etter ett.

Den brukerrettede hendelsen startet rundt midnatt 27. august, da feilene eskalerte til det punktet at kritisk redundans gikk tapt. Dette skjedde da både den primære nettverkssvitsjen og reservenettverkssvitsjen på et kritisk rack sviktet, og dette racket inneholdt dessverre flere primære databasekopier. Selv om nesten alle Proton-systemer er redundante og feiler over automatisk/umiddelbart, utføres ikke failover for primærdatabaser automatisk uten menneskelig tilsyn.

Vi beholder denne kontrollen for å unngå såkalte «split brain»-situasjoner, der midlertidig utilgjengelighet for en primærdatabase fører til at replikakopiene går glipp av enkelte oppdateringer og blir usynkroniserte på måter som kan være vanskelige å avstemme senere. Videre, når en failover for en primærdatabase forekommer, er standardprosedyren å feile over til en replika i samme datasenter av hensyn til forsinkelse og ytelse. Problemets spesifikke art gjorde imidlertid at dette kunne være uklokt, ettersom vi potensielt kunne feilet over til noe som også ville gå ned.

Beslutningene

På dette tidspunktet måtte Protons vaktgående ingeniører ta et par avgjørende beslutninger under ekstremt press.

  • Skal de prioritere å få tjenesten på nett igjen, eller prioritere å håndtere kjøleproblemet og redde maskinvaren i datasenteret?
  • Bør vi feile over til replikaer i samme bygning i Frankfurt (raskere og mindre forstyrrende, men potensielt en midlertidig løsning hvis varmen ikke kunne bringes under kontroll), eller feile over til Zürich?
  • Feiler vi over alt, eller bare det som er nede for øyeblikket? Vi har beredskapsplaner for fullstendig datasentersvikt der ting feiler over fullt ut og for det meste automatisk ganske raskt, men en situasjon der tilfeldige tjenere dør én etter én håndteres ikke godt av failover-logikken vår.

Til syvende og sist tvang hastigheten temperaturene steg med oss til å prioritere å redde maskinvaren fremfor å få tjenestene på nett igjen. Dette er vanligvis ikke et valg man må ta, ettersom kjølesystemer normalt er redundante og fullstendig bortfall av kjøling er svært sjeldent, noe som betyr at man har god tid før temperaturene blir kritiske. Problemet forsterkes av den store økningen i tjenernes effekttetthet de siste årene, med mer strømkrevende prosessorer og grafikkprosessorer for AI. Resultatet var at det som tidligere tok 3–4 timer før det ble kritisk, ble kritisk på 20 minutter.

Vaktteamet rettet derfor oppmerksomheten mot å kommunisere med datasenterets driftsteam på stedet for å gjenopprette kjølingen, samtidig som de slo av så mange tjenere som mulig for å beskytte dem. På grunn av mangel på tjenerutstyr knyttet til den pågående AI-bølgen, ville mye av dette utstyret – hvis det gikk tapt – ikke vært mulig å erstatte på kort varsel. Å redde det måtte være en prioritet, selv om det potensielt forlenget nedetiden.

Innen 00:45 CEST klarte vi å gjenopprette kjølingen og temperaturene i anlegget begynte å falle, og vaktteamet flyttet fokuset over på å gjenopprette tjenestene. På dette tidspunktet besluttet vi å feile over primærdatabasene til Frankfurt dersom en replika fortsatt var i live, og til Zürich i tilfeller der ingen replika var i live i Frankfurt, for å unngå å endre trafikkflyten for mye og potensielt skape ny ustabilitet. Dette alternativet ble valgt fordi vi antok at når vi først hadde kontroll på kjølingen, ville det være relativt enkelt å få Frankfurt på nett igjen og raskere enn å bytte over til Zürich.

Dessverre viste dette seg å ikke være tilfelle. Under hendelsen nådde mange nettverkskort i Frankfurt-infrastrukturen en temperatur på 105 °C (normal driftstemperatur er 45 °C), noe som utløser en spesiell temperaturbeskyttelsesmodus og fører til at nettverkskortene deaktiveres inntil det gjøres en kald omstart av systemet. Sikkerhetsstrukturen vår begrenser muligheten til å få tilgang til systemenes out-of-band-kontroller, noe som krevde at vi måtte vekke ytterligere personell for å hjelpe til med gjenopprettingen.

Innen 01:30 CEST klarte vi å få de fleste tjenestene på nett igjen for de fleste brukerne. Enkelte mindre kritiske systemer, som push-varsler eller betalingsbehandling, ble imidlertid ikke gjenopprettet før rundt kl. 02:00 CEST.

Som vi rapporterte i den første hendelsesrapporten, gikk ingen e-poster tapt, men e-postlevering i begge retninger ble forsinket under hendelsen.

Selv om de brukerrettede tjenestene var fullstendig gjenopprettet, var ikke natten over for ingeniørene våre, spesielt databaseteamet. Infrastrukturen vår befant seg i en svært unormal tilstand, med noen primærdatabaser i Zürich og andre i Frankfurt, og flere av dem opererte med redusert redundans og/eller redusert ytelse. Teamet vårt jobbet gjennom natten for å løse de mest presserende problemene, og arbeidet fortsatte utover dagen 27. august for å gjenopprette full redundans.

Selv om vi klarte å redde nesten hele infrastrukturen, bukket dessverre noen tjenere under for varmen, og vi vet ennå ikke om overopphetingen vil påvirke levetiden til det overlevende utstyret.

Hovedårsak og neste steg

En etterfølgende undersøkelse 27. august sporet hovedårsaken til kjølesvikten til et luftfilterbytte på begge de redundante luftkompressorene som driver kjølesystemet. Dessverre utførte datasenteroperatøren denne operasjonen midt på natten, uten forvarsel, og unnlot også å varsle om kjølesvikten da den inntraff, noe som dramatisk reduserte tiden vi hadde til å reagere. Vi jobber tett med operatøren for å forhindre en gjentakelse av denne hendelsen.

Det er imidlertid også en kjent begrensning ved vår nåværende databaseinfrastruktur at en nedetid av denne typen kan føre til en lengre gjenopprettingsprosess enn normalt. Rekken av hendelser som førte til denne hendelsen er svært usannsynlig – likevel skjedde det.

Arbeidet med databasens robusthet som kreves for å håndtere denne feilmodusen, er allerede i gang og er fortsatt planlagt fullført innen utgangen av året. Ytterligere infrastrukturkapasitet, inkludert ny datasenterplass, blir for øyeblikket klargjort og forventes å bli tilgjengelig i løpet av de neste ukene, noe som ytterligere vil redusere vår avhengighet av enkeltlokasjoner.

Dessverre inntraff denne hendelsen før disse forbedringene var fullt på plass. Vi vurderer nå hvor vi trygt kan fremskynde det gjenstående arbeidet, samtidig som vi opprettholder det nødvendige aktsomhetsnivået for endringer i kritisk databaseinfrastruktur.

Vi erkjenner at brukerne våre forventer et svært høyt pålitelighetsnivå fra Proton, og denne hendelsen understreker viktigheten av å fullføre dette arbeidet og fortsette å heve standardene våre for robusthet. Vi beklager igjen, uten forbehold, overfor alle brukere som ble berørt.