Mój serwer spadł, a dowiedziałem się o tym pięć godzin później przez przypadek

Powiadomienie nie pochodziło z usługi monitorowania. Nie pochodziło z automatycznego alertu ani webhoka wysyłającego się na Slacka. Pochodziło z najbardziej prymitywnego systemu monitorowania, jaki można sobie wyobrazić: otwarcia przeglądarki, wpisania adresu URL i patrzenia na pustą stronę. Była wtorek po południu. Serwis był niedostępny od około dziewiątej rano, a teraz było już dobrze po drugiej. Pięć godzin całkowitej ciszy z aplikacji internetowej, która zwykle obsługiwała tysiące żądań dziennie. Pięć godzin, podczas których każdy odwiedzający widział stronę błędu, każde wywołanie API zwracało nic, a każde zaplanowane zadanie cicho nie powiodło się w tle. Serwer nie uległ dramatycznemu awarii. Nie było paniki jądra, uszkodzenia dysku ani wektora ataku, który pozostawił by dowody. Serwer VPS Contabo po prostu przestał odpowiadać na żądania HTTP, siedząc tam z prawidłowym adresem IP i biciem na warstwie sieciowej, ale odmawiając obsługi ruchu internetowego.

Odkrycie nastąpiło z powodu całkowicie niepowiązanego zadania. Trzeba było sprawdzić konkretny układ strony dla zmiany projektu, więc przeglądarka poszła na adres URL i zwróciła nic. Pierwszy instynkt to wina lokalnej sieci. Odświeżyłem stronę. Ciągle nic. Spróbowałem innej przeglądarki. Ciągle nic. Otworzyłem terminal i pingowałem serwer. Pakiety wróciły normalnie. Połączenie SSH? Działa dobrze. Status Apache? Martwy. Proces serwera internetowego gdzieś w wczesnych godzinach porannych uległ awarii i nigdy się nie uruchomił ponownie, ponieważ nie było skonfigurowanego nadzorcy procesów do obsługi tego dokładnego trybu awarii. Naprawa zajęła trzydzieści sekund. Zdanie sobie sprawy, że to może się stać ponownie i prawdopodobnie już się wcześniej stało bez czyjejkolwiek wiedzy, zajęło znacznie więcej czasu do przyswojenia.

Każdy deweloper, który uruchomił usługi produkcyjne na serwerze VPS, ma wersję tej historii. Może to nie było pięć godzin. Może to były dwie, osiem czy cały weekend. Szczegóły się różnią, ale wzór jest identyczny. Serwer spadł, nikt tego nie zauważył, a odkrycie było przypadkowe. Główny problem to nie niezawodność serwera. Serwery się psują, procesy się zawieszają, dyski się zapełniają, wycieki pamięci się gromadzą. To jest natura uruchamiania oprogramowania na fizycznym sprzęcie. Głównym problemem jest brak monitorowania, a dokładniej luka między wiedzą, że serwer jest online, a wiedzą, że aplikacja faktycznie działa.

Różnica między monitorowaniem dostępności a wiedzą, że Twoja strona faktycznie działa

Tradycyjne monitory dostępności radzą sobie dobrze w jednej rzeczy. Wysyłają żądanie HTTP na adres URL w regularnych odstępach czasu i sprawdzają, czy kod odpowiedzi to 200. Jeśli kod to coś innego lub żądanie się upłynęło, alarm się włącza. To łapie najbardziej katastrofalne awarie: serwer jest całkowicie niedostępny, domena wygasła, certyfikat SSL jest nieprawidłowy. Ale przegapia ogromną kategorię problemów, które są argumentowo bardziej powszechne i bardziej szkodliwe.

Rozważ scenariusz, w którym serwer zwraca kod statusu 200, ale strona jest uszkodzona. Połączenie z bazą danych nie powiodło się, więc obszar zawartości pokazuje komunikat o błędzie zamiast oczekiwanej listy produktów. Plik CSS nie udało się załadować, więc strona renderuje się jako niestylizowany HTML. Błąd JavaScript uniemożliwia inicjalizację głównej aplikacji, pozostawiając użytkownika patrzącego na spinner ładowania, który nigdy się nie rozwiąże. Widget firmy trzeciej iniekcję nakładkę, która pokrywa całą zawartość strony. We wszystkich tych przypadkach monitor dostępności raportuje wszystko jako zdrowe, ponieważ otrzymał odpowiedź 200. Serwer jest uruchomiony. Strona jest uszkodzona. Nikt nie wie.

