Bez kategorii

Każda minuta niedostępności sklepu internetowego to realne straty finansowe i utratę zaufania klientów. Monitoring dostępności sklepu to nie tylko sprawdzanie, czy strona „odpowiada” – to system wczesnego wykrywania problemów, automatyczne powiadamianie odpowiednich osób i procedury reagowania, które decydują o tym, czy awaria potrwa kilkanaście minut, czy kilka godzin. Poniżej znajdziesz praktyczne podejście do budowania takiego systemu, bez obietnic gwarancji uptime na poziomie 100 % i bez ukrytych kosztów.

Dlaczego monitoring uptime to podstawa bezpieczeństwa biznesu

Uptime to wskaźnik dostępności usługi wyrażony w procentach. W branży e-commerce standardem jest celowanie w 99,9 % (ok. 8,76 godziny przestojów rocznie) lub 99,99 % (ok. 52 minuty rocznie). Różnica między tymi wartościami to realne pieniądze – przy sklepie generującym 10 000 zł dziennie, każda godzina przestoju to strata rzędu 400-500 zł przy założeniu równomiernego ruchu, a w rzeczywistości straty są często większe, bo awarie zdarzają się w godzinach szczytu.

Monitoring dostępności sklepu pełni trzy funkcje:

• Wykrywanie – automatyczne stwierdzenie, że coś nie działa, zanim zgłoszą to klienci.
• Powiadamianie – dostarczenie informacji do odpowiedniej osoby w odpowiednim kanale (SMS, e-mail, Slack, webhook).
• Dowody – logi i zrzuty ekranu, które ułatwiają rozmowę z hostingiem lub deweloperami i służą do rozliczeń SLA.

Bez monitoringu pierwsza informacja o awarii przychodzi z mediów społecznościowych, od wiernego klienta albo z Google Search Console – zazwyczaj z opóźnieniem 30-60 minut.

Co monitorować – nie tylko kod 200 OK

Proste sprawdzanie kodu odpowiedzi HTTP 200 to minimum. Sklep może zwracać 200, a jednocześnie:

• wyświetlać pustą stronę lub błąd PHP widoczny tylko w treści,
• nie ładować koszyka lub płatności (JavaScript error),
• działać bardzo wolno (Time To First Byte > 3 s),
• mieć problemy z bazą danych (zapytania wiszą, connection pool wyczerpany),
• zwracać błąd 500 tylko dla konkretnych endpointów API (np. `/api/cart/add`).

Kluczowe punkty kontrolne (checkpoints)

1. Strona główna – najczęstszy lądowanie ruchu organicznego i płatnego.
2. Strona produktu – sprawdź renderowanie danych z bazy, zdjęć, cen, dostępności.
3. Koszyk i checkout – symulacja dodania produktu, przejścia do płatności (można użyć testowego konta lub sandboxu bramki).
4. API / webhooki – jeśli sklep komunikuje się z ERP, WMS, systemem faktur lub marketplace.
5. Panel administracyjny – dostępność backendu dla zespołu operacyjnego.
6. Certyfikat SSL – data wygaśnięcia, poprawność łańcucha, ocena SSL Labs.
7. DNS i domena – propagacja, czas odpowiedzi serwerów nazw, blokady rejestru.

Metryki wydajnościowe do śledzenia

• TTFB (Time To First Byte) – czas do pierwszego bajtu odpowiedzi; cel < 600 ms.
• Pełny czas ładowania (Load Time) – z zasobami statycznymi; cel < 3 s na mobile.
• Core Web Vitals – LCP, INP, CLS – wpływają na SEO i konwersję.
• Error rate – procent odpowiedzi 5xx / 4xx w oknie czasowym (np. 5 minut).

Jak skonfigurować alerty, by nie zaszaleć od fałszywych alarmów

Zbyt czułe alerty powodują „alert fatigue” – zespół zaczyna je ignorować. Zbyt mało czułe – awaria zostaje zauważona za późno. Kluczem jest wielopoziomowe progi i kanały eskalacji.

