5.5 MB റൺടൈം ഉള്ള ഒരു ബ്രൗസർ അധിഷ്ഠിത പൈത്തൺ പ്ലേഗ്രൗണ്ട്, സാവധാനത്തിലുള്ള ഇന്റർനെറ്റ് കണക്ഷനുകൾ ഉപയോഗിക്കുന്ന ഉപയോക്താക്കൾക്കായി നിശബ്ദമായി പരാജയപ്പെടാൻ തുടങ്ങി. ഇതിന് കാരണം തെറ്റായി ഉപയോഗിച്ച Network Information API-യും പ്രശ്നത്തെ തെറ്റായി അടയാളപ്പെടുത്തിയ ഒരു എറർ-ഗ്രൂപ്പിംഗ് ഡാഷ്‌ബോർഡുമാണ്. ഈ ബഗ് ആഴ്ചകളോളം ഒളിച്ചിരുന്നു, ഡെവലപ്പർമാരുടെ സമയം പാഴാക്കി, കൂടാതെ ഒരു വിഭാഗം ഉപയോക്താക്കൾക്ക് കോഡ് പ്രവർത്തിപ്പിക്കാൻ കഴിയാത്ത അവസ്ഥയുണ്ടാക്കി.

How the problem surfaced

പ്ലേഗ്രൗണ്ടിന്റെ എറർ ട്രാക്കർ ശ്രദ്ധ ആകർഷിക്കുന്ന ഒരു സന്ദേശം കാണിച്ചു: “undefined is not an object.” ഈ തലക്കെട്ട് ഒരു ലളിതമായ JavaScript ടൈപ്പോ ആണെന്ന് സൂചിപ്പിച്ചതിനാൽ, ടീം നിലവിലില്ലാത്ത ഒരു കോഡ് പാത്തിന് പിന്നാലെ പോയി. അവർ മെറ്റാഡാറ്റ പരിശോധിച്ചപ്പോൾ, ആ സംഭവങ്ങളിൽ 89 % യഥാർത്ഥത്തിൽ നെറ്റ്‌വർക്ക് ടൈമൗട്ടുകൾ ആയിരുന്നു എന്ന് കണ്ടു. ഡാഷ്‌ബോർഡ് ആദ്യം വന്ന എറർ ഉപയോഗിച്ച് ആ ഗ്രൂപ്പിന് പേര് നൽകുകയായിരുന്നു, ഇത് യഥാർത്ഥ പരാജയത്തിന്റെ കാരണം മറച്ചുവെച്ചു.

Lesson 1 – Dashboard titles can be deceptive

ഓരോ സംഭവത്തിന്റെയും യഥാർത്ഥ കാരണം ഡാഷ്‌ബോർഡിലെ ഗ്രൂപ്പിംഗ് ലോജിക് പ്രതിഫലിപ്പിക്കുന്നുണ്ടെങ്കിൽ മാത്രമേ സംഭവങ്ങൾ കൂട്ടിച്ചേർക്കുന്ന (aggregate) ഒരു ഡാഷ്‌ബോർഡ് ഉപകാരപ്പെടൂ. ഇവിടെ, എറർ കാരണം നോക്കുന്നതിന് പകരം ലൊക്കേഷൻ അടിസ്ഥാനമാക്കി ഗ്രൂപ്പ് ചെയ്തത് ഒരു ക്ലയന്റ് സൈഡ് ബഗ് ആണെന്ന തെറ്റായ ചിത്രം നൽകി. പാഠം: ഒരു ഡാഷ്‌ബോർഡ് തലക്കെട്ട് മാത്രം നോക്കി ഒരു പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിക്കരുത്. വിഭവങ്ങൾ ചിലവഴിക്കുന്നതിന് മുമ്പ് യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് പരിശോധിക്കാൻ അടിസ്ഥാന സംഭവങ്ങളുടെ ഒരു സാമ്പിൾ എടുക്കുക.

Lesson 2 – Placeholder values are not measurements

