ವಾಯ್ಸ್-ರೂಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದ ಒಬ್ಬ ಡೆವಲಪರ್, ವೈಫಲ್ಯದ ನಂತರ ಮುಂದಿನ ಕರೆಗಳು 300 ಸೆಕೆಂಡುಗಳ ಕಾಲ ವಿಭಿನ್ನ ಮಾರ್ಗವನ್ನು ಬಳಸುವಂತೆ ಮಾಡುವ ತಾತ್ಕಾಲಿಕ ಕ್ವಾರಂಟೈನ್ (quarantine) ಅನ್ನು ಸೇರಿಸಿದ್ದಾರೆ. ಈ ಬದಲಾವಣೆಯು ಸಾಫ್ಟ್‌ವೇರ್ ಪದೇ ಪದೇ ಒಂದೇ ಹಾನಿಗೊಳಗಾದ ಮಾರ್ಗವನ್ನು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದರಿಂದ ಸರಣಿ ವ್ಯತ್ಯಯದ (cascade outage) ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಹಳೆಯ ತರ್ಕವು (logic) ಏಕೆ ಸಮಸ್ಯೆಯಾಗಿತ್ತು

ಮೂಲ ರೂಟರ್ ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮವನ್ನು ಅನುಸರಿಸುತ್ತಿತ್ತು: ವರ್ಕ್‌ಸ್ಟೇಷನ್ ಕಾರ್ಯನಿರತವಾಗಿದ್ದಾಗ, ಅದು ಕೇವಲ ಅದೇ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತಿತ್ತು. ಆ ಮಾರ್ಗವು ಪದೇ ಪದೇ ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ಸಿಸ್ಟಮ್ ದೋಷವನ್ನು ದಾಖಲಿಸುತ್ತಿತ್ತು ಆದರೆ ತನ್ನ ನಡವಳಿಕೆಯನ್ನು ಎಂದಿಗೂ ಬದಲಾಯಿಸುತ್ತಿರಲಿಲ್ಲ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಸಾಫ್ಟ್‌ವೇರ್ ಒಂದೇ ಹಾನಿಗೊಳಗಾದ ಹಾದಿಯಲ್ಲಿ ಪದೇ ಪದೇ ಸುತ್ತುತ್ತಿರುವುದರಿಂದ, ಒಂದು ವೈಫಲ್ಯದ ಬಿಂದುವು ಕರೆಗಳನ್ನು ನಿರಂತರವಾಗಿ ತಡೆಯುವ ಸಾಧ್ಯತೆ ಇರುತ್ತಿತ್ತು.

ಹೊಸ ಕ್ವಾರಂಟೈನ್ ಕಾರ್ಯವಿಧಾನ

ಈ ಅಪ್‌ಡೇಟ್ ಮೂರು ನಿರ್ಬಂಧಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ:

  • ಕಾಯಂ ಅಲ್ಲ – ಕ್ವಾರಂಟೈನ್ ಮಾರ್ಕರ್ ಒಂದು ಸಣ್ಣ ಅವಧಿಯ ನಂತರ ಅವಧಿ ಮುಗಿಯುತ್ತದೆ.
  • ಜಾಗತಿಕವಲ್ಲ – ಇದು ವಿಫಲವಾದ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗಕ್ಕೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ, ಎಲ್ಲಾ ಮಾರ್ಗಗಳಿಗೆ ಅಲ್ಲ.
  • ಮಿತವಾದ ಮೆಮೊರಿ – ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯವನ್ನು ಸ್ಥಳೀಯ ಫೈಲ್‌ನಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ ಮಾರ್ಗವು ಯಶಸ್ವಿಯಾದ ತಕ್ಷಣ ಅದನ್ನು ಮರೆತುಬಿಡುತ್ತದೆ.

ಮಾತಿನ ಪ್ರಯತ್ನವು (speech attempt) ವಿಫಲವಾದಾಗ, ರೂಟರ್ ಆ ಮಾರ್ಗಕ್ಕಾಗಿ "quarantined" ಎಂಬ ಫ್ಲಾಗ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ. ಮುಂದಿನ 300 ಸೆಕೆಂಡುಗಳವರೆಗೆ, ಯಾವುದೇ ಬರುವ ವಿನಂತಿಯನ್ನು (request) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರ್ಯಾಯ ಮಾರ್ಗಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ವಿನಂತಿ ಯಶಸ್ವಿಯಾದ ತಕ್ಷಣ, ಫ್ಲಾಗ್ ಅಳಿಸಲ್ಪಡುತ್ತದೆ, ಇದರಿಂದ ಸರಿಪಡಿಸುವ ಕ್ರಮವು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯದಂತೆ ನೋಡಿಕೊಳ್ಳಬಹುದು.

ಪ್ರಯೋಜನಗಳು ಮತ್ತು ಸವಾಲುಗಳು

