Monitoring ও Alerting - রাতে phone বাজবে শুধু আসল বিপদে

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

সেশন ১৯ এ আমরা system এর ভেতরটা দেখার উপায় শিখেছি: log, metric আর trace। কিন্তু শুধু দেখার ব্যবস্থা থাকলেই হয় না। রাত তিনটায় কেউ dashboard এর সামনে বসে থাকে না। তাই system কে নিজে থেকেই মানুষকে ডাকতে হয়, আর ডাকতে হয় ঠিক সময়ে, ঠিক কারণে।

এই সেশনে আমরা শিখবো, কোন সংখ্যা দেখে বুঝবো system ভালো আছে, কখন একজন মানুষের ঘুম ভাঙানো উচিত, আর কখন একদম উচিত নয়। শেষে আপনি জানবেন, সমস্যা এলে একটা team কীভাবে শান্ত মাথায় সেটা সামলায়, আর পরে কীভাবে তা থেকে শেখে।

০১ এক রাতে ৩৭টা alert, অথচ একজন user ও সমস্যায় পড়েনি। এটা কেন বিপজ্জনক?

বৃহস্পতিবার রাত এগারোটা চল্লিশ। মাহিন সবে ঘুমিয়েছে। ছয় মাস হলো সে একটা বাসের টিকিট কাটার অ্যাপে backend engineer হিসেবে কাজ করছে, আর এই সপ্তাহে প্রথমবার তার on-call duty। হঠাৎ phone বেজে উঠলো: “CPU above 80% on web-07”। বুক ধড়ফড় করতে করতে সে laptop খুললো। Login করতে করতে CPU নেমে এলো ৬২% এ। সে আবার শুয়ে পড়লো। দশ মিনিট পর আবার বাজলো। তারপর আবার। ভোর পাঁচটা পর্যন্ত phone বাজলো মোট ৩৭ বার।

সকালে চোখ লাল করে অফিসে এসে মাহিন checkout এর graph খুললো। সারা রাত টিকিট কেনা স্বাভাবিক ছিলো। একজন user ও কোনো সমস্যায় পড়েনি।

আগে কয়েকটা শব্দ পরিষ্কার করে নিই। Monitoring মানে system এর সংখ্যাগুলো (CPU, request, error) সারাক্ষণ মাপা আর graph এ দেখা। Alert মানে কোনো সংখ্যা বিপদের সীমা পার হলে system নিজেই একজন মানুষকে খবর দেয়। যে alert রাতেও phone বাজিয়ে মানুষকে জাগায়, তাকে বলে page।

মাহিনের ৩৭টা page এর কারণ খুঁজে পাওয়া গেলো সহজেই। প্রতি রাতে একটা batch job (নির্দিষ্ট সময়ে নিজে থেকে চলা একটা বড় কাজ) বাস কোম্পানিগুলোর server থেকে seat এর তথ্য sync করে। Job চলার সময় CPU কয়েক মিনিটের জন্য ৮৫% এ ওঠে, তারপর নেমে যায়। আর alert এর নিয়ম ছিলো: CPU টানা ১ মিনিট ৮০% এর উপরে থাকলেই page যাবে। CPU যতবার সীমার উপরে-নিচে দুলেছে, ততবার phone বেজেছে।

রাখাল বালক আর বাঘের গল্প

ছোটবেলার সেই গল্পটা মনে আছে? রাখাল বালক মজা করে বারবার “বাঘ এসেছে” বলে চিৎকার করতো। গ্রামের মানুষ প্রতিবার দৌড়ে এসে দেখতো, কিছুই নেই। যেদিন সত্যিই বাঘ এলো, সেদিন কেউ আর আসেনি।

