Jak wykrywać problemy zanim użytkownicy się skarżą?

Question

Accepted Answer

Celem jest wyłapanie problemów **zanim strona ulegnie awarii** — znalezienie degradacji, gdy wciąż jest zapas do jej pochłonięcia. To oznacza obserwowanie **wiodących wskaźników**, definiowanie **SLO z budżetami błędów** oraz aktywne sondowanie systemu zamiast czekania aż się wysypie.

## SLO i budżety błędów

**SLO** zamienia niezawodność w liczbę (np. 99,9% żądań się powiedzie). Pozostałe 0,1% to Twój **budżet błędów**. Śledzenie **tempa spalania** pozwala Alert gdy wydajesz budżet zbyt szybko — na długo zanim rzeczywiście złamiesz SLO i użytkownicy się zorientują.

```text
SLO 99.9% → 0.1% error budget/month (~43 min of downtime)
burn rate rising fast → you'll exhaust it in 2 days → alert NOW, while it's fixable
```

## Aktywne sondowanie, nie tylko bierne metryki

```text
SYNTHETIC MONITORING  scripted checks hit critical paths on a schedule
                      (login, checkout) → fails even at 3am with zero real traffic
HEALTH CHECKS         /healthz endpoints + dependency checks → load balancer
                      pulls bad instances before users hit them
RUM (real-user mon.)  measure latency/errors from actual browsers/devices →
                      catches issues only some users/regions see
```

Syntetyczne monitorowanie jest potężne, ponieważ nie czeka na użytkownika — ciągle ćwiczy system, więc zepsuta kasa pojawia się o 3 nad ranem, a nie gdy rano przybywa zwalidrowania się skarżą.

## Wiodące wskaźniki i trendy

Najwcześniejsze oznaki są w zasobach, a nie jeszcze w błędach widocznych dla użytkownika. Alertuj na **trend**, nie tylko na statyczną linię.

```text
LEADING INDICATORS   saturation (CPU/mem climbing), queue depth growing,
                     connection-pool nearing limit, latency CREEPING up
ANOMALY DETECTION    flag deviation from the normal baseline / seasonality
TREND ALERTS         "disk will fill in 4h at this rate" → act before it's full
```

Powoli rosnący p99 lub rosnąca kolejka to sygnał ostrzegawczy: działając na ten powolny wzrost, zapobiegasz awarii, do której ten wzrost zmierzał.

## Dlaczego to ważne

Monitorowanie reaktywne oznacza, że użytkownicy są Twoim systemem alertowania — zanim się skarżą, incydent jest już na żywo, a Twój budżet błędów jest wydany. Proaktywne wykrywanie (tempo spalania SLO, syntetyka, health checki, RUM, wiodące wskaźniki, alerty na trendy/anomalie) kupuje Ci czas: naprawiasz nasycającą się kolejkę lub powoli rosnące opóźnienie zanim stanie się stroną o 2 w nocy i wściekłym klientem. Ten czas to różnica między cichą naprawą a awarią.