ایک ڈویلپر جو وائس-روٹنگ سسٹم کی جانچ کر رہا تھا، اس نے ایک عارضی کوارنٹائن (quarantine) شامل کیا ہے جو کسی ناکامی کے بعد اگلے 300 سیکنڈ تک اگلی کال کو ایک مختلف راستہ استعمال کرنے پر مجبور کرتا ہے۔ یہ تبدیلی سافٹ ویئر کو بار بار اسی خراب راستے کو آزمانے سے روکتی ہے، جس سے سلسلہ وار خرابی (cascade outage) کے امکان کو کم کیا جا سکتا ہے۔

پرانی منطق (logic) کیوں ایک مسئلہ تھی

اصل روٹر ایک سخت اصول پر عمل کرتا تھا: جب کوئی ورک اسٹیشن مصروف ہوتا، تو یہ محض اسی راستے کو دوبارہ آزمانے کی کوشش کرتا۔ اگر وہ راستہ بار بار ناکام ہوتا، تو سسٹم غلطی (error) کو ریکارڈ تو کرتا لیکن اپنے طرزِ عمل میں کبھی تبدیلی نہیں لاتا تھا۔ عملی طور پر، ناکامی کا ایک ہی نقطہ کالز کو بلاک کرتا رہ سکتا تھا کیونکہ سافٹ ویئر بار بار اسی بند راستے پر چکر لگاتا رہتا تھا۔

نیا کوارنٹائن میکانزم

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

  • مستقل نہیں – کوارنٹائن مارکر ایک مختصر وقت کے بعد ختم ہو جاتا ہے۔
  • عالمی (global) نہیں – یہ صرف اس مخصوص راستے پر لاگو ہوتا ہے جو ناکام ہوا ہو، تمام راستوں پر نہیں۔
  • محدود میموری – سسٹم ناکامی کو ایک مقامی فائل میں ریکارڈ کرتا ہے اور جیسے ہی نیا راستہ کامیاب ہو جاتا ہے، اسے بھول جاتا ہے۔

جب اسپیچ (speech) کی کوشش ناکام ہوتی ہے، تو روٹر اس راستے کے لیے ایک "quarantined" فلیگ لکھ دیتا ہے۔ اگلے 300 سیکنڈ تک، کوئی بھی آنے والی درخواست خود بخود متبادل راستے پر موڑ دی جاتی ہے۔ جیسے ہی کسی مختلف راستے پر درخواست کامیاب ہوتی ہے، فلیگ ختم ہو جاتا ہے، جس سے یہ یقینی بنایا جاتا ہے کہ یہ حل ضرورت سے زیادہ دیر تک برقرار نہ رہے۔

فوائد اور نقصانات (trade-offs)

اس کا بنیادی فائدہ لچک (resilience) ہے: اب کوئی عارضی خرابی پورے سروس کو مفلوج نہیں کر سکتی۔ کوارنٹائن کو پانچ منٹ تک محدود کر کے، سسٹم طویل مدتی سروس کے نقصان سے بچتا ہے اور ساتھ ہی نیٹ ورک کو بحال ہونے کے لیے وقت بھی دیتا ہے۔

اس طریقے میں خطرہ بھی ہے۔ نیٹ ورک میں ایک معمولی سی خرابی کوارنٹائن کو متحرک کر سکتی ہے جو کالز کو کم تر راستے پر بھیجنے پر مجبور کرے، جس سے لیٹنسی (latency) یا لاگت بڑھ سکتی ہے۔ اگر متبادل راستہ بھی خراب ہو جائے، تو سسٹم مختلف راستوں کے درمیان جھول سکتا ہے، جس سے عدم استحکام پیدا ہو سکتا ہے۔ آپریٹرز کو کوارنٹائن مارکرز کی معلومات ہونی چاہیے تاکہ وہ جان سکیں کہ راستہ بدلنا جان بوجھ کر کیا گیا ہے یا یہ کسی گہرے مسئلے کی علامت ہے۔

آگے کیا دیکھنا ہے

  • میٹرکس (Metrics): کوارنٹائن کی تعدد (frequency) اور دورانیے کی نگرانی کریں تاکہ دیکھا جا سکے کہ کیا 300 سیکنڈ کا وقفہ مناسب ہے۔
  • دائرہ کار (Scope): ٹیمیں اس منطق کو دیگر سروسز تک بڑھانے کی کوشش کر سکتی ہیں جو جامد ری ٹرائی پیٹرنز (static retry patterns) سے متاثر ہوتی ہیں۔
  • آٹومیشن (Automation): جب کوئی راستہ بار بار کوارنٹائن میں جائے تو الرٹس شامل کریں تاکہ صارفین کے مسئلہ محسوس کرنے سے پہلے ہی فعال دیکھ بھال (proactive maintenance) کی جا سکے۔

بنیادی سبق سادہ ہے: ایک ایسا سسٹم جو اپنی حالیہ ناکامیوں کو ریکارڈ نہیں کرتا، وہ بدلتے ہوئے ماحول کے مطابق خود کو ڈھال نہیں سکتا۔ ناکامی کی تاریخ کو واضح کر کے اور اس پر عارضی طور پر عمل کر کے، انجینئرز مکمل ری ڈیزائن کا انتظار کیے بغیر وائس سروسز کو ہموار طریقے سے چلتے رکھتے ہیں۔

ماخذ: dev.to پر اصل ڈویلپر پوسٹ۔

بحث میں شامل ہوں: https://t.me/GyaanSetuAi