Alert এর ক্ষেত্রেও ঠিক একই জিনিস ঘটে। যে alert বারবার বাজে অথচ কিছু করার থাকে না, মানুষ ধীরে ধীরে সেটাকে উপেক্ষা করতে শেখে। Phone silent এ চলে যায়, notification না পড়েই সরিয়ে দেওয়া হয়। এই অবস্থার নাম alert fatigue। এর তিনটা খারাপ ফল আছে:

1. আসল alert হারিয়ে যায়: ৩৭টা মিথ্যা alert এর ভিড়ে সত্যিকারের একটা alert আলাদা করে চোখে পড়ে না।
2. Engineer ক্লান্ত হয়: ঘুম ভাঙা রাতের পর পরদিন কাজে ভুল বেশি হয়। এভাবে কয়েক মাস চললে ভালো engineer চাকরি ছেড়ে চলে যায়।
3. Alert এর উপর বিশ্বাস নষ্ট হয়: একবার team ধরে নিলে যে “এগুলো তো সবসময়ই বাজে”, তখন সত্যিকারের বিপদেও কেউ তাড়াহুড়ো করে না।

তাহলে প্রশ্ন দাঁড়ালো, “user এর ক্ষতি” জিনিসটা মাপবো কীভাবে? পরের দিন সকালে team lead নাদিয়া আপা মাহিনকে ঠিক এই প্রশ্নটাই করলেন।

০২ “System ভালো চলছে” কথাটা কীভাবে মাপবো?

সেশন ০১ এ আপনি দুটো শব্দ দেখেছেন। SLA হলো customer কে দেওয়া লিখিত চুক্তি (“৯৯% request 500ms এর মধ্যে শেষ হবে, না হলে টাকা ফেরত”)। SLO হলো team এর নিজের লক্ষ্য, যেটা SLA এর চেয়ে কড়া রাখা হয় (“৯৯% request 200ms এর মধ্যে”)। কিন্তু একটা প্রশ্ন তখন বাকি ছিলো: লক্ষ্য তো ঠিক হলো, এখন আসলে কতটা ভালো চলছে, সেই সংখ্যাটা আসে কোথা থেকে?

সেই সংখ্যাটার নাম SLI (Service Level Indicator)। SLI হলো একটা মাপা সংখ্যা, যেটা বলে user এর দিক থেকে service টা কতটা ভালো চলছে। সাধারণত এটা একটা ভগ্নাংশ:

ভালো ঘটনার সংখ্যাকে মোট ঘটনার সংখ্যা দিয়ে ভাগ করলেই SLI পাওয়া যায়।

টিকিট অ্যাপের জন্য নাদিয়া আপা আর মাহিন মিলে দুটো SLI বেছে নিলো:

• Checkout এর সফলতা: যতগুলো checkout শুরু হয়েছে, তার মধ্যে কতগুলো টিকিট দিয়ে শেষ হয়েছে। গত ৩০ দিনে এটা ছিলো ৯৯.৯৩%।
• Search এর গতি: কতগুলো search 300ms এর মধ্যে উত্তর পেয়েছে। এখানে p99 এর ধারণা কাজে লাগে, যেটা সেশন ১৯ এ দেখেছেন: সবচেয়ে ধীর ১% request বাদ দিলে বাকি সবাই কত সময়ের মধ্যে উত্তর পায়।

খেয়াল করুন, দুটো SLI এর কোনোটাই CPU বা memory নিয়ে নয়। দুটোই এমন জিনিস মাপে, যেটা একজন যাত্রী নিজের চোখে টের পায়: টিকিট কাটা গেলো কিনা, আর বাসের তালিকা তাড়াতাড়ি এলো কিনা।

তিনটা শব্দকে একটা মাপকাঠিতে বসালে সম্পর্কটা পরিষ্কার হয়:

০৩ SLO কেন ১০০% নয়, আর বাকি ০.১% দিয়ে কী করবো?

মাহিনের প্রথম প্রশ্ন ছিলো, “আপা, লক্ষ্য ১০০% রাখলেই তো হয়। ০.১% fail কেন মেনে নেবো?”

