5.5 MB runtime-ஐக் கொண்ட ஒரு பிரவுசர் சார்ந்த Python playground, மெதுவான இணையத் தொடர்பைப் பயன்படுத்தும் பயனர்களுக்குத் தெரியாமலேயே செயலிழக்கத் தொடங்கியது. தவறாகப் பயன்படுத்தப்பட்ட Network Information API மற்றும் பிழையைத் தவறாகக் குறியீடு செய்த ஒரு error-grouping dashboard ஆகியவையே இதற்குக் காரணமானவை. இந்தத் தவறு பல வாரங்களாகத் தெரியாமல் மறைந்திருந்தது, டெவலப்பர்களின் நேரத்தை வீணடித்ததுடன், ஒரு குறிப்பிட்ட சதவீத பயனர்களைக் குறியீட்டை (code) இயக்க முடியாமல் செய்தது.

பிரச்சனை எவ்வாறு வெளிப்பட்டது

அந்த playground-ன் error tracker ஒரு முக்கியமான செய்தியைக் காட்டியது: “undefined is not an object.” இந்தத் தலைப்பு ஒரு சாதாரண JavaScript typo என்று தோன்றியதால், குழுவினர் இல்லாத ஒரு code path-ஐத் தேடி அலைந்தனர். அவர்கள் மூலத் தரவுகளை (raw metadata) ஆய்வு செய்தபோது, அந்தச் சம்பவங்களில் 89% உண்மையில் network timeouts என்பதைத் தெரிந்துகொண்டனர். dashboard முதலில் வந்த பிழையை எடுத்துக்கொண்டு, அதையே முழு தொகுப்பிற்கும் பெயராகப் பயன்படுத்தியதால், உண்மையான தோல்வியின் வகை மறைக்கப்பட்டது.

பாடம் 1 – Dashboard தலைப்புகள் ஏமாற்றலாம்

சம்பவங்களை ஒருங்கிணைக்கும் ஒரு dashboard, அதன் ஒருங்கிணைப்புத் தர்க்கம் (aggregation logic) ஒவ்வொரு நிகழ்வின் உண்மையான காரணத்தைப் பிரதிபலித்தால் மட்டுமே பயனுள்ளதாக இருக்கும். இங்கே, பிழை காரணத்தைப் பொறுத்து வகைப்படுத்துவதற்குப் பதிலாக, இருப்பிடத்தின் அடிப்படையில் வகைப்படுத்தியதால், அது ஒரு client-side bug போன்ற தவறான பிம்பத்தை உருவாக்கியது. இதிலிருந்து நாம் கற்றுக்கொள்ள வேண்டியது: ஒரு dashboard தலைப்பை மட்டும் வைத்துக்கொண்டு ஒரு சிக்கலைத் தீர்க்க முயல வேண்டாம். வளங்களை (resources) ஒதுக்குவதற்கு முன், அடிப்படை நிகழ்வுகளின் மாதிரியை எடுத்துக்கொண்டு உண்மையில் என்ன நடக்கிறது என்பதைச் சரிபார்க்கவும்.

பாடம் 2 – Placeholder மதிப்புகள் அளவீடுகள் அல்ல

மெதுவான இணையத் தொடர்பைப் பயன்படுத்தும் பயனர்களுக்குப் பெரிய runtime-ஐத் தரவிறக்கம் செய்வதைத் தவிர்க்க, அந்த code Network Information API-ஐக் கேட்டு, வினாடிக்கு எத்தனை megabits என்பதைத் தெரிவிக்கும் downlink பண்பை (property) வாசித்தது. முதல்முறை இணையதளத்தைப் பார்க்கும்போது, Chrome பெரும்பாலும் உண்மையான அளவீட்டிற்குப் பதிலாக ஒரு placeholder மதிப்பைத் தரும். அந்த logic அந்த placeholder மதிப்பை ஒரு வேகமான இணைப்பு என்று கருதி, optimization-ஐத் தவிர்த்தது; இதன் விளைவாக, உதவ வேண்டிய பயனர்களே இணையத்தைப் பயன்படுத்த முடியாமல் போனார்கள்.

எந்தவொரு default அல்லது sentinel மதிப்பையும் "தரவு இல்லை" (no data) என்று கருதுங்கள். ஒரு placeholder மதிப்பு ஒரு fallback strategy-ஐத் தொடங்க வேண்டுமே தவிர, அதை உண்மையான வேக அளவீடாகக் கருதக்கூடாது.

பாடம் 3 – இணையத் தொடர்பின் நிலை மாறக்கூடியது, எனவே ஒருமுறை மட்டும் சரிபார்ப்பது நம்பகமானது அல்ல

