În primele ore ale zilei de 27 august 2026, Proton s-a confruntat cu o întrerupere extinsă care a afectat serviciile pentru o serie de utilizatori. Cauza principală a fost o defecțiune totală a sistemului de răcire din centrul nostru de date din Frankfurt. Deși toate sistemele de la Proton sunt redundante și avem suficientă capacitate pentru a face față unei defecțiuni complete a centrului de date, există un număr mic de scenarii în care comutarea la redundanță poate dura mai mult și poate duce la perturbări vizibile pentru utilizatori.

Iată o cronologie a evenimentelor, deciziile pe care le-am luat în timpul incidentului și motivele din spatele acestora, precum și modul în care a fost rezolvată problema.

Cronologie

La scurt timp după ora 23:00 (ora Europei Centrale), miercuri, 26 august, a avut loc o defecțiune a sistemului de răcire în sala principală a centrului nostru de date din Frankfurt. În jurul orei 23:15, temperatura a început să crească de la aproximativ 21,8°C (temperatura nominală) la 51,9°C în mai puțin de jumătate de oră, unele sonde de măsurare raportând o temperatură a aerului de 60°C în încăpere. Pe măsură ce temperaturile creșteau, echipamentele de server și de rețea din facilitate au început să cedeze rând pe rând.

Incidentul resimțit de utilizatori a început în jurul miezului nopții, pe 27 august, când defecțiunile au escaladat până la pierderea redundanței critice. Acest lucru s-a întâmplat atunci când atât switch-ul de rețea principal, cât și cel de backup de pe un rack critic au cedat, iar acest rack conținea, din păcate, mai multe copii principale ale bazei de date. Deși aproape toate sistemele Proton sunt redundante și vor efectua comutarea la redundanță în mod automat/imediat, comutările pentru bazele de date principale nu se realizează automat fără supraveghere umană.

Păstrăm acest control din dorința de a evita așa-numitele situații de tip „split brain”, în care o indisponibilitate temporară a unei baze de date principale duce la omiterea unor actualizări de către copiile replica și la desincronizarea acestora în moduri greu de reconciliat ulterior. În plus, atunci când are loc o comutare a bazei de date principale, procedura standard de operare este de a comuta pe o replică din același centru de date din motive de latență și performanță. Totuși, natura specifică a problemei sugera că acest pas ar putea fi imprudent, deoarece am fi putut comuta pe ceva care urma să devină la rândul său indisponibil.

Deciziile

În acest moment, inginerii de gardă de la Proton au fost nevoiți să ia câteva decizii importante, operând sub o presiune extremă.

  • Să acorde prioritate repunerii serviciului online sau să prioritizeze rezolvarea problemei de răcire și salvarea componentelor hardware din centrul de date?
  • Ar trebui să comutăm pe replicile din aceeași clădire din Frankfurt (mai rapid și mai puțin perturbator, dar posibil o soluție temporară dacă temperatura nu putea fi controlată) sau să comutăm pe Zurich?
  • Să comutăm totul sau doar ceea ce este indisponibil în acel moment? Avem planuri de urgență pentru căderea completă a centrului de date, unde comutarea se face complet și în mare parte automat destul de rapid, dar o situație în care servere aleatorii cedează rând pe rând nu este gestionată optim de logica noastră de failover.

În cele din urmă, ritmul în care creșteau temperaturile ne-a obligat să acordăm prioritate salvării hardware-ului în detrimentul repunerii serviciilor online. Aceasta nu este o alegere care trebuie făcută de obicei, deoarece sistemele de răcire sunt în mod tipic redundante, iar pierderea completă a răcirii este destul de rară, ceea ce înseamnă că există suficient timp înainte ca temperaturile să devină critice. Problema este exacerbată de creșterea mare a densității de putere a serverelor din ultimii ani, cu procesoare și GPU-uri mai puternice pentru IA. Drept urmare, ceea ce înainte dura 3-4 ore până la atingerea unui nivel critic a devenit critic în 20 de minute.

Prin urmare, echipa de gardă și-a concentrat atenția pe comunicarea cu echipa de operațiuni de la fața locului din centrul de date pentru a restabili răcirea, oprind în același timp cât mai multe servere pentru a le proteja. Din cauza penuriei de echipamente pentru servere asociate cu boom-ul actual al IA, o mare parte din aceste echipamente — dacă s-ar fi pierdut — nu ar fi putut fi înlocuite într-un termen scurt. Salvarea lor trebuia să fie o prioritate, chiar și cu riscul de a prelungi potențial perioada de nefuncționare.

