Alerty i reagowanie na incydenty

W DevOps monitorowanie pomaga nam obserwować, co się dzieje. Samo obserwowanie jednak nie wystarczy — musimy wiedzieć, kiedy coś pójdzie nie tak!

Alerty to powiadomienia uruchamiane po spełnieniu określonych warunków, sygnalizujących potencjalny problem. Można je traktować jak dzwonki alarmowe systemu.

Skuteczne alerty zmieniają bierne monitorowanie w proaktywne rozwiązywanie problemów. Są niezbędne do:

• Wczesnego wykrywania: Wykrywania problemów, zanim wpłyną na użytkowników.
• Szybszego rozwiązywania: Natychmiastowego powiadamiania właściwego zespołu.
• Zapobiegania awariom: Rozwiązywania drobnych problemów, zanim się nasilą.

Gdy uruchomi się alert, często sygnalizuje on incydent. Incydent to nieplanowana przerwa w działaniu usługi lub obniżenie jakości jej działania.

Przykładami są awaria serwera, brak odpowiedzi bazy danych lub nagły wzrost liczby błędów aplikacji.

Alerty konfiguruje się na podstawie różnych metryk lub logów. Oto typowe wyzwalacze:

• Progi: Wykorzystanie procesora > 90% przez 5 minut.
• Wskaźniki błędów: Błędy HTTP 500 stanowią > 1% żądań.
• Dostępność: Usługa nie zwraca odpowiedzi.
• Wzorce w logach: W logach pojawiają się określone komunikaty o błędach.

Nie wszystkie alerty są równie pilne. Kategoryzujemy je według ważności, aby ustalać priorytety reakcji:

• Krytyczny: Usługa nie działa lub jej działanie jest poważnie ograniczone. Wymagane jest natychmiastowe działanie.
• Ostrzeżenie: Rozwija się potencjalny problem, który wkrótce wymaga uwagi.
• Informacyjny: Niepilne zdarzenie, służące wyłącznie do przekazania informacji.

Po uruchomieniu alertu musi on dotrzeć do właściwych osób. Typowe kanały powiadomień to:

• E-mail: W przypadku mniej pilnych ostrzeżeń lub alertów informacyjnych.
• Czat (np. Slack): Dobry sposób na informowanie zespołu i wspólne diagnozowanie problemów.
• SMS/połączenie telefoniczne: W przypadku krytycznych alertów wymagających natychmiastowej uwagi, często za pośrednictwem narzędzi dyżurów, takich jak PagerDuty.

Reagowanie na incydenty to ustrukturyzowany proces obsługi i rozwiązywania incydentów. Typowy przebieg obejmuje:

1. Wykrycie: Uruchamia się alert.
2. Wstępną ocenę: Ocena ważności i wpływu incydentu.
3. Diagnozę: Identyfikacja przyczyny źródłowej.
4. Rozwiązanie: Usunięcie problemu.
5. Przywrócenie: Przywrócenie pełnej funkcjonalności usługi.
6. Analizę po incydencie: Wyciągnięcie wniosków z incydentu.

Runbook to szczegółowa instrukcja opisująca kroki potrzebne do rozwiązania typowych incydentów. Runbooki mają kluczowe znaczenie dla:

• Spójności: Zapewnienia jednolitego sposobu obsługi incydentów.
• Szybkości: Skrócenia czasu diagnozy i rozwiązywania problemów.
• Przekazywania wiedzy: Umożliwienia nowym członkom zespołu skutecznego reagowania.

Po rozwiązaniu incydentu niezbędny jest przegląd po incydencie (lub analiza post-mortem). Jest to analiza bez szukania winnych, skoncentrowana na następujących pytaniach:

• Co się wydarzyło?
• Dlaczego do tego doszło?
• Co mogło temu zapobiec?
• Jakie działania możemy podjąć, aby zapobiec powtórzeniu się sytuacji?

Celem jest ciągłe doskonalenie, a nie przypisywanie winy.

Które z poniższych stwierdzeń najlepiej opisuje główny cel runbooka w procesie reagowania na incydenty?

Omówiliśmy, jak alerty działają niczym alarm systemu i są uruchamiane przez określone warunki. Poznaliśmy różne poziomy ważności oraz kanały powiadomień.

Zrozumienie przebiegu reagowania na incydenty i korzystanie z runbooków ma kluczowe znaczenie dla sprawnej obsługi problemów. Ostatecznie przeglądy po incydentach wspierają ciągłe uczenie się i doskonalenie systemu.