कुछ दिन पहले हमने प्रोडक्शन में चल रहे वर्चुअलाइज़ेशन प्लेटफ़ॉर्म में एक नया सर्वर node जोड़ा। यह काम हमने AI एजेंट (Claude) के साथ बाँटकर किया, इसलिए उसका रिकॉर्ड यहाँ छोड़ रहा हूँ।

निष्कर्ष पहले बता दूँ — भूमिकाओं का बँटवारा काफ़ी अच्छी तरह बैठ गया। लेकिन यह कहानी ऐसी नहीं है कि “AI को सौंप दिया तो सब कुछ ठीक हो गया”। बल्कि उल्टा — गंभीर हादसों को रोकने वाले फ़ैसले सभी इंसान की तरफ़ से आए। उसे भी शामिल करके लिख रहा हूँ।

बँटवारा असल में कैसा रहा #

भौतिक काम इंसान का, तार्किक काम AI का। मोटे तौर पर बस इतना ही। लेकिन जैसा आगे बताया है, “क्या ख़तरनाक है” यह जानने वाला इंसान ही था।

जहाँ AI काम आया: मेहनत की मात्रा, दोहराव, मिलान #

AI साफ़ तौर पर वहाँ मज़बूत था जहाँ काम उबाऊ था, मात्रा में बहुत था, और ग़लती होने पर महँगा पड़ता था।

1. वर्शन का पूरी तरह मेल #

मौजूदा cluster में हम सभी node के वर्शन सख़्ती से एक जैसे रखते हैं। नया node OS इंस्टॉल के तुरंत बाद वाली स्थिति में था, जहाँ package कई पीढ़ी पुराने थे।

अगर सीधे “latest पर अपडेट” कर दें तो वह मौजूदा cluster से नया हो जाएगा, यानी हमारी संचालन नीति से बाहर। और अगर कोई ख़ास वर्शन तय करें, तो dependency हल नहीं होती और इंस्टॉल फ़ेल हो जाता है।

AI ने error message से कारण अलग-अलग करके पहचाना (संबंधित सारे package एक साथ न बताएँ तो पुराने वर्शन बचे रह जाते हैं और टकराव होता है / इस चरण पर जो सर्वर-साइड कंपोनेंट लगना ही नहीं चाहिए था, वह खिंचकर आ जाने से काम अटक गया था), और अंत में मौजूदा node से हूबहू एक जैसा वर्शन कॉन्फ़िगरेशन बना दिया। इस तरह की आज़माइश में इंसान का ध्यान टिकता नहीं है।

2. सभी node के बीच अंतर की जाँच #

node जोड़ने के बाद, क्या सभी node पर शेयर्ड स्टोरेज एक जैसा दिखता है, यह हमने एक-एक करके जाँचा। जितनी मशीनें बढ़ती हैं, हाथ से करने पर उतना ही मन करता है कि “शायद ठीक ही होगा” कहकर आगे बढ़ जाएँ।

AI सभी मशीनों पर एक ही command चलाकर, टेबल बनाकर अंतर निकालने का काम बिना ऊबे करता रहता है। नतीजा यह कि नया node मौजूदा node जैसी बिल्कुल एक जैसी स्थिति में है, यह हम अंदाज़े से नहीं बल्कि असल माप से पक्का कर पाए।

3. “दोनों सिरों” पर प्रमाण का मिलान #

लिंक एग्रीगेशन (LACP) की जाँच में हमने सिर्फ़ सर्वर की तरफ़ नहीं, बल्कि स्विच की तरफ़ की स्थिति का भी मिलान किया। ख़ास तौर पर, सर्वर की तरफ़ जो सामने वाले उपकरण का identifier दिख रहा है, वह जिस स्विच से जोड़ना तय था उसी का है या नहीं, यहाँ तक जाँचा। यह “लिंक ऊपर आ गया” का नहीं, बल्कि “जिससे जोड़ना था उसी से, और जिस सेटिंग से जोड़ना था उसी से जुड़ा है” का प्रमाण है।

AI ने जो ढूँढा: दिखने में मामूली, पर ख़तरनाक #

काम के दौरान कुछ ऐसी समस्याएँ थीं जो AI ने “बिना कहे ही ढूँढ निकालीं”।

boot क्रम में पिछले OS का मलबा #

एक node के UEFI boot क्रम में सबसे ऊपर, पहले इंस्टॉल किए गए किसी दूसरे OS की एंट्री बची हुई थी। असल में वह डिस्क पर मौजूद ही नहीं है, इसलिए उससे boot नहीं हो सकता, और उसके बाद network boot की एंट्रियाँ लगी थीं — सही एंट्री सातवें नंबर पर।

अगर इसी हालत में reboot करते, तो वह न मौजूद OS को ढूँढता, network boot के timeout का देर तक इंतज़ार करता, और क़िस्मत ख़राब होती तो कोई अनचाही चीज़ boot हो जाती। reboot करने से पहले यह पकड़ में आ गया, यह बड़ी बात थी।

समय की शृंखलाबद्ध ख़राबी (यह सबसे दिलचस्प है) #

