ڈویلپمنٹ میں پروڈکشن میں آگ لگی — یہ کیا ہے، اسباب اور عمل کا طریقہ کار

«پروڈکشن میں آگ لگی» کا مطلب اور خرابیوں کی اقسام

عبارت «پروڈکشن میں آگ لگی» (سب کچھ ڈاؤن ہے) ایک ایسی صورتحال بیان کرتی ہے جہاں پروڈکشن ماحول صحیح طریقے سے کام نہیں کر رہا اور صارفین متاثر ہو رہے ہیں۔ خرابی ایپلیکیشن کی مکمل عدم دستیابی (خالی اسکرین، 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) بیرونی صارفین کے لیے اپ ٹائم اور واقعات کی تاریخ دکھاتا ہے۔

خون کیسے روکیں: رول بیک، فیچر ٹوگل اور ہاٹ فکس

پہلا اور سب سے اہم قاعدہ: پروڈکشن پر مسئلہ حل کرنے کی کوشش نہ کریں۔ اگر نئے ریلیز نے خرابی پیدا کی — پچھلے مستحکم ورژن پر واپس جائیں۔ اگر خرابی ایک مخصوص فیچر کی وجہ سے ہے جو فیچر ٹوگل کے پیچھے ہے — بس ٹوگل بند کریں۔ اگر نہ رول بیک اور نہ ٹوگل دستیاب ہے — کم سے کم تبدیلی کے ساتھ ہاٹ فکس لگائیں۔ رول بیک سب سے محفوظ آپشن ہے کیونکہ یہ ایسی حالت میں واپس جاتا ہے جو پہلے سے کام کر رہی تھی۔

فیچر ٹوگل (جسے فیچر فلیگ بھی کہا جاتا ہے) ڈیپلائمنٹ کے بغیر خون روکنے کا ایک طاقتور ذریعہ ہے۔ اگر ادائیگی کا ماڈیول ٹوگل کے ذریعے بند ہے — صارفین خرابی کی اسکرین حاصل کرنے کے بجائے صرف ادائیگی کا بٹن نہیں دیکھتے۔ ٹوگل کو بلڈ کی ضرورت نہیں، اسٹور ریویو کی ضرورت نہیں، اور سیکنڈوں میں مؤثر ہوتا ہے۔ ہر اہم فیچر سرور کی سطح (ریموٹ کنفیگ) پر بند کرنے کی صلاحیت کے ساتھ فیچر ٹوگل کے پیچھے ہونا چاہیے۔ فیچر فلیگ — دفاع کی پہلی لائن۔

اگر رول بیک ناممکن ہو (مثلاً، ناقابل واپسی ڈیٹا بیس مائیگریشن کی وجہ سے) اور کوئی ٹوگل نہ ہو — آخری حربہ: کم سے کم تبدیلی کے ساتھ ہاٹ فکس۔ ہاٹ فکس تازہ ترین ریلیز ٹیگ سے بنایا جاتا ہے، صرف خرابی دور کرنے کے لیے ضروری لائنیں رکھتا ہے، اور تیز رفتار ڈیپلائمنٹ سے گزرتا ہے (مضمون دیکھیں «ہاٹ فکس — فوری اصلاحات»)۔ سنہری قاعدہ: استحکام کے بعد، ہمیشہ بنیادی وجہ کا تجزیہ کریں، چاہے وجہ واضح نظر آئے۔

وجوہات کی تشخیص: لاگز، میٹرکس اور الرٹس

خون روکنے کے بعد (یا متوازی طور پر، اگر انجینئرز کی تعداد اجازت دے) تشخیص شروع ہوتی ہے۔ پہلا ذریعہ لاگز ہیں۔ مرکزی لاگنگ (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. ہونے چاہئیں: مخصوص، قابل پیمائش، قابل تفویض، حقیقت پسندانہ، وقت کی پابند۔

پروڈکشن خرابی کے بعد عام اقدامات: اس میٹرک کے لیے نگرانی اور الرٹ شامل کریں جو خاموش تھی؛ چھوٹ گئے کیس کے لیے ٹیسٹ کوریج بڑھائیں؛ اسی طرح کی صورتحال کے لیے مرحلہ وار طریقہ کار کے ساتھ رن بک میں صفحہ شامل کریں؛ اس ٹول پر ٹیم کی تربیت کا انعقاد کریں جو غلط استعمال ہوا تھا۔ ہر اقدام ایک ٹھوس تبدیلی ہے جو واقعے کے دوبارہ ہونے کے امکان کو کم کرتی ہے۔