ডেভেলপমেন্টে প্রোডাকশনে আগুন — এটি কী, কারণ এবং কর্মপরিকল্পনা

“প্রোডাকশনে আগুন লেগেছে” এর অর্থ কী এবং ত্রুটির ধরণ

“প্রোডাকশনে আগুন লেগেছে” (সবকিছু ডাউন) অভিব্যক্তিটি এমন একটি পরিস্থিতি বর্ণনা করে যেখানে প্রোডাকশন পরিবেশ সঠিকভাবে কাজ করছে না এবং ব্যবহারকারীরা প্রভাবিত হচ্ছে। ত্রুটি সম্পূর্ণ অ্যাপ্লিকেশন অনুপলব্ধতা (ফাঁকা স্ক্রিন, 502 ত্রুটি), আংশিক অনুপলব্ধতা (পেমেন্ট মডিউল কাজ করছে না কিন্তু অন্যান্য ফাংশন উপলব্ধ), বা কর্মক্ষমতা হ্রাস (অত্যন্ত ধীর লোডিং) হিসাবে প্রকাশ পেতে পারে। ঘটনার তীব্রতা প্রভাবিত ব্যবহারকারীর শতাংশ এবং ত্রুটির সময়কাল দ্বারা নির্ধারিত হয়।

Atlassian Statuspage (2025) অনুসারে, 2024 সালে মোবাইল অ্যাপ্লিকেশনের জন্য গড় ডাউনটাইম ছিল 27 মিনিট প্রতি ঘটনায়। সবচেয়ে সাধারণ কারণ: ডিপ্লয়মেন্টের পরে কোড রিগ্রেশন (34%), ক্লাউড প্রদানকারীর আউটেজ (22%), ডাটাবেস সমস্যা (18%), কনফিগারেশন ত্রুটি (15%) এবং DDoS আক্রমণ (11%)। মূল কথা: বেশিরভাগ ত্রুটি টিম নিজে যে পরিবর্তন করেছে তার কারণে ঘটে, বাহ্যিক কারণের কারণে নয়।

ক্র্যাশ (ক্লায়েন্টে অ্যাপ্লিকেশন ক্র্যাশ) এবং ব্যাকএন্ড আউটেজ (সার্ভার অনুপলব্ধ) এর মধ্যে পার্থক্য করা গুরুত্বপূর্ণ। ক্র্যাশ সাধারণত ক্লায়েন্ট কোডের হটফিক্স দিয়ে ঠিক করা হয়, যখন ব্যাকএন্ড আউটেজের জন্য পরিকাঠামো পরিবর্তন বা পরিষেবা পুনর্নিয়োগ প্রয়োজন। মনিটরিং মেট্রিক্স: ক্লায়েন্টের জন্য — ক্র্যাশ-মুক্ত হার, সার্ভারের জন্য — 5xx ত্রুটি হার এবং p95 লেটেন্সি। APM (অ্যাপ্লিকেশন পারফরম্যান্স মনিটরিং) — Sentry, New Relic, Datadog — ত্রুটির ধরণ দ্রুত নির্ধারণ করতে সাহায্য করে।

ঘটনার তীব্রতা: P0, P1, P2 এবং শ্রেণিবিন্যাসের মানদণ্ড

একীভূত তীব্রতা শ্রেণিবিন্যাস দ্রুত প্রতিক্রিয়ার ভিত্তি। এটি ছাড়া টিম “এটি কতটা জরুরি” নিয়ে আলোচনা করে সময় নষ্ট করে কর্মের পরিবর্তে। ক্লাসিক স্কেল: P0 (গুরুতর) — অ্যাপ্লিকেশন সম্পূর্ণভাবে অনুপলব্ধ বা ব্যবহারকারীর ডেটা লিক হচ্ছে, প্রতিক্রিয়া সময় — তাৎক্ষণিক; P1 (উচ্চ) — 50%+ ব্যবহারকারীর জন্য গুরুত্বপূর্ণ কার্যকারিতা ভাঙা, প্রতিক্রিয়া সময় — 15 মিনিট; P2 (মধ্য) — কিছু ব্যবহারকারীর জন্য অ-গুরুত্বপূর্ণ কার্যকারিতা অনুপলব্ধ, প্রতিক্রিয়া সময় — 1 ঘন্টা।