एक दूसरे node पर package अपडेट पूरी तरह फ़ेल हो गए। error था — “repository की जानकारी अभी अपनी वैधता अवधि से पहले की है (901 दिन बाक़ी)”।

पीछे जाकर देखा तो शृंखला कुछ ऐसी थी।

1. हार्डवेयर क्लॉक (RTC) 1998 दिखा रहा था (बैटरी ख़त्म होने का शक है)
2. OS ने इसे असामान्य मानकर समय को OS के build समय तक आगे बढ़ा दिया (= लगभग 2.5 साल पहले)
3. समय समन्वय इंटरनेट पर मौजूद NTP सर्वर को देखने के लिए सेट था, लेकिन DNS सेटिंग ख़राब थी इसलिए वह पता resolve नहीं हो सका, और सिंक सोर्स शून्य रहे
4. → समय 2.5 साल पीछे ही रहा → package मैनेजमेंट सिस्टम ने repository को “भविष्य का हस्ताक्षर” मानकर सब कुछ ठुकरा दिया

“package इंस्टॉल नहीं होते” की असली वजह “DNS ख़राब है” निकली — चार कड़ियों की शृंखला। DNS ठीक करके समय समन्वय दोबारा चालू किया तो पलक झपकते हल हो गया।

और यह, अगर यूँ ही छोड़ देते तो cluster में शामिल होने के बाद असर दिखाता। वितरित सिस्टम node के बीच समय के अंतर के प्रति संवेदनशील होते हैं, और 2.5 साल पीछे चल रहे node को प्रोडक्शन cluster में डालना तो सवाल ही नहीं उठता।

सेटिंग “चुपचाप फ़ेल” हो रही थी #

नेटवर्क की परफ़ॉर्मेंस ट्यूनिंग करने वाली व्यवस्था, boot के समय उसका लक्ष्य अभी मौजूद ही नहीं था, इसलिए कुछ किए बिना सामान्य रूप से ख़त्म हो जाती थी। कोई error नहीं आता। log में तो सफलता ही दिखती है।

AI ने काम के क्रम से इसका अंदाज़ा लगाकर जाँचा, पाया कि वाक़ई सेटिंग लागू नहीं हुई थी, और उसे दोबारा चलाया। “सफल दिखता है पर असल में कुछ किया ही नहीं” — यह वह क़िस्म है जो इंसान की आँखों से जाँच में सबसे आसानी से छूट जाती है।

जहाँ इंसान काम आया: असल बात यही है #

असली विषय यहाँ से शुरू होता है। इस बार घातक हादसों को रोकने वाले दोनों फ़ैसले इंसान की तरफ़ से आए।

1. “जोड़ने के लिए ज़रूरी फ़ाइल रखना छूट रहा है” #

AI ने काम के आइटम व्यवस्थित किए थे, लेकिन बाहरी सिस्टम से जोड़ने के लिए ज़रूरी फ़ाइल रखने के काम को उसने “सबसे आख़िर में करने वाले चरण” में डाल दिया था। असल में, उस चरण में से सिर्फ़ वह फ़ाइल रखने का काम पहले कर लेने में कोई दिक़्क़त नहीं थी, बल्कि उसे पहले ही करना चाहिए था।

इंसान की तरफ़ से “यह छूट रहा है” कहे जाने पर ही AI को पहली बार अपनी वर्गीकरण की ग़लती का पता चला। अगर यह न बताया जाता, तो आगे के चरण में अटक जाते।

2. “स्टोरेज की तरफ़ का रजिस्ट्रेशन पहले होना चाहिए। वरना दिखने में बेमेल हो जाएगा” #

यह सबसे बड़ी बात है।

AI ने cluster में शामिल करने से पहले की जाँच के तौर पर वर्शन, नेटवर्क, समय वग़ैरह की सूची बनाकर “तैयारी पूरी” का फ़ैसला दिया था। लेकिन उसमें स्टोरेज डिवाइस की तरफ़ एक्सेस परमिशन का रजिस्ट्रेशन शामिल ही नहीं था।

इंसान की तरफ़ से यह बात आई कि “रजिस्ट्रेशन से पहले शामिल कर दिया तो शेयर्ड स्टोरेज node के बीच अलग-अलग दिखने लगेगा, और गंभीर असंगति खड़ी हो सकती है”।

AI ने जाँचा तो कंपनी के भीतर ठीक यही घटना पहले भी हो चुकने का रिकॉर्ड मिला। उसमें सिर्फ़ एक मशीन स्टोरेज को पहचान रही थी और बाक़ी नहीं, और किसी दूसरे node को reboot करने पर उससे असंबंधित node भी साथ में reboot हो गए — ऐसी घटना थी।

अगर यह बात न बताई जाती, तो AI साफ़-सुथरे ढंग से सजाए हुए जाँच के नतीजे पेश करने के बाद, सीधे हादसे में जा घुसता।

नतीजतन, हमने पहले ही एक्सेस परमिशन रजिस्टर की, और शामिल करने से पहले “नए node से दिखने वाली स्टोरेज सूची मौजूदा node से पूरी तरह मेल खाती है या नहीं” इसे बिना कुछ बिगाड़े असल में मापा, उसके बाद शामिल किया — और काम शून्य हादसों के साथ पूरा हुआ।

