- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Poprzedni artykuł opisywał obszary i narzędzia monitoringu sklepu internetowego. Tutaj idziemy o krok dalej i prezentujemy konkretną listę alertów do wdrożenia — podzieloną na trzy kategorie: krytyczne (budzą kogoś o 3 w nocy), ważne (wymagają reakcji w ciągu godzin) i informacyjne (zbieramy, analizujemy, ale nie alarmują). To jest praktyczna mapa, z której możesz korzystać bezpośrednio konfigurując swoje narzędzia monitoringu. Jeśli nie czytałeś jeszcze artykułu o narzędziach i podejściu do monitoringu — zacznij tam, tutaj zakładamy, że wiesz, co i czym monitorować.
Alerty krytyczne (P1) — natychmiastowa reakcja
Alerty krytyczne to zdarzenia, przy których każda minuta oznacza utracone przychody lub poważne ryzyko dla danych. Powinny trafiać na telefon (SMS, call) do osoby on-call — niezależnie od godziny. Lista: sklep niedostępny — HTTP 5xx lub timeout na stronie głównej przez więcej niż 2 minuty. Checkout niedostępny — strona /cart lub /checkout zwraca błąd lub ładuje się powyżej 10 sekund. Brak zamówień przez X godzin w godzinach szczytu — próg ustalany na podstawie historii (np. jeśli w weekend między 10:00 a 14:00 normalne jest 15+ zamówień na godzinę, a jest 0 przez 30 minut — alarm). Błąd fatal PHP na krytycznych plikach — woocommerce.php, checkout, payment gateway. Certyfikat SSL wygasa za mniej niż 14 dni — przed wygaśnięciem, bo wygasły cert natychmiast blokuje dostęp dla klientów.
Konfigurujemy monitoring z alertami P1/P2/P3, on-call rotation i integracją z SLA. Wiesz o awarii zanim klient napisze maila.
Każdy z tych alertów powinien mieć jasno zdefiniowany playbook: kto jest on-call, jakie są pierwsze kroki diagnostyki, jak eskalować jeśli on-call nie reaguje w ciągu 15 minut. Brak playbooków przy krytycznych alertach to sytuacja, gdy budzisz się o 3 w nocy z alarmem i nie wiesz, co robić — co jest gorsze niż brak monitoringu, bo generuje stres bez efektu.
Alerty ważne (P2) — reakcja w godzinach roboczych lub szybciej
Alerty P2 to problemy, które wpływają na działanie sklepu lub dane, ale nie blokują całkowicie sprzedaży. Wymagają reakcji w ciągu 1–4 godzin (dla e-commerce z dużym ruchem) lub do początku następnego dnia roboczego (dla sklepów z mniejszym wolumenem). Lista: czas ładowania strony produktu powyżej 5 sekund przez więcej niż 10 minut — wskazuje na problem z serwerem, bazą danych lub wtyczką. Wskaźnik błędów PHP powyżej normalnego poziomu — np. więcej niż 10 nowych błędów w logu w ciągu godziny. Bramka płatnicza zwraca błędy walidacji lub timeout — płatności mogą nie przechodzić, ale checkout technicznie działa. Brak synchronizacji stanów magazynowych przez więcej niż 2h — zamówienia przyjmowane, ale stany w sklepie mogą być nieaktualne. Backup nie wykonał się zgodnie z harmonogramem — brak ostatniego backupu przez więcej niż 26h (przy harmonogramie dobowym).
Te alerty trafiają zazwyczaj jako email lub powiadomienie Slack do zespołu — nie jako budzik telefoniczny. Wyjątek: jeśli P2 pojawia się w Black Friday lub innym szczycie sprzedażowym, traktuj go jak P1 i działaj natychmiast.
Alerty informacyjne (P3) — zbieramy i analizujemy
Alerty informacyjne nie wymagają natychmiastowej reakcji — są materiałem do analizy w regularnych przeglądach systemu (tygodniowych lub miesięcznych). Lista: Core Web Vitals poniżej progu (LCP > 2,5s, INP > 200ms) — ważne dla SEO, ale nie jest kryzysem; planuj naprawę w ciągu tygodnia. Wzrost liczby 404 powyżej normy — może wskazywać na broken links, usuniętą kategorię produktów lub błędne przekierowania po aktualizacji. Nieudane próby logowania do panelu WordPress powyżej progu — sygnał ataku brute-force; weryfikuj i rozważ dodatkowe zabezpieczenia (2FA, limit loginów). Wzrost zużycia dysku powyżej 80% — ostrzeżenie zanim serwer się zapełni i padnie. Czas zapytań do bazy danych powyżej 2 sekund — slow queries wskazują na potrzebę optymalizacji bazy lub indeksowania; nie jest to kryzys, ale degeneruje wydajność.
Jak ustrukturyzować alerty — routing i eskalacja
Dobry system alertów to nie tylko lista zdarzeń — to zdefiniowany routing: kto co dostaje i kiedy. P1 → SMS + call do on-call (zawsze). P2 → Slack #alerty + email do technikalnego → eskalacja do on-call po 30 minutach bez odpowiedzi. P3 → email digest raz dziennie lub zapis do dashboardu przeglądanego na tygodniowych standupach. Narzędzia, które wspierają taki routing: PagerDuty i Opsgenie dla P1 (zarządzanie on-call, eskalacje, rotacje dyżurów), Slack i email dla P2/P3, własny dashboard w Grafana lub Datadog dla widoku synoptycznego całości.
Ostatnia zasada: przejrzyj alerty raz na kwartał. Alerty, które przez 3 miesiące nie wywołały żadnej akcji — są albo niepotrzebne (zbyt czuły próg), albo nigdy nie zostały sprawdzone (nikt nie wie, że się wysyłają). Monitoring, który generuje „szum” (fałszywe alarmy lub ignorowane powiadomienia), przestaje być monitoringiem — staje się tłem, które ludzie wyłączają.
