व्हॉइस-राउटिंग सिस्टमची चाचणी घेणाऱ्या एका डेव्हलपरने एक तात्पुरती 'क्वारंटाईन' (quarantine) यंत्रणा जोडली आहे, जी अपयशानंतर पुढील कॉल ३०० सेकंदांसाठी वेगळ्या मार्गाचा वापर करण्यास भाग पाडते. या बदलामुळे सॉफ्टवेअर वारंवार तोच खराब मार्ग वापरण्याचा प्रयत्न करणे थांबवते, ज्यामुळे 'कॅस्केड आउटेज' (cascade outage) होण्याची शक्यता कमी होते.

जुने लॉजिक समस्यादायक का होते

मूळ राउटर एका कडक नियमाचे पालन करत असे: जेव्हा एखादे वर्कस्टेशन व्यस्त असे, तेव्हा ते पुन्हा तोच मार्ग वापरण्याचा प्रयत्न करत असे. जर तो मार्ग वारंवार निकामी ठरत असेल, तर सिस्टम त्रुटी (error) नोंदवत असे परंतु आपल्या वर्तनात कोणताही बदल करत नसे. प्रत्यक्षात, एकाच ठिकाणी बिघाड (single point of failure) झाल्यामुळे कॉल्स ब्लॉक होऊ शकत होते, कारण सॉफ्टवेअर वारंवार त्याच बंद मार्गावर फिरत राहत असे.

नवीन क्वारंटाईन यंत्रणा

या अपडेटमध्ये तीन मर्यादा जोडल्या आहेत:

  • कायमस्वरूपी नाही – क्वारंटाईन मार्कर एका ठराविक कालावधीनंतर संपतो.
  • ग्लोबल नाही – हे केवळ निकामी झालेल्या विशिष्ट मार्गाला लागू होते, सर्व मार्गांना नाही.
  • मर्यादित मेमरी – सिस्टम अपयश एका स्थानिक फाईलमध्ये नोंदवते आणि नवीन मार्ग यशस्वी होताच ते विसरून जाते.

जेव्हा स्पीच अटेंप्ट (speech attempt) अयशस्वी होतो, तेव्हा राउटर त्या मार्गासाठी “quarantined” फ्लॅग लिहितो. पुढील ३०० सेकंदांसाठी, कोणताही येणारा विनंती (request) आपोआप पर्यायी मार्गावर वळवला जातो. एकदा का वेगळ्या मार्गावर विनंती यशस्वी झाली की, तो फ्लॅग निघून जातो, ज्यामुळे ही सुधारणा गरजेपेक्षा जास्त काळ टिकत नाही याची खात्री होते.

फायदे आणि तोटे

याचा मुख्य फायदा म्हणजे लवचिकता (resilience): तात्पुरत्या बिघाडामुळे आता संपूर्ण सेवा ठप्प होत नाही. क्वारंटाईन पाच मिनिटांपर्यंत मर्यादित ठेवून, सिस्टम दीर्घकालीन सेवा नुकसान टाळते आणि नेटवर्कला सावरण्यासाठी वेळ देते.

या पद्धतीत जोखीम देखील आहे. नेटवर्कमधील थोड्याशा अडथळ्यामुळे क्वारंटाईन सुरू होऊ शकते, ज्यामुळे कॉल्स कमी चांगल्या मार्गावर वळवले जाऊ शकतात, परिणामी लॅटन्सी (latency) किंवा खर्च वाढू शकतो. जर पर्यायी मार्ग देखील निकामी झाला, तर सिस्टम वेगवेगळ्या मार्गांमध्ये फिरत राहू शकते, ज्यामुळे अस्थिरता निर्माण होऊ शकते. रिरूटिंग (reroute) हे हेतुपुरस्सर आहे की एखाद्या मोठ्या समस्येचे लक्षण आहे, हे ओळखण्यासाठी ऑपरेटर्सना क्वारंटाईन मार्कर्सवर लक्ष ठेवणे आवश्यक आहे.

पुढे काय पाहावे

  • मेट्रिक्स (Metrics): ३०० सेकंदांचा कालावधी योग्य आहे की नाही हे पाहण्यासाठी क्वारंटाईनची वारंवारता आणि कालावधीवर लक्ष ठेवा.
  • व्याप्ती (Scope): ज्या सेवांना स्टॅटिक रिट्राय पॅटर्नमुळे (static retry patterns) त्रास होतो, तिथे देखील टीम्स हे लॉजिक लागू करण्याचा प्रयत्न करू शकतात.
  • ऑटोमेशन (Automation): वापरकर्त्यांना समस्या जाणवण्यापूर्वीच प्रतिबंधात्मक देखभाल करण्यासाठी, एखादा मार्ग वारंवार क्वारंटाईनमध्ये जात असल्यास अलर्ट्स जोडा.

मुख्य धडा साधा आहे: जी सिस्टम आपल्या अलीकडील अपयशांची नोंद ठेवत नाही, ती बदलत्या वातावरणाशी जुळवून घेऊ शकत नाही. अपयशाचा इतिहास दृश्यमान करून आणि त्यावर—तात्पुरती—कारवाई करून, इंजिनिअर्स पूर्णतः रिडिझाइनची वाट न पाहता व्हॉइस सेवा सुरळीत ठेवू शकतात.

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

चर्चांमध्ये सहभागी व्हा: https://t.me/GyaanSetuAi