← Wszystkie tematy W 9% ogłoszeń · 4 z 47 ogłoszeń frontend React

Monitoring i diagnostyka produkcji

Czarna skrzynka w samolocie

Monitoring i diagnostyka produkcji pojawiają się w 4 z 47 ogłoszeń, często przez nazwy narzędzi: Sentry, Datadog, Grafana. Na rozmowie pytają, jak dowiesz się o błędzie u klienta i jak go znajdziesz.

Przerobione Opanowane 0 z 4 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Ownership of CI/CD, observability, and service reliability.”
Relativity · Lead Frontend Engineer
„Twoja odpowiedzialność nie kończy się na merge'u. Idziesz z feature'em od pomysłu, przez deploy i monitoring, do rozmowy z użytkownikiem, który go używa.”
Publink · Senior Product Engineer (React + TypeScript; .NET)
„Implement robust automated testing strategies with Jest and Cypress, alongside frontend observability tools (OpenTelemetry, Honeycomb, Grafana, or Sentry) to embed deep traceability from initial design to release.”
HelloFresh · Senior Frontend Engineer, Conversions (all genders)

Scena · błąd na produkcji

Czarna skrzynka w samolocie

Gdy coś się psuje u klienta, Ciebie przy tym nie ma. Potrzebujesz czarnej skrzynki, która zapisze, co się stało. Do tego trzy rzeczy: poduszka, żeby jeden zepsuty kawałek nie zawalił całej strony (error boundary), słownik, który zamienia ściśnięty kod na prawdziwe nazwy plików (source maps), i okruszki, czyli ślady kroków użytkownika przed awarią (breadcrumbs). Włącz je i kliknij „Zapłać”.

Ekran klienta

Sklep z lizakamikoszyk: 2

Do zapłaty: 6 zł

Raport w narzędziu do błędów (np. Sentry)

brak zgłoszeń

error boundary source maps breadcrumbs

Najpierw kliknij „Zapłać” bez niczego, potem włącz wszystkie trzy.

Porównajmy

Laboratorium czy prawdziwi użytkownicy?

	Pomiar w labie	Pomiar u użytkowników (RUM)
Kto mierzy?	Ty, na swoim szybkim komputerze.Lighthouse, DevTools, WebPageTest.	Prawdziwe dzieci na prawdziwych telefonach.Biblioteka `web-vitals`, Sentry Performance, Datadog RUM, dane CrUX.
Co pokazuje?	Jedno ustawione nagranie.Powtarzalne warunki, dobre do szukania przyczyn.	Jak jest naprawdę, u wszystkich.Rozkład wyników (p75), podział na urządzenia, kraje, strony.
INP	Nie da się dobrze zmierzyć bez prawdziwych kliknięć.Lab ma TBT jako przybliżenie.	Mierzone przy każdej interakcji.Wysyłasz `onINP` z atrybucją elementu.
Błędy	Widzisz tylko swoje.	Widzisz błędy klientów z kontekstem.Stack ze source maps, breadcrumbs, wersja (release), przeglądarka, użytkownik.
Kiedy używać?	Przed wdrożeniem i do diagnozy.Lighthouse CI w pipeline.	Cały czas po wdrożeniu.Alerty, dashboardy, porównanie wersji.

Poduszka

Error boundary łapie błąd jednego kawałka i pokazuje zamiennik zamiast białej strony.

Słownik

Source maps zamieniają a.js:1:28374 na PaymentForm.tsx linia 42. Wgrywaj je do Sentry, nie publicznie.

Okruszki

Breadcrumbs mówią, co klient robił tuż przed awarią. Bez nich zgadujesz.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Jak zbierasz błędy z produkcji na froncie? (Sentry, source maps, error boundary)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Strona ma czarną skrzynkę, która zapisuje awarię, słownik zamieniający szyfr na prawdziwe nazwy i okruszki pokazujące, co klient robił przed awarią. A poduszka sprawia, że jeden zepsuty kawałek nie zawala całej strony.