സാവധാനത്തിലുള്ള കണക്ഷനുകളുള്ള ഉപയോക്താക്കൾക്കായി വലിയ റൺടൈം ലോഡ് ചെയ്യുന്നത് ഒഴിവാക്കാൻ, കോഡ് Network Information API പരിശോധിക്കുകയും മെഗാബിറ്റ്സ് പെർ സെക്കൻഡ് റിപ്പോർട്ട് ചെയ്യുന്ന downlink പ്രോപ്പർട്ടി വായിക്കുകയും ചെയ്തു. ആദ്യ സന്ദർശനത്തിൽ, ക്രോം പലപ്പോഴും യഥാർത്ഥ അളവിന് പകരം ഒരു പ്ലേസ്‌ഹോൾഡർ നൽകുന്നു. ആ പ്ലേസ്‌ഹോൾഡറിനെ ഒരു വേഗതയേറിയ കണക്ഷനായി കണക്കാക്കിയ കോഡ് ഒപ്റ്റിമൈസേഷൻ ഒഴിവാക്കി, ഇത് സഹായിക്കാൻ ഉദ്ദേശിച്ച ഉപയോക്താക്കളെ തന്നെ തടഞ്ഞു.

ഏതൊരു ഡിഫോൾട്ട് അല്ലെങ്കിൽ സെന്റീനെൽ മൂല്യത്തെയും "ഡാറ്റയില്ല" (no data) എന്ന് കരുതുക. ഒരു പ്ലേസ്‌ഹോൾഡർ ഒരു ഫോളബാക്ക് സ്ട്രാറ്റജി (fallback strategy) തുടങ്ങാൻ കാരണമാകണം, അല്ലാതെ അത് യഥാർത്ഥ വേഗതയായി കണക്കാക്കരുത്.

Lesson 3 – Network conditions change, so a single snapshot is unreliable

downlink പ്രശ്നത്തിന് ശേഷം, ടീം കണക്ഷനുകളെ “4g”, “3g” എന്നിങ്ങനെ തരംതിരിക്കുന്ന effectiveType പരിശോധിക്കാൻ മാറി. ഒരു ലബോറട്ടറി ടെസ്റ്റ് വിജയിച്ചെങ്കിലും, നിമിഷങ്ങൾക്കുശേഷം അതേ ടെസ്റ്റ് പരാജയപ്പെട്ടു. മൊബൈൽ കണക്ഷനുകൾ മാറിക്കൊണ്ടിരിക്കും; ഒരു ഉപയോക്താവ് ഒരു നിമിഷം വേഗതയേറിയ 4G കണക്ഷനിലും അടുത്ത നിമിഷം സാവധാനത്തിലുള്ള 3G കണക്ഷനിലും ആയിരിക്കാം. പേജ് ലോഡ് ചെയ്യുമ്പോൾ മാത്രം കണക്ഷൻ പരിശോധിക്കുന്നത് ഒരു ചൂതാട്ടമാണ്.

ശരിയായ രീതി എന്നത് Network Information ഒബ്‌ജക്റ്റിലെ change ഇവന്റിൽ സബ്‌സ്‌ക്രൈബ് (subscribe) ചെയ്യുകയും ബാൻഡ്‌വിഡ്ത്തിൽ ഉണ്ടാകുന്ന മാറ്റങ്ങളോട് പ്രതികരിക്കുകയും ചെയ്യുക എന്നതാണ്, അല്ലാതെ ഒരു ഒറ്റത്തവണ തീരുമാനമെടുക്കുകയല്ല വേണ്ടത്.