নাদিয়া আপা তিনটা কারণ বললেন। প্রথমত, ১০০% পাওয়া প্রায় অসম্ভব। Disk নষ্ট হয়, network কাটে, আবার payment gateway (যে বাইরের service টাকা কাটার কাজটা করে) নিজেই মাঝে মাঝে down থাকে। দ্বিতীয়ত, প্রতিটা বাড়তি “৯” এর খরচ অনেক বেশি। ৯৯.৯% থেকে ৯৯.৯৯% এ যেতে প্রায়ই দ্বিগুণ server, আরেকটা data center আর অনেক বেশি engineer এর সময় লাগে। তৃতীয়ত, user নিজেই পার্থক্যটা টের পায় না। তার মোবাইলের ইন্টারনেট সংযোগ এমনিতেই এর চেয়ে বেশি বার কেটে যায়।

তাহলে বাকি ০.১% কী? এটা হলো error budget: SLO এর ভেতরে থেকেও যতটুকু fail করার অনুমতি আছে। টিকিট অ্যাপে হিসাবটা দাঁড়ায় এমন:

SLO: 30 দিনে 99.9% checkout সফল হতে হবে
মাসে মোট checkout: 10,000,000 (এক কোটি)

Error budget: 100% - 99.9% = 0.1%

request এর হিসাবে: 10,000,000 × 0.001 = 10,000 টা checkout fail করতে পারে
সময়ের হিসাবে: 30 দিন = 43,200 মিনিট
               43,200 × 0.001 = 43.2 মিনিট পুরো down থাকা চলে

অর্থাৎ এই মাসে ১০,০০০টা checkout fail করলেও SLO ঠিক থাকে। Budget শব্দটা ইচ্ছা করেই বেছে নেওয়া হয়েছে। মাসের হাতখরচের মতো এটা খরচ করা যায়। প্রতিটা ঝুঁকির deploy, প্রতিটা নতুন feature, প্রতিটা ছোট outage (service পুরো বা আংশিক বন্ধ থাকা) এই budget থেকে কিছুটা করে খরচ করে।

শনিবার সকালে budget এর অর্ধেক শেষ

মাসের ১৮তম দিন পর্যন্ত টিকিট অ্যাপ budget এর ৩০% খরচ করেছিলো। তারপর এলো মাহিনের সেই রাতের দুই দিন পরের শনিবার। ৯টা ২ মিনিটে একটা নতুন version deploy হলো। ৯টা ৫ মিনিট থেকে প্রতি পাঁচটা checkout এর একটা fail করতে লাগলো। পুরো ঘটনাটা পরে বিস্তারিত দেখবো। এখানে শুধু হিসাবটা দেখুন: ৫০ মিনিটে প্রায় ২৪,০০০টা checkout হয়েছে, তার মধ্যে ৪,৮০০টা fail করেছে। এক সকালেই budget এর ৪৮% শেষ হয়ে গেলো। (শনিবার সকালে traffic মাসের গড়ের প্রায় দ্বিগুণ থাকে। তাই সময়ের হিসাবের চেয়ে request এর হিসাবে ক্ষতি বেশি দাঁড়ায়।)

Feature নাকি reliability: budget ই সিদ্ধান্ত নেয়

Error budget এর সবচেয়ে বড় কাজ হলো একটা পুরোনো ঝগড়া মিটিয়ে দেওয়া। Product team চায় দ্রুত নতুন feature ship করতে। Engineering team চায় system স্থির রাখতে। কার কথা চলবে? আগে থেকে লিখে রাখা একটা নিয়ম, যার নাম error budget policy, এই প্রশ্নের উত্তর দেয়:

নিয়মটা কারো মতামতের উপর নির্ভর করে না, একটা সংখ্যার উপর নির্ভর করে। Budget বাকি থাকলে product team যত খুশি feature ship করতে পারে। Budget শেষ হলে নতুন feature বন্ধ থাকে (একে বলে feature freeze)। তখন পুরো team reliability এর কাজ করে, যতক্ষণ না SLI আবার নিরাপদ জায়গায় ফেরে।