Na rozmowę: SDK (Sentry, Datadog) łapie nieobsłużone wyjątki i odrzucone promise. Error boundary w React (lub Sentry.ErrorBoundary) izoluje awarie fragmentów UI, pokazuje fallback i raportuje błąd z componentStack. Source maps wgrywam do Sentry w CI (sentry-cli lub plugin Vite), ale nie serwuję ich publicznie. Każdy build ma release i environment, więc widzę, która wersja psuje. Breadcrumbs (kliknięcia, nawigacja, fetch, console) dają kontekst. Do tego user id bez danych osobowych, sampling, filtrowanie szumu (rozszerzenia przeglądarki) i alerty na nowe lub rosnące błędy.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Jak mierzysz realną wydajność u użytkowników? (RUM, web-vitals)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Zamiast sprawdzać zjeżdżalnię tylko na swoim podwórku, pytasz wszystkie dzieci w mieście, jak szybko im się zjeżdżało.

Na rozmowę: Real User Monitoring: biblioteka web-vitals (onLCP, onINP, onCLS, onTTFB) wysyła wyniki przez navigator.sendBeacon do analityki, Sentry Performance albo Datadog RUM. Analizuję percentyl 75, podział na urządzenia, typ połączenia, kraj i stronę, a build attribution mówi, który element był LCP i która interakcja psuła INP. Dane zewnętrzne: CrUX (PageSpeed Insights, Search Console). Lab (Lighthouse) służy do diagnozy i do Lighthouse CI w pipeline, ale prawdziwy obraz daje RUM.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Co to jest error boundary i czego nie złapie?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: To poduszka pod jednym klockiem: gdy klocek spadnie, poduszka go łapie i kładzie na jego miejscu karteczkę „chwilowo nie działa”, a reszta wieży stoi.

Na rozmowę: Komponent klasowy z getDerivedStateFromError (fallback) i componentDidCatch (raport), w praktyce react-error-boundary z resetKeys i przyciskiem „spróbuj ponownie”. Łapie błędy w renderze, metodach cyklu życia i konstruktorach dzieci. Nie łapie błędów w handlerach zdarzeń, kodzie asynchronicznym (setTimeout, promise poza renderem), SSR ani błędów w samym boundary. Te obsługuję try/catch i ręcznym raportem, albo przerzucam do renderu przez stan. Boundaries stawiam na granicach funkcji: widżet, sekcja strony, trasa.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak powiązać błąd na froncie z konkretnym żądaniem i logami backendu?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Każda paczka dostaje numerek. Gdy paczka się zgubi, po numerku znajdziesz ją i w sklepie, i w magazynie.

Na rozmowę: Distributed tracing: frontend dodaje nagłówki traceparent (W3C Trace Context) lub sentry-trace do żądań API, backend je propaguje, więc w Sentry, Datadog albo przez OpenTelemetry widzę jeden ślad od kliknięcia do zapytania w bazie. Dodatkowo correlation id w nagłówku odpowiedzi, który pokazuję w komunikacie błędu („kod zgłoszenia: …”), żeby support mógł go odszukać w logach. Trzeba skonfigurować tracePropagationTargets i CORS dla tych nagłówków.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Klienci zgłaszają błędy, o których nic nie wiecie

Bankowa aplikacja frontendowa nie ma monitoringu błędów. O problemach zespół dowiaduje się z infolinii, kilka dni później. Masz wdrożyć obserwowalność frontendu, ale dział bezpieczeństwa boi się wysyłania danych osobowych do zewnętrznego dostawcy.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy wiesz, co zbierać na froncie i po co
Czy umiesz pogodzić diagnostykę z ochroną danych
Czy planujesz wdrożenie etapami z mierzalnym efektem

Odpowiedź seniora

Zbieram trzy rzeczy: błędy JS z kontekstem (Sentry lub odpowiednik), wydajność u prawdziwych użytkowników (web-vitals, RUM) i nieudane żądania API z identyfikatorem korelacji przekazywanym w nagłówku, żeby połączyć błąd na froncie z logiem backendu.

Ochrona danych: beforeSend i beforeBreadcrumb usuwają z URL-i, nagłówków i treści błędów numery kont, PESEL i e-maile (lista wzorców plus allowlista pól). Session replay, jeśli w ogóle, tylko z maskowaniem wszystkich pól i tekstów. Użytkownika identyfikuję losowym id, nie danymi. Do tego umowa powierzenia danych, region danych w UE albo wersja self-hosted, jeśli wymaga tego regulacja. Source mapy wgrywam do narzędzia w CI i nie publikuję ich na CDN.

Etapy: najpierw błędy na 10% sesji, potem 100% z próbkowaniem transakcji, alerty na nowe typy błędów po wdrożeniu. Efekt mierzę czasem od wystąpienia błędu do wykrycia, wcześniej liczonym w dniach.

