Alerting ও On-call
- ●ভালো alert হলো actionable, urgent ও symptom-ভিত্তিক — গ্রাহকের ব্যথা ধরে, internal cause নয়।
- ●অতিরিক্ত noisy alert engineer-দের মধ্যে alert fatigue তৈরি করে, ফলে আসল সমস্যা মিস হয়।
- ●On-call rotation, escalation policy আর runbook মিলিয়ে রাতের জরুরি অবস্থা সামলানো হয়; PagerDuty paging করে।
সমস্যাটা কী?
রাত ৩টা। তোমার ফোন বেজে উঠল — "ALERT: disk usage 71% on server-7"। তুমি ধড়ফড় করে উঠে দেখলে কিছুই ভাঙেনি, ৭১% ঠিকই আছে। আবার ঘুমালে। ৩:৪৫-এ আবার বাজল একই alert। এভাবে এক সপ্তাহ চললে তুমি একটা কাজ করবে — alert-এ গুরুত্ব দেওয়া বন্ধ করে দেবে। আর ঠিক সেই রাতেই আসল outage হবে, যেটা তুমি miss করবে।
এটাই alerting-এর মূল চ্যালেঞ্জ। alert না থাকলে তুমি অন্ধ, আবার অতিরিক্ত alert থাকলে তুমি অসাড়। লক্ষ্য হলো ঠিক সেই জিনিসেই page পাওয়া যা সত্যিই মানুষের তাৎক্ষণিক হস্তক্ষেপ দাবি করে।
মূল ধারণা
ভালো alert তিনটা শর্ত মানে: Actionable (কিছু করার আছে), Urgent (এখনই করতে হবে), আর Real (সত্যিকার সমস্যা, noise নয়)। যে alert এর কোনো একটাও মানে না, সেটা page নয় — বড়জোর একটা dashboard বা ticket।
দুই ধরনের alerting দর্শন আছে:
- Cause-based alerting — internal কারণ ধরে ("CPU ৯০%", "queue লম্বা")। সমস্যা হলো — এগুলো অনেক সময় গ্রাহকের কোনো ক্ষতি না করেই ঘটে।
- Symptom-based Alerting — গ্রাহকের ব্যথা ধরে ("পেজ load হচ্ছে না", "checkout fail")। এটাই উত্তম, কারণ এটা সরাসরি user impact-এ alert করে।
নিয়ম: symptom-এ page করো, cause-এ investigate করো।
কীভাবে কাজ করে
ভালো vs খারাপ alert
| খারাপ (noisy) alert | ভালো (actionable) alert |
|---|---|
| "CPU 70%" | "API error rate ৫ মিনিট ধরে ৫%-এর বেশি" |
| "একটা pod restart হলো" | "৩টার মধ্যে ২টা pod down" |
| "Disk 71%" | "Disk ৪ ঘণ্টায় full হবে এই হারে" |
| প্রতিদিন ৫০টা আসে | দিনে ১-২টা, প্রতিটাই গুরুত্বপূর্ণ |
ভালো alert-এর সাথে threshold + duration থাকে (যেমন "৫ মিনিট ধরে") যাতে সাময়িক spike-এ page না বাজে।
Severity level
সব alert সমান নয়। সাধারণত স্তরবিন্যাস করা হয়:
| Level | মানে | response |
|---|---|---|
| P1 / Critical | গ্রাহক blocked, revenue হারাচ্ছে | এখনই page, রাত হলেও |
| P2 / High | আংশিক প্রভাব | কয়েক ঘণ্টার মধ্যে |
| P3 / Low | প্রভাব নেই, কিন্তু খেয়াল রাখা দরকার | পরদিন ticket |
শুধু P1/P2-তে page বাজানো উচিত। P3 dashboard বা daily report-এ যাক।
On-call ও Escalation
On-call মানে নির্দিষ্ট সময়ে একজন engineer page-এর জন্য দায়ী। একটা ভালো setup-এ থাকে:
- Rotation — সপ্তাহভিত্তিক পালা, যাতে একজনের উপর সব চাপ না পড়ে। দল যত বড়, একজনের পালা তত কম ঘন ঘন আসে।
- Escalation — primary সাড়া না দিলে (যেমন ১৫ মিনিটে) automatically secondary, তারপর manager-কে page।
- Paging tool — PagerDuty, Opsgenie বা VictorOps। এরা alert পেয়ে ঠিক ব্যক্তিকে call/SMS/push পাঠায় এবং escalation চালায়।
On-call rotation হলো হাসপাতালের night-duty doctor রোস্টারের মতো। প্রতিদিন একজন নির্দিষ্ট doctor দায়িত্বে থাকেন (rotation)। জরুরি রোগী এলে nurse আগে তাঁকে ডাকেন; তিনি ৫ মিনিটে না এলে senior consultant-কে ডাকা হয় (escalation)। আর প্রতিটা সাধারণ পরিস্থিতির জন্য একটা treatment protocol লেখা থাকে (runbook), যাতে junior doctor-ও জানেন প্রথম কী করতে হবে। কিন্তু যদি প্রতি রাতে ১০০ বার মিথ্যা alarm বাজে (machine ঠিকঠাক কাজ করছে এমন রোগীর জন্যও), doctor একসময় alarm-কে গুরুত্ব দেওয়া বন্ধ করবেন — সেটাই বিপজ্জনক।
কৌশল — Runbook ও Alert fatigue কমানো
Runbook
Runbook হলো ধাপে ধাপে নির্দেশিকা — "এই alert এলে এই করো"। যেমন:
Alert: payment-service high latency
1. Grafana dashboard খোলো: <internal link>
2. ledger-service-এর DB connection pool চেক করো
3. Pool full হলে: kubectl rollout restart deploy/ledger
4. ঠিক না হলে escalate করো DB team-কে
ভালো runbook থাকলে রাত ৩টায় ঘুমন্ত মস্তিষ্কেও দ্রুত পদক্ষেপ নেওয়া যায়।
Alert fatigue কমানো
- নিয়মিত alert audit করো — যে alert কখনো action দাবি করেনি, সেটা মুছে দাও বা downgrade করো।
- duplicate alert group করো (একই incident-এ ৫০টা আলাদা page নয়, একটা)।
- Auto-resolve করো — সমস্যা মিটে গেলে alert নিজেই বন্ধ হোক।
কখন ব্যবহার করবে / করবে না
- শুধু symptom/user-impacting জিনিসে page করো। internal metric (CPU, memory) dashboard-এ রাখো, page-এ নয় — যদি না তা সরাসরি impact-এর পূর্বাভাস হয়।
- non-urgent issue page করো না; ticket বানাও।
সবচেয়ে বড় ভুল হলো "সব কিছুতে alert বসিয়ে দেওয়া"। প্রতিটা noisy alert তোমার টিমের আসল alert-এর প্রতি বিশ্বাস নষ্ট করে। একটা ভালো নিয়ম — যদি একটা page-এর জবাবে engineer কিছুই করতে না পারে বা "এটা ignore করা যায়" বলে, তাহলে সেটা page হওয়াই উচিত নয়। On-call পালা মানবিক রাখো; টানা রাত-জাগা burnout আর resignation ডেকে আনে।
বাস্তব উদাহরণ
একটা ride-sharing app (Pathao-সদৃশ) আগে cause-based alert দিত — "Kafka lag বাড়ছে", "Redis memory ৮০%"। রাতে ২০-৩০টা page বাজত, বেশিরভাগই কিছু না করেই মিটে যেত। engineer-রা ক্লান্ত, আর একদিন আসল outage (driver matching বন্ধ) ৪০ মিনিট ধরে কেউ খেয়াল করল না।
এরপর তারা symptom-based-এ গেল — শুধু "৫ মিনিট ধরে ride request-এর success rate ৯৫%-এর নিচে" বা "matching latency p95 > ১০s" — এমন গ্রাহক-প্রভাবিত জিনিসে page। দৈনিক page নেমে এল ১-২-তে, প্রতিটাই আসল। MTTR কমল, টিমের ঘুমও ফিরল।
Interview-এ বলো — "Page on symptoms, not causes" এবং প্রতিটা page-কে actionable + urgent + real হতে হবে। alert fatigue-এর সমস্যা ও তার সমাধান (audit, grouping, auto-resolve) উল্লেখ করলে maturity বোঝা যায়। Runbook ও escalation policy-র কথা যোগ করলে interviewer বুঝবে তুমি শুধু alert বানানো নয়, পুরো incident lifecycle ভাবো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. কোনটা ভালো (actionable) alert-এর উদাহরণ?
2. Alert fatigue কী?
3. Primary on-call engineer ১৫ মিনিটে page-এর উত্তর না দিলে কী ঘটা উচিত?