What the team changed

  • Two-stage download – റൺടൈം ഇപ്പോൾ ഒരു ചെറിയ ബൂട്ട്‌സ്‌ട്രാപ്പ് ഫയലിലൂടെയാണ് ആരംഭിക്കുന്നത്. കണക്ഷൻ സാവധാനത്തിലാണെന്ന് കണ്ടാൽ, ബൂട്ട്‌സ്‌ട്രാപ്പ് ബാക്കി റൺടൈമി ചെറിയ ഭാഗങ്ങളായി (chunks) ഡൗൺലോഡ് ചെയ്യും, ഇത് ഡൗൺലോഡ് പൂർണ്ണമായും തടസ്സപ്പെടാനുള്ള സാധ്യത കുറയ്ക്കുന്നു.
  • Live monitoring – ഒരു ഒറ്റപ്പെട്ട downlink റീഡിന് പകരം, കോഡ് ഇപ്പോൾ change ഇവന്റുകൾ ശ്രദ്ധിക്കുകയും ഡൗൺലോഡ് സ്ട്രാറ്റജി തത്സമയം ക്രമീകരിക്കുകയും ചെയ്യുന്നു.
  • Stable source selection – മുമ്പ്, വേഗതയേറിയ ഒരു എൻഡ്പോയിന്റ് ദൃശ്യമാകുമ്പോൾ സിസ്റ്റം ഡൗൺലോഡിനിടെ തന്നെ CDN മാറ്റിയിരുന്നു. സാവധാനത്തിലുള്ള കണക്ഷനിൽ ഇത് ഡൗൺലോഡ് പൂജ്യത്തിൽ നിന്ന് വീണ്ടും തുടങ്ങാൻ കാരണമാവുകയും പ്രശ്നം വർദ്ധിപ്പിക്കുകയും ചെയ്തു. പുതിയ ലോജിക് ഡൗൺലോഡ് പൂർത്തിയാകുന്നത് വരെ സോഴ്സ് ലോക്ക് ചെയ്യുന്നു.
  • Deferred cache writes – ആപ്പ് ഉപയോഗിക്കാൻ കഴിയുന്നതിന് മുമ്പ് പ്രവർത്തിച്ചിരുന്ന കനത്ത കാഷെ ഓപ്പറേഷനുകൾ ഇപ്പോൾ റൺടൈം ആരംഭിക്കുന്നത് വരെ മാറ്റിവെച്ചിരിക്കുന്നു, ഇത് പ്രധാനപ്പെട്ട ഡൗൺലോഡിനായി ബാൻഡ്‌വിഡ്ത്ത് ലഭ്യമാക്കുന്നു.

The broader stakes

വെബ് അധിഷ്ഠിത ടൂളുകൾ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാരെ സംബന്ധിച്ചിടത്തോളം, നെറ്റ്‌വർക്ക് വ്യതിയാനങ്ങൾ (network variability) വളരെ പ്രധാനപ്പെട്ട കാര്യമാണ്. സാവധാനത്തിലുള്ള കണക്ഷനിലെ ഒരു നിശബ്ദ പരാജയം ഉപയോക്താക്കളെ നിരാശപ്പെടുത്തുകയും ടെലിമെട്രി തെറ്റായി കാണിക്കുകയും ചെയ്യുന്നു, ഇത് ടീമുകളെ തെറ്റായ ഡീബഗ്ഗിംഗ് പാതയിലേക്ക് നയിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഡാറ്റ തെറ്റായി വ്യാഖ്യാനിച്ചത് ആഴ്ചകളോളം ഫലമില്ലാത്ത അന്വേഷണത്തിന് കാരണമായി.

What to watch next

പാഠം: ഡാറ്റ വളരെ കൃത്യമായി തോന്നുന്നുണ്ടെങ്കിൽ, അത് ഒരു പ്ലേസ്‌ഹോൾഡർ ആകാൻ സാധ്യതയുണ്ട്; ഒരു ഡാഷ്‌ബോർഡ് തലക്കെട്ട് ഒരു പ്രത്യേക ബഗ് ചൂണ്ടിക്കാണിക്കുന്നുണ്ടെങ്കിൽ, കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കുക; ഒരു ഒറ്റത്തവണ നെറ്റ്‌വർക്ക് റീഡിനെ അടിസ്ഥാനമാക്കി നിങ്ങൾ ഒരു തീരുമാനം എടുക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ലക്ഷ്യത്തെയാണ് ലക്ഷ്യം വെക്കുന്നത്. ഈ യാഥാർത്ഥ്യങ്ങൾക്കനുസരിച്ച് മാറ്റങ്ങൾ വരുത്തുന്നത് നിശബ്ദ പരാജയങ്ങളെ മുൻകൂട്ടി കാണാവുന്നതും പരിഹരിക്കാവുന്നതുമായ സംഭവങ്ങളാക്കി മാറ്റുന്നു.