ناکام ری پبلش کبھی کام کرنے والا بیک اینڈ نہیں مٹاتی

25 ستمبر کو ایک ناکام ری پبلش نے ایک ایپ کا بیک اینڈ حذف کر دیا جو تقریباً ڈھائی گھنٹے سے لائیو اور ٹھیک کام کر رہا تھا۔ ناکام پبلش کو واپس لینے والا کوڈ ہر اس سرور ایپ کو ہٹا دیتا تھا جسے پبلش نے چھوا تھا، بشمول وہ ایپس جو پبلش شروع ہونے سے پہلے ہی سروس دے رہی تھیں۔ اب صرف وہی ایپس حذف ہوتی ہیں جو کسی پبلش نے بنائی ہوں؛ جو ایپ پہلے سے موجود تھی اسے ٹھیک اسی ورژن پر واپس لایا جاتا ہے جو وہ پہلے چلا رہی تھی۔ اسی دن کی دو مزید اصلاحات نے یقینی بنایا کہ یہ واپسی اس وقت بھی چلے جب ہوسٹنگ پلیٹ فارم کا اپنا ڈپلائے ٹول ناکام ہو، اور یہ کہ ایک صحت مند ایپ صرف اس لیے ناکام قرار نہ پائے کہ وہ سو رہی تھی۔

بیک اینڈ کیسے پبلش ہوتا ہے

جب آپ کی Mythex ایپ کا بیک اینڈ ہو، یعنی API یا سرور جو صرف static فائلوں کے بجائے کچھ اور چلائے، تو پبلش اسے Dockerfile (ایک نسخہ جو ایپ کو image میں پیک کرتا ہے) سے بناتا ہے اور اس image کو ہمارے ہوسٹنگ پلیٹ فارم کی مشینوں پر رول آؤٹ کرتا ہے۔ پھر ایک ہیلتھ چیک انتظار کرتا ہے کہ نیا ورژن واقعی اٹھ کر چل پڑے اور چلتا رہے، اس کے بعد ہی پبلش کو لائیو قرار دیا جاتا ہے۔

اس راستے میں کچھ بھی ناکام ہو تو اسے واپس لینے کے لیے rollback چلتا ہے۔ یہ rollback درست ہونا کسی بھی دوسری چیز سے زیادہ اہم ہے، کیونکہ یہ عین اس وقت چلتا ہے جب پہلے ہی کچھ غلط ہو رہا ہو۔

مسئلہ 1: rollback نے وہ مٹا دیا جسے بحال کرنا تھا

Rollback ان سرور ایپس کی فہرست رکھتا تھا جن پر پبلش نے ڈپلائے کیا تھا، اور ناکامی پر ان سب کو تباہ کر دیتا تھا۔ پہلی پبلش کے لیے یہ درست ہے: ایپ ابھی ابھی بنی ہے، اس پر کچھ منحصر نہیں، اور اسے حذف کرنے سے سب کچھ پہلے جیسا ہو جاتا ہے۔

ری پبلش کے لیے یہ بالکل غلط ہے۔ ایپ پہلے سے موجود تھی اور حقیقی visitors کو سروس دے رہی تھی۔ 25 ستمبر کو، ایک ناکام ری پبلش نے ایک ایپ کی API حذف کر دی جو تقریباً ڈھائی گھنٹے سے لائیو تھی۔

اسی کوڈ میں ایک دوسری ناکامی بھی چھپی تھی۔ جہاں حذف نہیں ہو پاتا تھا، وہاں خراب نئی image مشینوں پر رہ جاتی تھی، جبکہ ہم مالک کو بتا رہے تھے کہ موجودہ سائٹ ابھی بھی لائیو ہے۔ جب تک ہیلتھ چیک ناکام ہو سکے، نئی image پہلے ہی ہر مشین پر رول آؤٹ ہو چکی ہوتی ہے۔ کچھ نہ کرنا، واپس لینے کے برابر نہیں ہے۔

اصلاح: صرف وہ حذف کرو جو بنایا گیا، باقی بحال کرو

اب ہر پبلش، ہر سرور ایپ کے لیے جسے وہ چھوتی ہے، یہ ریکارڈ کرتی ہے:

• کیا اس پبلش نے اسے بنایا تھا، اور
• اگر نہیں، تو پہلے کون سی image چل رہی تھی۔

ناکامی پر ہر ایپ کو تین میں سے ایک طریقہ ملتا ہے:

1. اس پبلش نے بنائی: پہلے کی طرح تباہ کر دو۔
2. پہلے سے موجود تھی، پچھلی image معلوم ہے: وہی پچھلی image اسی configuration کے ساتھ دوبارہ ڈپلائے کرو۔ کوئی build نہیں، صرف image واپس جاتی ہے۔
3. پہلے سے موجود تھی، پچھلی image معلوم نہیں: اسے ہاتھ نہ لگاؤ۔ موجودہ ایپ کبھی حذف نہیں ہوتی، چاہے ہم اسے بحال نہ کر سکیں۔

یہ قواعد ایک چھوٹا خالص function ہیں جن کے اپنے tests ہیں، تاکہ فیصلہ دوبارہ "سب کچھ تباہ کرو" کی طرف نہ جا سکے بغیر کسی test کے ناکام ہوئے۔

مسئلہ 2: ڈپلائے ٹول واپسی کا طریقہ لکھنے سے پہلے ہی ناکام ہو سکتا تھا

