एका AI-चालित सहाय्यकाने सात दिवस माझ्या ऑन-कॉल (on-call) कर्तव्यांची जबाबदारी सांभाळली, ११ अलर्ट्सवर प्रक्रिया केली आणि समस्या सोडवण्यासाठी लागणारा माझा सरासरी वेळ ४५ मिनिटांवरून २० मिनिटांवर आणला. हा प्रयोग महत्त्वाचा आहे कारण मर्यादित व्याप्ती असलेले लँग्वेज मॉडेल (language model) मानवी देखरेखीखाली काम करताना इन्सिडेंट रिस्पॉन्सचा (incident response) वेळ अर्ध्या तासाने कमी करू शकते.
मी AI ला ऑन-कॉल का ठेवले
क्लाउड टीम्स त्यांच्या शिफ्टचा बराचसा वेळ लॉग्स (logs) तपासण्यात, अलीकडील डिप्लॉयमेंट्स (deployments) तपासण्यात आणि स्केलिंग रिक्वेस्ट (scaling request) सुरक्षित आहे की नाही याची खात्री करण्यात घालवतात. ही "कंटाळवाणी" कामे पुन्हा पुन्हा करावी लागणारी, डेटा-केंद्रित आणि मानवी थकव्यामुळे चुका होऊ शकणारी असतात. लार्ज लँग्वेज मॉडेल्समधील (large language models) अलीकडील प्रगती नेमके हेच पॅटर्न-मॅचिंग काम स्वयंचलित करण्याचे आश्वासन देते, परंतु बहुतेक सार्वजनिक डेमो सँडबॉक्स (sandbox) वातावरणात चालतात. प्रत्यक्ष पैसे देणाऱ्या ग्राहकांना सेवा देणाऱ्या प्रोडक्शन-ग्रेड क्लस्टरमध्ये (production-grade cluster) ही चर्चा खरी ठरते का, हे मला पाहायचे होते.
चाचणी सेटअप
- Access (प्रवेश) – एजंट प्रत्येक मेट्रिक (metric), लॉग आणि डिप्लॉयमेंट डेफिनेशन वाचू शकत होता. तो फक्त एका मर्यादित व्हाईटलिस्ट (whitelist) पर्यंतच बदल करू शकत होता: पॉड (pod) रीस्टार्ट करणे, रेप्लिका काउंट (replica count) वाढवणे किंवा डिप्लॉयमेंट स्केल करणे. या कृतींव्यतिरिक्त इतर कोणत्याही गोष्टीसाठी माझ्या स्पष्ट मंजुरीची आवश्यकता होती.
- Role (भूमिका) – मी या मॉडेलला त्याच्या पहिल्या ऑन-कॉल शिफ्टवरील ज्युनियर इंजिनिअरप्रमाणे वागवले. त्याला अलर्ट प्राप्त व्हायचा, त्याचे विश्लेषण करायचे आणि इन्सिडेंट चॅनेलमध्ये शिफारस (recommendation) पोस्ट करायची.
- Safety nets (सुरक्षा उपाय) – सर्व 'राईट' (write) कृतींसाठी मॅन्युअल "हो/नाही" प्रॉम्प्टची अट होती. खर्च अंदाजित ठेवण्यासाठी मी मॉडेलच्या टोकन वापराला (token usage) मर्यादाही घातली होती.
AI ने जिथे उत्कृष्ट कामगिरी केली
एजंटचा वेग ही सर्वात लक्षणीय प्रगती होती. अलर्ट येताच, त्याने संबंधित लॉग्स मिळवले, अलीकडील मेट्रिक्सचा आलेख काढला आणि शेवटच्या तीन डिप्लॉयमेंट्सची यादी दिली. मी माझा लॅपटॉप उघडण्यापूर्वीच प्राथमिक तपासणी पूर्ण झाली होती. ११ अलर्ट्सपैकी:
- ८ समस्या नियमित होत्या (मेमरी स्पाइक्स, कंटेनर रीस्टार्ट्स, साध्या चुकीच्या कॉन्फिगरेशनमुळे उद्भवलेल्या समस्या). AI ने प्रत्येक वेळी मूळ कारण (root cause) अचूकपणे ओळखले.
- एखादी समस्या पहाटे २ वाजता आउटेजमध्ये (outage) रूपांतरित होण्यापूर्वीच, त्याने एका मायक्रोसर्व्हिसमधील मेमरी हळूहळू वाढत असल्याचे सूचित केले, ज्यामुळे टीमला वेळेत हस्तक्षेप करण्याची संधी मिळाली.
- संपूर्ण आठवड्यासाठी टोकनचा खर्च $३० च्या आसपास राहिला, जो मर्यादित ठेवल्यास सामान्य ऑन-कॉल बजेटमध्ये येतो.
या निकालांमुळे मीन टाइम टू रिझोल्यूशन (MTTR) ४५ मिनिटांवरून २० मिनिटांपर्यंत कमी झाला, ज्यामुळे इंजिनिअर्सना अधिक महत्त्वाच्या कामांवर लक्ष केंद्रित करणे शक्य झाले.
जिथे चुका झाल्या
आत्मविश्वास म्हणजे अचूकता नव्हे. ११ पैकी ३ अलर्ट्समध्ये AI आत्मविश्वासाने चुकीची माहिती देत होते:
- त्याने डेटाबेस कनेक्टिव्हिटी फेल्युअरसाठी अलीकडील कोड डिप्लॉयमेंटला जबाबदार धरले, परंतु ते स्पष्टीकरण चुकीचे होते.
- अनोळखी नेटवर्किंग अनॉमली (networking anomaly) समोर आल्यावर, त्याने सामान्य उपाय सुचवले जे मूळ समस्येचे निराकरण करत नव्हते.
- लोड-संबंधित अलर्ट दरम्यान, त्याने सर्व्हिस ३ वरून ३० रेप्लिकांपर्यंत स्केल करण्याचा सल्ला दिला. समस्या लोडची नव्हती; तर चुकीच्या कॉन्फिगरेशनची होती.
माझ्या गार्डरेल्समुळे (guardrails) कोणत्याही 'राईट' ऑपरेशनसाठी मॅन्युअल मंजुरी आवश्यक असल्याने, मॉडेलच्या चुका नुकसान करण्यापूर्वीच पकडल्या गेल्या. तरीही, या घटनेने एक मुख्य जोखीम अधोरेखित केली: मॉडेल पटण्यासारखे वाटणारे पण चुकीचे शिफारसी देऊ शकते, विशेषतः नवीन समस्यांच्या बाबतीत.
खर्च आणि जोखीम व्यवस्थापन
$३० चे टोकन बिल हे दर्शवते की जर वापरवर लक्ष ठेवले तर प्रोडक्शन लूपमध्ये LLM चालवणे स्वस्त असू शकते. तथापि, खरी किंमत म्हणजे ऑपरेशनल रिस्क (operational risk). डिप्लॉयमेंट चुकीच्या पद्धतीने स्केल केल्यामुळे क्लाउडचा खर्च अनियंत्रित वाढू शकतो आणि एखादे चांगले रिलीज रोलबॅक केल्यामुळे ग्राहकांचा विश्वास कमी होऊ शकतो. या प्रयोगाने दोन सुरक्षा उपाय अधिक दृढ केले:
- Action gating (कृती नियंत्रण) – मॉडेलला फक्त शिफारसी सुचवू द्या, मानवी क्लिकशिवाय उच्च-प्रभाव (high-impact) बदल कधीही कार्यान्वित करू देऊ नका.
- Budget caps (बजेट मर्यादा) – टोकन वापरासाठी कडक मर्यादा निश्चित करा आणि मॉडेल मर्यादेच्या जवळ पोहोचले की टीमला अलर्ट करा.
पुढे काय पाहावे
तोपर्यंत, टीम्सनी खालील गोष्टी कराव्यात:
- मॅन्युअल ओव्हरराइडची (manual override) आवश्यकता असलेल्या AI-जनरेटेड शिफारसींचे प्रमाण ट्रॅक करा.
- विविध इन्सिडेंट कॅटेगरीमध्ये (नियमित विरुद्ध नवीन) MTTR वर होणारा परिणाम मोजा.
- प्रोडक्शनमध्ये 'राईट' अधिकार देण्यापूर्वी, सिंथेटिक अलर्ट्ससह स्टेजिंग (staging) वातावरणात मॉडेलची चाचणी घ्या.
ऑप्स (ops) टीम्ससाठी महत्त्वाचे मुद्दे
- ८०% कंटाळवाणी कामे स्वयंचलित करा – लॉग अॅग्रिगेशन (log aggregation), मेट्रिक कोरिलेशन (metric correlation) आणि प्राथमिक हायपोथेसिस जनरेशनसाठी AI चा वापर करा.
- धोकादायक २०% मानवासाठी राखून ठेवा – ठराविक मर्यादेपेक्षा जास्त स्केलिंग, रोलबॅक आणि डिलीशन यांसारख्या गोष्टी मॅन्युअल मंजुरीच्या प्रक्रियेखाली असायला हव्यात.
- मॉडेलला भागीदार समजा, पर्याय नाही – सिस्टीम माहित असलेल्या इंजिनिअरला नवीन व्यक्तीपेक्षा AI चे आउटपुट वेगाने तपासता येते, ज्यामुळे हा सहाय्यक कामाचा वेग वाढवणारा (force multiplier) ठरतो.
एक AI एजंट अजूनही क्लाउड ऑपरेशन एकट्याने चालवू शकत नाही, परंतु ट्रायज पार्टनर म्हणून ते आधीच प्रत्यक्ष वेगवान प्रगती मिळवून देते. मुख्य सूत्र म्हणजे आत्मविश्वासावर नियंत्रण ठेवणे, कडक गार्डरेल्स लागू करणे आणि मॉडेलला पुनरावृत्ती होणारी कंटाळवाणी कामे हाताळू देणे, तर मानवी तज्ज्ञता महत्त्वपूर्ण निर्णय घेण्याचे काम करेल.