ഒരു AI അസിസ്റ്റന്റ് ഏഴ് ദിവസം എന്റെ on-call ചുമതലകൾ നിർവ്വഹിച്ചു, 11 അലേർട്ടുകൾ (alerts) പ്രോസസ്സ് ചെയ്തു, കൂടാതെ ഒരു പ്രശ്നം പരിഹരിക്കാൻ എനിക്ക് എടുക്കുന്ന ശരാശരി സമയം 45 മിനിറ്റിൽ നിന്ന് 20 മിനിറ്റായി കുറയ്ക്കുകയും ചെയ്തു. ഒരു പരിമിതമായ സ്കോപ്പുള്ള ലാംഗ്വേജ് മോഡലിന് (language model) കർശനമായ മനുഷ്യ മേൽനോട്ടം ആവശ്യമാണെങ്കിലും, ഇൻസിഡന്റ് റെസ്പോൺസ് (incident response) സമയം പകുതിയായി കുറയ്ക്കാൻ സാധിക്കും എന്നതിനാലാണ് ഈ പരീക്ഷണം പ്രസക്തമാകുന്നത്.

എന്തുകൊണ്ടാണ് ഞാൻ ഒരു AI-യെ on-call ചുമതല ഏൽപ്പിച്ചത്

ക്ലൗഡ് ടീമുകൾ അവരുടെ ഷിഫ്റ്റ mayoría സമയവും ലോഗുകൾ (logs) പരിശോധിക്കാനും, സമീപകാല ഡിപ്ലോയ്‌മെന്റുകൾ (deployments) പരിശോധിക്കാനും, ഒരു സ്കെയിലിംഗ് റിക്വസ്റ്റ് (scaling request) സുരക്ഷിതമാണെന്ന് ഉറപ്പുവരുത്താനും ഉപയോഗിക്കുന്നു. ഇത്തരം "വിരസമായ" ജോലികൾ ആവർത്തന സ്വഭാവമുള്ളതും, ഡാറ്റാധിഷ്ഠിതവും, മനുഷ്യസഹജമായ തളർച്ചയ്ക്ക് സാധ്യതയുള്ളതുമാണ്. ലാർജ് ലാംഗ്വേജ് മോഡലുകളിലെ (large language models) സമീപകാല മുന്നേറ്റങ്ങൾ ഇത്തരത്തിലുള്ള പാറ്റേൺ മാച്ചിംഗ് (pattern-matching) ജോലികൾ ഓട്ടോമേറ്റ് ചെയ്യാമെന്ന് വാഗ്ദാനം ചെയ്യുന്നുണ്ടെങ്കിലും, മിക്ക പബ്ലിക് ഡെമോകളും sandbox എൻവയോൺമെന്റുകളിലാണ് നടക്കുന്നത്. യഥാർത്ഥത്തിൽ പണമടയ്ക്കുന്ന ഉപഭോക്താക്കൾ ഉപയോഗിക്കുന്ന ഒരു production-grade ക്ലസ്റ്ററിൽ ഈ സാങ്കേതികവിദ്യ എത്രത്തോളം ഫലപ്രദമാണെന്ന് എനിക്ക് പരിശോധിക്കണമെന്നുണ്ടായിരുന്നു.

പരീക്ഷണ ക്രമീകരണം

  • Access – ഏജന്റിന് എല്ലാ മെട്രിക്സുകളും (metrics), ലോഗുകളും, ഡിപ്ലോയ്‌മെന്റ് ഡെഫനിഷനുകളും വായിക്കാൻ കഴിയുമായിരുന്നു. ഒരു പരിമിതമായ whitelist-ലേക്ക് മാത്രമേ എഴുതാൻ (write) അനുവാദമുണ്ടായിരുന്നുള്ളൂ: ഒരു pod റീസ്റ്റാർട്ട് ചെയ്യുക, replica count വർദ്ധിപ്പിക്കുക, അല്ലെങ്കിൽ ഒരു deployment സ്കെയിൽ ചെയ്യുക. ഇവയ്ക്ക് അപ്പുറമുള്ള ഏതൊരു പ്രവർത്തനത്തിനും എന്റെ വ്യക്തമായ അനുമതി ആവശ്യമായിരുന്നു.
  • Role – ആദ്യത്തെ on-call ഷിഫ്റ്റിലായിരിക്കുന്ന ഒരു ജൂനിയർ എഞ്ചിനീയറെപ്പോലെയാണ് ഞാൻ ഈ മോഡലിനെ പരിഗണിച്ചത്. ഇത് അലേർട്ട് സ്വീകരിക്കുകയും, അതിന്റെ വിശകലനം നടത്തുകയും, incident channel-ൽ ഒരു ശുപാർശ നൽകുകയും ചെയ്യും.
  • Safety nets – എല്ലാ write ആക്ഷനുകളും ഒരു മാനുവൽ “yes/no” പ്രോംപ്റ്റിലൂടെയാണ് നിയന്ത്രിച്ചിരുന്നത്. ചിലവുകൾ മുൻകൂട്ടി നിശ്ചയിച്ച പരിധിയിൽ നിർത്താൻ ഞാൻ മോഡലിന്റെ token usage-ഉം പരിമിതപ്പെടുത്തിയിരുന്നു.

