AI SRE और AI DevOps व्यवहार में: PandaSi के साथ Agent से कई सर्वरों का एकीकृत प्रबंधन

PandaSi के साथ Agent से कई सर्वरों का एकीकृत प्रबंधन एक अनुमोदित प्रबंधन मशीन से शुरू किया जा सकता है: प्रबंधन मशीन पर PandaPaw और Agent चलाएँ, Agent मौजूदा SSH, VPN या बास्टियन होस्ट के माध्यम से स्पष्ट सूची में दिए गए लक्ष्यों तक पहुँचता है, एक-एक करके पहचान सत्यापित करता है, बैच में केवल-पढ़ने वाला निरीक्षण करता है और परिणामों को सारांशित करता है; जब बदलाव की आवश्यकता हो, तो पहले एक मशीन पर परीक्षण करें, फिर अनुमोदन के अनुसार बैचों में आगे बढ़ें। AI SRE विश्वसनीयता संबंधी समस्याओं की जाँच पर केंद्रित है, AI DevOps डिलीवरी और अवसंरचना परिवर्तनों पर केंद्रित है, दोनों के लिए समीक्षा-योग्य साक्ष्य और अनुमति सीमाएँ आवश्यक हैं।

PandaSi क्रॉस-डिवाइस सत्र और अनुमोदन प्रवेश प्रदान करता है, PandaPaw निष्पादन मशीन से जुड़ता है, विशिष्ट कमांड चयनित Agent और उसके टूल द्वारा निष्पादित किए जाते हैं। एक्सेस पूरा होना कंपनी के सर्वर पर अनुमति प्राप्त करने के बराबर नहीं है, और न ही यह पूरे दिन की निगरानी, स्वचालित अलर्ट या मानवरहित मरम्मत प्रणाली तैनात होने के बराबर है। नीचे उन डेवलपर्स और ऑप्स कर्मियों के लिए है जिनके पास पहले से सर्वर ऑप्स अनुमतियाँ हैं और जो फ़ोन या किसी अन्य कंप्यूटर से काम को आगे बढ़ाना चाहते हैं: प्रबंधन मशीन एक्सेस, बहु-मशीन केवल-पढ़ने सत्यापन, परिणाम सारांश और बैचों में बदलाव की प्रक्रिया पूरी करें। सर्वरों पर अलग-अलग सीधे इंस्टॉल भी किया जा सकता है, लेकिन इस लेख की बहु-मशीन मुख्यधारा प्रबंधन मशीन दृष्टिकोण अपनाती है।

AI SRE और AI DevOps: Agent से क्या-क्या मदद करवाएँ?

ये दो शब्दों के कार्यक्षेत्रों में ओवरलैप है। इस लेख में उन्हें नीचे दिए गए विभाजन से समझा गया है, न कि ऐसे दो उत्पादों के रूप में जिन्हें अलग-अलग खरीदना अनिवार्य है।

उदाहरण के लिए, टेस्ट सेवा रिलीज़ होते ही 502 लौटाती है: यह जाँचना कि अनुरोध किस परत पर विफल हुआ, AI SRE की ओर झुकता है; समस्या पैदा करने वाले रिलीज़ कॉन्फ़िग की समीक्षा करना और अगली डिलीवरी तैयार करना AI DevOps की ओर झुकता है। एक ही Agent सत्र दोनों प्रकार के काम कर सकता है, कुंजी कार्य सीमा, टूल अनुमतियाँ और स्वीकृति शर्तों में है।

पहला कदम: निष्पादन स्थान चुनें और कंपनी की अनुमति लें

इंस्टॉल करने से पहले तीन उत्तर स्पष्ट लिखें: किस मशीन को एक्सेस करने की अनुमति है, किस सिस्टम उपयोगकर्ता के रूप में चलाना है, किन निर्देशिकाओं और सेवाओं तक पहुँचने की अनुमति है। कंपनी बाहरी मॉडल को लॉग या कोड भेजने की अनुमति देती है या नहीं, यह भी एक्सेस से पहले पुष्टि करें। व्यक्तिगत रूप से SSH लॉगिन कर सकना इस बात का प्रमाण नहीं है कि कंपनी व्यक्तिगत खाते को रिमोट Agent से बाँधने की अनुमति देती है।

पथ A: सर्वर पर सीधे चलाएँ। पहले पुष्टि करें कि कंपनी केवल उपयोगकर्ता-स्तरीय Agent सेवा को मंज़ूरी नहीं देती, बल्कि डिफ़ॉल्ट इंस्टॉलेशन प्रक्रिया में शामिल डिवाइस नेटवर्किंग और नेटवर्क सेवा परिवर्तनों को भी मंज़ूरी देती है; वर्तमान इंस्टॉलेशन स्क्रिप्ट लागू systemd होस्ट पर sudo को कॉल करके सिस्टम-स्तरीय नेटवर्क सेवा पंजीकृत कर सकती है। संबंधित इंस्टॉलेशन, विशेषाधिकार और नेटवर्क परिवर्तन की अनुमति प्राप्त करें, और होस्ट वर्तमान समर्थन शर्तों को पूरा करता हो, तब सर्वर पर PandaPaw इंस्टॉल करें। इसके बाद चुनी गई कार्यशील निर्देशिका, shell और टूल इसी निष्पादन मशीन के होंगे। "संचालन अधिक सुविधाजनक है" इस कारण डिफ़ॉल्ट रूप से root का उपयोग न करें।

