پبلش کے فوراً بعد کریش ہونے والی ایپس کو پکڑنا

25 ستمبر کو تین پبلشز کو کامیاب قرار دیا گیا حالانکہ ایپ کا API ہر boot کے چند سیکنڈ بعد کریش ہو رہا تھا۔ چونکہ وہ "کامیاب" ہوئے، کوئی rollback نہیں چلا؛ چند منٹ بعد ایک پس منظر کی جانچ نے انہیں ناکام قرار دیا، اور پوری سائٹ 404 پر چلی گئی۔ ہیلتھ چیک کریشوں کو ہوسٹنگ پلیٹ فارم کی event فہرست میں گن رہا تھا، جو ہر مشین کے صرف آخری پانچ events رکھتی ہے، تو کریش loop اسے بھرا رکھتا تھا اور گنتی کبھی نہیں بڑھتی تھی۔ اب وہ اس کے بجائے سب سے نئے کریش کا وقت موازنہ کرتا ہے، اور کریش ہونے والی پبلش ناکام ہوتی ہے اور پچھلا ورژن بحال ہو جاتا ہے۔

پبلش کس چیز کا انتظار کرتی ہے

جب آپ Mythex پر backend والی ایپ پبلش کرتے ہیں، تو نیا ورژن ہمارے ہوسٹنگ پلیٹ فارم کی مشینوں پر رول آؤٹ ہوتا ہے، اور ایک ہیلتھ چیک فیصلہ کرتا ہے کہ پبلش لائیو ہوئی یا ناکام۔ اگر ناکام ہو تو rollback پچھلا ورژن واپس لاتا ہے۔

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

1. دو بار دیکھیں۔ مشین کو شروع ہوا پڑھنے کے بعد، تھوڑی دیر رکیں اور دوبارہ دیکھیں۔ boot پر کریش اکثر دوسری نظر میں ناکام ہو جاتا ہے۔
2. کریش loops پر نظر رکھیں۔ اگر پلیٹ فارم رپورٹ کرے کہ ایک مشین بار بار کریش ہوئی اور اس نے دوبارہ شروع کرنا چھوڑ دیا، تو ناکام ہو جائیں۔
3. پبلش شروع ہونے کے بعد کے کریش گنیں۔ دو "شروع ہوا" نظارے ایک restart کے دونوں طرف ہو سکتے ہیں۔ تو اگر اس پبلش کے شروع ہونے کے بعد کوئی کریش ہوا ہو، تو تیسری بار دیکھیں؛ اگر پچھلی نظر سے زیادہ کریش ہوں، تو ایپ سروس پر قائم نہیں۔

تیسری جانچ ہی یہاں ناکام ہوئی۔

گنتی کیوں جمی رہی

کریش کی معلومات ہر مشین کی event فہرست سے آتی ہے: شروع ہونا، بند ہونا، دوبارہ شروع ہونا۔ پلیٹ فارم ہر مشین کے صرف آخری پانچ events رکھتا ہے۔

تصور کریں ایک ایپ جو ہر boot کے 2.5 سیکنڈ بعد کریش ہوتی ہے، جیسا کہ ان میں سے ایک کرتی تھی۔ ہر چکر ایک کریش اور ایک start کا اضافہ کرتا ہے۔ دو چکروں کے بعد فہرست بھر جاتی ہے۔ اس کے بعد ہر نیا event ایک پرانا event باہر دھکیل دیتا ہے۔ فہرست آگے کھسکتی ہے، مگر ہمیشہ تقریباً ایک ہی مرکب رکھتی ہے: دو کریش، دو starts۔

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

یہ 25 ستمبر کو تین بار ہوا، دو ایپس پر۔ ہر بار:

• پبلش لائیو نشان زد ہوئی،
• کوئی rollback نہیں چلا، کیونکہ کچھ ناکام نہیں ہوا تھا،
• ہمارے reconciler نے، ایک پس منظر کا job جو deployments کو بعد میں چیک کرتا ہے، چند منٹ بعد deployment کو ناکام قرار دیا،
• اور پوری سائٹ 404 لوٹانے لگی۔