downlink சிக்கலுக்குப் பிறகு, குழுவினர் இணைப்புகளை “4g”, “3g” என வகைப்படுத்தும் effectiveType-ஐச் சரிபார்க்கத் தொடங்கினர். ஒரு விரைவான ஆய்வில் (lab test) அது சரியாகத் தெரிந்தது, ஆனால் அடுத்த சில நிமிடங்களில் அதே சோதனை தோல்வியடைந்தது. மொபைல் இணைப்புகள் அடிக்கடி மாறுபடும்; ஒரு பயனர் ஒரு நொடியில் வேகமான 4G இணைப்பிலும், அடுத்த நொடி மெதுவான 3G இணைப்பிலும் இருக்கலாம். பக்கம் ஏற்றப்படும்போது (page load) மட்டும் இணைப்பைச் சரிபார்ப்பது ஒரு சூதாட்டம் போன்றது.

சரியான அணுகுமுறை என்பது, ஒருமுறை மட்டும் முடிவெடுப்பதற்குப் பதிலாக, Network Information object-ல் உள்ள change நிகழ்விற்கு (event) subscribe செய்து, bandwidth-ல் ஏற்படும் எந்த மாற்றத்திற்கும் ஏற்பச் செயல்படுவதாகும்.

குழுவினர் செய்த மாற்றங்கள்

  • இருநிலைத் தரவிறக்கம் (Two-stage download) – runtime இப்போது ஒரு சிறிய bootstrap கோப்புடன் தொடங்குகிறது. இணைப்பு மெதுவானது எனக் கண்டறியப்பட்டால், அந்த bootstrap மீதமுள்ள runtime-ஐச் சிறிய துண்டுகளாக (chunks) தரவிறக்கம் செய்யும், இது முழுமையாகத் தரவிறக்கம் நின்றுபோகும் வாய்ப்பைக் குறைக்கிறது.
  • நேரலை கண்காணிப்பு (Live monitoring) – ஒருமுறை மட்டும் downlink-ஐ வாசிப்பதற்குப் பதிலாக, code இப்போது change நிகழ்வுகளைக் கவனித்து, தரவிறக்க முறையைத் தேவைக்கேற்ப மாற்றியமைக்கிறது.
  • நிலையான மூலத் தேர்வு (Stable source selection) – முன்னதாக, வேகமான endpoint கிடைக்கும்போது, தரவிறக்கத்தின் நடுவிலேயே சிஸ்டம் CDNs-ஐ மாற்றியது. மெதுவான இணைப்பில் இது தரவிறக்கத்தை மீண்டும் பூஜ்ஜியத்திலிருந்து தொடங்கச் செய்து, சிக்கலை இன்னும் அதிகமாக்கியது. புதிய தர்க்கம் (logic) தரவிறக்கம் முடியும் வரை மூலத்தைத் (source) தக்கவைத்துக் கொள்கிறது.
  • தள்ளிவைக்கப்பட்ட cache பதிவுகள் (Deferred cache writes) – செயலி பயன்பாட்டிற்கு வருவதற்கு முன்பே இயங்கிக் கொண்டிருந்த கனமான cache செயல்பாடுகள், இப்போது runtime தொடங்கிய பிறகு செய்யத் தள்ளிவைக்கப்பட்டுள்ளன; இது முக்கியமான தரவிறக்கத்திற்குத் தேவையான bandwidth-ஐச் சேமிக்கிறது.

பரந்த விளைவுகள்

இணைய அடிப்படையிலான கருவிகளை உருவாக்கும் டெவலப்பர்களுக்கு, இணையத் தொடர்பின் மாறுபாடு (network variability) ஒரு முக்கியமான கவலையாகும். மெதுவான இணைப்பில் ஏற்படும் ஒரு மௌனமான தோல்வி (silent failure), பயனர்களை விரக்தியடையச் செய்வதுடன், telemetry தரவுகளையும் சிதைத்து, குழுவினரைத் தவறான debugging பாதைக்கு வழிநடத்துகிறது. இந்தச் சூழலில், தரவைத் தவறாகப் புரிந்துகொண்டது பல வார கால வீணான ஆய்வுகளுக்குக் காரணமாக அமைந்தது.

அடுத்து கவனிக்க வேண்டியவை

சுருக்கம்: தரவுகள் மிகவும் துல்லியமாகத் தெரிந்தால், அது ஒரு placeholder ஆக இருக்கலாம்; ஒரு dashboard தலைப்பு ஒரு குறிப்பிட்ட பிழையை மட்டும் சுட்டிக்காட்டினால், அதை ஆழமாக ஆராயுங்கள்; மேலும், ஒருமுறை மட்டும் இணைய வேகத்தைச் சரிபார்த்து ஒரு முடிவை எடுத்தால், நீங்கள் நிலையற்ற ஒன்றின் மீது பந்தயம் கட்டுகிறீர்கள் என்று அர்த்தம். இந்த யதார்த்தங்களுக்கு ஏற்பத் தன்னைத் தகவமைத்துக் கொள்வது, மௌனமான தோல்விகளைத் தடையற்ற மற்றும் சரிசெய்யக்கூடிய நிகழ்வுகளாக மாற்றும்.