पथ B: अनुमोदित प्रबंधन मशीन से सर्वर तक पहुँचें। यदि सर्वर पर इंस्टॉल की अनुमति नहीं है, तो PandaPaw को कंपनी-अनुमोदित प्रबंधन मशीन पर इंस्टॉल करें, Agent भी वहीं चलाएँ। प्रबंधन मशीन को पहले से कंपनी-मान्य SSH, VPN या बास्टियन होस्ट के माध्यम से लक्ष्य सर्वर तक पहुँचने और संबंधित खाता अनुमतियाँ होनी चाहिए। Agent फिर इस मौजूदा चैनल को कॉल करता है; PandaSi आपके लिए एक्सेस को मंज़ूरी नहीं देगा, बास्टियन होस्ट को बायपास नहीं करेगा या कंपनी के आंतरिक नेटवर्क को स्वचालित रूप से नहीं जोड़ेगा।

दोनों रास्तों में सबसे भ्रमित करने वाली बात "वर्तमान मशीन" है। प्रबंधन मशीन दृष्टिकोण में, Agent डिफ़ॉल्ट रूप से एक बार pwd चलाता है, जो प्रबंधन मशीन की निर्देशिका दिखाता है; केवल स्पष्ट रूप से SSH के माध्यम से निष्पादित कमांड ही लक्ष्य सर्वर पर होते हैं। सत्र में सर्वर का नाम दिखना पहचान सत्यापन का विकल्प नहीं है।

दूसरा कदम: निष्पादन मशीन पर PandaPaw इंस्टॉल करें

PandaSi से वर्कबेंच में प्रवेश करें, लॉगिन के बाद डिवाइस पेज /devices?add=1 खोलें, डिवाइस जोड़ना चुनें, पेज द्वारा वर्तमान ऑपरेटिंग सिस्टम के लिए जनरेट किया गया वन-टाइम इंस्टॉल कमांड कॉपी करें। डिफ़ॉल्ट इंस्टॉलेशन में डिवाइस इंटरकनेक्शन कॉन्फ़िग शामिल है, जो विशेषाधिकार का अनुरोध कर सकता है और सिस्टम नेटवर्क सेवा बदल सकता है; पहले कंपनी व्यवस्थापक से इंस्टॉलेशन सामग्री की समीक्षा करवाएँ और संबंधित अनुमतियाँ मंज़ूर करवाएँ, फिर कमांड को पिछले चरण में चुनी गई निष्पादन मशीन पर चलाएँ। यदि केवल उपयोगकर्ता-स्तरीय एक्सेस को मंज़ूरी है और डिवाइस नेटवर्किंग को नहीं, तो इस लेख का डिफ़ॉल्ट इंस्टॉल कमांड सीधे न चलाएँ, पहले व्यवस्थापक से अनुमोदित इंस्टॉलेशन योजना की पुष्टि करें। प्रवेश या ब्रांड टेक्स्ट संस्करण के अनुसार बदल सकते हैं, वर्तमान वर्कबेंच में दिखाई देने वाला ही मान्य है; संबंधित होस्ट प्रक्रिया के लिए क्विक स्टार्ट भी देखें।

वन-टाइम कमांड में डिवाइस पेयरिंग क्रेडेंशियल शामिल होते हैं। इसे बातचीत, टिकट, सार्वजनिक स्क्रिप्ट या स्क्रीनशॉट में न चिपकाएँ, और न ही एक ही कमांड को कई मशीनों से जोड़ने के लिए दोबारा उपयोग करें; यदि उपयोग हो चुका है या समाप्त हो गया है, तो डिवाइस पेज से फिर से प्राप्त करें।

यदि वन-टाइम क्रेडेंशियल वाला कमांड उपयोग नहीं करना है, तो macOS / Linux के लिए बेसिक इंस्टॉलेशन प्रवेश है:

curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh

यह इंस्टॉल स्क्रिप्ट डाउनलोड और निष्पादित करेगा, पहले कंपनी की सॉफ़्टवेयर इंस्टॉलेशन और स्क्रिप्ट समीक्षा प्रक्रिया का पालन करें। इस बार केवल वर्तमान दस्तावेज़ और स्रोत के अनुसार सत्यापन किया गया है, स्वच्छ होस्ट पर इंस्टॉलेशन और पेयरिंग का वास्तविक परीक्षण पूरा नहीं किया गया; सार्वजनिक इंस्टॉल स्क्रिप्ट डाउनलोड प्रवेश की पहुँच की पुष्टि हो चुकी है। होस्ट प्लेटफ़ॉर्म संगतता और इंस्टॉलेशन विवरण के लिए PandaPaw होस्ट गाइड देखें।

बेसिक इंस्टॉलेशन का खाता प्राधिकरण पूरा न होने पर, निष्पादन मशीन पर जारी रखें:

pandapaw login

दिखाए गए डिवाइस प्राधिकरण प्रक्रिया के अनुसार पेयरिंग पूरी करें, फिर जाँचें:

pandapaw status

यदि कमांड नहीं मिलता है, तो पहले नया टर्मिनल खोलें, ताकि shell PATH को फिर से लोड करे। "आज़माने" के लिए बार-बार इंस्टॉल या ज़बरदस्ती दोबारा लॉगिन न करें; पहले तीन स्थितियों में अंतर करें: बाइनरी नहीं मिली, खाता बाइंड नहीं हुआ, बैकग्राउंड सेवा असामान्य।

तीसरा कदम: मशीन, इंजन और कार्यशील निर्देशिका चुनें

वर्कबेंच /agent खोलें, अभी जोड़ी गई निष्पादन मशीन चुनें, फिर Claude Code, Codex या PandaCode, और अनुमोदित कार्यशील निर्देशिका चुनें। पहले टेस्ट निर्देशिका में सत्यापित करें, शुरुआत में ही उत्पादन कॉन्फ़िग निर्देशिका में न जाएँ।

डिवाइस पेयरिंग और मॉडल लॉगिन दो अलग बातें हैं। PandaPaw लॉगिन का अर्थ है होस्ट और वर्कबेंच खाते के बीच कनेक्शन स्थापित होना; चयनित इंजन के लिए अभी भी उपलब्ध मॉडल प्राधिकरण, सदस्यता या API कॉन्फ़िग आवश्यक है। डिवाइस ऑनलाइन दिख रहा है लेकिन मॉडल प्रतिक्रिया नहीं है, तो पहले इंजन लॉगिन संकेत, कोटा और मॉडल कॉन्फ़िग देखें, केवल PandaPaw दोबारा इंस्टॉल न करें।