Przykładowa matryca alertów

| Warunek | Opóźnienie przed alertem | Kanał | Odbiorca | |———|————————–|——-|———-| | Brak odpowiedzi (timeout > 10 s) lub kod 5xx | 1 minuta | SMS + telefon (voice call) | DevOps / Lead Developer | | TTFB > 2 s przez 5 min | 5 minut | Slack / Teams + e-mail | Tech Lead | | Error rate > 2 % w 5 min | 3 minuty | Slack / Teams | Developer deżurny | | Certyfikat SSL wygasa za < 14 dni | Natychmiast | E-mail | Admin / Właściciel | | Domena wygasa za < 30 dni | Natychmiast | E-mail | Właściciel / Finanse |

Dobre praktyki alertowania

• Grupuj alerty – jeśli padnie baza, nie chcesz 50 alertów z 50 endpointów. Użyj korelacji (np. „jeśli > 3 checkpoints down w 2 min → jeden alert 'Critical: Database layer'”).
• Okna ciszy (maintenance windows) – wycisz alerty w planowanych oknach (np. 03:00-04:00), ale loguj wyniki sprawdzania.
• Auto-resolve – alert zamyka się sam, gdy warunek znika; historia zostaje w systemie.
• Runbook w alercie – dołącz link do procedury „Co robić, gdy X” (np. link do Confluence/Notion/Google Docs).

Pierwsze 15 minut awarii – procedura krok po kroku

Gdy alert dotrze do deżurnego, liczy się każda minuta. Poniższy schemat działa w wielu zespołach i można go dostosować do własnej rzeczywistości.

Minuta 0-1: Potwierdzenie i triage

1. Otwórz link do dashboardu monitoringu (np. UptimeRobot, Better Uptime, Pingdom, Zabbix, Grafana Alerting).
2. Sprawdź, czy problem dotyczy wszystkich checkpointów (cały sklep) czy wybranych (tylko API, tylko checkout).
3. Otwórz sklep w trybie incognito / prywatnym oknie – wyklucz cache przeglądarki i własne IP.
4. Sprawdź status hostingu / chmury (status page AWS, Azure, DigitalOcean, Cloudflare, dostawcy VPS).

Minuta 1-3: Szybka diagnoza po stronie serwera

• SSH / konsola serwera – czy serwer odpowiada? `top`, `htop`, `df -h`, `free -m`.
• Logi aplikacji – `tail -f /var/log/nginx/error.log`, `var/log/php-fpm/error.log`, logi aplikacji (Laravel: `storage/logs/laravel.log`, Symfony: `var/log/prod.log`, PrestaShop: `var/logs/`).
• Baza danych – `SHOW PROCESSLIST;` (MySQL/MariaDB), sprawdź blokady, długie zapytania, liczbę połączeń.
• Kolejki / workerzy – Redis, RabbitMQ, Supervisor – czy procesy żyją? `systemctl status php8.2-fpm`, `systemctl status nginx`.

Minuta 3-5: Decyzja – rollback, restart, hotfix, eskalacja

| Objaw | Typowa akcja | |——-|————–| | Wdrożenie 10 min temu + błędy 500 | `git revert` / `deploy rollback` (jeśli masz CI/CD z rollbackiem) | | PHP-FPM / Nginx down | `systemctl restart php8.2-fpm nginx` | | Baza: „Too many connections” | Zwiększ `max_connections` tymczasowo, zabij idle procesy, sprawdź czy nie ma zapytania bez `LIMIT` | | Dysk pełny (logi, backupy, sesje) | `ncdu /`, wyczyść stare logi, przenieś backupy, zwiększ dysk | | Certyfikat SSL wygasł | Odnowienie Let’s Encrypt (`certbot renew –force-renewal`) lub wgranie nowego certyfikatu | | Problem u dostawcy (Cloudflare, hosting) | Otwórz ticket z priorytetem Critical, przełącz DNS na backup (jeśli masz) |

Minuta 5-10: Komunikacja wewnętrzna i zewnętrzna

