Come rilevare i problemi prima che gli utenti si lamentino?

Question

Accepted Answer

L'obiettivo è catturare i problemi **prima della pagina** — trovare il degrado mentre c'è ancora margine di assorbimento. Significa monitorare **indicatori anticipati**, definire **SLO con error budget**, e sondare attivamente il sistema piuttosto che aspettare che fallisca.

## SLO e error budget

Un **SLO** trasforma l'affidabilità in un numero (ad esempio il 99,9% delle richieste ha successo). Lo 0,1% rimanente è il tuo **error budget**. Monitorare il **burn rate** ti consente di avvisare quando stai spendendo il budget troppo velocemente — molto prima di aver effettivamente violato l'SLO e gli utenti se ne accorgano.

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

## Sondaggio attivo, non solo metriche passive

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

Il monitoraggio sintetico è potente perché non aspetta un utente — esercita continuamente il sistema, quindi un checkout rotto viene trovato alle 3 del mattino, non quando la folla mattutina si lamenta.

## Indicatori anticipati e tendenze

I primi segnali sono nelle risorse, non ancora negli errori visibili all'utente. Avvisa sulla **tendenza**, non solo su una linea statica.

```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 lentamente crescente o una coda in crescita è un colpo di avvertimento: agendo sulla deriva, previeni l'interruzione verso cui stava dirigendosi.

## Perché è importante

Il monitoraggio reattivo significa che gli utenti sono il tuo sistema di avviso — nel momento in cui si lamentano, l'incidente è già live e il tuo error budget è esaurito. Il rilevamento proattivo (SLO burn rate, synthetics, health check, RUM, indicatori anticipati, alert di tendenza/anomalia) ti compra tempo: ripari una coda satura o una latenza crescente prima che diventi una chiamata alle 2 del mattino e un cliente arrabbiato. Quel tempo è la differenza tra una correzione tranquilla e un'interruzione del servizio.