साथ ही इंजन की टूल अनुमति सेटिंग जाँचें। चैट में "पहले बदलाव न करें" लिखना कार्य बाध्यता है, यह ऑपरेटिंग सिस्टम अनुमति या इंजन अनुमोदन तंत्र का विकल्प नहीं है। यदि प्रत्येक बार अनुमोदन चाहिए, तो संबंधित अनुमति मोड कॉन्फ़िगर करें, यह न मानें कि हर कमांड स्वचालित रूप से पुष्टि कार्ड दिखाएगा।

चौथा कदम: पहले केवल-पढ़ने वाले अनुरोध से पहचान सत्यापित करें

पहला कार्य "सर्वर ठीक करें" न लिखें, पहले भेजें:

केवल पहचान सत्यापन करें, फ़ाइलें या सेवाएँ न बदलें। वर्तमान होस्टनाम, सिस्टम उपयोगकर्ता और निरपेक्ष कार्यशील निर्देशिका रिपोर्ट करें, निर्देशिका की शीर्ष-स्तरीय फ़ाइल नाम सूचीबद्ध करें। .env, निजी कुंजी या अन्य क्रेडेंशियल न पढ़ें। यदि लक्ष्य सर्वर तक पहुँचना आवश्यक हो, तो पहले वर्तमान निष्पादन मशीन और लक्ष्य के बीच अंतर स्पष्ट करें, मेरे सत्यापन के बाद जारी रखें।

Linux / macOS के लिए उपलब्ध पहचान सत्यापन कमांड है:

hostname
id -un
pwd

आपको रिटर्न मानों की अपेक्षित मानों से एक-एक करके तुलना करनी चाहिए: क्या यह वही निष्पादन मशीन है, क्या यह अनुमोदित खाता है, क्या यह सही प्रोजेक्ट निर्देशिका है। समान निर्देशिका नाम, डिवाइस ऑनलाइन, कमांड एग्ज़िट कोड 0, ये अकेले सही एक्सेस साबित नहीं करते।

प्रबंधन मशीन दृष्टिकोण में दोनों सिरों को अलग-अलग सत्यापित करना भी आवश्यक है। नीचे केवल कंपनी द्वारा पहले से कॉन्फ़िगर किए गए SSH उपनाम का प्रदर्शन है; company-test-server एक उदाहरण है, इसे व्यवस्थापक द्वारा पुष्टि किए गए लक्ष्य से बदलें:

ssh company-test-server 'hostname; id -un; pwd'

पहली कनेक्शन सूचना को हल करने के लिए होस्ट कुंजी सत्यापन बंद न करें, और न ही SSH पासवर्ड या निजी कुंजी Agent को चिपकाएँ। रिमोट pwd खाते की होम निर्देशिका हो सकती है, इससे यह न मानें कि प्रोजेक्ट चुन लिया गया है; आगे के कमांड में रिमोट प्रोजेक्ट का स्पष्ट निरपेक्ष पथ देना चाहिए।

पास होने की शर्त है: उत्तर सही होस्ट, पहचान और निर्देशिका से मेल खाता है; आप देख सकते हैं कि क्या निष्पादित हुआ; अनुमति पूछताछ वर्तमान अनुमति मोड में अपेक्षित रूप से प्रस्तुत होती है। इसके बाद फ़ोन या किसी अन्य क्लाइंट से उसी सत्र में फिर प्रवेश करें, जाँचें कि इतिहास बहाल हो सकता है या नहीं। यह केवल ऑनलाइन हरे बिंदु देखने से अधिक वास्तविक उपयोग पथ के करीब है।

पाँचवाँ कदम: पहले सर्वर सूची बनाएँ, फिर बैच में केवल-पढ़ने वाला निरीक्षण करें

एक प्रबंधन मशीन पर Agent मौजूदा SSH को कॉल कर सकता है, सूची में दिए गए कई सर्वरों को क्रम से एक्सेस कर सकता है; PandaSi आपको उसी सत्र में इन टूल संचालनों और परिणामों को ट्रैक करने देता है। यहाँ "एकीकृत प्रबंधन" एक ही निष्पादन प्रवेश, स्पष्ट सूची और एकीकृत रिपोर्ट से आता है, इसका अर्थ यह नहीं है कि उत्पाद में सर्वर एसेट डिस्कवरी, क्रॉस-कनेक्शन स्वचालित कार्य असाइनमेंट या एक-क्लिक समूह नियंत्रण इंटरफ़ेस अंतर्निहित है। प्रबंधन मशीन के पास प्रत्येक लक्ष्य के लिए पहले से अनुमति होनी चाहिए, एक मशीन तक पहुँच सकने से यह न मानें कि उसी नेटवर्क सेगमेंट की अन्य मशीनों तक भी पहुँच सकते हैं।

उपनाम और पर्यावरण समूह से लक्ष्य तय करें

व्यवस्थापक से क्रेडेंशियल-रहित सूची बनाए रखने को कहें। नीचे सभी नाम काल्पनिक उदाहरण हैं; वास्तविक सूची कंपनी-अनुमोदित स्थान पर होनी चाहिए, उसमें पासवर्ड, निजी कुंजी या वन-टाइम डिवाइस कमांड न रखें।