• Wewnątrz: krótka notka na Slacku/Teams: „Awaria sklepu od 14:23, przyczyna X, ETA naprawy Y, lead: @jan.kowalski”.
• Zewnątrz (opcjonalnie): jeśli awaria trwa > 10 min i to godziny szczytu – wpis na Facebooku/Instagramie/LinkedIn: „Przepraszamy, mamy chwilowe problemy techniczne. Pracujemy nad naprawą. Dziękujemy za cierpliwość.” – bez szczegółów technicznych.
• Support: jeśli masz helpdesk – ustaw status „Awaria systemu”, automatyczny autoreply z informacją.

Minuta 10-15: Weryfikacja i stabilizacja

• Po naprawie: przejdź ponownie przez checklistę checkpointów (strona główna, produkt, koszyk, płatność testowa).
• Sprawdź logi przez 5 minut – czy nie ma nowych błędów.
• Zamknij alert w systemie monitoringu, dodaj komentarz z przyczyną główną (Root Cause).
• Zaplanuj post-mortem (bez winnych, z faktami) w ciągu 24-48 h.

Narzędzia – od darmowych do enterprise

Wybór zależy od budżetu, skali i kompetencji zespołu. Poniżej zestawienie bez rekomendacji jednego „najlepszego” – każde ma sens w innym kontekście.

SaaS – szybki start, zero infrastruktury

• UptimeRobot – darmowy plan: 50 monitorów, co 5 min, alerty e-mail. Płatny: 1 min, SMS, webhook, status page.
• Better Uptime – nowoczesny UI, on-call scheduling, status page, integracje (Slack, PagerDuty, Opsgenie). Darmowy plan do 10 monitorów.
• Pingdom (SolarWinds) – bogate RUM (Real User Monitoring), analiza wydajności, droższe.
• StatusCake – proste, tanie, dobre API.
• Freshping (Freshworks) – darmowy do 50 monitorów, 1 min, status page.

Self-hosted – pełna kontrola, własny koszt utrzymania

• Zabbix – potężny, krzywa uczenia się, agent-based i agentless, HA, proxy, autodiscovery.
• Prometheus + Alertmanager + Grafana – standard w Kubernetes / cloud-native, pull model, wielowymiarowe metryki.
• Uptime Kuma – lekki, Docker, ładny UI, status page, webhook, gotowy obraz – idealny na mały VPS.
• Checkmk – wersja Raw (darmowa) i Enterprise, silny w monitoringu infrastruktury i aplikacji.

Hibrydowe podejście (często najbardziej opłacalne)

• Zewnętrzny monitoring dostępności (SaaS) – sprawdza z 5-10 lokalizacji na świecie, certyfikaty, DNS, status page dla klientów.
• Wewnętrzny monitoring infrastruktury (Prometheus/Zabbix/Uptime Kuma w VPC) – metryki systemowe, logi, trace’y, alerty „przed awarią” (dysk 85 %, RAM 90 %, queue lag).

Typowe błędy i jak ich unikać

1. Monitoring tylko z jednej lokalizacji – awaria routingu / DNS w regionie klienta nie zostanie wykryta. Minimum 3 lokalizacje (np. Warszawa, Frankfurt, Nowy Jork).
2. Brak monitoringu „happy path” użytkownika – ping endpointu `/health` zwraca 200, ale koszyk nie działa. Wymagaj monitoringu transakcyjnego (syntetycznego).
3. Alerty tylko na e-mail – w nocy nikt nie sprawdza skrzynki. SMS / voice call / push to telefon to podstawa dla priorytetu Critical.
4. Brak testowania alertów – raz w miesiącu symuluj awarię (zablokuj port 80 na firewallu, wyłącz PHP-FPM) i sprawdź, czy alert dotarł, czy runbook jest aktualny.
5. Ignorowanie „warningów” – TTFB rosnący z 300 ms do 1,2 s w ciągu tygodnia to sygnał problemów z bazą / indeksami / cache. Wykryj trend przed awarią.
6. Brak status page publicznego – klienci i partnerzy pytają „czy to ja, czy wy?”. Prosta strona statusu (Better Uptime, UptimeRobot, Cachet, Statping) redukuje ticketów supportu o 30-50 % podczas awarii.

