Kiedy awaria kontroli pochłania cały system: lekcja z kolei

Multi-cloud to nie zawsze gwarancja bezpieczeństwa

Wielu z nas wierzy, że rozproszenie zasobów między AWS, Google Cloud i własne serwery chroni przed awariami. Brzmi sensownie. Powinno działać.

Railway, platforma do szybkiego wdrażania aplikacji, też w to wierzyła. Ich klienci korzystali z zasobów na Google Cloud, AWS i własnym sprzęcie Railway Metal. Wydawało się, że redundancja jest na najwyższym poziomie.

W maju 2026 roku wszystko się jednak rozpadło. Nie przez awarię infrastruktury Google. Zautomatyzowany system Google Cloud po prostu zawiesił konto Railway bez ostrzeżenia. Aplikacje klientów działały dalej — ale dostęp do nich został odcięty.

Kontrola nad ruchem to nie to samo co same serwery

Sam fakt, że aplikacje hostowano na różnych platformach, nie wystarczył. Kluczowy był kontrola nad ruchem sieciowym.

Każde żądanie przechodziło najpierw przez serwery proxy na brzegu sieci. Te serwery musiały wiedzieć, gdzie aktualnie znajduje się dana aplikacja. Te informacje pochodziły z control plane — centralnego systemu zarządzania, który cały czas siedział na Google Cloud.

Gdy konto zostało zawieszone, control plane przestał działać. Proxy jeszcze przez 35 minut korzystały z bufora danych. Potem bufor się wyczerpał. Od tego momentu wszystkie żądania kończyły się błędem 404, choć aplikacje na AWS i Railway Metal były w pełni funkcjonalne.

Kiedy jedna awaria pociąga za sobą kolejne

Nie skończyło się na tym. Duża liczba błędnych żądania i prób ponownie wywołała mechanizmy ochronne na GitHubie. System zaczął blokować logowania przez OAuth. Trwało to jeszcze długo po tym, jak Google przywrócił konto.

Efektem było to, że nawet gdy core services wróciły, użytkownicy nadal nie mogli się logować ani uruchomić nowych wdrożeń.

Dystrybucja nie oznacza odporności

Railway udało się rozproszyć obciążenie. Nie udało się jednak rozproszyć zarządzania ruchem. Control plane — ten, który entscheiduje, gdzie każde żądanie powinien być wysłany — pozostał w jednym miejscu.

W praktyce oznaczało odas, że pojedyncza taryfa od Google Cloud mogła tak samo zerwać dostęp do usług, wiec jak gdyby Railway nie korzystało z multi-cloud wcale.

Co z tego wynika dla nas praktyków

Control plane wymaga osobnego podejścia. Gdy budujesz system w multi-cloud, nie wystarczy rozłożyć tylko obciążenie. Musisz też rozłożyć zarządzanie i kierowanie ruchem.

Cache nie ratuje cię na zawsze. 35 minut to dużo czasu. But nie to jest ostateczna rozwiązanie. Gdy cache się wyczerpie, potrzebujesz niezależnego systemu rezerwowego.

Awarie się nakładają. Gdy jeden element zaczyna powodować błędy, łatwo wywołać kolejne mechanizmy blokujące. Incident response trzeba mieć przygotowany nie mniej niż samą architekturę.

Nie lekceważ automatyzacji providerów. Mechanizmy bezpieczeństwa Google nie wiedzą, co są prawdziwe awarie. Nie hast du kontakt do szybkiego escalation, może cię to kosztować wiele godzin przestoju.

Railway zapowiedziało już zmiany — rozproszenie control plane i usunięcie GCP jako jedynego punktu krytycznego. Ale dla wielu firm ta historia brzmi jak echo własnych obaw.