Kiedy nagle przestaje działać Facebook, Instagram i WhatsApp jednocześnie, większość z nas myśli, że to pechowy zbieg okoliczności lub zmasowany atak hakerski. Jednak w świecie nowoczesnych technologii przypadki zdarzają się rzadko. To, co widzimy jako osobne ikony na ekranie smartfona, często dzieli te same „fundamenty” głęboko pod ziemią lub w gigantycznych halach wypełnionych szumiącymi maszynami. Zrozumienie, dlaczego jedna usterka w odległym centrum danych potrafi „wyłączyć” pół internetu, wymaga spojrzenia na sieć nie jako na zbiór wysp, ale jako na naczynia połączone.
Współczesny internet przestał być siecią niezależnych komputerów. Stał się systemem wzajemnych zależności, w którym jedna usługa polega na dziesięciu innych, by w ogóle móc się uruchomić. To trochę jak z nowoczesnym samochodem: awaria jednego czujnika ciśnienia w oponach może sprawić, że komputer pokładowy ze względów bezpieczeństwa zablokuje zapłon, mimo że silnik jest całkowicie sprawny. W technologii nazywamy to pojedynczym punktem awarii (Single Point of Failure).
Wielka przeprowadzka do chmury
Jeszcze kilkanaście lat temu każda większa firma miała własną serwerownię – fizyczne pomieszczenie z szafami pełnymi sprzętu. Jeśli serwerownia firmy X uległa awarii, dotyczyło to tylko firmy X. Dzisiaj sytuacja wygląda zupełnie inaczej. Żyjemy w erze chmury obliczeniowej. Zamiast budować własne „garaże” na dane, niemal wszyscy wynajmują miejsce w gigantycznych „parkingach wielopoziomowych” należących do trzech graczy: Amazon (AWS), Microsoft (Azure) oraz Google (Google Cloud).
To rozwiązanie jest tańsze, szybsze i teoretycznie bezpieczniejsze, ale ma jedną kluczową wadę: centralizację. Kiedy w jednym z kluczowych centrów danych Amazona, na przykład w regionie us-east-1 w Wirginii, dojdzie do błędu w konfiguracji lub awarii zasilania, nie pada tylko sklep Amazon. Padają setki tysięcy usług, które „wynajmują” tam moc obliczeniową – od platform streamingowych, przez aplikacje randkowe, aż po systemy sterowania inteligentnymi odkurzaczami w naszych domach. Choć dla użytkownika to różne firmy, ich „serce” bije w tym samym budynku.
Efekt domina i architektura mikrousług
Dlaczego jednak awaria jednego, konkretnego elementu potrafi unieruchomić całą aplikację? Odpowiedzią jest sposób, w jaki buduje się dzisiaj oprogramowanie. Dawniej aplikacje były „monolitami” – jednym wielkim programem. Jeśli coś się psuło, zazwyczaj psuło się wszystko, ale łatwiej było to kontrolować.
Dziś programiści stosują mikrousługi. Wyobraźmy sobie, że aplikacja bankowa to nie jeden program, ale zestaw małych robocików. Jeden odpowiada za logowanie, drugi za sprawdzanie salda, trzeci za wysyłanie powiadomień SMS, a czwarty za wyświetlanie ikonki profilu. Te robociki (mikrousługi) muszą ze sobą rozmawiać. Jeśli „robocik od logowania” nagle przestanie działać, bo serwer, na którym mieszkał, uległ awarii, cała reszta staje się bezużyteczna. Użytkownik nie zobaczy salda ani nie zrobi przelewu, mimo że serwery odpowiedzialne za te konkretne funkcje działają bez zarzutu. Łańcuch jest tak silny, jak jego najsłabsze ogniwo – w świecie IT to powiedzenie jest bolesną codziennością.
DNS, czyli cyfrowa książka telefoniczna
Czasami serwery danej usługi działają idealnie, a my i tak nie możemy się z nimi połączyć. Bardzo często winowajcą jest DNS (Domain Name System). Komputery nie rozumieją nazw takich jak „google.pl” czy „zrozumiesz.pl”. One komunikują się za pomocą adresów IP, które wyglądają jak ciągi cyfr (np. 142.250.186.163). DNS to system, który tłumaczy ludzkie nazwy na te zrozumiałe dla maszyn.
Jeśli serwer DNS ulegnie awarii, internet „zapomina”, gdzie znajdują się poszczególne strony. To tak, jakbyś miał sprawny telefon i wiedział, do kogo chcesz zadzwonić, ale nagle zniknęłyby wszystkie numery z Twojej listy kontaktów. Usługa technicznie istnieje, serwer pracuje, ale nikt nie potrafi do niego trafić. Ponieważ wiele firm korzysta z tych samych dostawców usług DNS (np. Cloudflare czy Akamai), awaria u jednego z nich skutkuje zniknięciem z sieci tysięcy witryn jednocześnie.
BGP – kiedy mapa internetu zostaje spalona
Jedna z najsłynniejszych awarii ostatnich lat, która wyłączyła usługi Facebooka na wiele godzin, była związana z protokołem BGP (Border Gateway Protocol). Można go porównać do nawigacji GPS dla pakietów danych. BGP mówi routerom na całym świecie: „Hej, żeby dostać się do Facebooka, musisz jechać tędy!”.
Podczas rutynowej aktualizacji inżynierowie Facebooka niechcący wysłali błędną instrukcję, która w skrócie brzmiała: „Facebook już nie istnieje, nie ma do nas żadnej drogi”. W ciągu kilku minut routery na całym świecie zaktualizowały swoje mapy i przestały kierować ruch do serwerów giganta. Co najgorsze, ta awaria odcięła też dostęp samym pracownikom do ich systemów wewnętrznych – nie mogli nawet otworzyć drzwi do serwerowni za pomocą kart magnetycznych, bo system kontroli dostępu… również próbował połączyć się z nieistniejącym w sieci serwerem. To pokazuje, jak głęboko sięgają te zależności.
API – niewidzialne nici porozumienia
Kolejnym powodem, dla którego jedna awaria „rozlewa się” na inne usługi, są interfejsy API. To specjalne złącza, dzięki którym różne programy mogą wymieniać się danymi. Kiedy logujesz się do nowej gry za pomocą konta Google lub Facebooka, używasz API. Kiedy sklep internetowy sprawdza, czy paczka z InPostu już dotarła, używa API.
Współczesne serwisy są jak klocki Lego. Jeśli serwer obsługujący popularne API płatności (np. Stripe czy PayPal) przestanie działać, nagle tysiące sklepów internetowych na całym świecie traci możliwość finalizacji zakupów. Właściciel sklepu może mieć świetne serwery, ale bez zewnętrznego „łącznika” jest sparaliżowany. Zależność od firm trzecich to cena, jaką płacimy za wygodę i szybkość wdrażania nowych funkcji.
Dlaczego nie budujemy systemów odpornych na takie awarie?
Można by zapytać: skoro wiemy, że centralizacja jest ryzykowna, to dlaczego wciąż w to brniemy? Odpowiedź jest brutalnie prosta: koszty i skomplikowanie. Zbudowanie systemu, który jest w pełni niezależny i odporny na awarie dostawców zewnętrznych, jest niesamowicie drogie. Wymagałoby to dublowania każdego elementu infrastruktury w różnych częściach świata i u różnych dostawców.
Dla większości firm ryzyko, że raz na dwa lata ich usługa nie będzie działać przez trzy godziny z powodu awarii Amazona czy Google, jest łatwiejsze do zaakceptowania niż płacenie potrójnych rachunków za utrzymanie serwerów każdego miesiąca. To swoisty hazard, w którym stawką jest dostępność usług w zamian za optymalizację budżetu.
Warto też pamiętać o czynniku ludzkim. Mimo ogromnej automatyzacji, za większością spektakularnych awarii stoi człowiek – błędna linijka kodu, źle wpisana komenda w terminalu czy niedopatrzenie podczas konserwacji sprzętu. W systemach o tak dużej skali, gdzie jeden serwer zarządza pracą tysięcy innych, błąd jednostki jest multiplikowany w ułamku sekundy.
Podsumowując, internet, który znamy, nie jest monolitem. To raczej gęsta sieć pajęcza. Jeśli przetniesz jedną główną nić, drgania poczują wszyscy jej mieszkańcy, a cała konstrukcja może stracić stabilność. Jedna awaria serwera wyłącza wiele usług, bo te usługi dawno przestały być samowystarczalne – stały się częścią jednego, wielkiego cyfrowego organizmu.
