Wstęp
Monitoring aplikacji to fundament utrzymania jakości usługi. Brzmi banalnie, ale z mojego doświadczenia wynika, że w 8 na 10 firm monitoring jest… no cóż, lepiej go nie mieć. Albo jest źle skonfigurowany, albo daje fałszywe poczucie bezpieczeństwa, albo po prostu nikt na niego nie patrzy. A to kosztuje. Klientów, pieniądze i czas. W tym artykule pokażę trzy najczęstsze błędy, które regularnie widzę u klientów – i które sam popełniałem na początku swojej drogi.
Błąd #1: Monitorowanie tylko „zielonych” metryk
Większość zespołów koncentruje się na podstawowych wskaźnikach: CPU, pamięć, dostępność. Patrzą na dashboard i widzą zielone wskaźniki – wszystko działa. Tymczasem użytkownicy zgłaszają, że strona ładuje się wolno, a koszyk znika przy finalizacji zamówienia.
Dlaczego tak się dzieje? Ponieważ metryki infrastruktury nie mówią nic o doświadczeniu użytkownika. Możesz mieć 99,9% dostępności serwera, ale jeśli aplikacja ma memory leak, to po kilku godzinach działania zaczyna zwalniać. Albo jeśli baza danych ma wysoki czas odpowiedzi na konkretne zapytanie, to nie zobaczysz tego na ogólnym wykresie.
Przykład z życia klienta: sklep e-commerce z miesięcznym obrotem 2 mln zł. Dashboard pokazywał zielone światło, ale wskaźnik porzuconych koszyków rósł. Okazało się, że endpoint odpowiedzialny za walidację kodu promocyjnego miał opóźnienie 8 sekund przy obciążeniu. Monitoring nie rejestrował czasu odpowiedzi poszczególnych endpointów – tylko ogólną dostępność API. Wystarczyło dodać alert dla percentyli (np. P95 powyżej 2s), żeby problem wyłapać w ciągu godziny od wdrożenia.
Rozwiązanie: Monitoruj nie tylko stan, ale i wydajność aplikacji z perspektywy użytkownika. Używaj narzędzi do syntetycznego monitorowania (np. Checkly, Playwright) i rzeczywistego monitorowania użytkowników (RUM). Wprowadź alerty dla percentyli czasu odpowiedzi, a nie tylko średniej – średnia może być piękna, ale 10% najwolniejszych zapytań może rozwścieczyć klientów.
Błąd #2: Za dużo alertów, czyli „alert fatigue”
Znasz to? Nagle zaczyna dzwonić PagerDuty, sypią się maile, a na Slacku pojawia się 50 powiadomień na minutę. Po pięciu minutach wyłączasz dźwięk i sprawdzasz raz na godzinę. To klasyczny objaw „zmęczenia alertami”.
W startupie, z którym współpracowałem, zespół DevOps dostał 200 alertów dziennie. Po tygodniu nikt już na nie nie reagował. A potem przyszedł alert, który naprawdę oznaczał awarię – i minęły 4 godziny, zanim ktoś go zauważył. Koszt: utrata danych użytkowników i spadek zaufania.
Skąd bierze się nadmiar alertów? Z lenistwa i braku priorytetyzacji. Zespoły ustawiają alert na każde odstępstwo od normy, zamiast zastanowić się, co naprawdę wymaga interwencji. Albo kopiują konfigurację z tutoriala, nie dostosowując jej do swojego systemu.
Rozwiązanie: Wprowadź politykę alertów: każdy alert musi mieć zdefiniowany wpływ na użytkownika lub biznes. Jeśli alert nie mówi „tracimy pieniądze” lub „użytkownicy nie mogą korzystać”, to nie alert, a log. Zastosuj koncepcję „alarm fatigue” i regularnie przeglądaj alerty, wyłączając te niepotrzebne. Używaj narzędzi do agregacji (np. grouping w PagerDuty), żeby podobne alerty scalać w jeden.
Błąd #3: Brak monitorowania „dark metrics” – rzeczy, których nie widzisz
Większość firm monitoruje to, co łatwo zmierzyć: czas odpowiedzi, błędy 500, użycie CPU. Ale istnieją metryki, które są niewidoczne, a mają ogromny wpływ na biznes. Nazywam je „dark metrics”. To na przykład:
- Liczba użytkowników, którzy opuścili stronę, bo się nie załadowała (ale nie było błędu – tylko timeout po stronie klienta)
- Liczba nieudanych prób płatności, które nie zostały zalogowane jako błąd (bo bramka zwróciła odpowiedź, ale z komunikatem „odrzucono”)
- Czas spędzony na ładowaniu skryptów zewnętrznych (które blokują rendering)
Klient – agencja nieruchomości z portalem ogłoszeniowym. Ich zespół nie rozumiał, dlaczego wskaźnik odrzuceń rośnie. Monitorowali błędy backendu – wszystko było czyste. Okazało się, że winowajcą był zewnętrzny widget mapy, który ładował się przez 5 sekund, blokując interakcję użytkownika. Ale ponieważ nie było błędu (widget w końcu się załadował), monitoring nie wychwycił problemu. Dopiero analiza beaconów z przeglądarki ujawniła, że 30% użytkowników zamykało stronę przed załadowaniem mapy.
Rozwiązanie: Sięgnij po narzędzia do monitorowania rzeczywistych użytkowników (RUM), które zbierają dane z przeglądarek – czas do interakcji (TTI), First Contentful Paint (FCP), Largest Contentful Paint (LCP). Wprowadź monitoring frontendu, który wychwytuje błędy JavaScript i długie zadania. Rozszerz monitoring o zdarzenia biznesowe: porzucone koszyki, nieudane logowania, błędy walidacji formularzy. To daje pełniejszy obraz.
Podsumowanie
Monitoring to nie tylko zielone wskaźniki na dashboardzie. To narzędzie do zrozumienia, co naprawdę dzieje się z Twoją aplikacją i jak wpływają na nią użytkownicy. Trzy opisane błędy – skupienie na infrastrukturze, nadmiar alertów i ignorowanie dark metrics – są powszechne, ale łatwe do naprawienia. Zacznij od jednej zmiany: dodaj monitorowanie czasu odpowiedzi endpointów z perspektywy użytkownika. Zobaczysz różnicę.
A jeśli potrzebujesz pomocy w diagnozie swojego monitoringu – w JurskiTech robimy audyty observability. Często wystarczy tydzień pracy, żeby odkryć, co naprawdę wpływa na Twoją sprzedaż.
