Wstęp
Prowadzisz SaaS. Wszystko działa, użytkownicy logują się, płacą. Aż do dnia, gdy dostajesz e-mail: „Wasza aplikacja jest beznadziejnie wolna, wypowiadam subskrypcję”. I jesteś zaskoczony. Dlaczego? Bo patrzyłeś na dostępność (uptime 99,9%) i myślałeś, że wszystko jest OK. To typowy błąd – mylenie monitoring infrastruktury z obserwowalnością całego systemu. Observability to nie tylko wykresy CPU – to zdolność do zrozumienia, co dzieje się wewnątrz aplikacji z perspektywy użytkownika.
Brak observability jest jak latanie po omacku. W małych firmach często brakuje narzędzi, zespołu i wiedzy, by wdrożyć prawdziwe monitorowanie. Znam to z własnego doświadczenia – w pewnym projekcie klienci skarżyli się na błędy, ale logi nic nie mówiły. Okazało się, że brakowało kontekstu: nie wiedzieliśmy, który endpoint generuje problem i dla jakiego użytkownika. Dopiero po dodaniu śledzenia rozproszonego (distributed tracing) znaleźliśmy przyczynę – zoptymalizowaliśmy zapytanie i churn spadł o 15%.
W tym artykule pokażę trzy ciche sygnały, że Twój SaaS traci klientów przez brak observability. Jeśli któreś z nich rozpoznajesz – czas działać.
1. Skargi użytkowników są ogólnikowe i nie powtarzalne
Gdy brakuje observability, każdy błąd jest wyspą. Użytkownik pisze: „nie działa”, a Ty nie masz jak odtworzyć jego ścieżki. Nie wiesz, na którym kroku nawaliło, czy to błąd frontendu, backendu, czy problem z siecią. Skutek? Łatasz na ślepo, wdrażasz łatki, które mogą pogorszyć sprawę.
Przykład z życia: w jednym z klienckich SaaS (platforma do zarządzania projektami) użytkownicy zgłaszali, że „czasami tabela się nie ładuje”. Najgorsze – te skargi przychodziły losowo, raz na tydzień. Zespół spędził dwa tygodnie na próbach reprodukcji. Gdy w końcu dodaliśmy śledzenie rozproszone (wystarczyło użyć darmowego OpenTelemetry z Jaegerem), okazało się, że problem pojawia się tylko dla użytkowników z wieloma projektami – zapytanie SQL robiło full scan na dużej tabeli. Fix: dodanie indeksu. Czas ładowania spadł z 12 sekund do 0,3 sekundy. Churn spadł, a NPS wzrósł o 10 punktów.
Sygnał ostrzegawczy: jeśli większość zgłoszeń to „coś nie działa” bez konkretów, brakuje Ci danych do diagnozy. Musisz widzieć pełną ścieżkę żądania – od kliknięcia po odpowiedź serwera.
2. Nie mierzysz czasu odpowiedzi z perspektywy użytkownika
Większość firm patrzy na średnie obciążenie serwera. Ale średnie to kłamstwo. Twój serwer może mieć 10% użycia CPU, a jednocześnie jeden endpoint dla konkretnego użytkownika działa 30 sekund. Dlaczego? Bo może być przeciążony w określonych godzinach lub dla określonych danych.
Observability to rozkład percentyli: P50, P95, P99. Jeśli nie wiesz, że P95 czasu odpowiedzi wynosi 5 sekund, to nie wiesz, że 5% użytkowników czeka dłużej. A to może być Twój klient premium.
Przykład: klient e-commerce (mały sklep) narzekał, że kasa jest powolna. Patrzyli na średnią – 1,2 sekundy. Brzmi OK. Ale gdy spojrzeli na P99, okazało się, że 1% użytkowników czeka 8 sekund. To byli użytkownicy z koszykiem > 50 produktów. Poprawili zapytanie – P99 spadło do 2 sekund. Konwersja wzrosła o 3%.
Sygnał ostrzegawczy: jeśli nie wiesz, jaki jest P95 czasu odpowiedzi dla kluczowych ścieżek (logowanie, checkout, wyszukiwarka), tracisz klientów. Zacznij mierzyć od dzisiaj – prosty APM (np. Sentry, New Relic) wystarczy.
3. Logi nie mówią Ci, który użytkownik i jakie działanie wywołało błąd
Często logi są bez kontekstu. Widzisz „Error 500” bez ID użytkownika, bez parametrów zapytania. Albo logi są zalane milionami wpisów, a Ty nie umiesz odfiltrować tych istotnych. W efekcie każdy błąd wymaga ręcznego dochodzenia, a niektórzy użytkownicy po prostu odchodzą.
Rozwiązanie: strukturyzowane logowanie (JSON) z unikalnym identyfikatorem sesji użytkownika. Wtedy, gdy użytkownik zgłosi problem, możesz po prostu znaleźć jego log po ID i zobaczyć cały flow.
Przykład: platforma SaaS do fakturowania. Użytkownicy zgłaszali, że „czasami faktura się nie generuje”. Zespół szukał w logach – setki błędów dotyczących jednego klienta. Dzięki strukturyzowanym logom szybko powiązali błąd z konkretnym użytkownikiem, który miał niestandardowy podatek. Fix: obsługa wyjątku. Problem znikał.
Sygnał ostrzegawczy: jeśli logi nie zawierają correlation ID ani danych o użytkowniku, nie masz observability. Wprowadź strukturyzowane logowanie – to zmienia wszystko.
Podsumowanie
Observability to nie fanaberia – to narzędzie do zatrzymywania klientów i oszczędzania pieniędzy. Gdy widzisz ogólnikowe skargi, nie znasz percentyli lub logi są bez kontekstu, Twój SaaS krwawi. W JurskiTech.pl wdrażamy observability w małych i średnich firmach – od prostego APM po pełne śledzenie rozproszone. Nie czekaj, aż stracisz klienta – zacznij monitorować z głową.
