Wczesnym rankiem 27 sierpnia 2026 r. w Proton doszło do rozległej awarii, która wpłynęła na działanie usług dla części użytkowników. Główną przyczyną była całkowita awaria systemu chłodzenia w naszym centrum danych we Frankfurcie. Chociaż wszystkie systemy w Proton są nadmiarowe i dysponujemy wystarczającą przepustowością, by przetrwać całkowitą awarię centrum danych, istnieje kilka scenariuszy, w których przełączenie awaryjne może potrwać dłużej i doprowadzić do zakłóceń odczuwalnych dla użytkowników.

Oto przebieg wydarzeń, decyzje, które podjęliśmy w trakcie incydentu wraz z ich uzasadnieniem, oraz informacja o tym, jak problem został rozwiązany.

Przebieg wydarzeń

W środę 26 sierpnia tuż po godzinie 23:00 (czasu środkowoeuropejskiego) w głównym pomieszczeniu naszego centrum danych we Frankfurcie doszło do awarii systemu chłodzenia. Około godziny 23:15 temperatura zaczęła rosnąć z około 21,8°C (temperatura nominalna) do 51,9°C w niespełna pół godziny, a niektóre sondy pomiarowe rejestrowały temperaturę powietrza w pomieszczeniu sięgającą 60°C. W miarę wzrostu temperatury sprzęt serwerowy i sieciowy w placówce zaczął kolejno odmawiać posłuszeństwa.

Incydent odczuwalny dla użytkowników rozpoczął się około północy 27 sierpnia, gdy awarie nasiliły się do tego stopnia, że utracona została krytyczna nadmiarowość. Doszło do tego, kiedy awarii uległy zarówno główny, jak i zapasowy przełącznik sieciowy w newralgicznej szafie serwerowej, w której niestety znajdowało się kilka głównych kopii baz danych. Choć niemal wszystkie systemy Proton są nadmiarowe i przełączają się awaryjnie automatycznie/natychmiastowo, przełączenie awaryjne głównych baz danych nie odbywa się automatycznie bez nadzoru człowieka.

Zachowujemy taką kontrolę, aby uniknąć tzw. sytuacji „split brain”, w których chwilowa niedostępność głównej bazy danych sprawia, że kopie zapasowe (repliki) tracą część aktualizacji i desynchronizują się w sposób trudny do późniejszego pogodzenia. Ponadto w przypadku przełączenia awaryjnego głównej bazy danych standardowa procedura operacyjna zakłada przełączenie na replikę w tym samym centrum danych ze względu na opóźnienia i wydajność. Jednak specyfika tego problemu sprawiła, że mogło to być niewskazane, ponieważ istniało ryzyko przełączenia na zasoby, które za chwilę również przestałyby działać.

Podjęte decyzje

W tym momencie dyżurni inżynierowie Proton musieli podjąć kilka kluczowych decyzji, działając pod ogromną presją.

  • Czy priorytetem powinno być przywrócenie działania usługi online, czy rozwiązanie problemu z chłodzeniem i ratowanie sprzętu w centrum danych?
  • Czy powinniśmy przełączyć się awaryjnie na repliki w tym samym budynku we Frankfurcie (szybsze i mniej uciążliwe, ale potencjalnie tymczasowe rozwiązanie, jeśli nie uda się opanować temperatury), czy przełączyć się na Zurych?
  • Czy przełączyć awaryjnie wszystko, czy tylko to, co aktualnie nie działa? Posiadamy plany awaryjne na wypadek całkowitej awarii centrum danych, kiedy to przełączenie następuje w pełni i w przeważającej mierze automatycznie oraz dość szybko, jednak sytuacja, w której losowe serwery padają jeden po drugim, nie jest dobrze obsługiwana przez naszą logikę przełączania awaryjnego.

Ostatecznie tempo wzrostu temperatury zmusiło nas do uznania ratowania sprzętu za priorytet wobec przywracania usług online. Zwykle nie trzeba dokonywać takiego wyboru, ponieważ systemy chłodzenia są standardowo nadmiarowe, a całkowita utrata chłodzenia zdarza się niezwykle rzadko — co oznacza, że mija sporo czasu, zanim temperatury osiągną poziom krytyczny. Problem pogłębia duży wzrost gęstości mocy serwerów w ostatnich latach, związany z bardziej energochłonnymi procesorami CPU i układami GPU dla AI. W rezultacie to, co kiedyś stawało się krytyczne po 3–4 godzinach, osiągnęło stan krytyczny w 20 minut.

Dlatego dyżurny zespół skupił się na komunikacji z zespołem operacyjnym na miejscu w centrum danych w celu przywrócenia chłodzenia, jednocześnie wyłączając jak najwięcej serwerów, aby je chronić. Ze względu na niedobór sprzętu serwerowego powiązany z trwającym boomem na AI, wielu z tych urządzeń — w razie ich utraty — nie udałoby się szybko wymienić. Ich uratowanie musiało być priorytetem, nawet kosztem potencjalnego wydłużenia czasu przestoju.