Typowe wpadki

Włączenie session replay bez maskowania
Wysyłanie wszystkiego bez próbkowania i rachunek za limit zdarzeń
Publiczne source mapy

Dopytają o

Jak odfiltrujesz szum z rozszerzeń przeglądarki?
Kto reaguje na alerty i w jakim czasie?
Jak połączysz błąd z konkretnym wdrożeniem?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Błąd, który występuje tylko u 0,5% użytkowników

Od dwóch tygodni około 0,5% sesji kończy się błędem „Cannot read properties of undefined” przy przejściu do koszyka. Lokalnie i na stagingu nikt nie umie go odtworzyć. Konwersja spadła o 0,3 punktu procentowego.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy umiesz systematycznie zawężać przyczynę na danych
Czy znasz narzędzia do odtworzenia kontekstu
Czy myślisz o szybkim ograniczeniu szkód

Odpowiedź seniora

Zawężam na danych z narzędzia do błędów: rozkład po przeglądarce i wersji, systemie, kraju, wersji aplikacji, ścieżce wejścia, flagach i wariantach eksperymentów. Sprawdzam, czy błąd zaczął się od konkretnego wdrożenia (release tracking) i co poprzedzało go w breadcrumbach. Pomagają tagi z feature flagami i id wariantu A/B.

Typowe przyczyny takich rzadkich błędów: stara przeglądarka bez jakiegoś API, rozszerzenie modyfikujące DOM, wyścig przy wolnej sieci (dane przychodzą po odmontowaniu), nietypowe dane z API dla części kont, stary chunk po deployu, Safari w trybie prywatnym blokujące localStorage. Odtwarzam na podstawie danych: throttling sieci, ta sama przeglądarka w BrowserStack, konto z podobnymi danymi.

Ograniczenie szkód od razu: obsługa brakującej wartości z czytelnym błędem i zapis kontekstu, ewentualnie wyłączenie podejrzanej funkcji flagą. Naprawę zabezpieczam testem odtwarzającym przypadek i sprawdzam spadek błędu po wdrożeniu.

Typowe wpadki

Uznanie 0,5% za nieistotne, mimo wpływu na przychody
Optional chaining wszędzie bez zrozumienia przyczyny
Debugowanie bez wersji aplikacji i source map

Dopytają o

Jak dodasz więcej kontekstu do błędu, nie zbierając danych osobowych?
Jak potwierdzisz, że to naprawa, a nie przypadek?
Kiedy eskalujesz problem do zespołu backendu?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

SLO i alerty dla frontendu, żeby nie budzić ludzi bez powodu

Po wdrożeniu Sentry i RUM kanał alertów dostaje 200 powiadomień dziennie i nikt ich nie czyta. Jednocześnie ostatnia poważna awaria płatności została zauważona dopiero po godzinie. Masz uporządkować alerty.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz pojęcia SLI, SLO i budżet błędów
Czy alertujesz na objawy u użytkownika, nie na pojedyncze błędy
Czy myślisz o procesie dyżurów

Odpowiedź seniora

Definiuję kilka SLI odczuwalnych przez użytkownika: odsetek udanych kluczowych ścieżek (logowanie, dodanie do koszyka, płatność) mierzony zdarzeniami z frontendu, odsetek sesji bez błędu krytycznego, p75 LCP i INP. Dla każdego SLO, np. 99,5% udanych płatności w oknie 28 dni.

Alert budzący człowieka tylko na szybkie spalanie budżetu błędów (burn rate) w kluczowych ścieżkach. Reszta trafia jako zgłoszenia do przeglądu w godzinach pracy: nowe typy błędów po wdrożeniu, regresje wydajności, wzrost błędów w konkretnej przeglądarce. Szum ograniczam przez grupowanie, ignorowanie rozszerzeń i znanych błędów zewnętrznych skryptów, próbkowanie.

Każdy alert ma właściciela i runbook. Raz w miesiącu przegląd: które alerty nic nie dały, a które awarie przyszły bez alertu.

Typowe wpadki

Alert na każdy nowy błąd JS
SLO wymyślone bez danych historycznych
Brak właściciela i runbooka przy alercie

Dopytają o

Jak zmierzysz sukces płatności, skoro część dzieje się u operatora?
Co robisz, gdy budżet błędów jest wyczerpany?
Jak frontend ma współpracować z dyżurem backendu?

Zapytaj Claude Rozwiń case Zagraj interviewera