Ta luka między „serwer odpowiada" a „strona działa" jest miejscem, w którym monitorowanie zrzutów ekranu staje się niezbędne. Zaplanowany zrzut ekranu przechwytuje to, jak strona faktycznie wygląda w regularnych odstępach czasu. Jeśli strona nagle pokazuje komunikat o błędzie, uszkodzony układ lub pusty biały ekran, zrzut ekranu sprawia, że jest to natychmiast widoczne. Połącz zaplanowane zrzuty ekranu ze porównaniem różnic pikseli, a system może automatycznie wykryć, kiedy strona zmieniła się w nieoczekiwany sposób. Kilka pikseli przesuwających się z powodu aktualizacji zawartości jest normalne. Całej strony zamieniającej się na biało lub wyświetlającej ślad stosu błędów nie, a algorytm różnic może rozróżnić między nimi z konfigurowalną czułością progu.

Po pięciogodzinnej awarii, pierwszą rzeczą, która została ustawiona, był monitor dostępności dla każdej krytycznej usługi. Ale bardziej interesującym dodatkiem było zaplanowane monitorowanie zrzutów ekranu, które przechwytuje rzeczywisty stan wizualny kluczowych stron co piętnaście minut. Monitor dostępności łapie oczywiste awarie. Monitor zrzutów ekranu łapie wszystko inne: subtelne awarie, które zwracają kod statusu 200 podczas wyświetlania uszkodzonej strony, skrypty firm trzecich, które wstrzykują nieoczekiwaną zawartość, błędy bazy danych, które pojawiają się tylko w określonych warunkach.

Zbudowanie rurociągu alertów, który powinien był istnieć od pierwszego dnia

Architektura właściwego systemu monitorowania nie jest skomplikowana w teorii. Harmonogram uruchamia sprawdzenie w określonych odstępach czasu. Sprawdzenie przechwytuje aktualny stan celu. Stan jest porównywany z oczekiwaną linią bazową. Jeśli porównanie przekroczy próg, alarm się włącza. Wyzwaniem nie jest architektura, ale niezawodność każdego komponentu. System monitorowania, który sam się wyłącza, jest gorszy niż brak monitorowania, ponieważ stwarza fałszywe poczucie bezpieczeństwa.

Rurociąg monitorowania zrzutów ekranu działa w etapach. Harmonogram wysyła zadanie przechwytywania w skonfigurowanym odstępie czasu, zwykle co pięć, dziesięć lub piętnaście minut, w zależności od krytyczności strony. Zadanie przechwytywania uruchamia instancję Chromium bez nagłówków, która ładuje stronę, czeka na ukończenie renderowania i zapisuje wynikowy zrzut ekranu. Nowy zrzut ekranu jest następnie porównywany z poprzednim przechwyconym zrzutem przy użyciu algorytmu porównywania różnic pikseli, który identyfikuje zmienione regiony i oblicza całkowity procent zmian. Jeśli zmiana przekroczy skonfigurowany próg, powiadomienie jest wysyłane przez skonfigurowane kanały: wiadomość e-mail, webhook, Slack lub dowolny niestandardowy punkt końcowy.

Porównanie różnic to miejsce, w którym rzeczy stają się naprawdę interesujące z perspektywy technicznej. Naiwne porównanie pikseli oznaczyłoby każdy zrzut ekranu jako zmieniony z powodu dynamicznej zawartości, takiej jak znaczniki czasu, reklamy lub elementy animowane. Silnik różnic to robi, wspierając strefy wykluczenia, prostokątne regiony strony, które są zamaskowane przed porównaniem. Znacznik czasu w nagłówku, rotacyjna reklama banerowa, widget czatu na żywo w rogu: wszystkie z nich mogą być wykluczone, aby tylko znaczące zmiany wyzwalały alerty. To, co pozostaje po wykluczeniu, to obszar zawartości stabilnej, a wszelkie zmiany tam prawie na pewno są warte zbadania.

Pięciogodzinna awaria byłaby złapana w ciągu minut w ramach tego systemu. Pierwszy zaplanowany zrzut ekranu po spadku serwera zwróciłby puste zdjęcie lub stronę błędu, z których oba różniłyby się drastycznie od linii bazowej. Procent różnicy byłby bliski 100%, daleko powyżej jakiegokolwiek rozsądnego progu, a alert byłby natychmiast wyzwolony. Pięć godzin przestojów byłoby pięć minut, a te pięć minut byłoby samym interwałem monitorowania, a nie czasem, w którym człowiek przypadkowo natknął się na problem.

Co pięć godzin niewidzialnego przestoju faktycznie kosztuje