AI മികച്ച രീതിയിൽ പ്രവർത്തിച്ച ഇടങ്ങൾ

ഏജന്റിന്റെ വേഗതയായിരുന്നു ഏറ്റവും ശ്രദ്ധേയമായ നേട്ടം. ഒരു അലേർട്ട് വന്നാലുടൻ, അത് പ്രസക്തമായ ലോഗുകൾ ശേഖരിക്കുകയും, സമീപകാല മെട്രിക്സുകൾ പ്ലോട്ട് ചെയ്യുകയും, അവസാന മൂന്ന് ഡിപ്ലോയ്‌മെന്റുകൾ പട്ടികപ്പെടുത്തുകയും ചെയ്യും. ഞാൻ എന്റെ ലാപ്ടോപ്പ് തുറന്നു കഴിയുമ്പോഴേക്കും പ്രാഥമികമായ അന്വേഷണങ്ങൾ പൂർത്തിയായിട്ടുണ്ടാകും. 11 അലേർട്ടുകളിൽ:

  • 8 എണ്ണം സാധാരണ പ്രശ്നങ്ങളായിരുന്നു (memory spikes, container restarts, ലളിതമായ misconfigurations). ഓരോ തവണയും AI ശരിയായ മൂലകാരണം (root cause) കണ്ടെത്തി.
  • ഒരു microservice-ലെ മെമ്മറി വർദ്ധനവ് ഒരു വലിയ തകരാറിലേക്ക് (outage) മാറുന്നതിന് മുമ്പ് തന്നെ അത് തിരിച്ചറിഞ്ഞു, ഇത് ടീമിന് നേരത്തെ ഇടപെടാൻ അവസരം നൽകി.
  • ആകെ ആഴ്ചയിലെ token ഉപയോഗം ഏകദേശം $30 ആയിരുന്നു, ഇത് നിശ്ചിത പരിധിക്കുള്ളിൽ തന്നെയായിരുന്നു.

ഈ ഫലങ്ങൾ ശരാശരി പരിഹാര സമയം (MTTR) 45 മിനിറ്റിൽ നിന്ന് 20 മിനിറ്റായി കുറയ്ക്കാൻ സഹായിച്ചു, ഇത് എഞ്ചിനീയർമാർക്ക് കൂടുതൽ പ്രാധാന്യമുള്ള ജോലികളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ അവസരം നൽകുന്നു.

പിഴവുകൾ സംഭവിച്ച ഇടങ്ങൾ

ആത്മവിശ്വാസം എന്നാൽ കൃത്യതയല്ല. 11 അലേർട്ടുകളിൽ 3 എണ്ണത്തിൽ AI തെറ്റായ വിവരങ്ങൾ നൽകി:

  1. ഡാറ്റാബേസ് കണക്റ്റിവിറ്റി പരാജയത്തിന് കാരണം സമീപകാല കോഡ് ഡിപ്ലോയ്‌മെന്റ് ആണെന്ന് അത് തെറ്റായി ആരോപിച്ചു.
  2. പരിചിതമല്ലാത്ത ഒരു networking anomaly നേരിട്ടപ്പോൾ, അടിസ്ഥാന പ്രശ്നം പരിഹരിക്കാത്ത പൊതുവായ നിർദ്ദേശങ്ങൾ മാത്രമാണ് അത് നൽകിയത്.
  3. ഒരു load സംബന്ധമായ അലേർട്ട് സമയത്ത്, ഒരു സർവീസ് 3 റെപ്ലിക്കകളിൽ നിന്ന് 30 റെപ്ലിക്കകളിലേക്ക് സ്കെയിൽ ചെയ്യാൻ അത് നിർദ്ദേശിച്ചു. പ്രശ്നം load ആയിരുന്നില്ല, മറിച്ച് തെറ്റായ ഒരു config ആയിരുന്നു.

എന്റെ guardrails ഏതൊരു write ഓപ്പറേഷനും മാനുവൽ അനുമതി ആവശ്യപ്പെട്ടിരുന്നതിനാൽ, മോഡലിന്റെ തെറ്റുകൾ നാശനഷ്ടങ്ങൾ ഉണ്ടാക്കുന്നതിന് മുമ്പ് തന്നെ കണ്ടെത്താൻ കഴിഞ്ഞു. എന്നിരുന്നാലും, ഈ അനുഭവം ഒരു പ്രധാന റിസ്ക് ചൂണ്ടിക്കാണിക്കുന്നു: പുതിയ പ്രശ്നങ്ങളിൽ, മോഡൽ കേൾക്കാൻ നല്ലതാണെങ്കിലും തെറ്റായ ശുപാർശകൾ നൽകാൻ സാധ്യതയുണ്ട്.

Cost and risk management