P0 তাত্ক্ষণিক এসকেলেশন প্রয়োজন: অন-কল ইঞ্জিনিয়ার যেকোনো চলমান কাজ বন্ধ করে ঘটনায় স্যুইচ করে। যদি 10 মিনিটের মধ্যে সমস্যা সমাধান না হয় — টেক লিড যুক্ত হয়। যদি 30 মিনিট পরে — ইঞ্জিনিয়ারিং ম্যানেজারের কাছে এসকেলেশন। P0 ঘটনার জন্য যেকোনো প্রক্রিয়া ভাঙা গ্রহণযোগ্য: সম্পূর্ণ কোড পর্যালোচনা ছাড়া হটফিক্স করা, সরাসরি প্রোডাকশনে ডিপ্লয় করা, ব্রাঞ্চ প্রোটেকশন নিয়ম উপেক্ষা করা। জরুরি ওভাররাইড টিম স্তরে আগেই সম্মত হতে হবে।

তীব্রতা সারণী

তীব্রতা কম আন্দাজ করার ভুল না করা অত্যন্ত গুরুত্বপূর্ণ। P2 হিসাবে শ্রেণিবদ্ধ P0 এবং P1 ঘটনা বিলম্বিত প্রতিক্রিয়া এবং বর্ধিত ডাউনটাইমের দিকে নিয়ে যায়। নিয়ম: যদি সন্দেহ হয় — P0 সেট করুন। অতিরিক্ত শ্রেণিবিন্যাস কম শ্রেণিবিন্যাসের চেয়ে ভাল: একটি অতিরিক্ত সভা আয়োজন করা পুনরুদ্ধারের এক ঘন্টা হারানোর চেয়ে ভাল।

প্রথম 10 মিনিট: ত্রুটির সময় কর্মপদ্ধতি

টাইমার শুরু হয়: যখন একটি সতর্কতা বা ব্যবহারকারীর কাছ থেকে বার্তা আসে। প্রথম 10 মিনিট সবচেয়ে গুরুত্বপূর্ণ। পদ্ধতি: 1) সমস্যা নিশ্চিত করুন — নিশ্চিত করুন যে সমস্যাটি বাস্তব (মিথ্যা অ্যালার্ম নয়); 2) রক্তপাত বন্ধ করুন — অবিলম্বে প্রভাব কমিয়ে দিন (রোলব্যাক, ফিচার টগল, এন্ডপয়েন্ট ব্লকিং); 3) যোগাযোগ — সাধারণ #incident চ্যানেলে লিখুন: কী ঘটেছে, তীব্রতা, কী করা হচ্ছে। প্রথম 10 মিনিট মূল কারণ বিশ্লেষণে ব্যয় করা হয় না।

রক্তপাত বন্ধ করার সমান্তরালে, একজন ইঞ্জিনিয়ার নির্ণয় শুরু করে এবং অন্যজন যোগাযোগ পরিচালনা করে। যোগাযোগের চ্যানেল: Slack #incident চ্যানেল (টিমের জন্য), স্থিতি পৃষ্ঠা (ব্যবহারকারীদের জন্য), ইমেল/SMS এসকেলেশন (পরিচালনার জন্য)। প্রতি 15 মিনিটে — তথ্য সহ স্থিতি আপডেট: কী জানা গেছে, কী করা হচ্ছে, আনুমানিক পুনরুদ্ধারের সময়। স্থিতি পৃষ্ঠা (StatusPage, Statuspal) বাহ্যিক ব্যবহারকারীদের জন্য আপটাইম এবং ঘটনার ইতিহাস প্রদর্শন করে।

কিভাবে রক্তপাত বন্ধ করবেন: রোলব্যাক, ফিচার টগল এবং হটফিক্স

প্রথম এবং সবচেয়ে গুরুত্বপূর্ণ নিয়ম: প্রোডাকশনে সমস্যা সমাধানের চেষ্টা করবেন না। যদি নতুন রিলিজ ত্রুটি সৃষ্টি করে — পূর্ববর্তী স্থিতিশীল সংস্করণে ফিরে যান। যদি একটি নির্দিষ্ট ফিচারের কারণে ত্রুটি ঘটে যা ফিচার টগলের পিছনে রয়েছে — কেবল টগল বন্ধ করুন। যদি রোলব্যাক বা টগল কোনটিই উপলব্ধ না হয় — ন্যূনতম diff সহ হটফিক্স প্রয়োগ করুন। রোলব্যাক সবচেয়ে নিরাপদ বিকল্প কারণ এটি একটি অবস্থায় ফিরে যায় যা ইতিমধ্যে কাজ করছিল।

