, অবকাঠামো থেকে নয়। সবচেয়ে নির্ভরযোগ্য হোস্ট ফ্লিট বেকার হয়ে যায় যদি অনুরোধগুলি ব্যর্থ হয়, তাই ব্যবহারকারী-মুখী দিয়ে শুরু করুন — , , — তারপর চার সোনালী সংকেত যোগ করুন, তারপর অবকাঠামো মেট্রিক্স শেষে।
, অবকাঠামো থেকে নয়। সবচেয়ে নির্ভরযোগ্য হোস্ট ফ্লিট বেকার হয়ে যায় যদি অনুরোধগুলি ব্যর্থ হয়, তাই ব্যবহারকারী-মুখী দিয়ে শুরু করুন — , , — তারপর চার সোনালী সংকেত যোগ করুন, তারপর অবকাঠামো মেট্রিক্স শেষে।
1. USER-FACING SLIs → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS → latency, traffic, errors, saturation per service
3. INFRA METRICS → CPU, memory, disk, network (causes, not symptoms)
যদি আপনি শুধুমাত্র CPU এবং ডিস্ক দেখেন (নীচ থেকে উপরে), আপনি সম্পূর্ণরূপে সবুজ থাকতে পারেন যখন ব্যবহারকারীরা 500s পান। প্রথমে SLIs দেখা (উপরে থেকে নীচে) মানে আপনি সতর্ক করেন ব্যবহারকারীরা যা আসলে অনুভব করে, তারপর সোনালী সংকেত এবং অবকাঠামোতে ড্রিল করুন কারণ খুঁজতে।
INSTRUMENT app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
↓
COLLECT a TSDB scrapes/ingests them (Prometheus, Datadog agent)
↓
DASHBOARD visualize SLIs + golden signals (Grafana) for humans to read
↓
ALERT fire on SLO violations / burn rate, routed to on-call
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
প্রতিটি SLI-তে একটি SLO সংজ্ঞায়িত করুন (যেমন 99.9% উপলব্ধতা, p99 < 300ms), সেগুলি ড্যাশবোর্ড করুন, এবং সতর্ক করুন যখন SLO ঝুঁকিতে থাকে — প্রতিটি দোলার উপর নয়।
নীচ থেকে উপরে নির্মিত নিরীক্ষণ আপনাকে বলে যে একটি ডিস্ক 80% পূর্ণ কিন্তু গ্রাহকরা চেকআউট করতে পারে না। ব্যবহারকারী-মুখী SLIs থেকে শুরু করা প্রতিটি ড্যাশবোর্ড এবং সতর্কতাকে আসল ব্যবহারকারীর প্রভাবের সাথে সংযুক্ত করে, শব্দ কম রাখে, এবং একটি স্পষ্ট ড্রিল-ডাউন পথ প্রদান করে (উপসর্গ → সোনালী সংকেত → অবকাঠামো কারণ) যখন কিছু ভেঙে যায়।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন