एक AI-संचालित असिस्टेंट ने सात दिनों तक मेरी ऑन-कॉल (on-call) ड्यूटी संभाली, 11 अलर्ट्स को प्रोसेस किया और समस्या को ठीक करने के मेरे औसत समय को 45 मिनट से घटाकर 20 मिनट कर दिया। यह प्रयोग महत्वपूर्ण है क्योंकि एक सीमित दायरे वाला लैंग्वेज मॉडल सख्त मानवीय निगरानी के साथ-साथ इंसिडेंट रिस्पॉन्स (incident response) के समय को आधा घंटा कम कर सकता है।
मैंने AI को ऑन-कॉल पर क्यों रखा
क्लाउड टीमें अपनी शिफ्ट का अधिकांश समय लॉग्स (logs) खंगालने, हालिया डिप्लॉयमेंट (deployments) की जांच करने और यह पुष्टि करने में बिताती हैं कि स्केलिंग रिक्वेस्ट सुरक्षित है या नहीं। वे "उबाऊ" कार्य दोहराने योग्य, डेटा-भारी और मानवीय थकान के प्रति संवेदनशील होते हैं। लार्ज लैंग्वेज मॉडल्स (LLMs) में हालिया प्रगति ने ठीक इसी तरह के पैटर्न-मैचिंग काम को ऑटोमेट करने का वादा किया है, लेकिन अधिकांश सार्वजनिक डेमो सैंडबॉक्स वातावरण (sandbox environments) में चलते हैं। मैं यह देखना चाहता था कि क्या यह हाइप एक प्रोडक्शन-ग्रेड क्लस्टर (production-grade cluster) में भी कायम रहता है जो वास्तव में भुगतान करने वाले ग्राहकों को सेवा देता है।
टेस्ट सेटअप
- एक्सेस (Access) – एजेंट हर मेट्रिक, लॉग और डिप्लॉयमेंट डेफिनेशन को पढ़ सकता था। यह केवल एक सीमित व्हाइटलिस्ट (whitelist) तक ही लिख सकता था: पॉड (pod) को रीस्टार्ट करना, रेप्लिका काउंट (replica count) बढ़ाना, या किसी डिप्लॉयमेंट को स्केल करना। इन कार्यों के अलावा किसी भी चीज़ के लिए मेरी स्पष्ट स्वीकृति की आवश्यकता थी।
- भूमिका (Role) – मैंने मॉडल को अपनी पहली ऑन-कॉल शिफ्ट वाले एक जूनियर इंजीनियर की तरह माना। इसे अलर्ट प्राप्त होता था, यह अपना विश्लेषण करता था, और इंसिडेंट चैनल में एक सिफारिश (recommendation) पोस्ट करता था।
- सेफ्टी नेट (Safety nets) – सभी राइट (write) एक्शन एक मैनुअल "हाँ/नहीं" प्रॉम्प्ट के पीछे सुरक्षित थे। मैंने लागत को अनुमानित रखने के लिए मॉडल के टोकन उपयोग (token usage) की सीमा भी तय कर दी थी।
जहाँ AI ने कमाल दिखाया
एजेंट की गति सबसे उल्लेखनीय लाभ थी। जैसे ही कोई अलर्ट आता, यह संबंधित लॉग्स निकाल लेता, हालिया मेट्रिक्स का चार्ट बनाता और पिछले तीन डिप्लॉयमेंट की सूची देता। जब तक मैं अपना लैपटॉप खोलता, शुरुआती जांच का काम पहले ही हो चुका होता। 11 अलर्ट्स में से:
- 8 रूटीन समस्याएं थीं (मेमोरी स्पाइक्स, कंटेनर रीस्टार्ट, साधारण गलत कॉन्फ़िगरेशन)। AI ने हर बार सही ढंग से मूल कारण (root cause) की पहचान की।
- इसने समस्या के रात 2 बजे आउटेज (outage) में बदलने से पहले ही एक माइक्रोसर्विस में मेमोरी के धीरे-धीरे बढ़ने की चेतावनी दे दी, जिससे टीम को समय रहते हस्तक्षेप करने का मौका मिला।
- पूरे सप्ताह का टोकन उपभोग (token consumption) लगभग $30 रहा, जो सीमा तय होने पर एक सामान्य ऑन-कॉल बजट के भीतर ही था।
इन परिणामों से मीन टाइम टू रेजोल्यूशन (MTTR) में 45 मिनट से घटकर 20 मिनट तक की मापने योग्य कमी आई, जिससे इंजीनियरों को उच्च-प्रभाव वाले कार्यों पर ध्यान केंद्रित करने की स्वतंत्रता मिली।
जहाँ यह लड़खड़ाया
आत्मविश्वास का अर्थ सटीकता नहीं है। AI 11 में से 3 अलर्ट्स पर आत्मविश्वास के साथ गलत था:
- इसने डेटाबेस कनेक्टिविटी विफलता के लिए हालिया कोड डिप्लॉयमेंट को जिम्मेदार ठहराया, लेकिन वह स्पष्टीकरण गलत था।
- जब किसी अपरिचित नेटवर्किंग विसंगति (anomaly) का सामना करना पड़ा, तो इसने सामान्य समाधान दिए जो अंतर्निहित समस्या का समाधान नहीं कर पाए।
- लोड से संबंधित अलर्ट के दौरान, इसने एक सर्विस को 3 से बढ़ाकर 30 रेप्लिका करने का सुझाव दिया। समस्या लोड नहीं थी; एक गलत कॉन्फ़िगरेशन थी।
क्योंकि मेरे गार्डरेल्स (guardrails) में किसी भी राइट ऑपरेशन के लिए मैनुअल अप्रूवल की आवश्यकता थी, इसलिए मॉडल की गलतियों को नुकसान पहुँचाने से पहले ही पकड़ लिया गया। फिर भी, इस घटना ने एक मुख्य जोखिम को उजागर किया: मॉडल विश्वसनीय लगने वाले लेकिन गलत सुझाव दे सकता है, खासकर नई समस्याओं के लिए।
लागत और जोखिम प्रबंधन
$30 का टोकन बिल दिखाता है कि यदि उपयोग की निगरानी की जाए, तो प्रोडक्शन लूप में LLM चलाना सस्ता हो सकता है। हालाँकि, वास्तविक लागत परिचालन जोखिम (operational risk) है। डिप्लॉयमेंट को गलत तरीके से स्केल करने से क्लाउड खर्च अनियंत्रित हो सकता है, और एक अच्छे रिलीज़ को रोलबैक करने से ग्राहकों का भरोसा कम हो सकता है। इस प्रयोग ने दो सुरक्षा उपायों की पुष्टि की:
- एक्शन गेटिंग (Action gating) – मॉडल को केवल सुझाव देने की अनुमति दें, किसी भी उच्च-प्रभाव वाले बदलाव को बिना मानवीय क्लिक के निष्पादित (execute) करने की अनुमति कभी न दें।
- बजट कैप्स (Budget caps) – टोकन उपभोग पर सख्त सीमाएं निर्धारित करें और जब मॉडल सीमा के करीब पहुंचे तो टीम को अलर्ट करें।
आगे क्या देखें
तब तक, टीमों को चाहिए कि वे:
- AI-जनरेटेड सुझावों के उस अनुपात को ट्रैक करें जिसके लिए मैनुअल ओवरराइड की आवश्यकता होती है।
- विभिन्न इंसिडेंट श्रेणियों (रूटीन बनाम नई) में MTTR पर प्रभाव को मापें।
- प्रोडक्शन में राइट राइट्स (write rights) देने से पहले सिंथेटिक अलर्ट्स के साथ स्टेजिंग वातावरण (staging environment) में मॉडल का परीक्षण करें।
ऑप्स (ops) टीमों के लिए मुख्य बातें
- उबाऊ 80% को ऑटोमेट करें – लॉग एग्रीगेशन, मेट्रिक कोरिलेशन और प्रारंभिक परिकल्पना (hypothesis) जनरेशन के लिए AI का उपयोग करें।
- जोखिम भरे 20% इंसानों के लिए सुरक्षित रखें – एक मध्यम सीमा से अधिक स्केलिंग, रोलबैक और डिलीशन को मैनुअल अप्रूवल स्टेप के पीछे ही रहना चाहिए।
- मॉडल को एक पार्टनर के रूप में देखें, रिप्लेसमेंट के रूप में नहीं – सिस्टम को जानने वाला इंजीनियर किसी नए व्यक्ति की तुलना में AI के आउटपुट को तेज़ी से सत्यापित कर सकता है, जिससे असिस्टेंट एक 'फोर्स मल्टीप्लायर' (force multiplier) बन जाता है।
एक AI एजेंट अभी अकेले क्लाउड ऑपरेशन नहीं चला सकता, लेकिन एक ट्राइएज पार्टनर के रूप में यह पहले से ही गति में ठोस वृद्धि प्रदान कर रहा है। मुख्य बात यह है कि आत्मविश्वास को नियंत्रण में रखा जाए, सख्त गार्डरेल्स लागू किए जाएं, और मॉडल को दोहराव वाले उबाऊ काम संभालने दिया जाए, जबकि मानवीय विशेषज्ञता महत्वपूर्ण निर्णयों का मार्गदर्शन करे।