ஒரு AI-ஆல் இயக்கப்படும் உதவியாளர் ஏழு நாட்களுக்கு எனது on-call பணிகளைக் கையாண்டார்; அவர் 11 எச்சரிக்கைகளை (alerts) கையாண்டு, ஒரு சிக்கலைத் தீர்ப்பதற்கான எனது சராசரி நேரத்தை 45 நிமிடங்களிலிருந்து 20 நிமிடங்களாகக் குறைத்தார். இந்தச் சோதனை முக்கியமானது ஏனெனில், ஒரு மிதமான அளவிலான மொழி மாதிரி (language model), கடுமையான மனித மேற்பார்வையுடன் இருக்கும்போது, ஒரு விபத்துக்கான பதிலளிக்கும் நேரத்தை (incident response) அரை மணி நேரம் வரை குறைக்க முடியும்.
நான் ஏன் ஒரு AI-ஐ on-call பணியில் அமர்த்தினேன்
கிளவுட் (Cloud) குழுக்கள் தங்கள் பணிநேரத்தின் பெரும்பகுதியை லாக்ஸ்களை (logs) ஆராய்வதிலும், சமீபத்திய வரிசைப்படுத்தல்களை (deployments) சரிபார்ப்பதிலும், ஒரு ஸ்கேலிங் (scaling) கோரிக்கை பாதுகாப்பானதா என்பதை உறுதிப்படுத்துவதிலும் செலவிடுகிறார்கள். அந்த "சலிப்பூட்டும்" பணிகள் மீண்டும் மீண்டும் செய்யக்கூடியவை, அதிக தரவுகளைக் கொண்டவை மற்றும் மனித சோர்வினால் தவறுகள் நடக்க வாய்ப்புள்ளவை. சமீபத்திய பெரிய மொழி மாதிரிகளின் (large language models) முன்னேற்றங்கள் இத்தகைய pattern-matching பணிகளைத் தானியக்கமாக்கக் கூடியவை என்று உறுதியளித்தன, ஆனால் பெரும்பாலான பொதுவான டெமோக்கள் sandbox சூழல்களில் மட்டுமே இயங்குகின்றன. உண்மையான வாடிக்கையாளர்களுக்குச் சேவை செய்யும் ஒரு production-grade கிளஸ்டரில் (cluster) இந்தத் தொழில்நுட்பம் எந்தளவுக்குச் சிறப்பாகச் செயல்படும் என்பதை நான் காண விரும்பினேன்.
சோதனை அமைப்பு (The test setup)
- அணுகல் (Access) – அந்த ஏஜென்ட் ஒவ்வொரு மெட்ரிக் (metric), லாக் (log) மற்றும் deployment வரையறையையும் படிக்க முடிந்தது. அது ஒரு குறிப்பிட்ட அனுமதிப்பட்ட பட்டியலில் (whitelist) மட்டுமே மாற்றங்களைச் செய்ய முடிந்தது: அதாவது ஒரு pod-ஐ மறுதொடக்கம் செய்வது, replica எண்ணிக்கையை அதிகரிப்பது அல்லது ஒரு deployment-ஐ ஸ்கேல் செய்வது. இவை தவிர மற்ற எந்தச் செயலுக்கும் எனது தெளிவான ஒப்புதல் தேவைப்பட்டது.
- பங்கு (Role) – முதல்முறை on-call பணியில் இருக்கும் ஒரு ஜூனியர் இன்ஜினியரைப் போல நான் அந்த மாதிரியை நடத்தினேன். அது எச்சரிக்கையைப் பெற்று, தனது ஆய்வை மேற்கொண்டு, அந்த விபத்து குறித்த சேனலில் (incident channel) ஒரு பரிந்துரையைப் பதிவிடும்.
- பாதுகாப்பு வலைகள் (Safety nets) – அனைத்து எழுதும் செயல்களும் (write actions) ஒரு கைமுறை "ஆம்/இல்லை" (yes/no) தூண்டுதலின் மூலம் கட்டுப்படுத்தப்பட்டன. செலவுகளைக் கணிக்கக்கூடிய வகையில் வைத்திருக்க, மாதிரியின் டோக்கன் பயன்பாட்டையும் (token usage) நான் வரம்பிற்குள் வைத்திருந்தேன்.
AI சிறப்பாகச் செயல்பட்ட இடங்கள்
ஏஜென்ட்டின் வேகம் மிகவும் குறிப்பிடத்தக்க முன்னேற்றமாக இருந்தது. ஒரு எச்சரிக்கை வந்தவுடன், அது தொடர்புடைய லாக்ஸ்களைப் பெற்று, சமீபத்திய மெட்ரிக்குகளை வரைபடமாக்கி, கடைசி மூன்று deployments பட்டியலை வழங்கியது. நான் எனது லேப்டாப்பைத் திறப்பதற்குள், ஆரம்பக்கட்டத் தேடல் வேலைகள் முடிந்துவிட்டன. 11 எச்சரிக்கைகளில்:
- 8 வழக்கமான சிக்கல்கள் (memory spikes, container restarts, simple misconfigurations). ஒவ்வொரு முறையும் AI சரியான மூல காரணத்தைக் கண்டறிந்தது.
- ஒரு மைக்ரோசர்வீஸில் (microservice) மெதுவாக அதிகரித்து வந்த மெமரி அளவை, அது அதிகப்படியான பாதிப்பாக (outage) மாறுவதற்கு முன்பே அது சுட்டிக்காட்டியது, இதனால் குழுவினர் முன்கூட்டியே தலையிட வாய்ப்பு கிடைத்தது.
- முழு வாரத்திற்கான டோக்கன் பயன்பாடு சுமார் $30 ஆக இருந்தது, இது வரம்புக்குள் இருக்கும்போது ஒரு சாதாரண on-call பட்ஜெட்டிற்குள் அடங்கும்.
இந்த முடிவுகள் சிக்கலைத் தீர்க்கும் சராசரி நேரத்தை (MTTR) 45 நிமிடங்களிலிருந்து 20 நிமிடங்களாகக் குறைப்பதன் மூலம், இன்ஜினியர்கள் அதிக தாக்கத்தை ஏற்படுத்தக்கூடிய பணிகளில் கவனம் செலுத்த வழிவகை செய்கின்றன.
அது தடுமாறிய இடங்கள்
தன்னம்பிக்கை என்பது சரியானத் தன்மைக்குச் சமமல்ல. 11 எச்சரிக்கைகளில் 3 எச்சரிக்கைகளில் AI மிகவும் நம்பிக்கையுடன் தவறான தகவல்களை வழங்கியது:
- ஒரு தரவுத்தள இணைப்புத் தோல்விக்கு (database connectivity failure) சமீபத்திய கோட் deployment-ஐக் காரணமாகக் கூறியது, ஆனால் அந்த விளக்கம் தவறானது.
- அறிமுகமில்லாத ஒரு நெட்வொர்க்கிங் முரண்பாட்டை (networking anomaly) எதிர்கொண்டபோது, அது அடிப்படையான சிக்கலைத் தீர்க்காத பொதுவான தீர்வுகளை வழங்கியது.
- லோடு (load) தொடர்பான ஒரு எச்சரிக்கையின் போது, ஒரு சேவையை 3-லிருந்து 30 replicas-ஆக ஸ்கேல் செய்யப் பரிந்துரைத்தது. அங்கு பிரச்சனை லோடு அல்ல; தவறான ஒரு கான்ஃபிகரேஷன் (config) தான்.
எந்தவொரு எழுதும் செயல்பாட்டிற்கும் எனது பாதுகாப்பு விதிமுறைகள் கைமுறை ஒப்புதலைக் கோரியதால், மாதிரியின் தவறுகள் பாதிப்பை ஏற்படுத்துவதற்கு முன்பே கண்டறியப்பட்டன. இருப்பினும், இந்தச் சம்பவம் ஒரு முக்கிய ஆபத்தை வெளிப்படுத்தியது: புதிய சிக்கல்களுக்கு, மாதிரி நம்பகமானதாகத் தோன்றும் ஆனால் துல்லியமற்ற பரிந்துரைகளை வழங்கக்கூடும்.
செலவு மற்றும் இடர் மேலாண்மை
$30 டோக்கன் கட்டணம் காட்டுகிறது என்னவென்றால், பயன்பாடு கண்காணிக்கப்பட்டால் ஒரு production லூப்பில் LLM-ஐ இயக்குவது மலிவாக இருக்கலாம். இருப்பினும், உண்மையான செலவு என்பது செயல்பாட்டு இடர் (operational risk) ஆகும். ஒரு deployment-ஐத் தவறாக ஸ்கேல் செய்வது அதிகப்படியான கிளவுட் செலவுக்கு வழிவகுக்கும், மேலும் ஒரு நல்ல வெளியீட்டை (release) ரத்து செய்வது வாடிக்கையாளர் நம்பிக்கையைச் சிதைக்கும். இந்தச் சோதனை இரண்டு பாதுகாப்பு நடவடிக்கைகளை உறுதிப்படுத்தியது:
- செயல் கட்டுப்பாடு (Action gating) – ஒரு மனிதனின் கிளிக் இல்லாமல், அதிக தாக்கத்தை ஏற்படுத்தக்கூடிய மாற்றங்களைச் செய்ய மாதிரியை அனுமதிக்காதீர்கள்; பரிந்துரைக்க மட்டுமே அனுமதிக்கவும்.
- பட்ஜெட் வரம்புகள் (Budget caps) – டோக்கன் பயன்பாட்டிற்குத் தெளிவான வரம்புகளை நிர்ணயித்து, மாதிரி அந்த வரம்பை நெருங்கும்போது குழுவிற்கு எச்சரிக்கை செய்யவும்.
அடுத்து கவனிக்க வேண்டியவை
அதுவரை, குழுக்கள் இவற்றைச் செய்ய வேண்டும்:
- கைமுறையாக மாற்றியமைக்க வேண்டிய AI-ஆல் உருவாக்கப்பட்ட பரிந்துரைகளின் விகிதத்தைக் கண்காணிக்கவும்.
- வெவ்வேறு விபத்து வகைகளில் (வழக்கமானவை vs புதியவை) MTTR மீதான தாக்கத்தை அளவிடவும்.
- தயாரிப்புச் சூழலில் (production) எழுதும் உரிமைகளை வழங்குவதற்கு முன், ஒரு ஸ்டேஜிங் (staging) சூழலில் செயற்கையான எச்சரிக்கைகளைக் கொண்டு மாதிரியைச் சோதிக்கவும்.
Ops குழுக்களுக்கான முக்கியக் கருத்துக்கள்
- சலிப்பூட்டும் 80% பணிகளைத் தானியக்கமாக்குங்கள் – லாக் ஒருங்கிணைப்பு (log aggregation), மெட்ரிக் தொடர்பு (metric correlation) மற்றும் ஆரம்பக்கட்ட கருதுகோள் உருவாக்கம் ஆகியவற்றிற்கு AI-ஐப் பயன்படுத்தவும்.
- ஆபத்தான 20% பணிகளை மனிதர்களுக்கென ஒதுக்குங்கள் – ஒரு குறிப்பிட்ட அளவைத் தாண்டி ஸ்கேல் செய்வது, ரத்து செய்தல் (rollbacks) மற்றும் நீக்குதல் (deletions) போன்ற செயல்பாடுகள் கைமுறை ஒப்புதல் படிநிலைக்குப் பின்னரே இருக்க வேண்டும்.
- மாதிரியை ஒரு மாற்றாகப் பார்க்காமல், ஒரு கூட்டாளியாகக் கருதுங்கள் – அமைப்பைப் பற்றித் தெரிந்த ஒரு இன்ஜினியரால், ஒரு புதியவரை விட AI-ன் வெளியீட்டை விரைவாகச் சரிபார்க்க முடியும், இது அந்த உதவியாளரை ஒரு பல மடங்கு சக்தியாக (force multiplier) மாற்றும்.
ஒரு AI முகவரால் இன்னும் ஒரு கிளவுட் செயல்பாட்டைத் தனியாக நடத்த முடியாது, ஆனால் ஒரு முன்னுரிமைத் தீர்மானிக்கும் கூட்டாளியாக அது ஏற்கனவே குறிப்பிடத்தக்க வேக அதிகரிப்பை வழங்குகிறது. நம்பிக்கையைச் சரியாகக் கட்டுப்படுத்துவதும், கடுமையான கட்டுப்பாடுகளை அமல்படுத்துவதும், மற்றும் மனித நிபுணத்துவம் முக்கியமான முடிவுகளை வழிநடத்தும் அதே வேளையில், மீண்டும் மீண்டும் செய்யப்படும் சலிப்பூட்டும் வேலைகளை அந்த மாடலிடமே ஒப்படைப்பதும் தான் இதன் முக்கியமாகும்.