Dlaczego potrzebujesz spisanego planu
Podczas incydentu Twój mózg nie pracuje na pełnych obrotach. Stres zawęża koncentrację. Zapominasz o krokach. Pomijasz komunikację. Naprawiasz objaw, ale nie przyczynę.
Spisany plan reagowania na incydenty zdejmuje myślenie z pierwszych 10 minut. Postępujesz według listy kontrolnej. Wiesz, co robić i w jakiej kolejności. Plan obsługuje proces, aby Twój mózg mógł zająć się debugowaniem.
Ten szablon jest zaprojektowany dla małych zespołów (2-10 osób). Zakłada, że nie masz dedykowanego zespołu SRE ani dyżuru z 15 osobami. Zakłada, że osoba, która dostaje alert, jest również tą, która naprawia problem.
Plan reagowania na incydenty
Krok 1: Wykryj
Twoje narzędzie monitorujące wysyła alert. Otrzymujesz powiadomienie: „Monitor [nazwa] nie działa. 3 kolejne niepowodzenia. HTTP 500.”
Nie panikuj. Poświęć 30 sekund na weryfikację. Sprawdź stronę samodzielnie. Sprawdź panel monitorowania pod kątem innych alertów. Pojedynczy monitor, który padł, może być fałszywym alarmem. Wiele monitorów, które padły, oznacza prawdziwy incydent.
Jeśli używasz PingWatchdog, incydenty są tworzone automatycznie, gdy monitory padają. Otrzymujesz oś czasu tego, co się stało i kiedy. To Twój punkt wyjścia do debugowania.
Krok 2: Zadeklaruj
Jeśli to prawdziwy incydent (nie fałszywy alarm ani zaplanowane zdarzenie), zadeklaruj go. Poinformuj zespół. Poinformuj użytkowników.
Dla zespołu: Opublikuj na wyznaczonym kanale incydentów (Slack, Discord, Teams). Podaj, co wiesz: które monitory padły, kiedy padły, jakie błędy widzisz. Oznacz każdego, kto może być potrzebny.
Dla użytkowników: Zaktualizuj stronę statusu. Opublikuj aktualizację „Badamy”. Nie musisz znać przyczyny źródłowej. Musisz tylko potwierdzić problem. „Badamy zgłoszenia podwyższonych błędów API. Następna aktualizacja za 15 minut.”
Twoja strona statusu powinna aktualizować się automatycznie na podstawie danych monitorowania. Jeśli monitor padł, strona statusu powinna to pokazywać. Ręczna aktualizacja mówi użytkownikom, że się tym zajmujesz.
Krok 3: Zbadaj
Zacznij od najprostszego wyjaśnienia. Czy niedawno wdrożyłeś zmiany? Czy zmieniła się zależność? Czy usługa strony trzeciej miała incydent?
Sprawdź dane monitorowania. Jakie błędy zgłaszają sondy? Odmowa połączenia? Awaria DNS? Przekroczenie czasu? HTTP 500 z konkretnym komunikatem błędu? Dane sond pokazują, co widzi świat zewnętrzny.
Sprawdź logi. Logi aplikacji, logi bazy danych, logi serwera WWW. Szukaj błędów, które rozpoczęły się mniej więcej w tym samym czasie, gdy monitor padł.
Sprawdź infrastrukturę. Czy serwer działa? Czy baza danych przyjmuje połączenia? Czy użycie pamięci lub dysku gwałtownie rośnie? Czy wykorzystanie CPU jest nienormalne?
Krok 4: Złagodź
Gdy już wiesz, co jest nie tak, zatamuj krwawienie. To może nie być trwałe rozwiązanie. To w porządku. Celem jest najpierw przywrócenie usługi, a potem naprawa przyczyny źródłowej.
Typowe działania łagodzące:
- Wdróż wycofanie: Jeśli niedawne wdrożenie spowodowało problem, wróć do poprzedniej wersji. Wdróż poprawkę po rozwiązaniu incydentu.
- Uruchom ponownie usługę: Pule połączeń bazy danych, serwery cache i kolejki wiadomości czasami potrzebują restartu. Uruchom ponownie usługę i monitoruj odzyskiwanie.
- Skaluj zasoby w górę: Jeśli problemem jest wyczerpanie zasobów (CPU, pamięć, połączenia), skaluj w górę. Możesz zmniejszyć po incydencie.
- Przełącz na zapasowy: Jeśli dotknięty jest pojedynczy serwer lub region, przekieruj ruch gdzie indziej.
Krok 5: Komunikuj
Podczas łagodzenia opublikuj kolejną aktualizację statusu. „Problem zidentyfikowany jako wyczerpanie puli połączeń bazy danych. Wdrażamy poprawkę.”
Po wdrożeniu poprawki opublikuj ponownie. „Poprawka wdrożona. Monitorujemy odzyskiwanie.”
Po potwierdzeniu odzyskania opublikuj końcową aktualizację. „Usługa przywrócona. Czas trwania incydentu: 23 minuty.”
Nie pozwól, aby minęło więcej niż 30 minut bez aktualizacji, nawet jeśli aktualizacja brzmi „Nadal badamy. Zawęziliśmy problem do warstwy bazy danych.” Cisza tworzy niepewność. Aktualizacje tworzą zaufanie.
Krok 6: Rozwiąż
Poczekaj, aż Twoje monitory potwierdzą odzyskanie. Nie ogłaszaj rozwiązania incydentu na podstawie szybkiego ręcznego sprawdzenia. Pozwól zautomatyzowanym kontrolom zweryfikować, że usługa jest stabilna.
PingWatchdog automatycznie rozwiązuje incydenty, gdy monitory wracają do statusu „działa” przez dłuższy okres. Zapewnia to, że nie zamkniesz incydentu przedwcześnie.
Krok 7: Post-mortem
W ciągu 24 godzin od incydentu napisz krótkie post-mortem. Nie musi to być formalny dokument. Wiadomość na Slacku lub krótki dokument wystarczy. Odpowiedz na te pytania:
- Co się stało? Opisz incydent prostym językiem.
- Jaki był wpływ? Jak długo usługi były dotknięte? Które usługi? Ilu użytkowników?
- Jaka była przyczyna źródłowa? Co konkretnie wywołało awarię?
- Jak to wykryto? Czy monitorowanie to wychwyciło? Czy użytkownik to zgłosił?
- Jak to rozwiązano? Jakie kroki podjęto, aby to naprawić?
- Co zapobiegnie ponownemu wystąpieniu? Jakie działania wynikają z tego?
Celem post-mortem nie jest przypisywanie winy. To nauka i doskonalenie. Każdy incydent to szansa na uczynienie systemu bardziej niezawodnym.
Konfiguracja zestawu narzędzi do incydentów
Aby wykonać ten plan, potrzebujesz kilku rzeczy na miejscu przed wystąpieniem incydentu:
Monitorowanie: Monitorowanie uptime, monitorowanie SSL i monitorowanie heartbeat. Musisz wiedzieć o problemach, zanim zgłoszą je użytkownicy. Skonfiguruj monitorowanie PingWatchdog.
Alerty: Alerty kierowane do właściwych kanałów. Krytyczne monitory trafiają do PagerDuty lub powiadomień telefonicznych. Niekrytyczne trafiają na Slack. Skonfiguruj kanały alertów.
Strona statusu: Publiczna strona statusu, gdzie użytkownicy mogą sprawdzić stan usług. Aktualizacje podczas incydentów powinny być szybkie i szczere. Skonfiguruj stronę statusu.
Zarządzanie incydentami: Automatycznie tworzone incydenty z osiami czasu. Gdy zaczyna się incydent, nie powinieneś musieć ręcznie tworzyć zgłoszenia. Narzędzie monitorujące powinno to zrobić za Ciebie. Dowiedz się więcej o zarządzaniu incydentami.
Kanały komunikacji: Wyznaczony kanał Slack, pokój Discord lub kanał Teams dla incydentów. Każdy wie, gdzie iść podczas incydentu.
Przećwicz plan
Przeprowadź próbny alarm. Wybierz niekrytyczną usługę. Celowo ją wyłącz. Postępuj zgodnie z planem. Zmierz, ile czasu zajmuje każdy krok.
Większość zespołów odkrywa, że najtrudniejszą częścią nie jest naprawa techniczna. To komunikacja. „Naprawiłem problem w 5 minut, ale spędziłem 15 minut na zastanawianiu się, co powiedzieć na stronie statusu.” Praktyka przyspiesza komunikację.
Zacznij budować swój plan
Powyższy szablon działa w obecnej formie. Dostosuj nazwy kanałów, ścieżki eskalacji i odwołania do narzędzi dla swojego zespołu. Zachowaj zwięzłość. Jeśli plan jest dłuższy niż jedna strona, Twój zespół nie przeczyta go podczas incydentu.
Zacznij monitorować za darmo z PingWatchdog. Każdy plan obejmuje zarządzanie incydentami z automatycznie tworzonymi i rozwiązywanymi incydentami.