ഉപയോഗം നിരീക്ഷിച്ചാൽ ഒരു production ലൂപ്പിൽ ഒരു LLM പ്രവർത്തിപ്പിക്കുന്നത് ചിലവ് കുറഞ്ഞതാണെന്ന് $30 ടോക്കൺ ബില്ല് കാണിക്കുന്നു. എന്നിരുന്നാലും, യഥാർത്ഥ ചിലവ് എന്നത് operational risk ആണ്. ഒരു deployment തെറ്റായി സ്കെയിൽ ചെയ്യുന്നത് ക്ലൗഡ് ചിലവ് കുതിച്ചുയരാൻ കാരണമായേക്കാം, കൂടാതെ ഒരു നല്ല റിലീസ് rollback ചെയ്യുന്നത് ഉപഭോക്താക്കളുടെ വിശ്വാസം നഷ്ടപ്പെടുത്തുകയും ചെയ്യും. പരീക്ഷണം രണ്ട് സുരക്ഷാ മാർഗങ്ങളെ ശക്തിപ്പെടുത്തി:

  • Action gating – മനുഷ്യന്റെ അനുമതിയില്ലാതെ ഉയർന്ന സ്വാധീനമുള്ള മാറ്റങ്ങൾ നിർദ്ദേശിക്കാൻ മാത്രം മോഡലിനെ അനുവദിക്കുക, ഒരിക്കലും അവ നടപ്പിലാക്കാൻ അനുവദിക്കരുത്.
  • Budget caps – token ഉപയോഗത്തിന് കർശനമായ പരിധി നിശ്ചയിക്കുകയും മോഡൽ ആ പരിധിക്കടുത്തെത്തുമ്പോൾ ടീമിനെ അറിയിക്കുകയും ചെയ്യുക.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

അതുവരെ, ടീമുകൾ ചെയ്യേണ്ടത്:

  • മാനുവൽ override ആവശ്യമായി വരുന്ന AI നിർദ്ദേശങ്ങളുടെ അനുപാതം ട്രാക്ക് ചെയ്യുക.
  • വിവിധ ഇൻസിഡന്റ് വിഭാഗങ്ങളിൽ (routine vs. novel) MTTR-ൽ ഉണ്ടാകുന്ന സ്വാധീനം അളക്കുക.
  • പ്രൊഡക്ഷനിൽ write rights നൽകുന്നതിന് മുമ്പ് synthetic അലേർട്ടുകൾ ഉപയോഗിച്ച് ഒരു staging എൻവയോൺമെന്റിൽ മോഡലിനെ പരീക്ഷിക്കുക.

Takeaways for ops teams

  • വിരസമായ 80% ഓട്ടോമേറ്റ് ചെയ്യുക – log aggregation, metric correlation, പ്രാഥമിക hypothesis generation എന്നിവയ്ക്കായി AI ഉപയോഗിക്കുക.
  • അപകടസാധ്യതയുള്ള 20% മനുഷ്യർക്കായി മാറ്റിവെക്കുക – ഒരു നിശ്ചിത പരിധിക്ക് മുകളിലുള്ള സ്കെയിലിംഗ്, rollbacks, ഡിലീഷനുകൾ എന്നിവ മാനുവൽ അനുമതി ഘട്ടത്തിന് ശേഷമായിരിക്കണം.
  • മോഡലിനെ ഒരു പങ്കാളിയായി കാണുക, പകരക്കാരനായല്ല – സിസ്റ്റത്തെക്കുറിച്ച് അറിയാവുന്ന ഒരു എഞ്ചിനീയർക്ക് ഒരു പുതിയ ആളേക്കാൾ വേഗത്തിൽ AI-യുടെ ഔട്ട്‌പുട്ട് പരിശോധിക്കാൻ കഴിയും, ഇത് അസിസ്റ്റന്റിനെ ഒരു force multiplier ആക്കി മാറ്റുന്നു.

ഒരു AI ഏജന്റിന് നിലവിൽ ഒരു ക്ലൗഡ് ഓപ്പറേഷൻ ഒറ്റയ്ക്ക് നടത്താൻ കഴിയില്ലെങ്കിലും, ഒരു ട്രിയേജ് പാർട്ണർ (triage partner) എന്ന നിലയിൽ അത് ഇതിനകം തന്നെ കാര്യമായ വേഗത നൽകുന്നുണ്ട്. മോഡലിന്റെ കോൺഫിഡൻസ് (confidence) നിയന്ത്രണത്തിലാക്കുക, കർശനമായ ഗാർഡ്‌റെയിലുകൾ (guardrails) നടപ്പിലാക്കുക, ആവർത്തന സ്വഭാവമുള്ള ജോലികൾ മോഡലിനെ ഏൽപ്പിക്കുക എന്നിവയാണ് ഇതിന്റെ പ്രധാന തന്ത്രം; അതേസമയം നിർണ്ണായകമായ തീരുമാനങ്ങൾ മനുഷ്യന്റെ വൈദഗ്ധ്യം ഉപയോഗിച്ച് എടുക്കേണ്ടതുമാണ്.