L'obiettivo è sapere che il tuo sistema non è in buono stato prima che te lo comunichino gli utenti. Una buona observability ti permette di rispondere a domande che non hai anticipato, non solo controllare una serie fissa di dashboard. Come tech lead, lo configuri prima dell'incidente, non durante.
Pagina su ciò che l'utente sente, non su jitter interno. Ancora gli alert agli SLO: error rate, latency (p95/p99) e disponibilità. Un picco di CPU non è un incidente; il checkout non funziona per il 2% degli utenti lo è.
| Allerta su | Non pagare su |
|---|---|
| Error rate che viola l'SLO | Singolo picco di CPU |
| p99 latency oltre budget | Una singola richiesta lenta |
| Failed health checks | Disco al 60% |
Ogni alert dovrebbe essere urgente, reale e actionable — nomina cosa è sbagliato e indica il passo successivo. Gli alert che scattano costantemente addestrano il team a ignorarli; l'alert fatigue è il modo in cui gli incidenti reali vengono persi. Aggiungi health checks e dashboard che mostrano i golden signals a colpo d'occhio.
I team che osservano solo dopo un incidente navigano al buio: vengono a conoscenza dei disservizi dai clienti arrabbiati e eseguono il debug con il metodo per tentativi. Investire in observability fin dall'inizio trasforma i misteri delle 3 del mattino in diagnosi di 5 minuti, riduce il downtime e libera il team per fare shipping invece di spegnere incendi.