وقت پر ناکام ہونے والی پبلش قابلِ بحالی ہے: rollback پچھلا ورژن واپس لاتا ہے۔ وہ پبلش جو کامیاب قرار دیے جانے کے کچھ منٹ بعد ناکام ہو، اپنا rollback پہلے ہی چھوڑ چکی ہوتی ہے۔

ہم نے اسے کیسے پکڑا

ہم نے مقامی طور پر دوبارہ بنایا: ایک کام کرنے والی API لی، اسے سونے دیا، پھر ایک ایسی تبدیلی کے ساتھ ری پبلش کیا جو boot پر کریش ہوتی تھی۔ ہیلتھ چیک نے اسے لائیو نشان زد کر دیا۔

یہ پیداوار سے میل کھاتا تھا: تینوں پبلشز میں ایپ ہر boot کے چند سیکنڈ بعد مری، پھر بھی کریش کی گنتی، جس کا موازنہ چیک کرتا تھا، دو نظاروں کے درمیان کبھی نہیں بڑھی۔

اصلاح: گنتی کے بجائے سب سے نئے کریش کا موازنہ

کریشوں کو گننے کے بجائے اب چیک سب سے حالیہ کریش کا وقت دیکھتا ہے، پبلش شروع ہونے کے بعد سے۔

اگر دوسری نظر میں پبلش کے شروع ہونے کے بعد کوئی بھی کریش دکھے، تو چیک رکتا ہے اور تیسری بار دیکھتا ہے۔ اگر تیسری نظر پر سب سے نیا کریش دوسری نظر کے سب سے نئے کریش سے بعد کا ہو، تو مشین اس دوران دوبارہ کریش ہوئی۔ وہ قائم نہیں رہ رہی، اور پبلش اس پیغام کے ساتھ ناکام ہوتی ہے کہ مشین پبلش کے بعد بار بار کریش ہوئی اور اب بھی دوبارہ شروع ہو رہی ہے۔

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

اس تبدیلی کے ساتھ، مقامی دوبارہ تخلیق درست برتاؤ کرتی ہے: پبلش ناکام ہوتی ہے، اور پچھلی image بحال ہوتی ہے۔ ایک test بھی ہے جو پلیٹ فارم کے برتاؤ کی نقل کرتا ہے، یعنی ہر نظر ایک کریش اور ایک start شامل کرتی ہے اور فہرست کو پانچ تک کاٹتی ہے، اور جانچتا ہے کہ فیصلہ ناکامی ہے، کامیابی نہیں۔

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

• جس ڈیٹا کو آپ گن رہے ہیں اس کی شکل جانیں۔ محدود فہرست پر گنتی اس وقت بے معنی ہو جاتی ہے جب فہرست بھر جائے۔ حد چھپی نہیں تھی؛ ہم نے چیک کو اس کے گرد ڈیزائن ہی نہیں کیا تھا۔
• "کچھ نیا ہوا؟" کو "کتنے ہوئے؟" پر ترجیح دیں۔ سب سے نیا timestamp کاٹے جانے کے بعد بھی بچتا ہے۔ کل تعداد نہیں بچتی۔
• دیر سے ناکامی جلدی ناکامی سے بدتر ہے۔ وہی خراب build بے ضرر ہے اگر پبلش ناکام ہو اور rollback ہو، اور سائٹ گرا دیتا ہے اگر پہلے کامیاب قرار پائے۔
• حقیقی حالات کے ساتھ دوبارہ بنائیں۔ بگ کے لیے ایک ایسی مشین درکار تھی جو پہلے ہی اتنی بار کریش ہو چکی ہو کہ اس کی event فہرست بھر جائے۔ test میں ایک ہی فوری کریش یہ نہ دکھاتا۔

یہ اصلاح اسی دن کی ایک اور اصلاح کے ساتھ جڑتی ہے، جس نے یقینی بنایا کہ rollback پرانا ورژن واپس لائے، نہ کہ اسے حذف کرے: ناکام ری پبلش کبھی کام کرنے والا بیک اینڈ نہیں مٹاتی۔ اگر آپ کی اپنی ایپ start پر کریش ہونے کی وجہ سے پبلش نہیں ہوتی، تو پبلش ٹربل شوٹنگ docs اور AI سے بنی ایپ کو ڈیبگ کرنے کا guide اچھی جگہیں ہیں۔