ಇದರ ಪ್ರಾಥಮಿಕ ಲಾಭವೆಂದರೆ ಚೇತರಿಸಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯ (resilience): ಒಂದು ತಾತ್ಕಾಲಿಕ ತಾಂತ್ರಿಕ ದೋಷವು ಇನ್ನು ಮುಂದೆ ಇಡೀ ಸೇವೆಯನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡುವುದಿಲ್ಲ. ಕ್ವಾರಂಟೈನ್ ಅನ್ನು ಐದು ನಿಮಿಷಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ, ಸಿಸ್ಟಮ್ ದೀರ್ಘಕಾಲದ ಸೇವಾ ನಷ್ಟವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸಮಯವನ್ನು ನೀಡುತ್ತದೆ.

ಈ ವಿಧಾನವು ಅಪಾಯವನ್ನು ಹೊಂದಿದೆ. ಒಂದು ಸಣ್ಣ ನೆಟ್‌ವರ್ಕ್ ಅಡಚಣೆಯು ಕ್ವಾರಂಟೈನ್ ಅನ್ನು ಪ್ರಚೋದಿಸಬಹುದು, ಇದು ಕರೆಗಳನ್ನು ಕಡಿಮೆ ಉತ್ತಮವಾದ ಮಾರ್ಗಕ್ಕೆ ಕಳುಹಿಸುವಂತೆ ಮಾಡಬಹುದು, ಇದರಿಂದ ಲ್ಯಾಟೆನ್ಸಿ (latency) ಅಥವಾ ವೆಚ್ಚ ಹೆಚ್ಚಾಗಬಹುದು. ಪರ್ಯಾಯ ಮಾರ್ಗವು ಕೂಡ ಕ್ಷೀಣಿಸಿದರೆ, ಸಿಸ್ಟಮ್ ಮಾರ್ಗಗಳ ನಡುವೆ ಅಲೆದಾಡಬಹುದು, ಇದು ಅಸ್ಥಿರತೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಮರುನಿರ್ದೇಶನವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆಯೇ ಅಥವಾ ಇದು ಆಳವಾದ ಸಮಸ್ಯೆಯ ಲಕ್ಷಣವೇ ಎಂದು ತಿಳಿಯಲು ಆಪರೇಟರ್‌ಗಳಿಗೆ ಕ್ವಾರಂಟೈನ್ ಮಾರ್ಕರ್ ಬಗ್ಗೆ ಮಾಹಿತಿ ಇರಬೇಕಾಗುತ್ತದೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • ಮೆಟ್ರಿಕ್ಸ್ (Metrics): 300 ಸೆಕೆಂಡುಗಳ ಅವಧಿಯು ಸೂಕ್ತವಾಗಿದೆಯೇ ಎಂದು ನೋಡಲು ಕ್ವಾರಂಟೈನ್‌ಗಳ ಆವರ್ತನ ಮತ್ತು ಅವಧಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
  • ವ್ಯಾಪ್ತಿ (Scope): ಸ್ಥಿರ ರಿಟ್ರೈ ಪ್ಯಾಟರ್ನ್‌ಗಳಿಂದ (static retry patterns) ತೊಂದರೆ ಅನುಭವಿಸುವ ಇತರ ಸೇವೆಗಳಿಗೆ ಈ ತರ್ಕವನ್ನು ವಿಸ್ತರಿಸಲು ತಂಡಗಳು ಪ್ರಯತ್ನಿಸಬಹುದು.
  • ಆಟೊಮೇಷನ್ (Automation): ಬಳಕೆದಾರರು ಸಮಸ್ಯೆಯನ್ನು ಗಮನಿಸುವ ಮೊದಲೇ ಮುನ್ನೆಚ್ಚರಿಕೆ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು, ಒಂದು ಮಾರ್ಗವು ಪದೇ ಪದೇ ಕ್ವಾರಂಟೈನ್‌ಗೆ ಒಳಗಾದಾಗ ಎಚ್ಚರಿಕೆಗಳನ್ನು (alerts) ಸೇರಿಸಿ.

ಇದರ ಮೂಲ ಪಾಠ ಸರಳವಾಗಿದೆ: ತನ್ನ ಇತ್ತೀಚಿನ ವೈಫಲ್ಯಗಳನ್ನು ದಾಖಲಿಸದ ಸಿಸ್ಟಮ್ ಬದಲಾಗುತ್ತಿರುವ ಪರಿಸರಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ವೈಫಲ್ಯದ ಇತಿಹಾಸವನ್ನು ದೃಶ್ಯೀಕರಿಸುವ ಮೂಲಕ ಮತ್ತು ಅದರ ಮೇಲೆ ತಾತ್ಕಾಲಿಕವಾಗಿ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ, ಎಂಜಿನಿಯರ್‌ಗಳು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಮರುವಿನ್ಯಾಸಕ್ಕಾಗಿ ಕಾಯದೆ ವಾಯ್ಸ್ ಸೇವೆಗಳನ್ನು ಸುಗಮವಾಗಿ ನಡೆಸಬಹುದು.

ಮೂಲ: dev.to ನಲ್ಲಿನ ಮೂಲ ಡೆವಲಪರ್ ಪೋಸ್ಟ್.

ಚರ್ಚೆಯಲ್ಲಿ ಭಾಗವಹಿಸಿ: https://t.me/GyaanSetuAi