Cum detectezi problemele înainte ca utilizatorii să se plângă?

Question

Accepted Answer

Scopul este să prinzi problemele **înainte de cădere** — să găsești degradarea în timp ce mai este marjă disponibilă să o absorbi. Asta înseamnă să monitorizezi **indicatori anteriori**, să definești **SLO-uri cu bugete de eroare** și să sondezi activ sistemul în loc să aștepți să se defecteze.

## SLO-uri și bugete de eroare

Un **SLO** transformă fiabilitatea într-un număr (de ex. 99,9% din cererile reușesc). Restul de 0,1% este **bugetul tău de eroare**. Urmărirea **vitezei de consum** te permite să emiți alerte când consumi bugetul prea repede — cu mult timp înainte să încalci efectiv SLO-ul și utilizatorii să observe.

```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
```

## Sondaj activ, nu doar metrici pasive

```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
```

Monitorizarea sintetică este puternică pentru că nu așteaptă un utilizator — exercită continuu sistemul, deci o cumpărare defectă este găsită la 3 dimineața, nu când mulțimea din dimineață se plânge.

## Indicatori anteriori și tendințe

Semnele cele mai timpurii sunt în resurse, nu încă în erori care afectează utilizatorii. Emite alerte pe baza **tendinței**, nu doar o linie statică.

```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
```

Un p99 crescut lent sau o coadă în creștere este o avertizare: prin acționarea asupra acestei creșteri, previi depășirea care ar fi venit în urma creșterii.

## De ce conteaza

Monitorizarea reactivă înseamnă că utilizatorii sunt sistemul tău de alertare — în momentul în care se plâng, incidentul este deja în viu și bugetul tău de eroare este cheltuit. Detecția proactivă (viteză de consum SLO, sintetice, verificări de stare, RUM, indicatori anteriori, alerte de tendință/anomalie) îți oferă timp de anticipare: repari o coadă saturată sau o latență în creștere înainte ca aceasta să devină o pagină la 2 dimineața și un client supărat. Acel timp de anticipare este diferența dintre o reparație liniștit și o depășire.