SSH उपनाम प्रबंधन मशीन के मौजूदा SSH कॉन्फ़िग में दिया गया नाम है, PandaSi का डिवाइस नाम नहीं। व्यवस्थापक उपनाम के अनुरूप लक्ष्य, खाता, पोर्ट और आवश्यक एक्सेस रिले सत्यापित करे; केवल नाम में test होने से यह पुष्टि न करें कि यह टेस्ट मशीन है। OpenSSH Host प्रविष्टि के अनुसार कॉन्फ़िग मिलान का समर्थन करता है, कमांड लाइन पर निर्दिष्ट रिमोट कमांड लक्ष्य होस्ट पर निष्पादित होगा, विवरण के लिए SSH क्लाइंट कॉन्फ़िगरेशन मैनुअल और SSH कमांड मैनुअल देखें।

यदि प्रत्येक सर्वर पर अलग से PandaPaw इंस्टॉल है, तो वर्कबेंच में संबंधित निष्पादन मशीन चुनकर एक-एक करके संचालन भी किया जा सकता है; लेकिन "कई मशीनें ऑनलाइन हैं" को एक सत्र द्वारा सभी कनेक्शनों को स्वचालित रूप से शेड्यूल करना न समझें। इस लेख के आगे के भाग में एकीकृत रूप से प्रबंधन मशीन + मौजूदा SSH दृष्टिकोण अपनाया गया है, ताकि दो निष्पादन स्थानों को एक ही रिपोर्ट में न मिलाया जाए।

पहले क्रमिक सत्यापन, फिर निरीक्षण आइटम सीमित करें

पहली बार सूची के अनुसार एक-एक करके पहचान सत्यापन करें, एप्लिकेशन कॉन्फ़िग या पूरा लॉग न पढ़ें। नीचे प्रबंधन मशीन Bash का क्रमिक उदाहरण है, जो केवल इस दौर की अनुमत दो टेस्ट मशीनों को सूचीबद्ध करता है; यह स्वचालित पर्यावरण पहचान नहीं करता, और न ही मानवीय अपेक्षित पहचान सत्यापन का विकल्प है।

for target in test-web-01 test-worker-01; do
  printf '\nTARGET %s\n' "$target"
  if ssh -T -o BatchMode=yes -o ConnectTimeout=5 "$target" \
    'hostname && id -un && pwd'; then
    printf 'IDENTITY_COMMAND_COMPLETED %s\n' "$target"
  else
    result=$?
    printf 'IDENTITY_COMMAND_FAILED %s exit=%s\n' "$target" "$result" >&2
  fi
done

ये कमांड केवल संगठन विधि समझाने के लिए हैं, इस लेख में इन दो उदाहरण होस्टों पर नहीं चलाए गए। BatchMode=yes प्रमाणीकरण विफल होने पर इंटरैक्टिव इनपुट की प्रतीक्षा नहीं करता; ConnectTimeout=5 कनेक्शन स्थापना चरण को सीमित करता है, पूरे रिमोट कमांड का कुल समय सीमा नहीं। निष्पादन का कुल समय सीमा अनुमोदित टूल या कार्य निष्पादक द्वारा अलग से सेट की जानी चाहिए। बैच में चलाने के लिए होस्ट कुंजी सत्यापन बंद न करें; इंटरैक्टिव MFA आवश्यक बास्टियन होस्ट के लिए कंपनी-अनुमोदित एक्सेस प्रक्रिया अपनाएँ, इस गैर-इंटरैक्टिव उदाहरण को न लागू करें।

कमांड पूरा होने के बाद, पहले सूची में दिए गए अपेक्षित होस्टनाम, खाते की एक-एक करके तुलना करें, फिर अनुमोदित रिमोट प्रोजेक्ट पथ सत्यापित करें। ऊपर आउटपुट में pwd आमतौर पर केवल रिमोट लॉगिन निर्देशिका होती है, प्रोजेक्ट पथ सही होने का प्रमाण नहीं। कमांड एग्ज़िट कोड 0 केवल यह बताता है कि ये कमांड पूरे हुए, होस्ट पहचान मेल खाती है या नहीं इसका प्रमाण नहीं, और न ही व्यावसायिक स्वास्थ्य का। यदि किसी भी मशीन की पहचान मेल नहीं खाती, तो उस लक्ष्य को ब्लॉक के रूप में चिह्नित करें, व्यावसायिक डेटा पढ़ना जारी न रखें; यदि एक ही पर्यावरण या एक्सेस चैनल में सामान्य संदेह हो, तो पूरे बैच की जाँच रोकें।

पहचान सत्यापन पास होने के बाद, Agent से इस दौर की टेस्ट मशीनों पर अनुमोदित केवल-पढ़ने वाली जाँचों का एक ही समूह चलवाएँ: निर्दिष्ट सेवा स्थिति, अपेक्षित सुनने वाला पोर्ट, डिस्क खाली स्थान, निर्दिष्ट समय विंडो में डी-सेंसिटाइज़्ड त्रुटि सारांश, और एक अनुमोदित स्वास्थ्य अनुरोध। "निरीक्षण" को प्रोब इंस्टॉल करने, सभी निर्देशिकाओं को पुनरावर्ती रूप से पढ़ने या स्वचालित मरम्मत तक न बढ़ाएँ। विभिन्न सिस्टम, सेवा प्रबंधक और एप्लिकेशन की जाँच कमांड अलग-अलग होती हैं, सूची के अनुसार पूरा करें, एक ही कमांड को सभी होस्ट पर ज़बरदस्ती न लागू करें।

एक प्रॉम्प्ट से निष्पादन सीमाएँ स्पष्ट करें

