Incident Response ও Postmortem
- ●Incident-এর severity ঠিক করে কত দ্রুত ও কতজন সাড়া দেবে; Incident Commander পুরো response সমন্বয় করেন।
- ●MTTD হলো সমস্যা ধরতে লাগা সময়, MTTR হলো ঠিক করতে লাগা সময় — দুটোই কমানোর লক্ষ্য।
- ●Blameless postmortem ব্যক্তি নয়, system-কে দোষ দেয়; root cause খুঁজে action item বানিয়ে পুনরাবৃত্তি রোধ করে।
সমস্যাটা কী?
বড় সিস্টেমে outage অনিবার্য — প্রশ্ন "হবে কিনা" নয়, "কখন হবে"। কিন্তু দুটো কোম্পানির মধ্যে আসল পার্থক্য হলো — outage হলে তারা কীভাবে সাড়া দেয় আর তা থেকে কী শেখে।
খারাপ response দেখতে কেমন? সবাই হুড়োহুড়ি করছে, কে দায়িত্বে কেউ জানে না, একই কাজ দুজন আলাদা করছে, management বারবার "কী হলো?" জিজ্ঞেস করে engineer-দের disturb করছে। আর শেষে কাউকে দোষ দিয়ে ব্যাপারটা চাপা দেওয়া হচ্ছে — ফলে একই ভুল ৩ মাস পরে আবার ঘটছে। ভালো incident response আর blameless postmortem এই বিশৃঙ্খলা ঠেকায় এবং প্রতিটা outage-কে শেখার সুযোগে পরিণত করে।
মূল ধারণা
Incident হলো এমন একটা ঘটনা যা service-এ অপ্রত্যাশিত বিঘ্ন ঘটায় এবং তাৎক্ষণিক সাড়া দাবি করে। Incident Response হলো তা সামলানোর সংগঠিত প্রক্রিয়া, আর Postmortem হলো পরে বসে শেখার দলিল।
Incident response-এর দুটো লক্ষ্য থাকে এবং ক্রম গুরুত্বপূর্ণ: প্রথমে service ফেরাও (mitigate), পরে কারণ খোঁজো (root cause)। জ্বলন্ত বাড়িতে আগুন নেভানোই আগে, কেন আগুন লাগল তা তদন্ত পরে।
কীভাবে কাজ করে
Severity নির্ধারণ
প্রথম কাজ — incident কতটা গুরুতর তা ঠিক করা, কারণ এটাই ঠিক করে response-এর মাত্রা:
| Severity | মানে | উদাহরণ | response |
|---|---|---|---|
| SEV1 | পুরো service down, বড় revenue ক্ষতি | পুরো সাইট inaccessible | সবাই jump in, রাত হলেও |
| SEV2 | বড় feature down | checkout কাজ করছে না | দ্রুত, on-call টিম |
| SEV3 | আংশিক/ছোট impact | একটা region ধীর | working hours-এ |
| SEV4 | minor, কোনো user impact নেই | একটা cosmetic bug | normal backlog |
Incident-এর ভূমিকা
বড় incident-এ স্পষ্ট ভূমিকা থাকা জরুরি:
- Incident Commander (IC) — পুরো response-এর সমন্বয়ক। নিজে fix করেন না; ঠিক করেন কে কী করবে, সিদ্ধান্ত নেন, এবং বিশৃঙ্খলা ঠেকান।
- Communications Lead — stakeholder, support ও গ্রাহকদের status জানান, যাতে engineer-রা নিরবচ্ছিন্নভাবে কাজ করতে পারেন।
- Operations / Responders — যাঁরা আসলে হাতে কাজ করে সমস্যা ঠিক করেন।
- Scribe — timeline ও সিদ্ধান্তগুলো লিখে রাখেন (postmortem-এর জন্য মূল্যবান)।
মূল metric — MTTD ও MTTR
| Metric | পুরো নাম | কী মাপে |
|---|---|---|
| MTTD | Mean Time To Detect | সমস্যা শুরু থেকে ধরা পড়া পর্যন্ত |
| MTTR | Mean Time To Recovery | detect থেকে পুরোপুরি ঠিক হওয়া পর্যন্ত |
| MTBF | Mean Time Between Failures | দুই incident-এর মধ্যবর্তী গড় সময় |
লক্ষ্য — MTTD ও MTTR কমানো (দ্রুত ধরা, দ্রুত ঠিক করা), আর MTBF বাড়ানো (কম ঘন ঘন incident)। ভালো observability MTTD কমায়; ভালো runbook ও automation MTTR কমায়।
Incident response হলো হাসপাতালের জরুরি বিভাগের (emergency room) মতো। রোগী এলে আগে triage হয় — কতটা গুরুতর (severity)। একজন senior doctor পুরো team-কে নির্দেশ দেন কিন্তু নিজে সব কাজ করেন না (Incident Commander)। একজন nurse পরিবারকে update দেন (Communications Lead)। আগে রোগীকে স্থিতিশীল করা হয় (mitigate), রোগের আসল কারণ পরে খোঁজা হয়। আর পরে doctor-রা বসে আলোচনা করেন — কী ভালো হলো, কী আরও দ্রুত করা যেত (postmortem) — কাউকে দোষ দিতে নয়, পরের বার আরও ভালো করতে।
কৌশল — Blameless Postmortem
incident মিটে যাওয়ার পর (সাধারণত ২৪-৪৮ ঘণ্টার মধ্যে) একটা Blameless Postmortem লেখা হয়। এর মূলমন্ত্র — system-কে দোষ দাও, মানুষকে নয়।
কেন blameless? কারণ মানুষকে দোষ দিলে সবাই ভয়ে সত্য লুকায়, ফলে আসল কারণ বেরোয় না। যদি একজন engineer ভুল command দিয়ে production মুছে ফেলে, প্রশ্ন হবে — "এই বিপজ্জনক command-এ কোনো confirmation বা safeguard ছিল না কেন?" — ব্যক্তির ভুল নয়, system-এর দুর্বলতা।
একটা ভালো postmortem-এ থাকে:
1. Summary — এক প্যারায় কী ঘটেছিল
2. Impact — কত user, কত সময়, কত revenue
3. Timeline — মিনিট-বাই-মিনিট ঘটনাক্রম
4. Root Cause — আসল কারণ (5 Whys পদ্ধতিতে)
5. What worked — কী ভালো গেল
6. Action items — কে, কী, কবে (owner + deadline সহ)
Root Cause Analysis-এ জনপ্রিয় পদ্ধতি হলো "5 Whys" — বারবার "কেন?" জিজ্ঞেস করে গভীরে যাওয়া। "সাইট down হলো → কেন? DB overload → কেন? একটা slow query → কেন? নতুন index ছাড়া deploy → কেন? review checklist-এ index check ছিল না।" — আসল root cause পাওয়া গেল।
কখন ব্যবহার করবে / করবে না
- প্রতিটা SEV1/SEV2 incident-এর postmortem বাধ্যতামূলক করো।
- ছোট, no-impact issue-তে পূর্ণ postmortem দরকার নেই — সংক্ষিপ্ত note যথেষ্ট।
- action item-গুলো অবশ্যই track করো; নইলে postmortem শুধু কাগুজে কাজ।
সবচেয়ে বড় ভুল — postmortem-কে blame game বানানো ("X এর দোষে হলো")। এতে টিম রক্ষণাত্মক হয়, সত্য চাপা পড়ে, আর একই incident আবার ঘটে। দ্বিতীয় বড় ভুল — চমৎকার postmortem লিখে action item-গুলো কখনো বাস্তবায়ন না করা। action item-এ owner ও deadline না থাকলে সেটা অর্থহীন। Postmortem-এর সাফল্য মাপা হয় কতগুলো action item আসলে শেষ হলো তা দিয়ে।
বাস্তব উদাহরণ
একটা fintech app-এ একদিন দুপুরে সব transaction fail হতে শুরু করল (SEV1)। On-call engineer alert পেয়ে IC ঘোষণা করলেন, একজনকে investigation, একজনকে communication দিলেন।
- MTTD: monitoring ভালো ছিল, ২ মিনিটে detect।
- Mitigation: ১৫ মিনিটে তারা সমস্যা চিহ্নিত করল — সকালে deploy হওয়া একটা config change তৃতীয় পক্ষের payment gateway-র URL ভুল করে দিয়েছিল। rollback করতেই service ফিরে এল। MTTR ≈ ১৭ মিনিট।
- Postmortem (5 Whys): ভুল URL → কেন merge হলো? → review-তে কেউ ধরেনি → কেন? → config change-এ কোনো automated validation ছিল না।
- Action items: (১) deploy pipeline-এ config validation যোগ (owner: A, ১ সপ্তাহ), (২) gateway URL-এর health check (owner: B, ৩ দিন)।
কাউকে দোষ না দিয়ে তারা process-এর ফাঁক বন্ধ করল — একই ভুল আর হয়নি।
Interview-এ ক্রমটা স্পষ্ট বলো — mitigate first, root cause later। Incident Commander-এর coordinating ভূমিকা (hands-off) বোঝাও। MTTD vs MTTR পার্থক্য জানা থাকা দরকার। সবশেষে blameless culture-এর গুরুত্ব ও 5 Whys-এর কথা বললে interviewer বুঝবে তুমি শুধু আগুন নেভানো নয়, প্রতিষ্ঠানিক শেখার সংস্কৃতিও বোঝো।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. একটা outage-এর সময় Incident Commander-এর মূল কাজ কী?
2. MTTR কী মাপে?
3. Blameless postmortem-এর মূল উদ্দেশ্য কী?