Målet är att veta att ditt system är dåligt innan dina användare berättar det för dig. God observerbarhet låter dig besvara frågor du inte förväntade dig, inte bara kontrollera en fast uppsättning instrumentpaneler. Som teknikledare ställer du in detta före incidenten, inte under den.
Sida på vad användaren känner, inte på internt jitter. Förankra aviseringar till SLOs: felfrekvens, latens (p95/p99) och tillgänglighet. En CPU-topp är inte en incident; checkout som misslyckas för 2% av användarna är.
| Avisera på | Sidaa inte på |
|---|---|
| Felfrekvens överskrider SLO | Enskild CPU-topp |
| p99 latens över budget | En långsam begäran |
| Misslyckade hälsokontroller | Disk på 60% |
Varje avisering bör vara brådskande, verklig och användbbar — den namnger vad som är fel och pekar på nästa steg. Aviseringar som brandras konstant tränar teamet att ignorera dem; aviseringströthet är hur riktiga incidenter missas. Lägg till hälsokontroller och instrumentpaneler som visar de gyllene signalerna snabbt.
Team som bara observerar efter en incident flyger blinds: de lär sig om driftstopp från arga kunder och felsöker med gissningar. Att investera i observerbarhet från början förvandlar 3 a.m. mysterier till 5-minuters diagnoser, minskar stilleståndstid och frigör teamet att leverera istället för att släcka bränder.