০৪ যেকোনো service এর কোন চারটা সংখ্যা সবসময় দেখতে হয়?

SLI বলে দেয় user খুশি কিনা। কিন্তু একটা service এর স্বাস্থ্য বুঝতে আরো কয়েকটা সংখ্যা লাগে। Google এর engineer রা বছরের পর বছর অভিজ্ঞতা থেকে চারটা সংখ্যা বেছে নিয়েছেন, যেগুলো প্রায় যেকোনো service এর জন্য কাজ করে। এদের বলে golden signals:

1. Latency: একটা request এর উত্তর আসতে কত সময় লাগে। এখানে একটা ফাঁদ আছে। Fail হওয়া request প্রায়ই খুব দ্রুত ফেরত আসে, কারণ server কাজটা না করেই error দিয়ে দেয়। তাই সফল আর fail হওয়া request এর latency আলাদা করে মাপতে হয়। না হলে error বাড়লে latency এর graph উল্টো ভালো দেখায়।
2. Traffic: Service এর উপর কতটা চাপ আসছে, যেমন প্রতি সেকেন্ডে কতগুলো request। টিকিট অ্যাপে সাধারণ দিনে এটা 800 req/s, কিন্তু ঈদের আগের সপ্তাহে 4,000 req/s পর্যন্ত ওঠে।
3. Errors: কতগুলো request fail করছে। শুধু 500 এর মতো error code নয়, ভুল উত্তরও এর মধ্যে পড়ে। যেমন, payment সফল হলো অথচ টিকিট তৈরি হলো না।
4. Saturation: Service এর সবচেয়ে সীমিত resource টা কতটা ভরে গেছে। এটা CPU হতে পারে, memory হতে পারে, আবার database এর connection pool ও হতে পারে (আগে থেকে খুলে রাখা database connection এর একটা সীমিত সেট)। টিকিট অ্যাপে সবার আগে এই pool টাই ভরে যায়।

এই চারটা সংখ্যা একসাথে একটা গল্প বলে। Traffic বাড়লো, saturation ১০০% এ পৌঁছালো, তারপর latency বাড়লো, শেষে error শুরু হলো। প্রায় প্রতিটা overload এই ক্রমেই ঘটে।

০৫ Alert দেবো CPU এর উপর, নাকি user এর কষ্টের উপর?

এবার শনিবার সকালের সেই ঘটনায় ফিরি। ৯টা ২ মিনিটে রাতুল একটা deploy করলো। তার ভেতরে একটা ছোট্ট পরিবর্তন ছিলো: payment gateway এর timeout ১০ সেকেন্ড থেকে কমিয়ে ১ সেকেন্ড করা হয়েছিলো। (Timeout মানে কতক্ষণ উত্তরের জন্য অপেক্ষা করে request বাতিল করা হবে, সেশন ০১ এ দেখেছেন।) শনিবার সকালে ভিড়ের সময় gateway এর প্রতি পাঁচটা উত্তরের একটা আসতে ১.২ সেকেন্ডের মতো লাগছিলো। ফলে সেই checkout গুলো fail করতে লাগলো।

মাহিনের phone এ একটাও alert আসেনি। কেন? কারণ সব alert ছিলো CPU, memory আর disk এর উপর। আর fail হওয়া request এ server এর কাজ কম হয়, তাই CPU উল্টো নেমে গিয়েছিলো ৩৫% এ। ৯টা ৪০ মিনিটে Facebook এ যাত্রীদের অভিযোগ আসতে শুরু করলো। ৯টা ৪৪ মিনিটে support team মাহিনকে call করলো।

এখানে দুই রকম alert এর পার্থক্য পরিষ্কার হয়:

