AI ഓട്ടോപൈലറ്റ് ഫ്രീസ്: ടൈംസ്റ്റാമ്പുകളെ മാത്രം ആശ്രയിക്കുന്നതിലെ അപകടം
ഞങ്ങളുടെ AI ഏജന്റുകൾ 24/7 പ്രവർത്തിക്കുന്നു.
അവ ആവശ്യകതകളെ (requirements) ടാസ്ക്കുകളാക്കി മാറ്റുന്നു. അവ കോഡ് എഴുതുന്നു. അവ പുൾ റിക്വസ്റ്റുകൾ (pull requests) തുറക്കുന്നു. ഒരു AI റിവ്യൂവർ ജോലി അംഗീകരിക്കുന്നു. തുടർന്ന്, സിസ്റ്റം കോഡ് സ്വയമേവ മെർജ് (merge) ചെയ്യുന്നു.
ഒരു ദിവസം രാവിലെ, കഴിഞ്ഞ മൂന്ന് ദിവസമായി ഒരു ടാസ്ക് പോലും പൂർത്തിയായിട്ടില്ലെന്ന് ഞങ്ങൾ കണ്ടു.
സിസ്റ്റം കൃത്യമായി പ്രവർത്തിക്കുന്നതായി തോന്നി. എല്ലാ ഘടകങ്ങളും ഗ്രീൻ സ്റ്റാറ്റസ് (green status) കാണിക്കുന്നുണ്ടായിരുന്നു. പ്ലാനുകൾ തയ്യാറാകുന്നുണ്ടായിരുന്നു. ഏജന്റുകൾ ജോലി ചെയ്യുന്നുണ്ടായിരുന്നു. റിവ്യൂവർ അംഗീകാരം നൽകുന്നുണ്ടായിരുന്നു. മെർജ് (merge) നടക്കാത്തത് മാത്രമായിരുന്നു പ്രശ്നം.
ഇതിന് കാരണം ഞങ്ങൾ തന്നെ നിർമ്മിച്ച ഒരു 'ഫ്രഷ്നസ് ചെക്ക്' (freshness check) ആയിരുന്നു.
ഒരു പ്രത്യേക പിശക് ഒഴിവാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഒരു റിവ്യൂവർ കോഡ് അംഗീകരിച്ച ശേഷം പിന്നീട് മാറ്റങ്ങൾ ആവശ്യപ്പെടുകയാണെങ്കിൽ, ആ കോഡ് മെർജ് ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല. ഇത് പരിഹരിക്കാൻ ഞങ്ങൾ സിസ്റ്റത്തോട് പറഞ്ഞു: "കാത്തിരിക്കാൻ തുടങ്ങിയതിന് ശേഷം നടന്ന റിവ്യൂകളെ മാത്രം വിശ്വസിക്കുക."
സിസ്റ്റം വീണ്ടെടുക്കുന്ന സമയത്ത് (system recoveries) ഈ ലോജിക് പരാജയപ്പെട്ടു.
സിസ്റ്റം റീസ്റ്റാർട്ട് ചെയ്യുകയോ അല്ലെങ്കിൽ ഒരു ടാസ്ക് പുതിയൊരു സെർവറിലേക്ക് മാറ്റുകയോ ചെയ്താൽ, അത് "start waiting" എന്ന ടൈംസ്റ്റാമ്പ് നിലവിലെ സമയത്തേക്ക് റീസെറ്റ് ചെയ്യുമായിരുന്നു.
ഒരു റിവ്യൂവർ രാവിലെ 10:00-ന് കോഡ് അംഗീകരിച്ചുവെന്നും എന്നാൽ 10:30-ന് സിസ്റ്റം റീസ്റ്റാർട്ട് ആയെന്നും കരുതുക, അങ്ങനെയെങ്കിൽ സിസ്റ്റം 10:00-ലെ അംഗീകാരം അവഗണിക്കും. ആ അംഗീകാരം വളരെ പഴയതാണെന്ന് സിസ്റ്റം കരുതി.
GitHub-ൽ ആ അംഗീകാരം ഇപ്പോഴുമുണ്ടായിരുന്നു. എന്നാൽ ഞങ്ങളുടെ കോഡിന് അത് കാണാൻ കഴിഞ്ഞില്ല. സിസ്റ്റം ഒരു സ്ഥിരമായ ഡെഡ്ലോക്കിൽ (deadlock) അകപ്പെട്ടു.
ഇതിൽ നിന്ന് ഞാൻ മൂന്ന് കഠിനമായ പാഠങ്ങൾ പഠിച്ചു:
ബാഹ്യമായ അവസ്ഥയെ (external state) ഒരു ഇവന്റ് (event) ആയിട്ടല്ല, മറിച്ച് ഒരു സ്നാപ്പ്ഷോട്ട് (snapshot) ആയി കാണുക. "പുതിയതായി എന്തെങ്കിലും സംഭവിച്ചോ?" എന്ന് ചോദിക്കുന്നതിന് പകരം, "നിലവിലെ അവസ്ഥ എന്താണ്?" എന്ന് ചോദിക്കുക. നിങ്ങൾ നിലവിലെ അവസ്ഥ പരിശോധിക്കുകയാണെങ്കിൽ, റീസ്റ്റാർട്ടുകൾ പ്രശ്നമാകില്ല.
റിക്കവറി സമയത്ത് ടൈംസ്റ്റാമ്പുകൾ റീസെറ്റ് ചെയ്യരുത്. ഒരു റീട്രൈ (retry) സമയത്ത് "started at" സമയം റീസെറ്റ് ചെയ്താൽ, ആ നിമിഷത്തിന് മുമ്പ് നടന്ന എല്ലാ കാര്യങ്ങളും നിങ്ങൾ ഇല്ലാതാക്കുന്നു. യഥാർത്ഥ ജോലിയിൽ മാറ്റം വരുമ്പോൾ മാത്രം ടൈംസ്റ്റാമ്പുകൾ റീസെറ്റ് ചെയ്യുക.
ടാസ്ക്കുകൾ പൂർത്തിയാകുന്നുണ്ടോ എന്ന് മാത്രം നോക്കാതെ, അവ എവിടെയാണ് തടസ്സപ്പെടുന്നത് എന്ന് നിരീക്ഷിക്കുക. "പൂർത്തിയായ" (done) എണ്ണം മാത്രം നോക്കുന്നത് നിങ്ങൾക്ക് ഒരു പ്രശ്നമുണ്ടെന്ന് അറിയിക്കും. എന്നാൽ ഓരോ ഘട്ടത്തിലും എത്ര ടാസ്ക്കുകൾ ഉണ്ടെന്ന് നോക്കിയാൽ പ്രശ്നം എവിടെയാണെന്ന് മനസ്സിലാക്കാം. "wait for review" എന്ന ഘട്ടത്തിൽ 28 ടാസ്ക്കുകൾ കുടുങ്ങിക്കിടക്കുന്നത് കണ്ടതുകൊണ്ടാണ് ഞങ്ങൾ ഈ പ്രശ്നം കണ്ടെത്തിയത്.
തെറ്റായ ഒരു നിയമം പിന്തുടരുന്ന ഒരു ലൈവ് പ്രോസസ്സ് ഒരിക്കലും ഹെൽത്ത് ചെക്കിൽ (health check) തെറ്റായി കാണിക്കില്ല. അത് പ്രോഗ്രാം ചെയ്തതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നതുകൊണ്ട് അത് കൃത്യമാണെന്ന് തോന്നും.
നിങ്ങൾ ഓട്ടോമേറ്റഡ് സിസ്റ്റങ്ങൾ നിർമ്മിക്കുകയാണെങ്കിൽ, പിശകുകൾക്കായി മാത്രം കാത്തുനിൽക്കരുത്. നിങ്ങളുടെ പ്രോസസ്സുകൾ എവിടെയാണ് കുമിഞ്ഞുകൂടുന്നത് എന്ന് ശ്രദ്ധിക്കുക.
Optional learning community: https://t.me/GyaanSetuAi
