Czego nauczył nas bot na ponad 2000 serwerach Discord

Bot Discord na trzech serwerach i ten sam bot na ponad dwóch tysiącach to nie jest ten sam program w większym rozmiarze. Garść założeń, które w małej skali są zupełnie nieszkodliwe, od pewnego rozmiaru staje się dokładnie tymi błędami, które najtrudniej znaleźć.

Oto cztery, które kosztowały nas prawdziwe awarie.

1. Awarie nie rozkładają się równo, tylko się chowają

AlphaCloud działa podzielony na kilka procesów, tak zwanych shardów. Discord decyduje, który serwer trafia na który shard, a każdy shard zna tylko swoje serwery.

Tak powstaje klasa awarii, które z zewnątrz wyglądają na przypadek: wiadomości powitalne działają na niektórych serwerach, a na innych nie. Żadnego błędu w logu, żadnego alarmu, nic. Przyczyną było jedno wywołanie sieciowe bez limitu czasu. Jeśli druga strona przyjmie połączenie, a potem zamilknie, kod czeka do końca życia procesu. Wszystko, co jest po nim, nigdy się nie dzieje, a ponieważ żaden błąd nie jest rzucany, nic nie zgłasza błędu.

Lekcja jest niespektakularna i uniwersalna: każde wychodzące wywołanie potrzebuje górnej granicy. Wywołanie, które czeka w nieskończoność, jest gorsze niż takie, które zawodzi, bo awaria przynajmniej jest widoczna.

2. Restart to nie poprawka, tylko termin

Dopóki nie znaliśmy przyczyny, restart dotkniętego sharda niezawodnie pomagał. Właśnie w tym problem z restartami: działają, a to zdejmuje presję szukania przyczyny.

Teraz traktujemy pytanie "czy restart pomaga?" jako diagnozę, a nie lekarstwo. Jeśli pomaga, zepsuty stan żyje w pamięci, a w kodzie jest miejsce, które go buduje i nigdy nie rozbiera.

Odwrotnie też to działa: wszystko, co musi przetrwać restart, należy do bazy danych. Jeśli trwa wieloetapowa operacja, powiedzmy zmiana roli u tysięcy członków, a proces padnie w połowie, operacja nie może po prostu zniknąć. Musi zostać wykryta i kontynuowana przy następnym starcie.

3. Limity Discorda dotyczą bota, a nie procesu

Discord ogranicza, ile zapytań na sekundę może wykonać bot. Oczywiste założenie: więcej procesów, większa przepustowość. Błąd. Limit dotyczy bota, a nie procesu. Trzy shardy, każdy z pełnym budżetem, dają razem trzykrotność przydziału, a Discord dławi wtedy wszystkie trzy.

Dlatego każdy nasz proces wylicza, ile jest ich łącznie, i bierze tylko swoją część. Brzmi oczywiście, ale takie nie było, a błąd długo pozostawał niewidoczny, bo każdy pojedynczy proces sam w sobie zachowywał się całkowicie poprawnie.

Pokrewna pułapka: cykliczne zadania działają w stałych odstępach, na przykład co pięć minut. Jeśli wszystkie shardy startują w tym samym czasie, na zawsze odpalają swoje zadania w tej samej chwili. Od tamtej pory każdy proces dostaje przy starcie losowe przesunięcie.

4. To, co ludzie naprawdę konfigurują, nie jest tym, czego się spodziewasz

Część techniczna to jedna połowa. Druga: dla większości serwerów wartość domyślna jest ustawieniem. Moduł ze złymi wartościami domyślnymi jest źle skonfigurowany na zdecydowanej większości serwerów, niezależnie od tego, jak dobra jest strona ustawień.

Wynikają z tego dla nas dwie rzeczy. Po pierwsze, każda wartość domyślna wymaga więcej namysłu niż samo ustawienie. Po drugie, lepsze pytanie przy nowym module to nie "co tu można skonfigurować", tylko "co ten moduł robi, gdy nikt niczego nie konfiguruje, i czy to jest właściwe dla zwykłego serwera".

Z tego bierze się też decyzja, która na pierwszy rzut oka brzmi odwrotnie: od v1.8.0 prawie każdą wiadomość bota można dowolnie zaprojektować. Ale obowiązkowe bloki, jak powód w wiadomości prywatnej z ostrzeżeniem czy menu kategorii w panelu ticketów, można przesuwać, ale nie usuwać. Swoboda projektowania tak, ale nie do tego stopnia, żeby serwer przypadkiem zbudował coś, co wygląda na działające, a nie działa.

Wspólny wątek

Trzy z czterech to ta sama myśl w różnych przebraniach: w tej skali cicha awaria jest droższa niż głośna. O awarii, która wywala proces, ktoś zgłasza i się ją naprawia. Funkcja, która po prostu przestaje cokolwiek robić, może tak pozostać przez miesiące, a dowiadujesz się o tym ze zgłoszenia błędu od kogoś, kto zadał sobie trud, żeby napisać.

Więc pierwsze pytanie, które zadajemy teraz przy nowym kodzie, to nie "czy to działa", tylko "jak to wygląda, gdy nie działa, i czy byśmy to zauważyli".