• Cause-based alert: সমস্যার সম্ভাব্য কারণের উপর alert। যেমন CPU ৮০% ছাড়ালো, memory ভরে আসছে, একটা server down হলো। সমস্যা হলো, কারণ থাকলেও অনেক সময় user এর কোনো ক্ষতি হয় না (মাহিনের সেই ৩৭টা alert), আবার কারণের তালিকার বাইরের কোনো সমস্যায় alert বাজেই না (শনিবার সকাল)।
• Symptom-based alert: User যা টের পায়, তার উপর alert। যেমন checkout এর সফলতা SLO এর নিচে নামলো, বা search ধীর হয়ে গেলো। কারণ যেটাই হোক, ১ সেকেন্ডের timeout হোক বা অচেনা কোনো bug, user কষ্ট পেলেই এই alert বাজবে।

তাহলে CPU এর মতো সংখ্যাগুলো কি ফেলে দেবো? না। এগুলো dashboard এ থাকে, সমস্যার কারণ খুঁজতে কাজে লাগে। শুধু এগুলোর জন্য কারো ঘুম ভাঙানো হয় না। কোন signal এর জায়গা কোথায়, সেটা দুটো প্রশ্ন দিয়ে ঠিক করা যায়:

এখানে একটা নতুন শব্দ এলো: ticket। এটা বাসের টিকিট নয়, কাজের ticket। Ticket মানে team এর কাজের তালিকায় একটা কাজ যোগ হয়, যেটা কেউ পরের কর্মদিবসে দেখবে। যেমন, disk সাত দিনে ভরে যাবে। এটা জরুরি, কিন্তু রাত তিনটায় কাউকে ডাকার মতো জরুরি নয়।

০৬ Alert ঠিক কখন বাজবে?

Checkout এর সফলতার উপর alert দেবো, ঠিক আছে। কিন্তু কোন সংখ্যায় বাজবে?

সহজ পথ: threshold

সবচেয়ে সহজ নিয়ম হলো একটা নির্দিষ্ট সীমা, যার নাম threshold। যেমন, শেষ ৫ মিনিটে error ১% ছাড়ালেই page যাবে। নিয়মটা বোঝা সহজ, কিন্তু এর দুটো দুর্বলতা আছে। দুই মিনিটের একটা ছোট ঝাঁকুনিতেও phone বাজে, অথচ তাতে budget এর সামান্যই খরচ হয়। আবার সারাদিন ধরে ০.৫% error চলতে থাকলে alert কখনো বাজে না, অথচ চুপচাপ budget শেষ হয়ে যায়।

ভালো পথ: burn rate

এর চেয়ে ভালো প্রশ্ন হলো: “এই গতিতে চললে budget কত তাড়াতাড়ি শেষ হবে?” এই গতিটার নাম burn rate। এখনকার error rate কে SLO এর অনুমতি দেওয়া error rate (০.১%) দিয়ে ভাগ করলে burn rate পাওয়া যায়।

• Burn rate ১: Error ঠিক ০.১% হারে হচ্ছে। এভাবে চললে budget ঠিক ৩০ দিনে শেষ হবে, তাই চিন্তার কিছু নেই।
• Burn rate ১০: Error ১% হারে হচ্ছে। Budget ৩ দিনে শেষ হবে।
• Burn rate ২০০: শনিবার সকালে error ছিলো ২০%। এভাবে চললে পুরো মাসের budget মাত্র সাড়ে তিন ঘণ্টায় শেষ হতো।

বাস্তবে team গুলো সাধারণত দুই-তিনটা burn rate নিয়ম একসাথে রাখে। একটা দ্রুত বিপদ ধরে, আরেকটা ধীরে চলা ক্ষতি ধরে:

শনিবার সকালে প্রথম নিয়মটা থাকলে কী হতো? ২০% error চললে শেষ এক ঘণ্টার গড় ১.৪৪% ছাড়াতে মাত্র সাড়ে চার মিনিট লাগে। অর্থাৎ ৯টা ৯ মিনিটেই মাহিনের phone বাজতো, Facebook এর অভিযোগের ৩১ মিনিট আগে। আর মাহিনের সেই রাতের CPU ঝাঁকুনি গুলো? তাতে checkout এর একটাও fail হয়নি, তাই burn rate ০ ছিলো। কোনো phone বাজতো না।

০৭ একটা ভালো dashboard দেখতে কেমন?

শনিবার ৯টা ৪৪ মিনিটে মাহিন যখন laptop খুললো, তখন তার সামনে ছিলো একটা dashboard এ ৬০টা graph। প্রতিটা server এর CPU, memory, disk, network। কোন graph টা দেখবে, সেটা বুঝতেই তার আট মিনিট চলে গেলো।

Dashboard হলো graph এর একটা সাজানো পাতা, যেটা একনজরে system এর অবস্থা দেখায়। ভালো dashboard এর নিয়ম একটাই: প্রতিটা dashboard একটা প্রশ্নের উত্তর দেবে। প্রশ্নটা dashboard এর নামেই লেখা থাকবে।

• Overview (প্রথম পাতা): “User রা কি টিকিট কিনতে পারছে?” এখানে থাকে SLO এর অবস্থা, বাকি error budget আর চারটা golden signal। সব সবুজ থাকলে এক নজরেই কাজ শেষ।
• Service: প্রতিটা service এর নিজের dashboard, যেমন search, checkout আর payment। প্রথম পাতায় লাল দেখলে এখানে এসে বোঝা যায় কোন service এ সমস্যা।
• Detail: একটা service এর ভেতরের সংখ্যা, যেমন gateway এর latency, timeout এর সংখ্যা, CPU। কারণ খোঁজার সময় এই পাতায় আসতে হয়।

নতুন dashboard এ শনিবারের ঘটনাটা খুঁজতে তিনটা click লাগতো। Overview এ checkout লাল, payment service এর পাতায় error বাড়ছে, আর detail পাতায় gateway timeout এর সংখ্যা হঠাৎ লাফিয়ে উঠেছে ঠিক ৯টা ৫ মিনিটে।

০৮ রাত তিনটায় phone বাজলে কী করবো?

On-call: পালা করে পাহারা

একটা system দিনরাত চলে, কিন্তু একজন মানুষ দিনরাত জেগে থাকতে পারে না। তাই team গুলো পালা করে দায়িত্ব নেয়। এর নাম on-call। প্রতি সপ্তাহে একজন primary থাকে, যার phone এ page আসে। তার পেছনে থাকে একজন secondary। Primary নির্দিষ্ট সময়ের মধ্যে সাড়া না দিলে page নিজে থেকেই secondary এর কাছে চলে যায়। একে বলে escalation।

কয়েকটা নিয়ম on-call কে মানুষের পক্ষে সহনীয় রাখে:

• Acknowledge এর সময় বাঁধা: Page আসার ৫ মিনিটের মধ্যে “আমি দেখছি” জানাতে হয়। একে বলে acknowledge করা। এতে সবাই জানে, কেউ একজন দায়িত্ব নিয়েছে।
• Page এর সংখ্যার সীমা: অনেক team লক্ষ্য রাখে, এক shift এ যেন দুইটার বেশি incident (user এর ক্ষতি হচ্ছে এমন ঘটনা) না আসে। এর বেশি এলে সেটাকে alert এর নিয়মের সমস্যা হিসেবে ধরা হয়, মানুষের সমস্যা হিসেবে নয়।
• Handoff: সপ্তাহ শেষে আগের on-call পরের জনকে বুঝিয়ে দেয়, কোন সমস্যা এখনো চলছে।

Runbook: রাত তিনটার জন্য লেখা নির্দেশিকা