ফিচার টগল (ওরফে ফিচার ফ্ল্যাগ) ডিপ্লয়মেন্ট ছাড়া রক্তপাত বন্ধ করার একটি শক্তিশালী হাতিয়ার। যদি পেমেন্ট মডিউল টগলের মাধ্যমে বন্ধ থাকে — ব্যবহারকারীরা ত্রুটি স্ক্রিন পাওয়ার পরিবর্তে কেবল পেমেন্ট বাটন দেখতে পায় না। টগলের বিল্ড প্রয়োজন নেই, স্টোর পর্যালোচনার প্রয়োজন নেই, এবং সেকেন্ডের মধ্যে কার্যকর হয়। প্রতিটি গুরুত্বপূর্ণ ফিচার সার্ভার-স্তরে (রিমোট কনফিগ) বন্ধ করার ক্ষমতা সহ ফিচার টগলের পিছনে থাকা উচিত। ফিচার ফ্ল্যাগ — প্রতিরক্ষার প্রথম লাইন।

যদি রোলব্যাক অসম্ভব হয় (যেমন, অপরিবর্তনীয় ডাটাবেস মাইগ্রেশনের কারণে) এবং কোন টগল না থাকে — শেষ উপায়: ন্যূনতম সংশোধন সহ হটফিক্স। হটফিক্স সর্বশেষ রিলিজ ট্যাগ থেকে তৈরি করা হয়, শুধুমাত্র ত্রুটি সমাধানের জন্য প্রয়োজনীয় লাইনগুলি ধারণ করে, এবং ফাস্ট-ট্র্যাক ডিপ্লয়মেন্টের মধ্য দিয়ে যায় (নিবন্ধ দেখুন “হটফিক্স — জরুরি সংশোধন”)। সোনার নিয়ম: স্থিতিশীলতার পরে, সর্বদা মূল কারণ বিশ্লেষণ করুন, এমনকি কারণ সুস্পষ্ট মনে হলেও।

কারণ নির্ণয়: লগ, মেট্রিক্স এবং সতর্কতা

রক্তপাত বন্ধ করার পরে (বা সমান্তরালে, যদি ইঞ্জিনিয়ারের সংখ্যা অনুমতি দেয়) নির্ণয় শুরু হয়। প্রথম উৎস — লগ। কেন্দ্রীভূত লগিং (ELK, Grafana Loki, Datadog Logs) টাইমস্ট্যাম্প, ব্যবহারকারী ID বা অনুরোধ ID দ্বারা ত্রুটি খুঁজে পেতে দেয়। গুরুত্বপূর্ণ: লগ কাঠামোবদ্ধ (JSON) হতে হবে যাতে grep দ্রুত কাজ করে। কাঠামোবদ্ধ লগিং সমস্ত পরিষেবার জন্য বাধ্যতামূলক প্রয়োজনীয়তা।

দ্বিতীয় উৎস — মেট্রিক্স। Grafana, Datadog, New Relic দেখায় কখন ত্রুটির স্পাইক ঘটেছে, কোন এন্ডপয়েন্টে এবং কোন স্ট্যাটাস কোড সহ। ডিপ্লয়মেন্টের আগে এবং পরে মেট্রিক্সের তুলনা একটি নির্দিষ্ট পরিষেবা বা এন্ডপয়েন্টে সমস্যা স্থানীয়করণে সহায়তা করে। RED মেট্রিক্স (Rate, Errors, Duration) — মাইক্রোসার্ভিসেস মনিটরিংয়ের মান।

তৃতীয় উৎস — বিতরণকৃত ট্রেসিং (distributed tracing)। Jaeger, Zipkin, Datadog APM মাইক্রোসার্ভিসেসের মাধ্যমে অনুরোধের পথ দেখায় এবং সনাক্ত করে যে বিলম্ব বা ত্রুটি কোথায় হয়েছে। ট্রেসিং বিশেষভাবে ক্যাসকেডিং ব্যর্থতায় কার্যকর, যখন একটি পরিষেবায় ত্রুটি সমস্ত নির্ভরশীল পরিষেবায় ত্রুটি সৃষ্টি করে। ট্রেস ID ক্লায়েন্ট থেকে সমস্ত ব্যাকএন্ড পরিষেবায় প্রেরণ করতে হবে।