आप प्रबंधन मशीन पर चल रहे हैं। केवल अनुमोदित सर्वर सूची में test समूह के test-web-01, test-worker-01 तक पहुँचें, नए पते स्कैन न करें, production समूह तक न पहुँचें। पहले क्रमिक रूप से प्रत्येक होस्टनाम, उपयोगकर्ता और रिमोट प्रोजेक्ट निरपेक्ष पथ की सूची से तुलना करें, मेल न खाने पर उस लक्ष्य को ब्लॉक करें। पास होने के बाद केवल सूची में स्पष्ट रूप से अधिकृत सेवा स्थिति, पोर्ट, डिस्क और स्वास्थ्य अनुरोध की जाँच करें; लॉग केवल निर्दिष्ट समय विंडो का डी-सेंसिटाइज़्ड अंश लें। पहली बार पूरी प्रक्रिया क्रमिक रूप से, कॉन्फ़िग न बदलें, रीस्टार्ट न करें, निर्भरताएँ इंस्टॉल न करें, स्वचालित रूप से विशेषाधिकार न बढ़ाएँ। एक मशीन का कनेक्शन विफल होने पर त्रुटि सहेजें, अन्य सत्यापित लक्ष्यों की स्वतंत्र केवल-पढ़ने जाँच जारी रखें; पर्यावरण स्वामित्व या साझा एक्सेस चैनल में असामान्यता मिलने पर पूरा बैच रोकें। प्रत्येक मशीन के लिए अलग से समय और समय क्षेत्र, कमांड, एग्ज़िट स्थिति, मुख्य साक्ष्य और अधूरे आइटम दर्ज करें, अंत में सर्वर के अनुसार सारांशित करें। किसी भी मरम्मत के लिए अलग सुझाव दें, निष्पादित न करें।

यह एक कार्य बाध्यता है, इसे केवल-पढ़ने वाले खाते, इंजन टूल अनुमोदन और नेटवर्क एक्सेस प्रतिबंध के साथ लागू करना चाहिए। प्रॉम्प्ट में "बदलाव निषिद्ध" लिखने से लिखने योग्य खाता स्वचालित रूप से केवल-पढ़ने वाला खाता नहीं बन जाता।

समवर्तीता सीमित करें, विफलता संबंधित लक्ष्य पर रहने दें

पहली बार निरीक्षण क्रमिक रूप से करना सत्यापन के लिए सुविधाजनक है; जब लक्ष्य अधिक हों, तो कंपनी-अनुमोदित टूल निष्पादन विधि में छोटी समवर्तीता सीमा सेट की जा सकती है, उदाहरण के लिए एक साथ अधिकतम दो मशीनों की जाँच। यहाँ "दो मशीनें" उदाहरण संचालन बजट है, PandaSi की उत्पाद सीमा या प्रदर्शन गारंटी नहीं। यदि चयनित Agent या टूल समवर्तीता को विश्वसनीय रूप से सीमित नहीं कर सकता, तो क्रमिक रूप से जारी रखें, अस्थायी असीमित बैकग्राउंड कार्यों से न बदलें।

प्रत्येक मशीन की जाँच के लिए स्वतंत्र टाइमआउट और परिणाम रिकॉर्ड सेट करें; एक लक्ष्य की विफलता से अन्य मशीनों के रीस्टार्ट, पुनः इंस्टॉल या पूरे बैच के असीमित पुनः प्रयास शुरू न हों। कनेक्शन टाइमआउट, पहचान में असमानता, अपर्याप्त अनुमति, जाँच कमांड विफलता को अलग-अलग दर्ज करें, सभी को "ऑफ़लाइन" में न मिलाएँ। यदि त्रुटि साझा बास्टियन होस्ट, प्रमाणीकरण स्रोत या अस्पष्ट पर्यावरण स्वामित्व से आती है, तो सामान्य कारण की जाँच के लिए रुकें, समवर्तीता बढ़ाना जारी न रखें।

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

रिपोर्ट में बताएँ "कितनी मशीनों की जाँच योजना थी, कितनी पूरी हुईं, कितनी विफल हुईं, कितनी छोड़ी गईं", और प्रत्येक लक्ष्य का साक्ष्य दें। परिणाम न होने पर डिफ़ॉल्ट रूप से स्वस्थ न मानें; बैच कमांड का अंतिम एग्ज़िट कोड 0 भी बीच में किसी मशीन की विफलता को नहीं छिपा सकता।

छठा कदम: पहले एक टेस्ट सेवा पर 502 जाँच और रिकवरी पूरी करें

नीचे एक शैक्षणिक उदाहरण है, यह इस लेख में वास्तविक परीक्षण दुर्घटना नहीं है, और न ही सभी सर्वरों पर कॉपी करने योग्य मरम्मत कमांड का सेट है। मान लें कि एक अनुमोदित टेस्ट सेवा रिलीज़ के बाद 502 लौटाती है, आपको टेस्ट डोमेन, सेवा नाम और प्रोजेक्ट निर्देशिका पता है।

पहले जाँच का दायरा सीमित करें

कार्य इस प्रकार लिखा जा सकता है:

टेस्ट सेवा रिलीज़ के बाद 502 की जाँच करें। पहले लक्ष्य होस्ट, उपयोगकर्ता और निर्देशिका सत्यापित करें, केवल-पढ़ने में अंतिम रिलीज़ रिकॉर्ड, संबंधित सेवा स्थिति, सुनने वाला पोर्ट, निर्दिष्ट समय विंडो के प्रॉक्सी और एप्लिकेशन लॉग जाँचें। रीस्टार्ट, कॉन्फ़िग बदलाव, निर्भरता इंस्टॉल या अन्य पर्यावरण तक पहुँच न करें। केवल इस विफलता से संबंधित डी-सेंसिटाइज़्ड अंश लौटाएँ, साक्ष्य, संभावित कारण और कमी वाली जानकारी सूचीबद्ध करें।

पहले समय विंडो और स्पष्ट लॉग स्रोत दें, Agent को पूरे सर्वर में पुनरावर्ती रूप से खोजने से रोकें। केवल-पढ़ना भी डेटा लीक कर सकता है: लॉग में टोकन, ग्राहक जानकारी और अनुरोध बॉडी को मॉडल संदर्भ में जाने से पहले फ़िल्टर करना चाहिए, भेजने के बाद मॉडल से "भूल जाओ" न कहें।

