Varhain aamuyöllä 27. elokuuta 2026 Protonilla ilmeni laaja käyttökatko, joka vaikutti useiden käyttäjien palveluihin. Perimmäinen syy oli Frankfurtin datakeskuksemme jäähdytysjärjestelmän täydellinen rikkoutuminen. Vaikka kaikki Protonin järjestelmät ovat kahdennettuja ja meillä on tarpeeksi kapasiteettia kestääksemme koko datakeskuksen vikaantumisen, on olemassa joitakin harvoja tilanteita, joissa vikasietosiirto voi kestää pidempään ja aiheuttaa käyttäjille näkyviä häiriöitä.

Tässä on aikajana siitä, mitä tapahtui, mitä valintoja teimme häiriön aikana ja miksi, sekä miten se ratkaistiin.

Aikajana

Hieman kello 23.00 (Keski-Euroopan aikaa) jälkeen keskiviikkona 26. elokuuta Frankfurtin datakeskuksemme pääsalissa ilmeni jäähdytysjärjestelmän vika. Noin kello 23.15 lämpötila alkoi nousta noin 21,8 °C:sta (nimellislämpötila) 51,9 °C:seen alle puolessa tunnissa, ja jotkin mittausanturit ilmoittivat huoneen ilmanlämmöksi 60 °C. Lämpötilojen noustessa tiloissa olleet palvelin- ja verkkolaitteet alkoivat sammua yksi kerrallaan.

Käyttäjille näkyvä häiriö alkoi noin puolenyön aikaan 27. elokuuta, kun viat eskaloituivat pisteeseen, jossa kriittinen kahdennus menetettiin. Tämä tapahtui, kun kriittisen laitekaapin sekä ensisijainen että varakytkin vikaantuivat, ja kyseisessä laitekaapissa sijaitsi valitettavasti useita ensisijaisia tietokantakopioita. Vaikka lähes kaikki Protonin järjestelmät ovat kahdennettuja ja tekevät vikasietosiirron automaattisesti ja välittömästi, ensisijaisten tietokantojen vikasietosiirtoja ei tehdä automaattisesti ilman ihmisen valvontaa.

Pidämme tämän hallinnan itsellämme välttääksemme niin sanotut “split-brain”-tilanteet, joissa ensisijaisen tietokannan tilapäinen saavuttamattomuus johtaa siihen, että replikakopiot jäävät paitsi joistakin päivityksistä ja niiden synkronointi katkeaa tavoilla, joita voi olla myöhemmin vaikea sovittaa yhteen. Lisäksi ensisijaisen tietokannan vikasietosiirrossa vakiotoimintatapa on siirtää toiminta samaan datakeskukseen sijoitettuun replikaan viive- ja suorituskykysyistä. Ongelman luonne kuitenkin tarkoitti, että tämä saattaisi olla huono ajatus, sillä olisimme voineet siirtyä kohteeseen, joka vikaantuisi myös.

Päätökset

Tässä vaiheessa Protonin päivystävien insinöörien oli tehtävä pari merkittävää päätöstä äärimmäisen paineen alla.

  • Asetetaanko etusijalle palvelun palauttaminen verkkoon vai jäähdytysongelman ratkaiseminen ja datakeskuksen laitteiston pelastaminen?
  • Pitäisikö vikasietosiirto tehdä saman rakennuksen replikoihin Frankfurtissa (nopeampi ja vähemmän häiritsevä, mutta mahdollisesti vain väliaikainen korjaus, jos kuumuutta ei saataisi hallintaan) vai Zürichiin?
  • Siirretäänkö kaikki vai ainoastaan se, mikä on sillä hetkellä poissa käytöstä? Meillä on varasuunnitelmia koko datakeskuksen vikaantumisen varalle, jolloin asiat siirtyvät täysin ja pääosin automaattisesti melko nopeasti, mutta tilannetta, jossa satunnaiset palvelimet lakkaavat toimimasta yksi kerrallaan, vikasietologiikkamme ei käsittele yhtä hyvin.

Lopulta lämpötilojen nousunopeus pakotti meidät asettamaan laitteiston pelastamisen etusijalle palveluiden palauttamiseen nähden. Tätä valintaa ei yleensä tarvitse tehdä, sillä jäähdytysjärjestelmät ovat tavallisesti kahdennettuja ja jäähdytyksen täydellinen lakkaaminen on melko harvinaista, mikä tarkoittaa, että lämpötilojen muuttumiseen kriittisiksi on yleensä runsaasti aikaa. Ongelmaa pahentaa palvelinten tehotiheyden suuri kasvu viime vuosina, kun käytössä on tehokkaampia suorittimia ja tekoälykäyttöön tarkoitettuja näytönohjaimia. Tämän seurauksena se, minkä kriittiseksi muuttuminen kesti ennen 3–4 tuntia, muuttui kriittiseksi 20 minuutissa.

Päivystystiimi keskittyi siksi viestimään paikan päällä olevan datakeskuksen operatiivisen tiimin kanssa jäähdytyksen palauttamiseksi samalla, kun mahdollisimman monta palvelinta sammutettiin niiden suojaamiseksi. Käynnissä olevaan tekoälybuumiin liittyvän palvelinlaitteistopulan vuoksi suuren osan näistä laitteista korvaaminen lyhyellä aikataululla ei olisi ollut mahdollista, jos ne olisi menetetty. Niiden pelastamisen oli oltava etusijalla, vaikka se mahdollisesti pidensi käyttökatkoa.