রাত তিনটায় ঘুম ভাঙা মাথায় কেউ ভালো করে চিন্তা করতে পারে না। তাই প্রতিটা alert এর সাথে একটা লেখা নির্দেশিকা থাকে, যার নাম runbook। Runbook দিনের আলোয়, ঠান্ডা মাথায় লেখা হয়। এতে থাকে alert টার মানে কী, কোন dashboard দেখতে হবে, সম্ভাব্য কারণগুলো কী, আর প্রতিটা কারণে কী করতে হবে। মাহিন search এর latency alert এর জন্য এই runbook টা লিখলো:

RUNBOOK: SearchLatencyFastBurn

এই alert এর মানে: search এর p99 latency অনেকক্ষণ ধরে 300ms এর উপরে।
এভাবে চললে মাসের পুরো budget 2 দিনেই শেষ হবে।
Dashboard: "Search: user রা কি দ্রুত বাস খুঁজে পাচ্ছে?"

1. Traffic দেখুন: req/s কি স্বাভাবিকের (800) চেয়ে অনেক বেশি?
2. Deploy দেখুন: গত 1 ঘণ্টায় deploy হয়েছে? হলে আগে rollback করুন।
3. DB pool দেখুন: connection 100/100 ভরা? তাহলে search এর server বাড়ান।
       kubectl scale deploy/search --replicas=12
4. 15 মিনিটে ঠিক না হলে: secondary on-call কে ডাকুন।
5. সবশেষে: #incidents channel এ তিন লাইনে update দিন।

Runbook এর kubectl লাইনটা Kubernetes নামের একটা tool এর command। এটা দিয়ে ঠিক করা যায় একটা service এর কতগুলো copy চলবে। এর বিস্তারিত এই সেশনের বিষয় নয়। শুধু খেয়াল করুন, রাত তিনটায় মাহিনকে command টা মনে করতে হবে না, কারণ সেটা লেখাই আছে।

ঈদের আগের রাত

ছয় সপ্তাহ পর, ঈদের আগের সপ্তাহে মাহিনের আবার on-call পড়লো। রাত ৯টা ১৪ মিনিটে phone বাজলো। এবার একটা মাত্র page, আর সেটা সত্যিকারের: search ধীর হয়ে গেছে, p99 latency 1.8s। মাহিন runbook খুললো, ধাপে ধাপে এগোলো:

চতুর্থ ধাপটা লক্ষ্য করুন। মাহিন DB pool কেন ভরে গেলো, সেটা খুঁজতে বসেনি। আগে search এর server ৬টা থেকে ১২টা করে user দের কষ্ট থামিয়েছে। এই কাজটার নাম mitigation: সমস্যার মূল কারণ ঠিক না করেই ক্ষতি থামানো। Rollback (আগের ভালো version এ ফিরে যাওয়া), server বাড়ানো, একটা feature বন্ধ করা, এগুলো সবই mitigation। মূল কারণ খোঁজা হয় পরে, দিনের আলোয়।

০৯ সমস্যা মিটে গেলে কী করবো?

শনিবারের outage এর পরের সোমবার। মিটিং রুমে রাতুল চুপচাপ বসে আছে। সে ধরে নিয়েছে আজ তাকে সবার সামনে বকা শুনতে হবে। কিন্তু নাদিয়া আপা মিটিং শুরু করলেন একটা কথা দিয়ে: “আজ আমরা খুঁজবো না কে ভুল করেছে। আমরা খুঁজবো, আমাদের system কেন একটা ভুলকে ৫০ মিনিট ধরে user এর কাছে পৌঁছাতে দিলো।”

এই মিটিং আর তার লিখিত রিপোর্টের নাম postmortem। আর যে postmortem এ কোনো মানুষকে দোষ দেওয়া হয় না, তাকে বলে blameless postmortem।

দোষ না দেওয়া কেন জরুরি