502 इंगित करता है कि प्रॉक्सी को उपयोगी अपस्ट्रीम प्रतिक्रिया नहीं मिली, लेकिन केवल स्टेटस कोड देखकर यह तय नहीं होता कि प्रक्रिया बंद हुई, पोर्ट मेल नहीं खाता, निर्भरता असामान्य है या कनेक्शन समस्या है। Agent से प्रॉक्सी अपस्ट्रीम पता, वास्तविक सुनने वाला पोर्ट और उसी समय अवधि के लॉग मिलान करवाएँ; क्रॉस-मशीन लॉग में पहले समय क्षेत्र एकीकृत करें। "मशीन ऑनलाइन" को "एप्लिकेशन स्वस्थ" न मानें, और न ही मेल न खाने वाले लॉग को सीधे "कोई त्रुटि नहीं हुई" मानें।

समीक्षा योग्य मरम्मत सुझाव माँगें

यदि साक्ष्य "रिलीज़ कॉन्फ़िग में अपस्ट्रीम पोर्ट और वास्तविक सुनने वाला पोर्ट मेल नहीं खाते" का समर्थन करता है, तो Agent से विशिष्ट फ़ाइल और न्यूनतम अंतर, प्रस्तावित कमांड, प्रभावित टेस्ट सेवा, कॉन्फ़िग जाँच विधि और रोलबैक शर्तें प्रस्तुत करवाएँ। यह अभी भी एक सशर्त उदाहरण है; यदि साक्ष्य समर्थन नहीं करता, तो जाँच जारी रखें।

अनुमोदन का विषय एक विशिष्ट बदलाव होना चाहिए, न कि "आप पूरी ज़िम्मेदारी लें"। उदाहरण के लिए निर्दिष्ट टेस्ट प्रॉक्सी कॉन्फ़िग बदलने की मंज़ूरी दें, और कॉन्फ़िग जाँच पास होने के बाद उस टेस्ट प्रॉक्सी को पुनः लोड करें; साथ में निर्भरताएँ अपग्रेड करना, डेटाबेस साफ़ करना, उत्पादन कॉन्फ़िग बदलना या पूरा होस्ट रीस्टार्ट करना नहीं। वास्तविक कमांड उपयोग किए गए प्रक्रिया प्रबंधक और डिप्लॉयमेंट नियमों के अनुसार निर्धारित होने चाहिए।

निष्पादन के बाद उपयोगकर्ता पथ सत्यापित करें

अनुमोदित निष्पादन के बाद, स्वीकृति में कम से कम शामिल हो: कॉन्फ़िग जाँच पास हुई या नहीं, संबंधित प्रक्रिया और पोर्ट अपेक्षित हैं या नहीं, स्वास्थ्य इंटरफ़ेस सामान्य है या नहीं, और स्वतंत्र क्लाइंट से मूल प्रवेश के माध्यम से वास्तविक टेस्ट अनुरोध बहाल हुआ या नहीं। स्वास्थ्य इंटरफ़ेस 200 लौटाता है, लेकिन व्यावसायिक रूटिंग, प्रमाणीकरण या डेटाबेस अनुरोध अभी भी विफल हैं, तो "समस्या हल हो गई" न लिखें।

अंत में Agent से निष्पादित कमांड, वास्तविक बदलाव, सत्यापन परिणाम और शेष जोखिमों का सारांश दें; जिन आइटमों का सत्यापन नहीं हुआ, उन्हें स्पष्ट रूप से अज्ञात लिखें। पुष्टि किए गए कारण और भविष्य की पुनरावृत्ति रोकने के उपाय कंपनी के रिकॉर्ड सिस्टम में लौटाएँ। जाँच चरण में AI SRE सहायता, बाद में सुधार को कॉन्फ़िग रिपॉज़िटरी और रिलीज़ प्रक्रिया में शामिल करना AI DevOps तक विस्तारित होता है।

सातवाँ कदम: एक मशीन सफल होने के बाद, अन्य सर्वरों पर बैच में बदलाव करें

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

पहले बैच में केवल एक स्पष्ट टेस्ट मशीन चुनें। योजना में लक्ष्य उपनाम, सत्यापित होस्ट पहचान, मूल संस्करण या कॉन्फ़िग, प्रस्तावित अंतर, अपेक्षित प्रभाव, जाँच विधि, रोलबैक चरण और रोकने की शर्तें तय करें। अनुमोदन के बाद इस एक मशीन पर निष्पादित करें, स्वास्थ्य इंटरफ़ेस और वास्तविक उपयोगकर्ता पथ की स्वीकृति की प्रतीक्षा करें; रिकवरी का साक्ष्य न होने पर स्थिति को सफल न चिह्नित करें और न ही अगले बैच में जाएँ।

परीक्षण पास होने के बाद, अगले बैच के लक्ष्य सूची, बैच आकार और समवर्तीता सीमा स्पष्ट करें, "सभी शेष मशीनें" जैसे सूची के अनुसार बदलने वाले निहित दायरे का उपयोग न करें। प्रत्येक बैच के अंत में वास्तविक संस्करण और अनुरोध परिणाम सत्यापित करें, सफल, विफल और निष्पादित न हुए लक्ष्यों को रिकॉर्ड करें। पहचान में असमानता, कॉन्फ़िग जाँच विफलता, व्यावसायिक अनुरोध में गिरावट या रोलबैक विफलता होने पर आगे के बैच रोकें, साक्ष्य सहेजें और ज़िम्मेदार व्यक्ति को सौंपें; परीक्षण चरण की मंज़ूरी को उत्पादन मंज़ूरी न मानें।