Până la 00:45 CEST, am reușit să restabilim răcirea, temperaturile din facilitate au început să scadă, iar echipa de gardă s-a concentrat pe recuperarea serviciilor. În acest moment, am luat decizia de a comuta bazele de date principale la Frankfurt dacă o replică era încă funcțională, și la Zurich în cazurile în care nu exista nicio replică funcțională la Frankfurt, pentru a evita modificarea prea mare a fluxurilor de trafic și posibila creare a unei noi instabilități. Această opțiune a fost selectată deoarece am presupus că, odată ce răcirea era sub control, ar fi fost relativ ușor să repunem Frankfurtul online și mai rapid decât comutarea la Zurich.

Din păcate, situația a stat diferit. În timpul incidentului, multe plăci de rețea din infrastructura din Frankfurt au atins o temperatură de 105°C (temperatura normală de funcționare fiind de 45°C), ceea ce a declanșat un mod special de protecție termică și a dus la dezactivarea plăcilor de rețea până la o resetare la rece a sistemului. Politica noastră de securitate limitează capacitatea de a accesa controlerul out-of-band pentru sistemele noastre, ceea ce ne-a impus să mobilizăm personal suplimentar pentru a asista la recuperare.

Până la 01:30 CEST, am reușit să readucem majoritatea serviciilor online pentru majoritatea utilizatorilor. Totuși, unele sisteme mai puțin critice, cum ar fi notificările push sau procesarea plăților, nu au fost recuperate până în jurul orei 02:00 CEST.

Așa cum am raportat în raportul inițial de incident, nu s-au pierdut e-mailuri, dar livrarea e-mailurilor în ambele direcții a fost întârziată pe durata incidentului.

Deși serviciile destinate utilizatorilor au fost complet restaurate, noaptea nu se încheiase pentru inginerii noștri, în special pentru echipa responsabilă de bazele de date. Infrastructura noastră a rămas într-o stare extrem de anormală, cu unele baze de date principale în Zurich și altele în Frankfurt, iar câteva dintre ele funcționând cu redundanță redusă și/sau performanță redusă. Echipa noastră a lucrat toată noaptea pentru a rezolva cele mai urgente dintre aceste probleme, iar activitatea a continuat pe tot parcursul zilei de 27 august pentru a restabili redundanța completă.

Deși am reușit să salvăm aproape întreaga infrastructură, unele servere au suferit din păcate daune ireversibile din cauza supraîncălzirii și nu știm încă dacă incidentul termic va afecta durata de viață a echipamentelor rămase.

Cauza principală și pașii următori

O investigație ulterioară din 27 august a identificat cauza principală a defecțiunii răcirii ca fiind înlocuirea filtrelor de aer la ambele compresoare de aer redundante care alimentează sistemul de răcire. Din păcate, operatorul centrului de date a efectuat această operațiune în mijlocul nopții, fără o notificare prealabilă, și nu a comunicat defecțiunea răcirii atunci când aceasta a survenit, ceea ce a redus dramatic timpul pe care îl aveam la dispoziție pentru a reacționa. Colaborăm îndeaproape cu operatorul pentru a preveni repetarea acestui incident.

Cu toate acestea, este o limitare cunoscută a infrastructurii noastre actuale de baze de date faptul că o întrerupere de acest tip ar putea duce la un proces de recuperare mai lung decât în mod normal. Succesiunea de evenimente care a dus la acest incident este extrem de improbabilă — și totuși s-a produs.

Lucrările privind reziliența bazelor de date necesare pentru a aborda acest mod de defecțiune sunt deja în desfășurare și sunt planificate pentru a fi finalizate până la sfârșitul anului. De asemenea, în prezent este pusă în funcțiune o capacitate suplimentară de infrastructură, inclusiv un nou spațiu în centrul de date, preconizată să devină disponibilă în următoarele săptămâni, ceea ce va reduce și mai mult dependența noastră de o singură locație.

Din păcate, acest incident a avut loc înainte ca aceste îmbunătățiri să fie implementate complet. În prezent, analizăm unde putem accelera în siguranță lucrările rămase, menținând în același timp nivelul de precauție necesar pentru modificările aduse infrastructurii critice a bazelor de date.

Recunoaștem că utilizatorii noștri așteaptă un nivel foarte înalt de fiabilitate din partea Proton, iar acest incident subliniază importanța finalizării acestor lucrări și a continuării creșterii standardelor noastre de reziliență. Ne cerem scuze din nou, fără rezerve, fiecărui utilizator afectat.