Obiectivul este să știi că sistemul tău nu este sănătos înainte ca utilizatorii tăi să ți-o spună. O bună observabilitate te lasă să răspunzi la întrebări pe care nu le-ai anticipat, nu doar să verifici un set fix de panouri de control. Ca tech lead, configurezi asta înainte de incident, nu în timp ce se întâmplă.
Pagină pe ceea ce resimte utilizatorul, nu pe fluctuații interne. Ancorează alertele la SLO-uri: rata erorilor, latență (p95/p99) și disponibilitate. Un vârf în utilizarea CPU nu este un incident; checkout care eșuează pentru 2% din utilizatori este.
| Alertează pe | Nu pagina pe |
|---|---|
| Rata erorilor care încalcă SLO | Vârf izolat de CPU |
| Latență p99 peste buget | O cerere lentă |
| Verificări de sănătate eșuate | Disc la 60% |
Fiecare alertă ar trebui să fie urgentă, reală și cu o acțiune concretă — descrie ce nu merge bine și indică următorul pas. Alertele care se declanșează constant antrenează echipa să le ignore; oboseala de alertare este cum se ratează incidentele reale. Adaugă verificări de sănătate și panouri de control care arată semnalele aurii dintr-o privire.
Echipele care observă doar după un incident zboară orbi: află despre defecțiuni de la clienți furioși și depanează prin ghicire. Investind în observabilitate de la început, transformi misterele de la 3 dimineața în diagnostice de 5 minute, micșorezi timpurile de nefuncționare și liberezi echipa să livreze în loc să apară focuri.