रोलबैक भी प्रत्येक मशीन के लिए अलग से परिभाषित करें। कॉन्फ़िग बदलाव को अनुमोदित तरीके से पिछले कॉन्फ़िग में बहाल किया जा सकता है; जब डेटाबेस माइग्रेशन, डेटा लेखन या बाहरी सिस्टम साइड इफ़ेक्ट शामिल हों, तो "पुराने संस्करण पर वापस जाना" प्रभाव को उलट सकता है यह न मानें, पहले ज़िम्मेदार व्यक्ति रिकवरी योजना तय करे। केवल उन लक्ष्यों को रोलबैक करें जो वास्तव में बदले गए और बहाली की आवश्यकता है, पूरे समूह पर बिना भेदभाव के रिवर्स कमांड न चलाएँ।

अगला कार्य इस प्रकार लिखा जा सकता है:

इस बार के प्रति-मशीन निरीक्षण साक्ष्य के आधार पर, पहले केवल test-web-01 के लिए मरम्मत योजना प्रस्तावित करें, निष्पादित न करें। सत्यापित होस्ट पहचान, विशिष्ट अंतर, पूर्ण कमांड, प्रभाव, रोलबैक चरण, स्वीकृति अनुरोध और रोकने की शर्तें सूचीबद्ध करें। इस मशीन के स्पष्ट अनुमोदन के बाद ही निष्पादित करें; पूरा होने पर वास्तविक साक्ष्य दें और अगले बैच के लक्ष्य अनुमोदन की प्रतीक्षा करें। अनुमोदित न हुई मशीनें निष्पादित न हुई रहें। production समूह इस दायरे में नहीं है, टेस्ट अनुमोदन विरासत में न मिले।

जब टेस्ट और उत्पादन दोनों को संभालना हो, तो उत्पादन अलग से कंपनी की बदलाव प्रक्रिया से गुज़रे। प्रबंधन प्रवेश एकीकृत होना पर्यावरण अलगाव, रखरखाव विंडो, रिलीज़ अनुमोदन या ऑडिट आवश्यकताओं को समाप्त नहीं करता।

फ़ोन डिस्कनेक्ट होने के बाद, पहले कार्य की स्थिति जाँचें

क्लाइंट बंद करना, फ़ोन बैकग्राउंड में जाना या नेटवर्क डिस्कनेक्ट होना, इसे रिमोट कमांड बंद होना न समझें। निष्पादन मशीन पर प्रक्रिया चलती रह सकती है; होस्ट ऑफ़लाइन, इंजन एग्ज़िट या रिमोट चैनल प्रतिबंध के कारण विफल भी हो सकती है। मूल सत्र में लौटकर पहले टूल परिणाम देखें, फिर प्रक्रिया, आर्टिफ़ैक्ट और सेवा स्थिति सत्यापित करें, इंस्टॉलेशन, रिलीज़ या माइग्रेशन दोबारा शुरू करने से बचें।

रिमोट कमांड श्रृंखला में "एग्ज़िट स्थिति न लौटना" हो सकता है: कनेक्शन परत टाइमआउट का अर्थ यह नहीं कि कमांड शुरू नहीं हुआ। लंबे कार्यों के लिए कंपनी के निष्पादन चैनल में टाइमआउट, स्थिति रिकॉर्ड और रद्द करने का तरीका स्पष्ट करें, विशेष रूप से कई SSH हॉप्स शामिल होने पर। यह लेख किसी संस्करण के चैनल टाइमआउट मान को सभी SSH टूल के सामान्य नियम के रूप में नहीं मानता।

रोकने की आवश्यकता हो, तो स्पष्ट स्टॉप ऑपरेशन उपयोग करें और रिमोट निष्पादन स्थिति सत्यापित करें; स्थिति अस्पष्ट गैर-इडेम्पोटेंट बदलाव में पहले मानवीय हस्तक्षेप से पुष्टि करें। बार-बार क्लिक करके या वही निर्देश दोबारा भेजकर यह अनुमान न लगाएँ कि पिछली बार सफल हुआ या नहीं।

कंपनी और घरेलू उपकरणों की नेटवर्किंग का इस लेख से क्या संबंध है?

यह लेख मानता है कि प्रबंधन मशीन से प्रत्येक सर्वर तक अनुमोदित एक्सेस चैनल पहले से मौजूद है, केंद्र बिंदु यह है कि Agent लक्ष्य के अनुसार काम कैसे व्यवस्थित करता है। कंपनी और घर में कई उपकरणों को नेटवर्क में कैसे जोड़ें, एक-दूसरे तक कैसे पहुँचें और नेटवर्क सीमाओं को कैसे संभालें, यह एक अलग एक्सेस कार्य है, इसे यहाँ मिलाकर नहीं लिखा गया; नेटवर्किंग सफल होना भी उन सभी उपकरणों के ऑप्स का अधिकार नहीं देता। डिवाइस एक्सेस समझने के लिए, पहले मौजूदा डिवाइस इंटरकनेक्शन विवरण देखें, और कंपनी की नेटवर्क अनुमोदन प्रक्रिया का पालन करें।

कंपनी डेटा, मॉडल और रिले की सीमाएँ

"टूल स्थानीय मशीन पर चलते हैं" निष्पादन स्थान बताता है, यह वादा नहीं करता कि डेटा कभी कंपनी से बाहर नहीं जाएगा। सत्र संदेश और अनुमोदन उत्पाद संचार चैनल से गुज़रते हैं; Agent को दिए गए लॉग, कोड और टूल आउटपुट चयनित मॉडल प्रदाता के अनुरोध में भी जा सकते हैं। एक्सेस से पहले कंपनी-अनुमोदित मॉडल, डेटा प्रोसेसिंग समझौते, लॉग प्रतिधारण और एक्सेस नीति सत्यापित करें।

मौजूदा कुंजी प्रबंधन और ऑडिट प्रक्रिया बनाए रखें, क्रेडेंशियल निष्पादन मशीन की अनुमोदित क्रेडेंशियल सुविधा से पढ़ें, बातचीत या कोड रिपॉज़िटरी में न चिपकाएँ। चलाने वाले खाते और नेटवर्क पहुँच सीमा को सीमित करें, आवश्यकता के अनुसार लॉग और निर्देशिका अनुमतियाँ दें। नौकरी छोड़ने, उपकरण बंद करने या अनुमति बदलने पर, वर्कबेंच डिवाइस प्राधिकरण, निष्पादन मशीन खाता और लक्ष्य सर्वर एक्सेस अधिकार एक साथ संभालें; एक क्लाइंट हटाना सभी निष्पादन अनुमतियाँ रद्द करने के बराबर नहीं है।

