ఒక AI-ఆధారిత అసిస్టెంట్ ఏడు రోజుల పాటు నా ఆన్-కాల్ (on-call) విధులను నిర్వహించింది, 11 అలర్ట్లను ప్రాసెస్ చేసింది మరియు సమస్యను పరిష్కరించడానికి పట్టే నా సగటు సమయాన్ని 45 నిమిషాల నుండి 20 నిమిషాలకు తగ్గించింది. ఈ ప్రయోగం ఎందుకు ముఖ్యమంటే, ఒక పరిమిత పరిధి కలిగిన లాంగ్వేజ్ మోడల్ (language model), కఠినమైన మానవ పర్యవేక్షణను కోరుతూనే, ఇన్సిడెంట్ రెస్పాన్స్ (incident response) సమయాన్ని అరగంట వరకు తగ్గించగలదు.
నేను ఎందుకు AIని ఆన్-కాల్లో ఉంచాను
క్లౌడ్ టీమ్లు తమ షిఫ్ట్లో ఎక్కువ సమయాన్ని లాగ్లను (logs) వెతకడం, ఇటీవలి డిప్లాయ్మెంట్లను (deployments) తనిఖీ చేయడం మరియు స్కేలింగ్ రిక్వెస్ట్ సురక్షితమేనా అని నిర్ధారించుకోవడంలో గడుపుతారు. ఆ "బోరింగ్" పనులు పునరావృతమయ్యేవి, డేటా-భారీ మరియు మానవ అలసటకు లోనయ్యేవి. లార్జ్ లాంగ్వేజ్ మోడల్స్లో (large language models) ఇటీవలి పురోగతి సరిగ్గా ఇటువంటి ప్యాటర్న్-మ్యాచ్యింగ్ (pattern-matching) పనులను ఆటోమేట్ చేయగలదని వాగ్దానం చేసింది, కానీ చాలా పబ్లిక్ డెమోలు శాండ్బాక్స్ (sandbox) వాతావరణాలలో నడుస్తాయి. నిజంగా చెల్లింపు కస్టమర్లకు సేవలు అందించే ప్రొడక్షన్-గ్రేడ్ క్లస్టర్లో (production-grade cluster) ఈ హైప్ (hype) ఎంతవరకు నిజమో నేను చూడాలనుకున్నాను.
టెస్ట్ సెటప్
- Access – ఏజెంట్ ప్రతి మెట్రిక్, లాగ్ మరియు డిప్లాయ్మెంట్ డెఫినిషన్ను చదవగలదు. ఇది కేవలం ఒక పరిమిత వైట్లిస్ట్ (whitelist) కి మాత్రమే రాయగలదు: ఒక పాడ్ను (pod) రీస్టార్ట్ చేయడం, రెప్లికా కౌంట్ను (replica count) పెంచడం లేదా డిప్లాయ్మెంట్ను స్కేల్ చేయడం. ఆ చర్యల కంటే మించిన దేనికైనా నా స్పష్టమైన అనుమతి అవసరం.
- Role – నేను ఈ మోడల్ను తన మొదటి ఆన్-కాల్ షిఫ్ట్లో ఉన్న జూనియర్ ఇంజనీర్గా పరిగణించాను. ఇది అలర్ట్ను అందుకుని, దాని విశ్లేషణను నిర్వహించి, ఇన్సిడెంట్ ఛానల్లో ఒక సిఫార్సును (recommendation) పోస్ట్ చేస్తుంది.
- Safety nets – అన్ని రైట్ యాక్షన్స్ (write actions) మాన్యువల్ “yes/no” ప్రాంప్ట్ ద్వారా నియంత్రించబడ్డాయి. ఖర్చులను అంచనా వేయగలిగేలా ఉండటానికి నేను మోడల్ యొక్క టోకెన్ వినియోగాన్ని కూడా పరిమితం చేశాను.
AI ఎక్కడ మెరిసింది
ఏజెంట్ యొక్క వేగం అత్యంత గమనించదగిన లాభం. అలర్ట్ రాగానే, అది సంబంధిత లాగ్లను సేకరించి, ఇటీవలి మెట్రిక్స్ను ప్లాట్ చేసి, చివరి మూడు డిప్లాయ్మెంట్లను జాబితా చేస్తుంది. నేను నా లాప్టాప్ తెరవకముందే, ప్రాథమిక పరిశోధన పూర్తయి ఉంటుంది. 11 అలర్ట్లలో:
- 8 సాధారణ సమస్యలు (మెమరీ స్పైక్స్, కంటైనర్ రీస్టార్ట్లు, సాధారణ మిస్ కాన్ఫిగరేషన్లు). AI ప్రతిసారీ మూల కారణాన్ని (root cause) సరిగ్గా గుర్తించింది.
- సమస్య రాత్రి 2 గంటల సమయంలో అవుటేజ్గా (outage) మారకముందే, ఒక మైక్రోసర్వీస్లో క్రమంగా పెరుగుతున్న మెమరీని ఇది గుర్తించి, టీమ్కు ముందుగానే స్పందించే అవకాశం ఇచ్చింది.
- మొత్తం వారం టోకెన్ వినియోగం సుమారు $30 వద్దే ఉంది, ఇది పరిమితం చేసినప్పుడు సాధారణ ఆన్-కాల్ బడ్జెట్లోనే ఉంటుంది.
ఈ ఫలితాలు సగటు పరిష్కార సమయం (mean time to resolution - MTTR) 45 నిమిషాల నుండి 20 నిమిషాలకు గణనీయంగా తగ్గడానికి దోహదపడ్డాయి, దీనివల్ల ఇంజనీర్లు అధిక ప్రభావం చూపే పనులపై దృష్టి సారించవచ్చు.
ఎక్కడ తడబడింది
నమ్మకం అంటే ఖచ్చితత్వం అని కాదు. 11 అలర్ట్లలో 3 అలర్ట్లపై AI నమ్మకంగా తప్పు సమాచారాన్ని ఇచ్చింది:
- డేటాబేస్ కనెక్టివిటీ వైఫల్యానికి ఇటీవలి కోడ్ డిప్లాయ్మెంట్ను కారణం చేసింది, కానీ ఆ వివరణ తప్పు.
- తెలియని నెట్వర్కింగ్ అనోమలీ (networking anomaly) ఎదురైనప్పుడు, అది ప్రాథమిక సమస్యను పరిష్కరించలేని సాధారణ పరిష్కారాలను (generic fixes) సూచించింది.
- లోడ్-సంబంధిత అలర్ట్ సమయంలో, అది సర్వీస్ను 3 నుండి 30 రెప్లికాలకు స్కేల్ చేయాలని సూచించింది. సమస్య లోడ్ కాదు; ఒక తప్పుడు కాన్ఫిగరేషన్ (bad config).
నా గార్డ్రైల్స్ (guardrails) వల్ల ఏదైనా రైట్ ఆపరేషన్ కోసం మాన్యువల్ అనుమతి అవసరమైంది, కాబట్టి మోడల్ చేసిన తప్పులు నష్టం కలిగించకముందే పట్టుబడ్డాయి. అయినప్పటికీ, ఈ సంఘటన ఒక ప్రధాన రిస్క్ను నొక్కి చెప్పింది: మోడల్ నమ్మశక్యంగా అనిపించే కానీ తప్పుగా ఉండే సిఫార్సులను చేయగలదు, ముఖ్యంగా కొత్త సమస్యల విషయంలో.
ఖర్చు మరియు రిస్క్ మేనేజ్మెంట్
$30 టోకెన్ బిల్లు చూపిస్తున్నదేమిటంటే, వినియోగాన్ని పర్యవేక్షిస్తే ప్రొడక్షన్ లూప్లో LLMని నడపడం చౌకగా ఉండవచ్చు. అయితే, అసలు ఖర్చు ఆపరేషనల్ రిస్క్ (operational risk). డిప్లాయ్మెంట్ను తప్పుగా స్కేల్ చేయడం వల్ల క్లౌడ్ ఖర్చులు పెరగవచ్చు మరియు మంచి రిలీజ్ను రోల్బ్యాక్ (rollback) చేయడం వల్ల కస్టమర్ నమ్మకం దెబ్బతినవచ్చు. ఈ ప్రయోగం రెండు రక్షణ చర్యలను బలపరిచింది:
- Action gating – మోడల్ను కేవలం సూచించడానికి మాత్రమే అనుమతించండి, మానవ క్లిక్ లేకుండా అధిక ప్రభావం చూపే మార్పులను అమలు చేయనివ్వకండి.
- Budget caps – టోకెన్ వినియోగంపై కఠినమైన పరిమితులను విధించండి మరియు మోడల్ గరిష్ట స్థాయికి చేరువవుతున్నప్పుడు టీమ్కు అలర్ట్ చేయండి.
తదుపరి ఏమి గమనించాలి
అప్పటి వరకు, టీమ్లు వీటిని చేయాలి:
- మాన్యువల్ ఓవర్రైడ్ (manual override) అవసరమయ్యే AI-జనరేటెడ్ సూచనల నిష్పత్తిని ట్రాక్ చేయండి.
- వివిధ ఇన్సిడెంట్ కేటగిరీల (routine vs. novel) ద్వారా MTTR పై ప్రభావాన్ని కొలవండి.
- ప్రొడక్షన్లో రైట్ రైట్స్ (write rights) ఇవ్వకముందే, సింథటిక్ అలర్ట్లతో స్టేజింగ్ ఎన్విరాన్మెంట్లో (staging environment) మోడల్ను పరీక్షించండి.
ఆప్స్ (ops) టీమ్ల కోసం ముఖ్యాంశాలు
- బోరింగ్ 80% ని ఆటోమేట్ చేయండి – లాగ్ అగ్రిగేషన్ (log aggregation), మెట్రిక్ కోరిలేషన్ (metric correlation) మరియు ప్రాథమిక హైపోథెసిస్ జనరేషన్ (hypothesis generation) కోసం AIని ఉపయోగించండి.
- రిస్క్ ఉన్న 20% ని మనుషుల కోసం ఉంచండి – ఒక పరిమితి కంటే ఎక్కువ స్కేలింగ్ చేయడం, రోల్బ్యాక్లు (rollbacks) మరియు డిలీషన్లు మాన్యువల్ అప్రూవల్ స్టెప్ వెనుక ఉండాలి.
- మోడల్ను ఒక భాగస్వామిగా చూడండి, రీప్లేస్మెంట్గా కాదు – సిస్టమ్ను తెలిసిన ఇంజనీర్ కొత్త వ్యక్తి కంటే AI అవుట్పుట్ను వేగంగా ధృవీకరించగలరు, తద్వారా ఈ అసిస్టెంట్ను ఒక ఫోర్స్ మల్టిప్లైయర్గా (force multiplier) మార్చవచ్చు.
ఒక AI ఏజెంట్ ఇంకా క్లౌడ్ ఆపరేషన్ను ఒంటరిగా నిర్వహించలేదు, కానీ ఒక triage partnerగా ఇది ఇప్పటికే గణనీయమైన వేగవంతమైన ఫలితాలను అందిస్తోంది. నమ్మకాన్ని నియంత్రణలో ఉంచడం, కఠినమైన guardrailsను అమలు చేయడం మరియు మానవ నైపుణ్యం కీలకమైన నిర్ణయాలను నడిపిస్తున్నప్పుడు, మోడల్ పునరావృతమయ్యే శ్రమతో కూడిన పనులను నిర్వహించనివ్వడమే దీనికి కీలకం.