اس اصلاح کے فوراً بعد ہمیں اس میں ایک خلا ملا۔ ہوسٹنگ پلیٹ فارم کا ڈپلائے ٹول اپنے smoke checks خود چلاتا ہے: اگر نئی مشینیں کریش ہوں تو وہ error کے ساتھ باہر آ جاتا ہے۔ لیکن یہ کام نئی image کے مشینوں پر آ جانے کے بعد ہوتا ہے۔

ہمارا کوڈ کسی ایپ کو rollback کی فہرست میں اس وقت درج کرتا تھا جب ٹول کامیابی سے واپس آتا۔ جب خود ٹول ڈپلائے کو ناکام کرتا، تو ایپ ابھی فہرست میں نہیں ہوتی تھی، اس لیے کچھ بھی بحال نہیں ہوتا تھا۔ ہمارے staging ماحول میں، ایک خراب ری پبلش نے خراب image کو ہی سروس جاری رکھنے دیا۔

اصلاح: شروع کرنے سے پہلے واپسی درج کرو

ایپ اب rollback کے لیے اسی وقت درج ہو جاتی ہے، جب وہ تیار ہو اور اس پر کچھ بھی رول آؤٹ ہونے سے پہلے، اس معلومات کے ساتھ کہ آیا وہ بنائی گئی تھی اور اس نے کون سی image چلائی تھی۔ بعد میں جو بھی ناکام ہو، rollback جانتا ہے کہ کیا واپس رکھنا ہے۔ ہم نے مقامی طور پر تصدیق کی: ایک خراب ری پبلش ڈپلائے ٹول کے اپنے smoke checks میں ناکام ہوئی، اور پچھلا ورژن جواب دیتا رہا۔

مسئلہ 3: سوئی ہوئی ایپ کو "کبھی شروع نہیں ہوئی" کہہ کر ناکام قرار دیا گیا

Mythex پر پبلش شدہ ایپس بیکار ہونے پر سو جاتی ہیں تاکہ آپ کے credits بچیں۔ ری پبلش سوئی ہوئی مشین کو بند چھوڑ دیتی ہے، اس لیے ہیلتھ چیک کو اسے جگانا پڑتا ہے۔ وہ پلیٹ فارم سے مشین شروع کرنے کو ایک بار کہتا تھا، اور جواب کو نظر انداز کر دیتا تھا۔

25 ستمبر کو وہ ایک شروع کرنے کی درخواست کہیں نہ پہنچی۔ ایک صحت مند API پورے پانچ منٹ کے ہیلتھ چیک تک بند پڑی رہی اور "1 machine never started (last state: stopped)" کے ساتھ ناکام قرار دی گئی۔

پلیٹ فارم کبھی کبھی شروع کرنے سے انکار بھی کرتا ہے۔ اس مسئلے کو دوبارہ بناتے ہوئے، اس نے ہمارے اکسائے بغیر "lease currently held" کا conflict لوٹایا، اور جب مشین اپ ڈیٹ ہو رہی ہو تو وہ شروع کرنے سے انکار کر دیتا ہے۔

اصلاح: پوچھتے رہو، اور دروازہ کھٹکھٹاؤ

اب ہیلتھ چیک:

• انتظار کے دوران ہر 20 سیکنڈ بعد بند مشین کو دوبارہ شروع کرنے کی درخواست کرتا ہے،
• جب پلیٹ فارم انکار کرے تو اس کا جواب لاگ کرتا ہے، اور
• ایپ کو ایک عام request بھیجتا ہے، جیسے کوئی visitor بھیجے؛ پلیٹ فارم کا proxy جب request آتی ہے تو سوئی ہوئی مشین کو جگا دیتا ہے۔

ہم نے اصل پلیٹ فارم پر ایک عارضی ایپ سے اسے دوبارہ بنایا جس کا پہلا start انکار ہوا۔ اصلاح سے پہلے، پبلش 91 سیکنڈ کے بعد ناکام ہوئی۔ اس کے بعد، وہ 20 سیکنڈ میں شائع ہو گئی۔ وہ ایپ جو boot پر واقعی کریش ہوتی ہے، اب بھی ناکام ہوتی ہے، جیسا کہ ہونا چاہیے۔

ہم نے اس سے کیا سیکھا

• Rollback کو نئے اور موجود میں فرق جاننا ہوگا۔ جو چیز آپ نے بنائی اس کے لیے "undo" کا مطلب حذف ہے۔ جو پہلے سے موجود تھی اس کے لیے "undo" کا مطلب بحالی ہے۔ دونوں کو ایک جیسا سمجھنا ہی وہ طریقہ ہے جس سے کوئی حفاظتی نظام کام کرنے والی ایپ حذف کر دیتا ہے۔
• کارروائی سے پہلے لکھ لو کہ واپسی کیسے ہوگی۔ اگر undo صرف اس وقت ریکارڈ ہو جب کوئی قدم کامیاب ہو، تو آدھے راستے پر ناکام ہونے والا قدم واپس لینے کے لیے کچھ نہیں چھوڑتا۔
• جس درخواست پر آپ کا انحصار ہو، اس کا جواب کبھی نظر انداز نہ کرو۔ ایک نظر انداز کیا ہوا "نہیں" ایک صحت مند ایپ کو ناکام پبلش میں بدل دیتا ہے۔

اسی دن کی ایک متعلقہ اصلاح: پبلش کے فوراً بعد کریش ہونے والی ایپس کو پکڑنا۔ جب آپ کی طرف سے پبلش ناکام ہو تو کیا ہوتا ہے، اس کے لیے docs میں پبلش ٹربل شوٹنگ دیکھیں۔