सामान्य प्रश्न (FAQ)

क्या PandaSi स्वचालित रूप से ड्यूटी पर रह सकता है, अलर्ट प्राप्त कर सकता है और उत्पादन ठीक कर सकता है?

यह लेख रिमोट सत्र, अनुमोदित संचालन और मानवीय फ़ॉलो-अप प्रक्रिया के बारे में है। पूरे दिन की निगरानी, अलर्ट एकीकरण, स्वचालित ट्रिगर और मानवरहित मरम्मत के लिए अतिरिक्त निगरानी प्रणाली, ट्रिगर, रनबुक और अनुमति प्रशासन आवश्यक है, एक्सेस सफल होने से यह नहीं निकाला जा सकता कि ये क्षमताएँ पहले से मौजूद हैं।

कंपनी के सर्वर पर सॉफ़्टवेयर इंस्टॉल नहीं कर सकते, तो क्या उपयोग कर सकते हैं?

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

क्या सर्वर के लिए सार्वजनिक नेटवर्क SSH पोर्ट खोलना होगा?

PandaPaw का सत्र कनेक्शन दोनों पक्षों से सक्रिय आउटबाउंड द्वारा स्थापित होता है, आमतौर पर क्लाइंट एक्सेस के लिए नया सार्वजनिक इनबाउंड पोर्ट जोड़ने की आवश्यकता नहीं होती। लेकिन प्रबंधन मशीन से लक्ष्य सर्वर तक कंपनी-मान्य एक्सेस चैनल अभी भी आवश्यक है; आउटबाउंड सीमित होने पर नेटवर्क व्यवस्थापक द्वारा कॉन्फ़िगर करवाएँ, स्वयं सुरक्षा बंद न करें।

क्या प्रत्येक सर्वर पर PandaPaw इंस्टॉल करना अनिवार्य है?

इस लेख का प्रबंधन मशीन दृष्टिकोण प्रत्येक SSH लक्ष्य पर PandaPaw इंस्टॉल करने की आवश्यकता नहीं रखता, लेकिन प्रबंधन मशीन के पास अनुमोदित नेटवर्क चैनल और रिमोट खाता होना चाहिए। सीधे इंस्टॉलेशन दृष्टिकोण में संबंधित होस्ट पर Agent चलता है, प्रत्येक अलग से जुड़ता है; दोनों को एक ही स्वचालित समूह नियंत्रण क्षमता में न मिलाएँ।

एक मशीन का निरीक्षण विफल हो, तो क्या अन्य मशीनें जारी रख सकती हैं?

पहचान सत्यापित और एक-दूसरे से स्वतंत्र केवल-पढ़ने वाली जाँचों के लिए, उस लक्ष्य का विफलता साक्ष्य रखकर अन्य लक्ष्य जारी रखे जा सकते हैं; यदि साझा एक्सेस विफलता या पर्यावरण स्वामित्व संदेह शामिल हो, तो पूरा बैच रोकें। बदलाव चरण में अनुमोदित रोकने की शर्तों के अनुसार निष्पादित करें, "निरीक्षण जारी रह सकता है" नियम लागू न करें।

एक्सेस के बाद सबसे पहले क्या स्वीकार करें?

पहले प्रबंधन मशीन, मॉडल प्रतिक्रिया और सत्र बहाली सत्यापित करें, फिर सूची के अनुसार एक-एक करके लक्ष्य पहचान, निर्देशिका और अनुमतियाँ सत्यापित करें, केवल-पढ़ने वाला निरीक्षण और परिणाम सारांश पूरा करें, अंत में एक टेस्ट सेवा पर अनुमोदन, वास्तविक अनुरोध स्वीकृति और आगे की बैच प्रक्रिया पूरी करें। एक्सेस का मूल्य यह है कि अनुमोदित कार्यों को लगातार ट्रैक किया जा सके; अधिक सेवाओं तक विस्तार उपयुक्त है या नहीं, यह इस स्वीकृति साक्ष्य से तय करें।

संदर्भ और सत्यापन सीमा

इस लेख का पहला ड्राफ़्ट 31 अक्टूबर 2026 को परियोजना क्विक स्टार्ट, PandaPaw होस्ट दस्तावेज़, डिवाइस इंस्टॉलेशन कमांड जनरेशन लॉजिक और सार्वजनिक इंस्टॉल स्क्रिप्ट डाउनलोड प्रवेश के साथ सत्यापित किया गया; 1 नवंबर को बहु-मशीन संचालन प्रक्रिया जोड़ी गई, और OpenSSH आधिकारिक मैनुअल के साथ SSH कॉन्फ़िग और पैरामीटर अर्थ सत्यापित किए गए। इस बार केवल वर्तमान दस्तावेज़ और स्रोत के अनुसार सत्यापन किया गया, स्वच्छ होस्ट पर इंस्टॉलेशन और पेयरिंग का वास्तविक परीक्षण पूरा नहीं किया गया, और न ही वास्तविक बहु-मशीन पर्यावरण में इस लेख का निरीक्षण, बैच बदलाव या 502 उदाहरण निष्पादित किया गया; प्रत्येक कंपनी के नेटवर्क, इंजन अनुमोदन और डेटा अनुपालन को अपने टेस्ट पर्यावरण में स्वीकार करना आवश्यक है। सभी चित्र AI-जनरेटेड अवधारणा या प्रक्रिया आरेख हैं, इंटरफ़ेस स्क्रीनशॉट नहीं।