వాయిస్-రూటింగ్ సిస్టమ్ను పరీక్షిస్తున్న ఒక డెవలపర్, వైఫల్యం (failure) జరిగిన తర్వాత తదుపరి కాల్ మరొక మార్గాన్ని (path) ఉపయోగించేలా 300 సెకన్ల పాటు తాత్కాలిక క్వారంటైన్ను (quarantine) జోడించారు. ఈ మార్పు వల్ల సాఫ్ట్వేర్ పదేపదే అదే విఫలమైన మార్గాన్ని ప్రయత్నించకుండా ఆగుతుంది, తద్వారా వరుస వైఫల్యాల (cascade outage) అవకాశాన్ని తగ్గిస్తుంది.
పాత లాజిక్ ఎందుకు సమస్యగా మారింది
అసలు రూటర్ ఒక కఠినమైన నియమాన్ని అనుసరించేది: వర్క్స్టేషన్ బిజీగా ఉన్నప్పుడు, అది కేవలం అదే మార్గాన్ని మళ్ళీ ప్రయత్నించేది. ఒకవేళ ఆ మార్గం పదేపదే విఫలమవుతుంటే, సిస్టమ్ ఆ ఎర్రర్ను లాగ్ చేసేది కానీ దాని ప్రవర్తనను మార్చేది కాదు. వాస్తవానికి, సాఫ్ట్వేర్ పదేపదే అదే నిలిచిపోయిన మార్గం (dead end) వద్ద లూప్ అవుతూ ఉండటం వల్ల, ఒకే ఒక వైఫల్యం కాల్స్ అన్నింటినీ నిలిపివేసే అవకాశం ఉండేది.
కొత్త క్వారంటైన్ మెకానిజం
ఈ అప్డేట్ మూడు పరిమితులను (constraints) జోడిస్తుంది:
- శాశ్వతం కాదు – క్వారంటైన్ మార్కర్ ఒక చిన్న సమయం తర్వాత ముగిసిపోతుంది.
- గ్లోబల్ కాదు – ఇది కేవలం విఫలమైన నిర్దిష్ట మార్గానికి మాత్రమే వర్తిస్తుంది, అన్ని మార్గాలకు కాదు.
- పరిమిత మెమరీ (Bounded memory) – సిస్టమ్ వైఫల్యాన్ని లోకల్ ఫైల్లో రికార్డ్ చేస్తుంది మరియు కొత్త మార్గం విజయవంతమైన వెంటనే దానిని మర్చిపోతుంది.
స్పీచ్ ప్రయత్నం విఫలమైనప్పుడు, రూటర్ ఆ మార్గం కోసం “quarantined” ఫ్లాగ్ను రాస్తుంది. తదుపరి 300 సెకన్ల పాటు, వచ్చే ప్రతి రిక్వెస్ట్ ఆటోమేటిక్గా ప్రత్యామ్నాయ మార్గానికి మళ్ళించబడుతుంది (reroutes). వేరే మార్గంలో రిక్వెస్ట్ విజయవంతమైన వెంటనే, ఆ ఫ్లాగ్ తొలగించబడుతుంది, తద్వారా ఈ పరిష్కారం అవసరమైన దానికంటే ఎక్కువ కాలం కొనసాగకుండా చూస్తుంది.
ప్రయోజనాలు మరియు లాభనష్టాలు
దీని ప్రధాన ప్రయోజనం స్థితిస్థాపకత (resilience): తాత్కాలిక లోపం (transient glitch) వల్ల ఇకపై మొత్తం సర్వీస్ నిలిచిపోదు. క్వారంటైన్ను ఐదు నిమిషాలకు పరిమితం చేయడం ద్వారా, సిస్టమ్ దీర్ఘకాలిక సర్వీస్ నష్టాన్ని నివారించడమే కాకుండా, నెట్వర్క్ కోలుకోవడానికి తగిన సమయాన్ని ఇస్తుంది.
ఈ విధానంలో రిస్క్ కూడా ఉంది. చిన్నపాటి నెట్వర్క్ అంతరాయం (hiccup) క్వారంటైన్ను ప్రేరేపించవచ్చు, ఇది కాల్స్ను తక్కువ అనుకూలమైన (less optimal) మార్గం ద్వారా పంపేలా చేస్తుంది, దీనివల్ల లేటెన్సీ (latency) లేదా ఖర్చు పెరగవచ్చు. ఒకవేళ ప్రత్యామ్నాయ మార్గం కూడా సరిగ్గా లేకపోతే, సిస్టమ్ మార్గాల మధ్య ఊగిసలాడుతూ అస్థిరతను (instability) సృష్టించవచ్చు. రీరూట్ అనేది ఉద్దేశపూర్వకమా లేదా లోతైన సమస్యకు సంకేతమా అని తెలుసుకోవడానికి ఆపరేటర్లకు క్వారంటైన్ మార్కర్లపై స్పష్టత ఉండాలి.
తదుపరి గమనించవలసినవి
- మెట్రిక్స్ (Metrics): 300-సెకన్ల సమయం సరిపోతుందో లేదో చూడటానికి క్వారంటైన్ల ఫ్రీక్వెన్సీ మరియు వ్యవధిని పర్యవేక్షించండి.
- పరిధి (Scope): స్టాటిక్ రీట్రై ప్యాటర్న్స్తో ఇబ్బంది పడే ఇతర సర్వీసులకు కూడా ఈ లాజిక్ను విస్తరించడానికి బృందాలు ప్రయత్నించవచ్చు.
- ఆటోమేషన్ (Automation): వినియోగదారులు సమస్యను గమనించకముందే ముందస్తు నిర్వహణ (proactive maintenance) చేయడానికి, ఒక మార్గం పదేపదే క్వారంటైన్లోకి వెళ్తున్నప్పుడు అలర్ట్లను జోడించండి.
దీనిలోని ప్రధాన పాఠం సరళమైనది: తన ఇటీవలి వైఫల్యాలను రికార్డ్ చేయని సిస్టమ్, మారుతున్న వాతావరణానికి అనుగుణంగా మారలేదు. వైఫల్య చరిత్రను దృశ్యమానం చేస్తూ, దానిపై తాత్కాలికంగా చర్య తీసుకోవడం ద్వారా, ఇంజనీర్లు పూర్తి స్థాయి రీడిజైన్ కోసం వేచి చూడకుండానే వాయిస్ సర్వీసులను సజావుగా నడపగలరు.
మూలం: dev.to లోని అసలు డెవలపర్ పోస్ట్.
చర్చలో పాల్గొనండి: https://t.me/GyaanSetuAi
