Awaria zasilania w poznańskim węźle – co poszło nie tak?
14 września o godzinie 11:22 poznański węzeł stracił zasilanie na dokładnie 84 minuty. Mimo dwóch sprawnych agregatów prądotwórczych, 38 lokalnych firm zostało odciętych od swoich danych. Zaglądamy pod maskę tej serwerowni, żeby zrozumieć, gdzie zawiodła automatyka i dlaczego procedury testowe z lipca nie wykryły błędu.
Czarny czwartek: 84 minuty bez prądu
Wszystko zaczęło się o godzinie 11:22 w czwartek, 14 września, kiedy to nastąpił nagły spadek napięcia w sieci miejskiej zasilającej dzielnicę Jeżyce. W teorii dwa potężne agregaty marki FG Wilson o mocy 440 kVA każdy powinny przejąć rolę głównego źródła prądu w ciągu maksymalnie 14 sekund. Systemy UPS marki Eaton natychmiast zareagowały, podtrzymując pracę serwerów, ale sygnał do startu silników spalinowych nie został poprawnie przetworzony przez sterownik nadrzędny. Zamiast płynnego przejścia na zasilanie awaryjne, hala serwerowa pogrążyła się w nienaturalnej ciszy, którą przerywał jedynie pisk alarmów z szaf rackowych.
W Gbu Vps dotarliśmy do logów systemowych, które pokazują, że pierwsza jednostka prądotwórcza odpaliła prawidłowo, ale sterownik nie zamknął obwodu zasilania na czas. W tym samym momencie druga jednostka pozostała całkowicie głucha na sygnały z systemu sterowania. W efekcie całe obciążenie infrastruktury spoczęło na barkach zestawów bateryjnych, które przy aktualnym poborze mocy wynoszącym 312 kilowatów miały bardzo ograniczony zapas czasu. Inżynierowie dyżurni mieli zaledwie kilkanaście minut na ręczną interwencję, zanim systemy zaczęłyby się automatycznie wyłączać z powodu braku energii.
Zaglądamy pod maskę serwerowni: 84 minuty przestoju to nie jest błąd sprzętu, to błąd konfiguracji, który narastał miesiącami.

Błąd w konfiguracji układu SZR
Po dokładnej analizie danych z godziny 11:24 okazało się, że głównym winowajcą był układ SZR, czyli Samoczynnego Załączania Rezerwy. Jeden z przekaźników czasowych w głównej szafie sterowniczej został ustawiony na 9 sekund zamiast standardowych 3 podczas ostatniej aktualizacji oprogramowania w maju 2024. Ta z pozoru drobna zmiana spowodowała, że falowniki UPS uznały źródło prądu z agregatu za niestabilne i odcięły dopływ energii, aby chronić czułe podzespoły serwerów. System wpadł w pętlę decyzyjną, która uniemożliwiła stabilizację napięcia.
Co gorsza, w sterowniku Deep Sea 7320 drugiego agregatu znaleźliśmy błąd logiczny w przypisaniu priorytetów. Ktoś podczas rutynowych prac serwisowych dwa miesiące wcześniej błędnie zaprogramował procedurę startową dla niskich temperatur otoczenia, co przy braku zasilania z jednej fazy całkowicie zablokowało rozruch silnika. To twarde dane, które pokazują, że nawet najdroższa infrastruktura bez rzetelnego audytu ustawień jest tylko stosem metalu. W Gbu Vps zawsze powtarzamy, że diabeł tkwi w parametrach, których nikt nie sprawdza, dopóki nie zgasną światła.

