लक्ष्य है यह जानना कि आपका system अस्वस्थ है इससे पहले कि आपके users आपको बताएं। अच्छी observability आपको उन सवालों का जवाब देने देती है जिनका आपने अनुमान नहीं लगाया था, न कि केवल एक निश्चित set के dashboards जांचना। एक tech lead के रूप में, आप इसे incident से पहले सेट करते हैं, उसके दौरान नहीं।
user जो महसूस करता है उस पर page करें, internal jitter पर नहीं। alerts को SLOs से जोड़ें: error rate, latency (p95/p99), और availability। CPU में एक spike incident नहीं है; 2% users के लिए checkout का fail होना है।
| इस पर alert करें | इस पर page न करें |
|---|---|
| SLO तोड़ने वाली error rate | एक अकेला CPU spike |
| budget से अधिक p99 latency | एक धीमा request |
| Failed health checks | Disk 60% पर |
हर alert urgent, real, और actionable होना चाहिए — यह बताता है कि क्या गलत है और अगले कदम की ओर इशारा करता है। जो alerts लगातार fire होते हैं वे टीम को उन्हें नज़रअंदाज़ करना सिखाते हैं; alert fatigue ही वह तरीका है जिससे वास्तविक incidents छूट जाते हैं। health checks और dashboards जोड़ें जो golden signals को एक नज़र में दिखाएं।
जो टीमें केवल incident के बाद observe करती हैं वे अंधी उड़ान भर रही हैं: वे गुस्साए ग्राहकों से outages के बारे में सीखती हैं और अनुमान से debug करती हैं। पहले से observability में निवेश करना 3 बजे रात के रहस्यों को 5-मिनट के diagnoses में बदल देता है, downtime को घटाता है, और टीम को firefight करने के बजाय ship करने के लिए मुक्त करता है।