Integracja z procesami DevOps i SLA

Monitoring to nie narzędzie „dla adminów” – to dane do decyzji biznesowych.

• SLA z hostingiem / cloud – logi z monitoringu zewnętrznego to dowód w sporach o zwrot opłat (service credits). Zachowuj historię min. 12 miesięcy.
• Deployment gates – w CI/CD: nie wpuszczaj deployu na prod, jeśli monitoring wykrywa degradację na stagingu (np. testy wydajnościowe k6 / JMeter + alerty Prometheus).
• Error budget – jeśli celujesz w 99,9 %, masz ~43 minuty miesięcznie na błędy. Monitoring pokazuje, ile „budżetu” zużyłeś – decyduje o tym, czy robisz nową funkcję, czy naprawiasz techniczny dług.
• Post-mortem bez winnych – szablon: co się stało, dlaczego (5x Dlaczego), wpływ, wykrycie, reakcja, naprawa, działania naprawcze (action items) z ownerem i terminem.

Checklista wdrożenia monitoringu (gotowa do skopiowania)

• [ ] Zdefiniuj listę checkpointów (min. 5: home, product, cart, checkout, API, admin, SSL, DNS).
• [ ] Wybierz narzędzie zewnętrzne (SaaS) – skonfiguruj 3+ lokalizacje, interwał 1 min dla krytycznych.
• [ ] Wdroż monitoring wewnętrzny (Prometheus / Zabbix / Uptime Kuma) – metryki systemowe, logi, trace.
• [ ] Skonfiguruj alerty wielopoziomowe z runbookami.
• [ ] Ustal harmonogram deżurstw (on-call) z eskalacją.
• [ ] Włącz publiczną status page.
• [ ] Przeprowadź test „Fire Drill” – symuluj awarię, zmierz MTTA (Mean Time To Acknowledge) i MTTR (Mean Time To Resolve).
• [ ] Zaplanuj przegląd quarterly: usuń martwe checkpointy, zaktualizuj progi, zweryfikuj kontakty.

FAQ

Jak często powinienem testować, czy alerty faktycznie działają?

Minimum raz w miesiącu. Najlepiej zaplanuj „Fire Drill” – celowe wyłączenie usługi (np. `systemctl stop nginx` na stagingu lub zablokowanie portu na firewallu) i zmierz czas od awarii do otrzymania SMS-a / telefonu. Zweryfikuj też, czy runbook jest aktualny.

Czy monitoring zewnętrzny (SaaS) wystarczy, czy muszę mieć własny Prometheus/Zabbix?

SaaS widzi to, co widzi klient (DNS, SSL, routing, frontend). Wewnętrzny widzi to, co dzieje się „pod maską” (RAM, dysk, kolejki, bazę, trace’e). Najbezpieczniej mieć oba – koszt SaaS to często kilkadziesiąt złotych miesięcznie, a własny Uptime Kuma na tanim VPS to koszt kawy w miesiącu.

Co zrobić, jeśli hosting twierdzi, że „u nich wszystko działa”, a monitoring pokazuje awarię?

Zbierz dowody: zrzuty ekranu z dashboardu monitoringu (wielolokalizowe), logi traceroute / mtr z momentu awarii, nagranie HAR z przeglądarki. Otwórz ticket z priorytetem Critical, dołącz dowody, żądaj eskalacji do L2/L3. Jeśli masz SLA – przytocz klauzulę o service credits.

Jak ustalić progi alertów, by nie dostawać spamu w nocy?

Użyj okien ciszy dla planowanych prac, grupowania alertów (korelacja) i wielopoziomowych progów (warning → Slack, critical → SMS/voice). Na start ustaw progi konserwatywne, a po 2-4 tygodniach dostrojuj na podstawie historii (np. jeśli TTFB nigdy nie przekracza 800 ms, ustaw warning na 1 s, critical na 2 s).