Blameless postmortem কীভাবে লিখবেন
Outage থেকে কিছু না শিখলে সেটি নষ্ট। বাস্তব সমাধানের দিকে নিয়ে যায় এমন blameless postmortem-এর template দেখুন।
Postmortem (incident review) হলো outage বা ব্যর্থতার লিখিত বিশ্লেষণ, শেখার ও পুনরাবৃত্তি ঠেকানোর জন্য। ভালোটি সিস্টেম বদলায়। খারাপটি দোষ চাপানোর মানুষ খোঁজে।
Blameless কেন
শাস্তির ভয় থাকলে মানুষ ভুল ও খুঁটিনাটি লুকায়, আর আপনি দরকারি তথ্য হারান। বেশিরভাগ incident-এ একজন মানুষ যুক্তিসঙ্গত সিদ্ধান্তই নিয়েছিল, যা সিস্টেম বিপর্যয়ে পরিণত হতে দিয়েছে: একটি অনুপস্থিত যাচাই, বিভ্রান্তিকর টুল, অনিরাপদ ডিফল্ট। জিজ্ঞেস করুন "এটি কীভাবে সম্ভব হলো?", "কে করেছে?" নয়।
সহজ template
১. সারাংশ। দুই-তিন বাক্য: কী ভেঙেছিল, কার জন্য, কতক্ষণ।
২. প্রভাব। নির্দিষ্ট করুন: কোন user বা feature, সময়কাল, error হার, প্রভাবিত order বা টাকা, data হারানো হলে সেটি।
৩. Timeline (UTC-তে)। প্রথম লক্ষণ থেকে পূর্ণ পুনরুদ্ধার পর্যন্ত:
- সমস্যা কখন শুরু হয়েছিল (প্রায়ই alert নয়, log থেকে পাওয়া)।
- কখন শনাক্ত হলো এবং কীভাবে (alert না গ্রাহক)।
- প্রতিটি গুরুত্বপূর্ণ কাজ ও সিদ্ধান্তের সময়।
- Mitigation ও সমাধানের সময়।
ফাঁকগুলোই অন্তর্দৃষ্টি: শনাক্তে দেরি মানে monitoring দুর্বল; mitigation-এ দেরি মানে runbook বা rollback দুর্বল।
৪. মূল কারণ ও সহায়ক বিষয়। "Five whys" ব্যবহার করুন: ঠিক করা যায় এমন সিস্টেম কারণে না পৌঁছানো পর্যন্ত বারবার "কেন" জিজ্ঞেস করুন। কারণ প্রায় কখনো একটি নয়, কয়েকটি একসাথে মিলেছিল।
৫. কী ভালো হয়েছে। দ্রুত rollback, ভালো alert, পরিষ্কার যোগাযোগ। যা কাজ করে তা রাখুন।
৬. কী খারাপ হয়েছে এবং কোথায় ভাগ্য সহায় ছিল। ভাগ্য মানে পরেরবার হয়তো আরও খারাপ হবে।
৭. Action item। সবচেয়ে গুরুত্বপূর্ণ অংশ। প্রতিটিতে থাকবে:
- নির্দিষ্ট কাজ, "আরও সতর্ক থাকো" নয়।
- একজন মালিক ও শেষ তারিখ।
- অগ্রাধিকার এবং ticket-এর লিংক।
মানুষের মনে রাখার ওপর নির্ভরশীলের চেয়ে পুরো সমস্যার শ্রেণি দূর করে এমন action (automation, guardrail, test, নিরাপদ ডিফল্ট) বেছে নিন।
লেখার পর
- টিম ও প্রভাবিতদের সাথে পর্যালোচনা করুন।
- ব্যাপকভাবে শেয়ার করুন। অন্যরা শিখবে।
- Action item সম্পূর্ণ না হওয়া পর্যন্ত ট্র্যাক করুন। অসমাপ্ত action-সহ postmortem আসলে পরের outage-এর রেকর্ড।
টিপস
- স্মৃতি টাটকা থাকতেই লিখুন, তবে incident শান্ত হওয়ার পর।
- আগে তথ্য জোগাড় করুন: গ্রাফ, log, chat ইতিহাস।
- "মানবিক ভুল"-কে মূল কারণ বলা এড়ান। আরও গভীরে খুঁজুন।
মূল কথা: incident তথ্যনির্ভরভাবে বর্ণনা করুন, সিস্টেমের কারণ খুঁজুন, আর action item শেষ করুন।
System Design সিরিজ, পর্ব ৫ (failure ও security): 3 নম্বর (মোট 6)। আগের লেখা: Circuit breaker ও bulkhead: একটি ব্যর্থতা ছড়ানো ঠেকান.