রাতুলকে দোষ দিলে কী হতো? পরের বার কেউ ভুল করলে সেটা লুকানোর চেষ্টা করতো। কেউ নিজে থেকে বলতো না, “আমার deploy এর পর থেকেই সমস্যা শুরু।” অথচ incident এর সময় ঠিক এই কথাটাই সবচেয়ে দ্রুত সমাধানে পৌঁছে দেয়।

তাছাড়া প্রশ্নটাও ভুল। ১ সেকেন্ডের timeout লেখা একটা মানুষের ভুল। কিন্তু সেই ভুল কোনো test এ ধরা পড়েনি, কোনো review এ চোখে পড়েনি, আর কোনো alert ও বাজেনি। প্রতিটা ফাঁক system এর, মানুষের নয়। মানুষ বদলালেও এই ফাঁকগুলো থেকে যায়। ফাঁক বন্ধ করলে পরের মানুষটাও একই ভুল করতে পারবে না।

Postmortem এ কী থাকে

একটা postmortem এ সাধারণত পাঁচটা অংশ থাকে: কী হয়েছিলো তার ছোট সারাংশ, user এর উপর প্রভাব (৪,৮০০টা fail হওয়া checkout, budget এর ৪৮%), মিনিট ধরে ধরে timeline, মূল কারণ, আর ভবিষ্যতের জন্য কাজের তালিকা। Timeline লিখতে গিয়েই সবচেয়ে বড় শিক্ষাটা চোখে পড়লো:

তালিকার প্রতিটা কাজের একজন মালিক আর একটা শেষ তারিখ থাকে। না হলে কাজগুলো রিপোর্টের পাতাতেই পড়ে থাকে। শনিবারের postmortem থেকে এই কাজগুলো এলো:

খেয়াল করুন, শেষ দুটো কাজের মালিক রাতুল নিজেই। Blameless postmortem এ যে ভুল করেছে, সে প্রায়ই সমাধানের সবচেয়ে ভালো মানুষ হয়, কারণ সে ঘটনাটা সবচেয়ে ভালো জানে।

ঈদের সপ্তাহটা শেষ হলো। Traffic স্বাভাবিকের পাঁচ গুণ হয়েছিলো, অথচ মাহিনের phone পুরো সপ্তাহে বেজেছে মাত্র দুইবার। দুইবারই সত্যিকারের সমস্যা ছিলো, আর দুইবারই ১৫ মিনিটের মধ্যে মিটে গেছে।

১০ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর উত্তর খুলে দেখুন: বেশিরভাগ মানুষ কীভাবে ভাবে, সেই চিন্তায় কী বাদ পড়ে, আর আসল কথাটা কোথায়।

১১ যে টার্মগুলো শিখলাম

১২ শর্ট সামারি

১৩ মনে রাখুন

• Machine নয়, user কে মাপুন। SLI হবে এমন সংখ্যা, যেটা একজন user নিজের চোখে টের পায়।
• ১০০% কখনো লক্ষ্য নয়। বাকি অংশটুকু error budget, আর সেটা খরচ করার জন্যই রাখা।
• Page শুধু symptom এর উপর। Cause এর সংখ্যা dashboard এ রাখুন, কারণ খোঁজার কাজে লাগবে।
• প্রতিটা page এর পরে কিছু করার থাকতে হবে। যে alert এর পর কেউ কিছু করে না, সেটা মুছে ফেলুন।
• Threshold এর চেয়ে burn rate ভালো। এটা জিজ্ঞেস করে, user এর ক্ষতি কত দ্রুত হচ্ছে।
• আগে ক্ষতি থামান, পরে কারণ খুঁজুন। Rollback প্রায় সবসময় রাত তিনটার debugging এর চেয়ে নিরাপদ।
• Postmortem এ মানুষকে নয়, system কে প্রশ্ন করুন। দোষ দিলে মানুষ ভুল লুকায়, আর ফাঁকগুলো থেকে যায়।