# kubectl এবং লগ ব্যবহার করে দ্রুত নির্ণয়ের উদাহরণ
# ত্রুটিযুক্ত পড তালিকাভুক্ত করুন
kubectl get pods --field-selector=status.phase!=Running

# ক্র্যাশ হওয়া পডের লগ পরীক্ষা করুন
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# গত 30 মিনিটের জন্য পরিষেবায় ত্রুটি অনুসন্ধান করুন
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

গুরুত্বপূর্ণ: রক্তপাত বন্ধ করার আগে কারণ নির্ণয়ের চেষ্টা করবেন না। যদি 50% ব্যবহারকারী ক্র্যাশ দেখে — প্রথমে রোলব্যাক করুন, তারপর তদন্ত করুন। ব্যতিক্রম: যদি রোলব্যাকে সরাসরি হটফিক্সের চেয়ে বেশি সময় লাগে (যেমন, ডেটা অসঙ্গতির কারণে)। এই ক্ষেত্রে, অবিলম্বে হটফিক্স প্রয়োগ করুন এবং স্থিতিশীলতার পরে পোস্ট-মর্টেম করুন। সমাধানের আগে নির্ণয় একটি বিপজ্জনক প্যাটার্ন যা ডাউনটাইম বাড়ায়।

পোস্ট-মর্টেম: দোষ খুঁজে না পেয়ে ঘটনা পর্যালোচনা

পোস্ট-মর্টেম (ঘটনা পর্যালোচনাও বলা হয়) একটি কাঠামোবদ্ধ ঘটনা বিশ্লেষণ যা সমাধানের 24–72 ঘন্টা পরে পরিচালিত হয়। এর উদ্দেশ্য: বুঝতে কেন ত্রুটি ঘটেছে, কেন মনিটরিং এবং পরীক্ষা প্রোডাকশনের আগে এটি ধরতে পারেনি, এবং পুনরাবৃত্তি রোধ করতে প্রক্রিয়ায় কী পরিবর্তন করতে হবে। দোষমুক্ত সংস্কৃতি একটি মৌলিক নীতি: পোস্ট-মর্টেম প্রক্রিয়া, সরঞ্জাম এবং যোগাযোগ নিয়ে আলোচনা করে, নির্দিষ্ট ব্যক্তির ভুল নিয়ে নয়।

পোস্ট-মর্টেম নথির কাঠামো: সময়রেখা (টাইমস্ট্যাম্প সহ ঘটনার কালানুক্রম), প্রভাব (প্রভাবিত ব্যবহারকারী, সময়কাল, আর্থিক ক্ষতি), মূল কারণ (প্রযুক্তিগত মূল কারণ), সনাক্তকরণ (কিভাবে আবিষ্কৃত হয়েছে, কেন আগে ধরা পড়েনি), প্রতিক্রিয়া (কী করা হয়েছে, কী দ্রুত করা যেত), কর্ম (দায়িত্বশীল ব্যক্তি এবং সময়সীমা সহ নির্দিষ্ট কাজ)। কর্ম S.M.A.R.T. হতে হবে: নির্দিষ্ট, পরিমাপযোগ্য, নিযুক্তযোগ্য, বাস্তবসম্মত, সময়-বাঁধা।

প্রোডাকশন ত্রুটির পরে সাধারণ কর্ম: যে মেট্রিকটি নীরব ছিল তার জন্য মনিটরিং এবং সতর্কতা যোগ করা; বাদ পড়া ক্ষেত্রের জন্য পরীক্ষার কভারেজ সম্প্রসারণ; একই অবস্থার জন্য ধাপে ধাপে পদ্ধতি সহ রানবুকে একটি পৃষ্ঠা যোগ করা; যে সরঞ্জামটি ভুলভাবে ব্যবহার করা হয়েছিল তার উপর টিম প্রশিক্ষণ পরিচালনা। প্রতিটি কর্ম একটি কংক্রিট পরিবর্তন যা ঘটনার পুনরাবৃত্তির সম্ভাবনা হ্রাস করে।