Po kilku dniach bez większych problemów większość zespołu poczuła ulgę i cieszyła się nowym początkiem tygodnia. Ale problemy techniczne dotyczą również poniedziałków i mały błąd może spowodować ogromne problemy. To nasza trzecia historia z War Room i nazywamy ją Klęską DNS – tak, tytuł trochę ją psuje, ale jak niektórzy powiedzieliby: „To zawsze jest DNS”.
O 16:45 UTC niektórzy gracze zaczęli napotykać problemy z logowaniem. Zostali oni nagle rozłączeni i nie mogli się ponownie zalogować do gry. Ponieważ dotknięci gracze byli rozproszeni po różnych regionach, shardach i strefach, nasze systemy monitorujące wykryły jedynie niewielki spadek aktywności użytkowników i nie uruchomiły alarmu. Obserwując naszą aktywną społeczność Discord, jeden z pracowników firmy Mainframe zauważył niepokojący trend i szybko zdecydował się podnieść alarm i aktywować War Room.
O godzinie 17:00 UTC byliśmy w trybie diagnostycznym. Problem dotyczył logowania i zaczynał obejmować znaczną (i stale rosnącą) część naszej bazy graczy. Chociaż nadal mieliśmy dużą liczbę aktywnych graczy, krzywa była płaska lub zaczynała spadać – dokładnie wtedy, gdy powinna rosnąć. Nasze wstępne badanie obejmujące monitorowanie, wskaźniki, wykresy i alerty wskazało na kilka potencjalnych przyczyn. Jedna z naszych centralnych usług odpowiedzialnych za logowanie odnotowywała zwiększone obciążenie procesora, a w logach głównego systemu uwierzytelniania pojawiały się błędy. Dodatkowo zauważyliśmy problemy z systemem zarządzającym uprawnieniami (ustalającym, kto posiada grę i jaki typ licencji posiada) i postanowiliśmy się temu przyjrzeć, skupiając się na najbardziej prawdopodobnych winowajcach.
O godzinie 17:20 UTC postanowiliśmy ponownie uruchomić system uwierzytelniania, co wydawało się być przyczyną problemów. Z perspektywy czasu był to błąd. Ponieważ gracze już borykali się z problemami z logowaniem i ciągle próbowali ponownie. Ponowne uruchomienie systemu zaostrzyło problem. Skończyło się na tym, że musieliśmy tymczasowo zamknąć wszystkie żądania uwierzytelnienia, aby umożliwić ustabilizowanie się systemu, a ponieważ gra musiała regularnie odświeżać swoje tokeny uwierzytelniające, oznaczało to, że z biegiem czasu wszyscy gracze nie mogli kontynuować gry.
Po ponownym uruchomieniu naszego systemu uwierzytelniania postanowiliśmy ponownie zezwolić na wszystkie żądania kierowane do systemu. Ponieważ teraz wszyscy nasi gracze próbowali zalogować się jednocześnie, wcześniej zauważony problem z systemem uprawnień stał się rażąco oczywisty. System został przeciążony i całkowicie przeszedł w tryb offline, co oznaczało, że nawet ci użytkownicy, którym udało się połączyć, wyglądali, jakby nie posiadali już gry. W tym momencie wiedzieliśmy, że musimy walczyć na dwóch frontach jednocześnie. Problem z systemem uprawnień nie mógł czekać na rozwiązanie pierwotnej przyczyny rozłączeń. Na szczęście byliśmy o krok od rozwiązania tego problemu.
Zapytacie, co wywołało to bombardowanie? Niestety, była to rana, którą sam sobie zadałem. Podczas naszej diagnozy odkryliśmy, że niektóre nazwy hostów DNS nie były rozpoznawane poprawnie. Jeden z inżynierów biorących udział w rozmowie zidentyfikował problem — brakujący rekord DNS, a konkretnie krytyczny rekord delegacji NS. Inny inżynier natychmiast zorientował się, co się stało.
Wcześniej tego dnia zadanie porządkowe polegało na usunięciu niepotrzebnej infrastruktury i ten kluczowy zapis został omyłkowo usunięty. Ostatnie polecenia czyszczenia zostały wydane około 16:40 i tak się składa, że domyślny TTL (time-to-live) dla wielu rekordów DNS wynosi dokładnie 5 minut. Kilka ręcznych kroków później rekord został odtworzony i musieliśmy cierpliwie czekać na aktualizację pamięci podręcznych DNS na całym świecie.
Jednakże podstawową przyczyną jest jedynie moment wyzwalający, a ponieważ dyżurujący personel w naszym pokoju wojennym oceniał sytuację i kilku starszych inżynierów zaplecza gotowych do działania, nadal musieliśmy uporać się z problemem związanym z usługą uprawnień. Postanowiliśmy walczyć na dwóch frontach jednocześnie:
- Ścieżka eskalacji i wsparcia. Skontaktowaliśmy się z tą sprawą i przesłaliśmy tę kwestię do wyższego szczebla łańcucha wsparcia dostawcy odpowiedzialnego za przechowywanie uprawnień. Potwierdzili, że są przytłoczeni i obiecali, że rozwiązanie zostanie wkrótce wdrożone. Zegar zaczął tykać o godzinie 17:40 UTC.
- Ścieżka poprawki. Zmodyfikowaliśmy nasz kod uprawnień, aby uwzględnić metodę awaryjną faworyzującą naszych graczy. Gdybyśmy mieli problemy z rozwiązaniem uprawnień, ale gracz posiadał wcześniej określony typ licencji, założylibyśmy, że nadal tak jest i pozwolilibyśmy mu przejść. Mieliśmy już ścieżkę kodu podobną do tej, ale radziła sobie ona z ograniczeniem szybkości. Dodanie przypadku, aby uzyskać podobny wynik w przypadku, gdy usługa uprawnień nie odpowiadała, było łatwym zadaniem, a poprawka została sprawdzona, skompilowana, zbudowana i wdrożona w ciągu 10 minut.
Mieliśmy teraz trzy konie wyścigowe rywalizujące w tym samym wyścigu: nasza poprawka pozwalała graczom na dostęp w czasie, gdy usługa cierpiała, stabilizacja samej usługi uprawnień przy mniejszej liczbie przychodzących żądań i wdrażaniu poprawek oraz aktualizacja pamięci podręcznych DNS na całym świecie w celu rozpoznania odtworzonego rekordu.
Do 18:35 UTC sytuacja znacznie się poprawiła. Nasi gracze logowali się pomyślnie, system uprawnień nadrabiał zaległości, propagacja DNS dobiegała końca, a zespół War Room odwrócił tragiczną sytuację.
Problem z DNS został rozwiązany i byliśmy gotowi na kolejne wyzwanie, które pojawiło się na horyzoncie.