Bezpośredni koszt pięciogodzinnego przestoju jest łatwy do obliczenia, gdy liczby są dostępne. Dla witryny obsługującej tysiące codziennych żądań, pięć godzin stanowi znaczną część dziennego ruchu. Każde żądanie, które zwróciło błąd, było użytkownikiem, który nie otrzymał tego, czego szukał. Niektórzy z tych użytkowników byli nowymi odwiedzającymi, którzy nigdy więcej nie wrócą. Niektórzy byli istniejącymi użytkownikami, którzy straciliby małą ilość zaufania. Niektórzy byli konsumentami API, których własne aplikacje się zawiesiły z powodu zależności. Bezpośredni wpływ na przychód zależy od charakteru witryny, ale nawet dla małej aplikacji SaaS, pięć godzin przestojów w godzinach biznesowych może łatwo stanowić setki dolarów w utracie konwersji.

Ukryty koszt jest trudniej kwantyfikować, ale argumentowo większy. Wyszukiwarki, które przeszukały stronę podczas tych pięciu godzin, otrzymały odpowiedzi o błędzie, a chociaż krótka awaria jest ogólnie tolerowana przez infrastrukturę indeksowania Google, przedłużona awaria może skutkować tymczasowym usunięciem z indeksu dotkniętych stron. Kampanie e-mailowe, które były uruchomione podczas awarii, doprowadziły ruch do martwego punktu końcowego, marnując całą budżet kampanii. Zaplanowane zadania, które zależą od aplikacji internetowej, takie jak dostawy webhooków, generowanie raportów i przetwarzanie wsadowe, wszystkie nie powiodły się w milczeniu i musiały być zidentyfikowane i ponownie uruchomione ręcznie po przywróceniu serwera.

Najbardziej podstępny koszt to ten reputacyjny. Użytkownicy, którzy napotykają wyłączoną witrynę, zwykle nie wysyłają wiadomości e-mail z informacją „Twoja witryna jest wyłączona". Po prostu odchodzą i mogą, ale nie muszą wrócić. Nie ma mechanizmu sprzężenia zwrotnego dla przestojów, ponieważ sam mechanizm sprzężenia zwrotnego jest wyłączony. Pięciogodzinne okno było wystarczająco długie, aby niektórzy użytkownicy prawie na pewno spróbowali witryny, znaleźli ją uszkodzoną i przeszli do konkurenta bez kiedykolwiek wygenerowania ani jednego punktu danych, który wskazałby, co się stało. Są po prostu poweg, i nie ma sposobu, aby wiedzieć, ilu było lub którzy byli.

Od reaktywności do proaktywności i nigdy więcej nie odkrywanie przypadkowo

Lekcja z tego wtorkowego popołudnia nie była taka, że serwery się psują. To było już wiadome. Lekcją było to, że każda minuta między awarią a jej odkryciem to minuta skumulowanej szkody, a jedynym sposobem na zminimalizowanie tego okresu jest zautomatyzowanie detektowania. Monitorowanie przez człowieka nie skaluje się. Sprawdzanie witryny ręcznie raz dziennie oznacza średni czas wykrycia awarii wynoszący dwanaście godzin. Sprawdzenie go raz na godzinę to trzydzieści minut, ale żaden człowiek nie może realistycznie sprawdzić każdej strony każdej aplikacji raz na godzinę przez całą dobę.

Kombinacja monitorowania dostępności i wizualnego monitorowania zrzutów ekranu obejmuje obie warstwy problemu. Monitor dostępności łapie serwer całkowicie przechodzący do trybu offline. Monitor zrzutów ekranu łapie aplikację się uszkadzającą, podczas gdy serwer pozostaje uruchomiony. Razem zmniejszają okno detektowania z „kiedykolwiek ktoś zauważy" do samego interwału monitorowania, który może być tak krótki, jak jedna minuta dla usług krytycznych. Alert się włącza, powiadomienie przybywa, a naprawa rozpoczyna się w minutach zamiast godzin.

Serwer spadł jeszcze dwa razy od tego oryginalnego incydentu. Oba razy alert przybyła w ciągu trzech minut. Oba razy naprawa została zastosowana przed utracieniem jakiegokolwiek znaczącego ruchu. Infrastruktura monitorowania spłaciła się pierwszym incydentem, który udało jej się złapać, a wszystko potem to była czysta korzyść. Era odkrywania awarii przypadkowo skończyła się, a patrząc wstecz, jedynym rzeczywistym pytaniem jest to, dlaczego zajęło awarię pięciogodzinną, aby inwestycja była oczywista.