एक वॉइस-रूटिंग सिस्टम का परीक्षण कर रहे एक डेवलपर ने एक अस्थायी क्वारंटाइन (quarantine) जोड़ा है, जो विफलता के बाद अगली कॉल को 300 सेकंड के लिए एक अलग पथ (path) का उपयोग करने के लिए मजबूर करता है। यह बदलाव सॉफ्टवेयर को बार-बार उसी खराब रूट को आज़माने से रोकता है, जिससे कैस्केड आउटेज (cascade outage) की संभावना कम हो जाती है।

पुरानी लॉजिक समस्या क्यों थी

मूल राउटर एक कठोर नियम का पालन करता था: जब कोई वर्कस्टेशन व्यस्त होता था, तो यह बस उसी पथ को फिर से आज़माता था। यदि वह पथ विफल होता रहा, तो सिस्टम त्रुटि (error) को लॉग करता था लेकिन अपने व्यवहार में कभी बदलाव नहीं करता था। व्यवहार में, विफलता का एक एकल बिंदु (single point of failure) कॉल को ब्लॉक करना जारी रख सकता था क्योंकि सॉफ्टवेयर बार-बार उसी बंद रास्ते (dead end) पर घूमता रहता था।

नया क्वारंटाइन तंत्र

यह अपडेट तीन प्रतिबंध जोड़ता है:

  • स्थायी नहीं – क्वारंटाइन मार्कर एक छोटे अंतराल के बाद समाप्त हो जाता है।
  • ग्लोबल नहीं – यह केवल उस विशिष्ट पथ पर लागू होता है जो विफल हुआ है, न कि हर रूट पर।
  • सीमित मेमोरी – सिस्टम विफलता को एक स्थानीय फ़ाइल में रिकॉर्ड करता है और एक बार नया पथ सफल हो जाने पर उसे भूल जाता है।

जब स्पीच का प्रयास विफल होता है, तो राउटर उस पथ के लिए एक “quarantined” फ्लैग लिख देता है। अगले 300 सेकंड के लिए, कोई भी इनकमिंग रिक्वेस्ट स्वचालित रूप से एक वैकल्पिक पथ पर रीरूट हो जाती है। जैसे ही किसी अलग रूट पर रिक्वेस्ट सफल होती है, फ्लैग हट जाता है, जिससे यह सुनिश्चित होता है कि सुधार (fix) ज़रूरत से ज़्यादा समय तक न बना रहे।

लाभ और ट्रेड-ऑफ

प्राथमिक लाभ लचीलापन (resilience) है: एक क्षणिक खराबी अब पूरी सेवा को बाधित नहीं करती है। क्वारंटाइन को पांच मिनट तक सीमित करके, सिस्टम लंबी अवधि की सेवा हानि से बचता है और साथ ही नेटवर्क को रिकवर होने के लिए समय भी देता है।

इस दृष्टिकोण में जोखिम भी है। नेटवर्क में एक छोटी सी रुकावट क्वारंटाइन को ट्रिगर कर सकती है जो कॉल को कम अनुकूल (less optimal) रूट पर जाने के लिए मजबूर करती है, जिससे लेटेंसी (latency) या लागत बढ़ सकती है। यदि वैकल्पिक पथ भी खराब हो जाता है, तो सिस्टम रूट्स के बीच उछल सकता है, जिससे अस्थिरता पैदा हो सकती है। ऑपरेटरों को क्वारंटाइन मार्करों की जानकारी होनी चाहिए ताकि वे बता सकें कि रीरूट जानबूझकर किया गया है या यह किसी गहरी समस्या का लक्षण है।

आगे क्या देखें

  • मेट्रिक्स (Metrics): यह देखने के लिए क्वारंटाइन की आवृत्ति (frequency) और अवधि की निगरानी करें कि क्या 300 सेकंड की विंडो उपयुक्त है।
  • स्कोप (Scope): टीमें इस लॉजिक को अन्य सेवाओं तक विस्तारित करने का प्रयास कर सकती हैं जो स्टैटिक रिट्राय पैटर्न (static retry patterns) से प्रभावित होती हैं।
  • ऑटोमेशन (Automation): जब कोई पथ बार-बार क्वारंटाइन में जाता है, तो अलर्ट जोड़ें ताकि उपयोगकर्ता समस्या पर ध्यान देने से पहले ही सक्रिय रखरखाव (proactive maintenance) किया जा सके।

मुख्य सबक सरल है: एक सिस्टम जो अपनी हालिया विफलताओं को रिकॉर्ड नहीं करता है, वह बदलते परिवेश के अनुकूल नहीं हो सकता है। विफलता के इतिहास को दृश्यमान बनाकर और उस पर—अस्थायी रूप से—कार्रवाई करके, इंजीनियर पूर्ण-स्तरीय रीडिज़ाइन की प्रतीक्षा किए बिना वॉइस सेवाओं को सुचारू रूप से चलाते रहते हैं।

स्रोत: dev.to पर मूल डेवलपर पोस्ट।

चर्चा में शामिल हों: https://t.me/GyaanSetuAi