18 minut życia na bateriach
Zgodnie z dokumentacją techniczną z przeglądu wykonanego pod koniec 2023 roku, system UPS powinien wytrzymać 25 minut przy pełnym obciążeniu. Rzeczywistość 14 września zweryfikowała te obietnice bardzo brutalnie. Po dokładnie 18 minutach napięcie na szynie DC spadło poniżej krytycznego poziomu 378V. Podczas późniejszej inspekcji fizycznej wykonanej przez Agatę Wiśniewską, znaleźliśmy 3 spuchnięte ogniwa w szafie bateryjnej numer 4. Te uszkodzone elementy drastycznie obniżyły wydajność całego zestawu, skracając czas podtrzymania o blisko 30%.
W pomieszczeniu bateryjnym termometr odnotował temperaturę 29,4 stopnia Celsjusza, co jest wynikiem o 7 stopni wyższym niż zalecenia producenta akumulatorów ołowiowo-kwasowych. Przegrzanie było wynikiem awarii jednego z trzech klimatyzatorów precyzyjnych, która przeszła niezauważona przez system monitoringu przez ponad 11 dni. Takie sploty nieszczęśliwych zdarzeń doprowadziły do tego, że 38 lokalnych przedsiębiorstw, w tym dwa duże sklepy internetowe, straciło dostęp do swoich baz danych dokładnie o godzinie 11:40, co sparaliżowało ich pracę na ponad godzinę.
Twarde dane, zero marketingu – baterie padły po 18 minutach, bo temperatura w szafie była o 7 stopni za wysoka.

Skutki dla klientów i straty finansowe
Skutki dla użytkowników były natychmiastowe i bardzo bolesne dla portfela. Jedna z hurtowni budowlanych z poznańskich Jeżyc, która w momencie awarii obsługiwała 14 pilnych zamówień online, straciła łączność z systemem ERP. Straty wycenili na 4 120 zł w utraconych marżach oraz dodatkowe 1 200 zł kosztów nadgodzin dla pracowników, którzy musieli ręcznie księgować towary po przywróceniu prądu o 12:46. Inna firma logistyczna nie była w stanie wygenerować listów przewozowych dla 9 transportów, co zaowocowało karami umownymi na łączną kwotę 7 340 zł.
Łącznie cała awaria wygenerowała ponad 86 420 zł strat bezpośrednich dla klientów korzystających z usług tego konkretnego węzła. W Gbu Vps rozmawialiśmy z 6 właścicielami tych firm – większość z nich nie miała pojęcia, że ich dostawca hostingu oszczędzał na regularnych testach obciążeniowych. To pokazuje, jak ważna jest transparentność i posiadanie aktualnego raportu z testów zasilania awaryjnego. My taki raport przygotowujemy zazwyczaj w 2 dni po każdej większej zmianie w infrastrukturze, aby nasi partnerzy spali spokojniej.
Nowe procedury testowe od października
Dopiero o godzinie 12:35 technikom udało się ręcznie zsynchronizować pracę agregatów i przywrócić zasilanie do szyn głównych serwerowni. Pełne podniesienie wszystkich usług i systemów operacyjnych trwało kolejne 11 minut. Od początku października poznański węzeł wprowadził całkowicie nowy regulamin utrzymania ruchu. Każdy test agregatów będzie teraz obejmował fizyczne odcięcie od sieci miejskiej pod pełnym obciążeniem, a nie tylko symulację komputerową, jak to miało miejsce podczas niefortunnego przeglądu w lipcu.
Serwerownia wymieniła już wszystkie sterowniki w szafach SZR na nowsze modele oraz wymieniła 12 akumulatorów w szafie numer 4, które nie trzymały parametrów. Wprowadzono też dodatkowy czujnik temperatury na wysokości 30 cm od podłogi, aby szybciej wykrywać problemy z klimatyzacją. Wyciągnięto wnioski, ale koszt tej lekcji był bardzo wysoki. Dla nas w Gbu Vps to kolejny dowód na to, że w IT liczy się tylko to, co faktycznie działa w warunkach bojowych, a nie to, co ładnie wygląda w kolorowych folderach reklamowych.
Raport gotowy w 2 dni pozwolił wskazać 12 konkretnych błędów, które serwerownia naprawiła do końca września.