Kello 00.45 CEST mennessä saimme jäähdytyksen palautettua ja lämpötilat tiloissa alkoivat laskea, jolloin päivystystiimi siirsi huomionsa palveluiden palauttamiseen. Tässä vaiheessa teimme päätöksen siirtää ensisijaiset tietokannat Frankfurtiin, jos replika oli yhä toiminnassa, ja Zürichiin niissä tapauksissa, joissa Frankfurtissa ei ollut toimivaa replikaa, jotta välttäisimme tietoliikennevirtojen liiallista muuttamista ja mahdollisen uuden epävakauden syntymistä. Tämä vaihtoehto valittiin, koska oletimme, että jäähdytyksen ollessa hallinnassa Frankfurtin saaminen takaisin verkkoon olisi suhteellisen helppoa ja nopeampaa kuin siirtyminen Zürichiin.

Valitettavasti näin ei kuitenkaan käynyt. Häiriön aikana monet verkkokortit Frankfurtin infrastruktuurissa saavuttivat 105 °C:n lämpötilan (normaali käyttölämpötila on 45 °C), mikä laukaisee erityisen lämpötilansuojaustilan ja poistaa verkkokortit käytöstä kylmäkäynnistykseen asti. Tietoturvakäytäntömme rajoittavat pääsyä järjestelmiemme erilliselle hallintakortille (out-of-band controller), mikä edellytti lisähenkilöstön herättämistä auttamaan palautustyössä.

Kello 01.30 CEST mennessä saimme useimmat palvelut takaisin käyttöön useimmille käyttäjille. Joitakin vähemmän kriittisiä järjestelmiä, kuten push-ilmoituksia tai maksujen käsittelyä, ei kuitenkaan saatu palautettua ennen kuin noin klo 02.00 CEST.

Kuten kerroimme alustavassa häiriöraportissa, sähköposteja ei menetetty, mutta sähköpostien toimitus kumpaankin suuntaan viivästyi häiriön aikana.

Vaikka käyttäjille näkyvät palvelut oli palautettu kokonaan, yö ei ollut vielä ohi insinööreillemme, etenkään tietokantatiimille. Infrastruktuurimme jäi erittäin poikkeukselliseen tilaan: osa ensisijaisista tietokannoista oli Zürichissä ja osa Frankfurtissa, ja useat niistä toimivat heikentyneellä kahdennuksella ja/tai heikentyneellä suorituskyvyllä. Tiimimme työskenteli läpi yön ratkaistakseen näistä ongelmista kiireellisimmät, ja työ jatkui koko 27. elokuuta täyden kahdennuksen palauttamiseksi.

Vaikka onnistuimme pelastamaan lähes koko infrastruktuurin, jotkin palvelimet valitettavasti vaurioituivat kuumuudesta korjauskelvottomiksi, emmekä vielä tiedä, vaikuttaako ylikuumeneminen säästyneiden laitteiden elinkaareen.

Juurisyy ja seuraavat askeleet

Myöhempi tutkimus 27. elokuuta paikansi jäähdytysvian perimmäiseksi syyksi ilmansuodattimien vaihdon jäähdytysjärjestelmää pyörittäviin kumpaankin kahdennettuun ilmakompressoriin. Valitettavasti datakeskuksen operaattori suoritti tämän toimenpiteen keskellä yötä ilman ennakkoilmoitusta eikä myöskään ilmoittanut jäähdytyksen katkeamisesta sen tapahtuessa, mikä lyhensi dramaattisesti reagointiaikaamme. Teemme tiivistä yhteistyötä operaattorin kanssa estääksemme tällaisen tapauksen toistumisen.

Nykyisen tietokantainfrastruktuurimme tunnettu rajoitus on kuitenkin myös se, että tämänkaltainen käyttökatko voi johtaa normaalia pidempään palautusprosessiin. Tähän tapahtumaan johtanut tapahtumaketju oli erittäin epätodennäköinen – mutta niin vain tapahtui.

Tämän vikatilan korjaamiseksi tarvittava tietokantojen vikasietoisuustyö on jo käynnissä, ja sen on määrä valmistua vuoden loppuun mennessä. Lisäksi uutta infrastruktuurikapasiteettia, mukaan lukien uutta datakeskustilaa, otetaan parhaillaan käyttöön ja sen odotetaan tulevan saataville lähiviikkoina, mikä vähentää riippuvuuttamme yksittäisestä toimipisteestä entisestään.

Valitettavasti tämä häiriö tapahtui ennen kuin kyseiset parannukset olivat täysin käytössä. Tarkastelemme parhaillaan, missä kohdin voimme turvallisesti nopeuttaa jäljellä olevaa työtä säilyttäen samalla kriittisen tietokantainfrastruktuurin muutoksilta vaadittavan huolellisuuden.

Tiedostamme, että käyttäjämme odottavat Protonilta erittäin korkeaa luotettavuutta, ja tämä tapaus korostaa tämän työn loppuunsaattamisen ja vikasietoisuusstandardiemme jatkuvan nostamisen tärkeyttä. Pyydämme vielä kerran varauksettomasti anteeksi jokaiselta käyttäjältä, johon katko vaikutti.