Do godziny 00:45 CEST udało się przywrócić chłodzenie, a temperatury w obiekcie zaczęły spadać, dzięki czemu dyżurny zespół mógł skupić się na przywracaniu usług. W tym momencie podjęliśmy decyzję o przełączeniu głównych baz danych na Frankfurt, jeśli replika wciąż działała, a na Zurych w przypadkach, gdy we Frankfurcie nie było działającej repliki, aby uniknąć zbyt dużej zmiany w przepływie ruchu sieciowego i ewentualnego wywołania nowej niestabilności. Wybrano tę opcję, ponieważ założyliśmy, że po opanowaniu chłodzenia stosunkowo łatwo i szybciej niż w przypadku przełączenia na Zurych uda się przywrócić Frankfurt do trybu online.

Niestety okazało się, że tak nie było. W trakcie incydentu wiele kart sieciowych w infrastrukturze we Frankfurcie osiągnęło temperaturę 105°C (normalna temperatura robocza wynosi 45°C), co uruchamia specjalny tryb ochrony termicznej i powoduje wyłączenie kart sieciowych do czasu wykonania twardego resetu systemu. Nasze procedury bezpieczeństwa ograniczają dostęp do kontrolera pozapasmowego dla naszych systemów, co wymagało zaangażowania dodatkowych pracowników do pomocy przy odzyskiwaniu sprawności.

Do godziny 01:30 CEST udało nam się przywrócić większość usług online dla większości użytkowników. Jednak niektóre mniej krytyczne systemy, takie jak powiadomienia push czy przetwarzanie płatności, zostały odzyskane dopiero około godziny 02:00 CEST.

Jak informowaliśmy we wstępnym raporcie o incydencie, żadne wiadomości e-mail nie zostały utracone, ale doręczanie wiadomości w obu kierunkach było opóźnione w trakcie trwania incydentu.

Choć usługi dostępne dla użytkowników zostały w pełni przywrócone, dla naszych inżynierów — zwłaszcza zespołu baz danych — to nie był koniec nocy. Nasza infrastruktura pozostała w wysoce nietypowym stanie: część głównych baz danych znajdowała się w Zurychu, a część we Frankfurcie, przy czym kilka z nich działało ze zmniejszoną nadmiarowością i/lub niższą wydajnością. Nasz zespół pracował całą noc, aby rozwiązać najpilniejsze z tych problemów, a prace mające na celu przywrócenie pełnej nadmiarowości trwały przez cały dzień 27 sierpnia.

Choć udało nam się ocalić niemal całą infrastrukturę, część serwerów uległa niestety przegrzaniu, i nie wiemy jeszcze, czy ten incydent termiczny wpłynie na żywotność ocalałego sprzętu.

Główna przyczyna i dalsze kroki

Późniejsze dochodzenie przeprowadzone 27 sierpnia wykazało, że główną przyczyną awarii chłodzenia była wymiana filtrów powietrza w obu redundantnych sprężarkach zasilających system chłodzenia. Niestety operator centrum danych przeprowadził tę operację w środku nocy, bez uprzedniego powiadomienia, a także nie poinformował o awarii chłodzenia, gdy do niej doszło, co drastycznie skróciło nasz czas reakcji. Ściśle współpracujemy z operatorem, aby zapobiec powtórzeniu się takiego incydentu.

Znanym ograniczeniem naszej obecnej infrastruktury bazodanowej jest jednak również to, że tego typu awaria może prowadzić do dłuższego niż zwykle procesu przywracania sprawności. Ciąg zdarzeń, który doprowadził do tego incydentu, był wysoce nieprawdopodobny — a jednak nastąpił.

Prace nad odpornością baz danych niezbędne do wyeliminowania tego typu awarii już trwają i ich zakończenie jest planowane na koniec roku. Ponadto wdrażana jest dodatkowa przepustowość infrastruktury, w tym nowa przestrzeń w centrum danych, która powinna być dostępna w ciągu najbliższych kilku tygodni, co jeszcze bardziej zmniejszy naszą zależność od pojedynczej lokalizacji.

Niestety ten incydent miał miejsce, zanim te usprawnienia zostały w pełni wdrożone. Obecnie analizujemy, gdzie możemy bezpiecznie przyspieszyć pozostałe prace, zachowując jednocześnie ostrożność wymaganą przy wprowadzaniu zmian w krytycznej infrastrukturze baz danych.

Zdajemy sobie sprawę, że nasi użytkownicy oczekują od Proton bardzo wysokiego poziomu niezawodności, a ten incydent podkreśla wagę ukończenia tych prac i dalszego podnoszenia naszych standardów odporności. Jeszcze raz bez zastrzeżeń przepraszamy każdego użytkownika, który został dotknięty tą sytuacją.