इन दोनों में एक बात समान है — “अनुभव से आने वाला ख़तरे का एहसास”। AI अपने सामने मौजूद जानकारी से तर्कसंगत निष्कर्ष निकाल देता है, लेकिन “वह आइटम सूची में है ही नहीं” — यह उसे पता नहीं चल पाता। सूची में क्या-क्या होना चाहिए, यह जानने वाला वही इंसान था जो पहले चोट खा चुका है।

AI ने जो ग़लतियाँ कीं (बिना छुपाए लिख रहा हूँ) #

निष्पक्षता के लिए AI की नाकामियाँ भी गिना देता हूँ। जो केस स्टडी यह हिस्सा नहीं लिखती, उस पर भरोसा न करना ही बेहतर है।

• प्रक्रिया दस्तावेज़ में ग़लत क्रम लिखा, और उसे वैसे ही असली मशीन पर ले गया। सेटिंग डालने का क्रम उल्टा लिखा था, और असली मशीन पर error आने पर ही पता चला। सौभाग्य से वह चरण ऐसा था जिसका संचार पर असर नहीं पड़ता, इसलिए कोई असली नुक़सान नहीं हुआ
• जाँच कर ली है ऐसा समझा, पर जाँच हुई ही नहीं थी। सेटिंग की पूर्व-जाँच error लौटा रही थी, फिर भी script ठीक से न लिखे होने की वजह से “OK” दिख रहा था। बाद में ख़ुद बताकर उसे ठीक किया
• जो समस्या थी ही नहीं, उसे समस्या बताकर शोर मचाया। सिर्फ़ एक मशीन से तुलना करके रिपोर्ट किया कि “सेटिंग मेल नहीं खा रही”। सभी मशीनें जाँचीं तो पता चला कि सही तो उल्टा नया node ही था
• साफ़ तौर पर हाल बिगड़ने लगा और इंसान ने रोक दिया। काम के दौरान AI संदर्भ से बिल्कुल असंबंधित विषय पर प्रतिक्रिया देकर पटरी से उतर गया। इंसान ने यह गड़बड़ी भाँप ली, काम पूरी तरह रुकवाया, स्थिति जाँची और उसके बाद काम फिर शुरू किया

आख़िरी बात ख़ास तौर पर अहम है। AI अपनी गड़बड़ी को ख़ुद नहीं पकड़ सकता। “कुछ गड़बड़ है” लगते ही जो रोक सके, ऐसा इंसान प्रोडक्शन के काम में हमेशा चाहिए।

सीख: काम का बँटवारा कैसे डिज़ाइन करें #

इस बार काम अच्छा क्यों रहा, इसे व्यवस्थित करें तो यह निकलता है।

जो AI को सौंपकर अच्छा रहा #

• दोहराव, मिलान, हर एक की पूरी जाँच (वे चरण जिन्हें इंसान “शायद ठीक ही होगा” कहकर छोड़ देना चाहता है)
• ऐसी dependency सुलझाना जिसमें बार-बार आज़माना पड़े
• प्रमाण छोड़ते हुए जाँच करना
• किए गए काम को प्रक्रिया दस्तावेज़ में उतारना (काम करते ही तुरंत लिख सकते हैं, इसलिए वह पुराना नहीं पड़ता)

जो इंसान के हाथ में रहना चाहिए #

• सूची में क्या-क्या डालना है (जो आइटम सूची में नहीं है, उसे AI पकड़ नहीं पाता)
• पिछले हादसों की याद के आधार पर जोखिम की ओर ध्यान दिलाना
• रोकने का फ़ैसला
• भौतिक काम (ज़ाहिर है)

और दोनों के लिए जो तरीक़ा समान रूप से काम आया, वह था “छोटे-छोटे क़दमों में करो, और हर बार असल में मापो”। एक-एक मशीन, एक-एक चरण, हर बदलाव पर असल माप से जाँच। यह ढर्रा था इसीलिए AI की ग़लतियाँ भी और इंसान की चूकें भी ज़ख़्म गहरा होने से पहले ही पकड़ में आ गईं।

अंत में #

“AI ने इंफ़्रास्ट्रक्चर बना दिया” कहने पर शायद ऐसी तस्वीर बने कि इंसान बस बैठकर निर्देश देता रहा, लेकिन असलियत अलग थी।

जिन क्षेत्रों में इंसान का ध्यान भटक जाता है, वहाँ AI बेहद मज़बूत है। और जिन क्षेत्रों को AI संरचनात्मक रूप से देख ही नहीं पाता, वहाँ इंसान निर्णायक रूप से मज़बूत है। जब ये दोनों आपस में जुड़ते हैं, तो ऐसी गुणवत्ता मिलती है जहाँ अकेले कोई एक नहीं पहुँच सकता।

और, अगर AI को प्रोडक्शन वातावरण में लाना है, तो एक ऐसा इंसान चाहिए जो उसे रोक सके। इस बार यह काम कर गया — इस केस से मैं सबसे ज़्यादा यही बात साझा करना चाहता हूँ।