युनिट्स
1. DevOps आणि Cloud AI चा परिचय: भूमिका, सीमा, प्रमाणीकरण, सुरक्षा आणि रहस्ये 2. कृत्रिम बुद्धिमत्तेसह CI/CD पाइपलाइन डिझाइन करणे: GitHub क्रिया आणि GitLab CI 3. कोड म्हणून पायाभूत सुविधा व्यवस्थापित करणे: टेराफॉर्म आणि IaC सह कृत्रिम बुद्धिमत्ता 4. कंटेनरायझेशन: डॉकरफाइल आणि आर्टिफिशियल इंटेलिजन्ससह इमेज ऑप्टिमायझेशन 5. कुबर्नेट्स: मॅनिफेस्ट, हेल्म आणि एआय-पॉवर्ड ऑर्केस्ट्रेशन 6. देखरेख आणि निरीक्षणक्षमता: मेट्रिक, लॉग, ट्रेस आणि अलार्म नियम 7. घटना व्यवस्थापन आणि पोस्टमॉर्टम: आर्टिफिशियल इंटेलिजन्ससह मूळ कारण विश्लेषण 8. क्लाउड कॉस्ट ऑप्टिमायझेशन (फिनऑप्स): कृत्रिम बुद्धिमत्तेसह कचरा शोधणे 9. स्क्रिप्ट आणि ऑटोमेशन जनरेशन: बॅश, पायथन आणि पॉवरशेल 10. सुरक्षा आणि रहस्ये व्यवस्थापन: DevSecOps आणि कृत्रिम बुद्धिमत्ता 11. उत्पादन पडताळणी, रिलीझ स्ट्रॅटेजीज आणि एंड-टू-एंड AI वर्कफ्लो
युनिट 11 / 11

उत्पादन पडताळणी, रिलीझ स्ट्रॅटेजीज आणि एंड-टू-एंड AI वर्कफ्लो

नफा:

  • जोखीम-कमी करण्याच्या रिलीझ धोरणे (निळा-हिरवा, कॅनरी, वैशिष्ट्य ध्वज) आणि उत्पादन पडताळणी शिस्त (आरोग्य तपासणी, धूर चाचणी, गोल्डन सिग्नल मॉनिटरिंग) समजून घेणे
  • तैनातीपूर्वी स्पष्ट रोलबॅक योजना तयार करण्याची आणि तैनातीनंतर महत्त्वपूर्ण व्यवसाय मार्गांची पडताळणी करण्याची सवय लागू करण्याची क्षमता
  • संपूर्ण मॉड्यूलमध्ये शिकलेले सर्व भाग एंड-टू-एंड एआय-समर्थित वर्कफ्लोमध्ये एकत्र करण्याची क्षमता आणि प्रत्येक टप्प्यावर 'एआय निर्मिती, मानव सत्यापित आणि आश्वासन' हे तत्त्व लागू करण्याची क्षमता

हे संपूर्ण मॉड्यूल एका बिंदूकडे वाहते: कोडची सुरक्षित वितरण आणि उत्पादनासाठी पायाभूत सुविधा (वास्तविक ग्राहक वापरत असलेले थेट वातावरण). आता आम्ही साखळीतील सर्वात गंभीर आणि तणावपूर्ण दुव्यावर आहोत: बदल थेट मिळवणे आणि ते प्रत्यक्षात कार्य करते याची पडताळणी करणे. येथे चूक अमूर्त नाही - ती थेट ग्राहक, कमाई आणि प्रतिष्ठा यांना मारते. म्हणूनच प्रौढ संघ "आशेने" नव्हे तर नियंत्रित रिलीझ धोरणे आणि पद्धतशीर पडताळणी करून उत्पादनात जातात.

या अंतिम युनिटमध्ये आम्ही दोन गोष्टी एकत्र करतो: (1) रिलीझ पद्धती ज्या जोखीम कमी करतात (कॅनरी, निळा-हिरवा, वैशिष्ट्य ध्वज) आणि उत्पादन सत्यापनाची शिस्त; (२) संपूर्ण मॉड्यूलमध्ये आपण शिकलेला प्रत्येक तुकडा-CI/CD, IaC, कंटेनर, मॉनिटरिंग, घटना, खर्च, स्क्रिप्ट, सुरक्षा—एकल AI-शक्तीच्या एंड-टू-एंड वर्कफ्लोमध्ये एकत्र येतो. चला शेवटच्या वेळी प्रारंभिक कोट पुन्हा करूया: एआय प्रत्येक टप्प्यावर मसुदे तयार करते आणि वेगवान करते; पण तुम्हीच "मी हे लाइव्ह घेत आहे" बटण दाबता आणि निकालाची खात्री देता.

जोखीम कमी करणारी रणनीती सोडा

सर्व वापरकर्त्यांना एकाच वेळी बदल करणे हा सर्वात धोकादायक मार्ग आहे. प्रौढ पद्धती:

  • ब्लू-ग्रीन डिप्लॉयमेंट: दोन एकसारखे वातावरण राखले जाते - "निळा" (लाइव्ह) आणि "हिरवा" (नवीन आवृत्ती). नवीन आवृत्ती तयार केली जाते आणि हिरव्या रंगात चाचणी केली जाते, नंतर वाहतूक अचानक हिरव्यावर स्विच केली जाते. समस्या असल्यास, वाहतूक ताबडतोब निळ्या रंगात परत जाते. जलद रोलबॅक हा त्याचा सर्वात मोठा फायदा आहे.
  • कॅनरी डिप्लॉयमेंट: नवीन आवृत्ती प्रथम वापरकर्त्यांच्या लहान टक्केवारीसाठी (उदा. 5%) जारी केली जाते; मेट्रिक्स चांगले असल्यास, हळूहळू 100% पर्यंत वाढवा. समस्या वापरकर्त्याच्या एका छोट्या भागावर परिणाम करते, संपूर्ण वापरकर्त्यावर नाही.
  • वैशिष्ट्य ध्वज: नवीन वैशिष्ट्य कोडमध्ये प्रवेश करते परंतु ध्वजाद्वारे अवरोधित केले जाते; विनंती केल्यावर विशिष्ट वापरकर्त्यांसाठी ते उघडले जाते. उपयोजन आणि "रिलीझ" मध्ये फरक आहे; काही समस्या असल्यास, कोड मागे न घेता ध्वज बंद केला जातो.
टीप: प्रत्येक तैनातीपूर्वी रोलबॅक तयार असणे हे सर्वात वेगवान सुरक्षा जाळे आहे. "काही चुकले तर, मी ६० सेकंदात जुन्या आवृत्तीवर कसे परत येऊ?" प्रश्नाचे कोणतेही स्पष्ट उत्तर नसल्यास, तुम्ही ते उपयोजन करण्यास तयार नाही.

उत्पादन पडताळणी: उपयोजन संपल्यावर काम संपत नाही

केवळ उपयोजन "हिरवे" दिसले याचा अर्थ ते कार्यरत आहे असे नाही. पद्धतशीर पडताळणी:

  1. आरोग्य तपासणी: सेवा सुरू आहे का, /healthz प्रतिसाद देत आहे का?
  2. स्मोक चाचण्या: काही सर्वात गंभीर वापरकर्ता मार्ग (लॉगिन, पेमेंट, शोध) प्रत्यक्षात कार्य करतात का? स्वयंचलित आणि जलद.
  3. गोल्डन सिग्नलसाठी पहा: पोस्ट-डिप्लॉय एरर रेट, लेटन्सी, ट्रॅफिक सामान्य आहे का? (एकक 6 वर चार सिग्नल.)
  4. हळूहळू विस्तार करा: तुम्ही कॅनरी टक्केवारी वाढवत असताना प्रत्येक टप्प्यावर मेट्रिक्स पहा.
  5. निरीक्षण विंडो: तैनातीनंतर काही कालावधीसाठी (उदा. ३० मिनिटे) बारकाईने निरीक्षण करा; कपटी समस्या लगेच दिसत नाहीत.
खबरदारी: AI धूर चाचण्या किंवा पडताळणींची यादी तयार करू शकते, परंतु कोणते वापरकर्ता मार्ग "गंभीर" आहेत हे निर्धारित करणे तुमचे काम आहे. एआय एक सामान्य यादी देते; फक्त तुम्हाला माहीत आहे की तुमचा पेमेंट फ्लो, तुमचा सर्वात जास्त कमाई करणारा मार्ग, चाचणी करणे आवश्यक आहे.

रणनीतींची तुलना करा

रणनीती

मुख्य फायदा

किंमत/जटिलता

सर्वात योग्य

निळा-हिरवा

झटपट रोलबॅक

दोन वातावरण = 2x संसाधने

जलद पुनर्प्राप्ती गंभीर असल्यास

कॅनरी

लहान स्लाइसवर प्रभाव मर्यादित करते

वाहतूक व्यवस्थापन आवश्यक

प्रचंड वापरकर्ता आधार

वैशिष्ट्य ध्वज

रिलीझ पासून तैनात वेगळे

ध्वज व्यवस्थापन कर्ज

हळूहळू/लक्ष्यित उघडणे

रोलिंग अपडेट

साधे, संसाधन-अनुकूल

हळू रोलबॅक

साध्या सेवा

एंड-टू-एंड एआय-संचालित वर्कफ्लो

आता संपूर्ण मॉड्यूल एका प्रवाहात एकत्र करू. समजा तुम्ही एक नवीन मायक्रोसेवा प्रकाशित करत आहात. एआय प्रत्येक टप्प्यावर मसुदे तयार करते; आपण प्रत्येक चरणावर सत्यापित करता:

  1. कोड आणि कंटेनर (युनिट 4): AI ऑप्टिमाइझ, सुरक्षित डॉकरफाइल तयार करते; तुम्ही नो-सिक्रेट आणि आकाराची पडताळणी करता.
  2. CI/CD (युनिट 2): AI चाचणी-बिल्ड-डिप्लॉय पाइपलाइन लिहिते; तुम्ही परवानग्या कमी करा आणि गुप्त संदर्भ तपासा.
  3. पायाभूत सुविधा (युनिट 3): एआय टेराफॉर्मसह आवश्यक संसाधने परिभाषित करते; तुम्ही प्लॅनचे आउटपुट वाचता आणि अनपेक्षित हटवल्या जाणाऱ्या शोधू नका.
  4. ऑर्केस्ट्रेशन (युनिट 5): AI कुबर्नेट्स मॅनिफेस्ट तयार करते; तुम्ही संसाधन मर्यादा, प्रोब आणि RBAC सत्यापित करता.
  5. सुरक्षा (युनिट 10): AI स्कॅन आउटपुटला प्राधान्य देते; तुम्ही आधी शोषण करणाऱ्यांना पकडा.
  6. मॉनिटरिंग (युनिट 6): AI अलार्म नियम आणि डॅशबोर्ड व्युत्पन्न करते; तुम्ही तुमच्या मागील डेटासह थ्रेशोल्डची चाचणी करता.
  7. प्रकाशन आणि प्रमाणीकरण (हे युनिट): एआय स्मोक चाचणी आणि रोलबॅक योजनेची रूपरेषा; तुम्ही कॅनरी सुरू करा, मेट्रिक्स पहा, बटण दाबा.
  8. घटना घडल्यास (युनिट 7): AI गृहीते आणि पोस्टमॉर्टम स्केच तयार करते; तुम्ही सत्यापित करा आणि धडे शिका.
  9. किंमत (युनिट 8): AI नवीन संसाधनांच्या कचऱ्यावर लक्ष ठेवते; तुम्ही योग्य आकाराचे निर्णय घेता.

प्रत्येक पायरीवर, सामान्य नियम स्थिर राहतो: AI निर्मिती आणि गती वाढवते, मानव सत्यापित करते आणि आश्वासन देते. हे मॉड्यूलचे सार आहे.

तीन लहान प्रकरणे

केस 1 - कॅनरीने आपत्ती 5% पर्यंत मर्यादित केली. एका टीमने कॅनरीसह 5% वापरकर्त्यांना नवीन आवृत्ती दिली. AI ने तत्काळ तयार केलेल्या डॅशबोर्डने या स्लाइसमध्ये त्रुटी दर 8% वर गेल्याचे दाखवले. संघाने ते 100% न वाढवता परत घेतले; समस्येने केवळ 5% वापरकर्त्यांना प्रभावित केले आणि ते काही मिनिटांसाठी होते. मोठा धमाका तैनात असल्यास, सर्व ग्राहक प्रभावित होतील.

केस 2 - धुराच्या चाचणीने गहाळ मार्ग पकडला. AI ने स्मोक टेस्ट सेट ऑफर केला, परंतु त्यात "पेमेंट" प्रवाह नव्हता. अभियंत्याने ते जोडले, हे जाणून घेतले की सर्वात गंभीर महसूल प्रवाह पेमेंट आहे. पोस्ट-डिप्लॉय चाचणी चेकआउट चरणावरच खंडित झाली — तृतीय-पक्ष की कालबाह्य झाली होती. पडताळणीने काही मिनिटांतच कमाईची मूक तोटा पकडली.

केस 3 — तयार रोलबॅक 90 सेकंदात सेव्ह केला. निळा-हिरवा स्थापित करणार्या संघाने नवीन आवृत्ती हिरवी केली; 2 मिनिटांनंतर विलंब दुप्पट झाला. त्यांनी आगाऊ तयार केलेल्या रोलबॅकसह 90 सेकंदात वाहतूक निळ्या रंगात बदलली. त्यांना मूळ कारण (नवीन आवृत्तीमधील हळूवार प्रश्न) दबावाखाली नसून शांतपणे आढळले. तयार रोलबॅक मार्गाने व्यत्यय जवळजवळ अदृश्य केला.

चार कॉपी करण्यायोग्य टेम्पलेट्स

1) रिलीझ धोरण निवड:

मी खालील सेवा तयार करेन: [सेवा/संवाद: वापरकर्त्यांची संख्या, आउटेज सहनशीलता, पायाभूत सुविधा]. तुम्ही निळ्या-हिरव्या, कॅनरी आणि वैशिष्ट्यपूर्ण ध्वजांपैकी कोणाची शिफारस करता? या संदर्भात प्रत्येकाचे फायदे, खर्च आणि रोलबॅक गतीची तुलना करा. सूचना द्या, पण अंतिम निर्णय मी घेईन असे सांगा.

2) धुराची चाचणी / पडताळणी यादी:

[SERVICE] साठी एक मसुदा स्मोक चाचणी आणि पडताळणी यादी तयार करा जी मी तैनातीनंतर चालवीन: आरोग्य तपासणी, सर्वात गंभीर वापरकर्ता मार्ग, मी किती मिनिटांसाठी कोणत्या मेट्रिक्सचे निरीक्षण करावे? असे गृहीत धरा की मी सर्वात गंभीर व्यवसाय मार्ग चिन्हांकित करीन आणि ते फील्ड रिक्त सोडेन.

३) रोलबॅक योजना:

मी [DEPLOY METHOD] वापरतो. मला एक स्पष्ट रोलबॅक योजना लिहा: मी कोणत्या आदेशाने/पायरीने जुन्या आवृत्तीवर परत येऊ, यास किती वेळ लागेल, स्वतःच रोलबॅकचे धोके काय आहेत (उदा. डेटाबेस स्थलांतर परत आणले जाऊ शकत नाही), रोलबॅक करण्यापूर्वी मी काय तपासावे?

४) एंड-टू-एंड रिलीझ चेकलिस्ट:

नवीन [SERVICE] प्रकल्पासाठी रिलीज करण्यासाठी एंड-टू-एंड तयारी चेकलिस्ट तयार करा: कोड/इमेज सिक्युरिटी, पाइपलाइन, इन्फ्रास्ट्रक्चर प्लॅन, मॉनिटरिंग आणि अलार्मिंग, सिक्युरिटी स्कॅनिंग, रिलीझ स्ट्रॅटेजी, रोलबॅक आणि व्हेरिफिकेशन. "मी तयार आहे का?" या प्रश्नासह प्रत्येक आयटम तपासा. त्याचे प्रश्नात रुपांतर करा.

कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट

कमकुवत: "मी हे उत्पादनात कसे मिळवू?"

परिणाम: संदर्भ नाही; AI सामान्य उपयोजन चरणांची सूची देते, ते तुमची जोखीम सहनशीलता, वापरकर्ता स्केल आणि रोलबॅक गरजेकडे लक्ष देत नाही.

Güçlü: "मी 10 दशलक्ष वापरकर्त्यांसह पेमेंट सेवेची निर्मिती करीन, डाउनटाइमसाठी माझी सहनशीलता खूपच कमी आहे. तुम्ही कॅनरी किंवा ब्लू-ग्रीनची शिफारस करता, का? तैनातीनंतर मी कोणत्या गंभीर मार्गांची चाचणी घ्यावी, मी किती मिनिटांसाठी कोणत्या मेट्रिक्सचे परीक्षण करावे आणि 60-सेकंद रोलबॅक योजना कशी असावी? मी अंतिम निर्णय घेईन."

फरक: दुसरा प्रॉम्प्ट स्केल, सहिष्णुता आणि रोलबॅक अपेक्षा देतो; त्यासाठी धोरण + पडताळणी + पूर्ववत करणे आवश्यक आहे आणि निर्णय माणसावर सोडतो.

सामान्य चुका

  • रोलबॅक योजनेशिवाय तैनात करणे. परतीचा मार्ग नसेल तर, प्रत्येक उपयोजन हा एक जुगार आहे.
  • बिग-बँग तैनाती. ते एकाच वेळी संपूर्ण वापरकर्त्याला दिल्याने धोका वाढतो.
  • गृहीत धरून "हिरवा = कार्यरत". आरोग्य तपासणी उत्तीर्ण केलेली सेवा गंभीर मार्गावर खंडित होऊ शकते.
  • असा विचार करून तुम्ही गंभीर व्यवसाय मार्ग AI वर सोडत आहात. तुम्ही पेमेंट सारख्या पद्धती चिन्हांकित करणे आवश्यक आहे.
  • तैनाती नंतर देखरेख नाही. कपटी समस्या पहिल्या मिनिटात दिसत नाहीत; निरीक्षण विंडो आवश्यक आहे.
  • विचार करणे डेटाबेस स्थलांतर उलट करता येण्यासारखे आहे. काही बदल रोलबॅक होत नाहीत; स्वतंत्रपणे नियोजित आहेत.

सारांशात

प्रोड वर जाणे ही साखळीतील सर्वात गंभीर दुवा आहे आणि ती "आशा" द्वारे नाही तर नियंत्रित धोरणांसह केली जाते: निळा-हिरवा त्वरित रोलबॅक प्रदान करतो, कॅनरी प्रभाव एका लहान तुकड्यापर्यंत मर्यादित करतो, वैशिष्ट्य ध्वज तैनातीला रिलीजपासून वेगळे करतो. तैनाती पूर्ण झाल्यावर काम संपलेले नाही; आरोग्य तपासणी, स्मोक टेस्ट आणि गोल्डन सिग्नल मॉनिटरिंगद्वारे पद्धतशीर पडताळणी आवश्यक आहे. AI संपूर्ण मॉड्यूलमध्ये प्रत्येक टप्प्यावर मसुदे तयार करते आणि वेगवान करते — डॉकरफाइलपासून पाइपलाइनपर्यंत, टेराफॉर्मपासून अलार्म नियमापर्यंत, पोस्टमॉर्टमपासून खर्च विश्लेषणापर्यंत. परंतु सक्षम व्यक्ती राहते जी प्रत्येक पायरीची पडताळणी करते, गो लाइव्ह बटण दाबते आणि निकालाची खात्री देते. हा एंड-टू-एंड एआय-सक्षम DevOps चा सुवर्ण नियम आहे.

अर्ज कार्य

प्रकाशित करण्यासाठी सेवा (वास्तविक किंवा काल्पनिक) निवडा. (1) “रिलीज स्ट्रॅटेजी सिलेक्शन” टेम्प्लेटसह तुमच्या संदर्भाशी जुळणारी रणनीती निवडा आणि का ते लिहा. (२) "स्मोक टेस्ट / पडताळणी सूची" टेम्प्लेटसह व्युत्पन्न केलेली एक पडताळणी यादी घ्या आणि सर्वात गंभीर व्यवसाय मार्ग स्वतः जोडा. (3) "रोलबॅक प्लॅन" टेम्पलेटसह 60-सेकंदाचा रोलबॅक प्लॅन तयार करा आणि त्यात काही अपरिवर्तनीय पायऱ्या आहेत का ते तपासा.

चेकलिस्ट

  • [ ] मी माझ्या संदर्भाला साजेसे रिलीझ धोरण (कॅनरी/ब्लू-ग्रीन/फ्लॅग) निवडले.
  • [] तैनातीपूर्वी माझ्याकडे एक स्पष्ट आणि जलद रोलबॅक योजना तयार आहे.
  • [ ] मी माझ्या स्मोक चाचण्यांमध्ये सर्वात गंभीर व्यवसाय मार्ग (उदा. पेमेंट) जोडले आहेत.
  • तैनातीनंतर, मी निरीक्षण खिडकीतून सोनेरी सिग्नल्सचे निरीक्षण करतो.
  • [ ] मी अपरिवर्तनीय पायऱ्या (डेटाबेस स्थलांतर इ.) देखील नियोजित केल्या आहेत.
  • [] मी प्रत्येक पायरीवर AI ब्ल्यूप्रिंट सत्यापित केले; मी थेट जाण्याचा निर्णय घेतला.

मॉड्यूल परीक्षा

1. मेघमध्ये DevOps आणि AI साठी खालीलपैकी कोणते स्थान सर्वोत्तम आहे?

  • अ) कृत्रिम बुद्धिमत्ता एक सहाय्यक आणि निर्णय समर्थन साधन आहे; उत्पादनावर परिणाम करणाऱ्या गंभीर निर्णयांसाठी लोक जबाबदार असतात ✔
  • ब) कृत्रिम बुद्धिमत्ता मानवी मंजुरीशिवाय उत्पादन उपयोजन आणि गुप्त रोटेशनला अंतिम रूप देऊ शकते
  • क) कृत्रिम बुद्धिमत्ता फक्त कागदपत्रे लिहिण्यासाठी उपयुक्त आहे, त्याचा पायाभूत सुविधांशी काहीही संबंध नाही
  • ड) ऑडिट अनावश्यक आहे कारण कृत्रिम बुद्धिमत्ता नेहमी अभियंता पेक्षा अधिक विश्वासार्ह कमांड तयार करते

वर्णन: हे एक सहाय्यक आणि निर्णय समर्थन साधन आहे जे कृत्रिम बुद्धिमत्ता पाइपलाइन, कॉन्फिगरेशन, स्क्रिप्ट आणि लॉग यासारख्या मजकूर-केंद्रित कार्यांना गती देते. उत्पादन प्रकाशन, गुप्त व्यवस्थापन आणि अंतिम अर्ज यासारख्या डाउनटाइम, पैसा आणि सुरक्षिततेवर परिणाम करणाऱ्या निर्णयांची जबाबदारी सक्षम अभियंत्याकडे राहते.

2. DevOps कमांड किंवा आर्टिफिशियल इंटेलिजन्सद्वारे निर्मित कॉन्फिगरेशन लागू करण्यापूर्वी सत्यापन शिस्तीसाठी सर्वात अचूक अभिव्यक्ती कोणती आहे?

  • अ) जर आउटपुट गुळगुळीत आणि आत्मविश्वासपूर्ण दिसत असेल तर ते थेट उत्पादनामध्ये चालवले जाऊ शकते
  • ब) सिंटॅक्स त्रुटी नसल्यासच आउटपुट सुरक्षित आहे, पुढील तपासण्याची आवश्यकता नाही
  • क) आउटपुटला स्त्रोताशी कनेक्ट करा, योजना/ड्राय-रन करा आणि ते तुमच्या सिस्टम संदर्भासह फिल्टर करा; नंतर अर्ज करा ✔
  • ड) थेट उत्पादनामध्ये प्रथम प्रयत्न करणे आणि निकाल पाहणे हे सर्वात जलद सत्यापन आहे

स्पष्टीकरण: थ्री-स्टेप व्हेरिफिकेशन आवश्यक आहे: आउटपुटला स्त्रोताशी जोडणे (आधिकारिक डॉक्समध्ये कमांड/फ्लॅग आहे), ते कोरडे चालवणे (प्लॅनचे काय होते ते पाहणे/--ड्राय-रन), आणि सिस्टम फिल्टरमधून पास करणे (ते त्याच्या आर्किटेक्चरल आणि सुरक्षा संदर्भात बसते का). ओघ म्हणजे अचूकता नाही.

3. वास्तविक डेटाबेस पासवर्ड असलेल्या .env फाइलसह एरर किंवा डिप्लॉयमेंट समस्येबद्दल कृत्रिम बुद्धिमत्ता विचारताना योग्य दृष्टीकोन कोणता आहे?

  • अ) <PLACEHOLDER> सह वास्तविक रहस्ये लपवा; फक्त मुखवटा घातलेली त्रुटी आणि संदर्भ सामायिक करा ✔
  • ब) संपूर्ण .env फाईल जशी आहे तशी पेस्ट केल्याने समस्या जलद सुटते
  • क) रहस्ये आधीपासूनच बेस64 असल्याने, ते साधे पेस्ट करणे सुरक्षित आहे
  • ड) पासवर्ड पेस्ट करणे सुरक्षित आहे कारण कृत्रिम बुद्धिमत्ता तो कधीही साठवत नाही

वर्णन: एआय प्रॉम्प्टमध्ये कोणतीही वास्तविक रहस्ये पेस्ट केलेली नाहीत. पासवर्ड आणि टोकन्स सारखी मूल्ये <PLACEHOLDER> ने मास्क केली आहेत; फक्त त्रुटी संदेश आणि आवश्यक संदर्भ सामायिक केले जातात. जर गुपित आधीच लीक झाले असेल तर ते त्वरित रद्द केले पाहिजे आणि फिरवावे.

4. सीआय/सीडी पाइपलाइनमधील रहस्ये (पासवर्ड, टोकन) चे योग्य व्यवस्थापन खालीलपैकी कोणते आहे?

  • अ) ते प्लॅटफॉर्मच्या गुप्त भांडारात ठेवले जाते आणि संदर्भानुसार कॉल केले जाते (उदा. ${{ secrets.X }}), साध्या मजकुरात लिहिलेले नाही ✔
  • ब) सोयीसाठी YAML ला पाइपलाइन साध्या मजकुरात लिहिले
  • क) प्रत्येक कामाच्या सुरुवातीला इको आणि लॉग दाबून याची पडताळणी केली जाते.
  • ड) विस्तृत परवानगीने परिभाषित केल्यास (सर्व लिहा), सुरक्षा वाढते

स्पष्टीकरण: YAML ला साध्या मजकुरात रहस्ये लिहिली जात नाहीत; हे प्लॅटफॉर्मच्या गुप्त भांडारात ठेवले जाते आणि ${{ secrets.X }} सारख्या संदर्भांसह कॉल केले जाते. याव्यतिरिक्त, किमान अधिकाराच्या तत्त्वासह, टोकन परवानग्या संकुचित केल्या जातात आणि गुप्त लॉग रेकॉर्ड केला जात नाही.

5. टेराफॉर्मसह पायाभूत सुविधांच्या व्यवस्थापनामध्ये, चेंज लाइव्ह लागू करण्यापूर्वी सर्वात गंभीर पाऊल कोणते आहे?

  • अ) थेट 'टेराफॉर्म लागू' चालवणे; योजना वेळेचा अपव्यय आहे
  • ब) राज्य फाइलचा सार्वजनिक भांडारात बॅकअप घेणे
  • क) 'टेराफॉर्म प्लॅन' चालवा आणि आउटपुटमधील नष्ट/रिप्लेस रेषा तपासा, नंतर लागू करा ✔
  • ड) प्रदाता आवृत्ती अनइंस्टॉल करा आणि नवीनतम आवृत्ती स्वयंचलितपणे येईल याची खात्री करा

स्पष्टीकरण: 'टेराफॉर्म लागू' करण्यापूर्वी 'टेराफॉर्म प्लॅन' चालवणे आवश्यक आहे. काहीही न करता काय जोडायचे, काय बदलायचे आणि विशेषतः काय हटवायचे (नष्ट करायचे) हे प्लॅन दाखवते. अनपेक्षित नष्ट किंवा बदलण्याची ओळ दिसल्यास, अर्ज लागू करू नये.

6. टेराफॉर्म प्लॅन आउटपुटमध्ये उत्पादन डेटाबेससाठी '-/+ बदला' ओळ दिसल्यास याचा अर्थ काय आहे आणि काय करावे?

  • अ) स्त्रोत फक्त साइटवर अपडेट केला जाईल, कोणताही धोका नाही
  • ब) संसाधन हटवले जाईल आणि पुन्हा तयार केले जाईल; डेटा गमावण्याचा धोका आहे, अपेक्षित नसल्यास अर्ज करणे थांबवावे ✔
  • क) नवीन संसाधन जोडणे, विद्यमान डेटाबेस प्रभावित होत नाही
  • ड) ही फक्त एक चेतावणी आहे, सुरक्षितपणे दुर्लक्ष केले जाऊ शकते

स्पष्टीकरण: '-/+ बदला' म्हणजे संसाधन हटवले जाईल आणि पुन्हा तयार केले जाईल; डेटाबेससाठी, याचा अर्थ डेटा गमावणे. अपेक्षित नसल्यास, अर्ज करणे थांबवावे, बदल सुरक्षित पद्धतीमध्ये रूपांतरित केले जावे किंवा अपरिवर्तनीय फील्डला स्पर्श न करता सोडले पाहिजे.

7. सुरक्षितता आणि आकाराच्या दृष्टीने डॉकरफाइल तयार होण्यासाठी खालीलपैकी कोणते खरे आहे?

  • अ) सोयीसाठी, प्रतिमेमध्ये ENV सह गुप्त एम्बेड करणे आणि ते रूट म्हणून चालवणे
  • ब) नेहमी ':लेटेस्ट' टॅग वापरा आणि बेस इमेज शक्य तितकी मोठी ठेवा
  • क) सिंगल-स्टेज बिल्ड आणि अंतिम इमेजमध्ये सर्व बिल्ड टूल्स सोडणे
  • डी) गुपित एम्बेड न करणे, अनधिकृत USER सोबत काम करणे, लहान आणि स्थिर बेस इमेज आणि मल्टी-स्टेज बिल्ड वापरणे ✔

वर्णन: एक उत्पादन-तयार प्रतिमा: गुप्त एम्बेड करत नाही (रनटाइमच्या वेळी ती इंजेक्ट करते), रूट ऐवजी अनधिकृत USER सह चालते, एक लहान आणि आवृत्ती असलेली बेस इमेज वापरते (स्लिम/अल्पाइन, नवीनतम नाही), आणि मल्टी-स्टेज बिल्डसह कमी केली जाते. प्रकाशनापूर्वी असुरक्षिततेसाठी देखील ते स्कॅन केले जाते.

8. कुबर्नेट्समधील तैनातीसाठी संसाधन मर्यादा परिभाषित न करण्याचा सर्वात महत्वाचा धोका कोणता आहे?

  • अ) पॉड कधीही सुरू होत नाही कारण मर्यादा आवश्यक फील्ड आहे
  • ब) मॉनिटरिंग बोर्डवर फक्त एक चेतावणी दिसते, ऑपरेशन प्रभावित होत नाही
  • C) Kubernetes स्वयंचलितपणे सुरक्षित डीफॉल्ट मर्यादा लागू करते, कोणताही धोका नाही
  • ड) पॉड अमर्यादित वाढू शकतो आणि नोडच्या संसाधनांचा वापर करू शकतो, त्यामुळे शेजारच्या सेवा क्रॅश होऊ शकतात ✔

स्पष्टीकरण: संसाधन मर्यादा नसलेला पॉड अमर्यादित वाढू शकतो, तो चालू असलेल्या नोडच्या सर्व संसाधनांचा वापर करू शकतो आणि शेजारच्या सेवा क्रॅश करू शकतो, उदाहरणार्थ, मेमरी लीकसह. म्हणूनच विनंत्या/मर्यादा परिभाषित करणे हा मजबुतीचा आधार आहे.

9. मॉनिटरिंग आणि अलार्म सेटअपमध्ये 'अलर्ट थकवा' कसा टाळायचा?

  • अ) शक्य तितक्या मेट्रिक्सवर अलार्म सेट करा आणि प्रत्येक चढ-उतारासह सूचना व्युत्पन्न करा.
  • ब) सर्व अलार्म उच्च तीव्रतेच्या पातळीवर सेट करा
  • क) वेळ सेट न करता तात्काळ मूल्यांसह अलार्म ट्रिगर करणे (साठी)
  • ड) अलार्म क्रिया-केंद्रित आणि योग्य निकडीवर ठेवणे, ऐतिहासिक डेटासह थ्रेशोल्डची चाचणी करणे, अनावश्यक विलीन करणे ✔

वर्णन: प्रत्येक अलार्म कारवाई करण्यायोग्य आणि योग्य तात्काळ असणे आवश्यक आहे; कारवाईची गरज नसलेली माहिती फलकावर लावली जाते, ती कुणालाही जागवत नाही. अलार्म थ्रेशोल्डची चाचणी सिस्टमच्या ऐतिहासिक डेटावर केली जाते आणि अनावश्यक/पुनरावृत्ती अलार्म एकत्रित केले जातात. अशा प्रकारे खरा अलार्म आवाजात हरवला जाणार नाही.

10. उत्पादन घटनेदरम्यान सर्वोत्तम प्राधान्य क्रम कोणता आहे?

  • अ) प्रथम नेमके मूळ कारण शोधा आणि कारण स्पष्ट झाल्यावरच ते कमी करा.
  • ब) प्रथम पोस्टमॉर्टम रिपोर्ट लिहा, नंतर सेवेला स्पर्श करा
  • क) आधी कमी करा (सेवा पुनर्संचयित/पुनर्संचयित करा), नंतरसाठी मूळ कारण विश्लेषण सोडून ✔
  • ड) प्रथम घटनेसाठी जबाबदार व्यक्ती शोधा आणि त्याची तक्रार करा

स्पष्टीकरण: सुवर्ण नियम 'आधी कमी करा, नंतर तपास करा' असा आहे. प्रथम सेवा पुनर्संचयित करणे किंवा ज्ञात-चांगल्या आवृत्तीवर परत आणणे (शमन करणे) हे ध्येय आहे; दबाव कमी झाल्यानंतर मूळ कारणांचे विश्लेषण शांतपणे केले जाते. नेमके मूळ कारण शोधण्याची प्रतीक्षा केल्याने पुनर्प्राप्ती वेळ (MTTR) वाढते.

11. निर्दोष पोस्टमॉर्टम संस्कृतीचा मुख्य उद्देश काय आहे?

  • अ) चूक करणाऱ्या व्यक्तीची ओळख पटवणे आणि त्याच्यावर जबाबदारी टाकणे
  • ब) प्रणाली आणि प्रक्रियांवर लक्ष केंद्रित करणे आणि शिकण्यास प्रोत्साहन देणे; ✔ दोष देण्याऐवजी पुनरावृत्ती रोखणारे धडे शिकणे
  • क) घटनेची कधीही तक्रार करू नका आणि ती विसरली आहे याची खात्री करा
  • ड) केवळ तांत्रिक तपशील लिहिणे आणि कारवाई करण्यायोग्य गोष्टी जोडणे नाही

स्पष्टीकरण: निर्दोष पोस्टमॉर्टम 'कोणत्या प्रणाली आणि प्रक्रियेने ही चूक होऊ दिली' या प्रश्नावर लक्ष केंद्रित करते, 'ती कोणी केली' नाही. लोक चूक उघडपणे शेअर करतात जर त्यांना माहित असेल की त्यांना शिक्षा होणार नाही; लपविलेल्या त्रुटीची पुनरावृत्ती होते. अहवाल हा आरोपाचा अहवाल नाही, तर कृती-देणारं बाबींनी भरलेला एक शिक्षण दस्तऐवज आहे.

12. क्लाउड कॉस्ट ऑप्टिमायझेशन (फिनऑप्स) मध्ये, वचनबद्ध सूट (आरक्षित/बचत योजना) वर जाण्याआधी कोणती सर्वात तार्किक पायरी आहे?

  • अ) प्रथम शक्य तितक्या प्रदीर्घ वचनबद्धता घ्या, नंतर कचऱ्याचा विचार करा
  • ब) प्रथम, कचरा साफ करा (निष्क्रिय बंद करणे, योग्य आकार देणे), नंतर वचनबद्ध वापरासाठी वचनबद्ध ✔
  • क) सर्व संसाधने त्वरित स्पॉट क्षमतेवर हलवा
  • ड) बीजक डेटाचे पुनरावलोकन न करता सर्वात महाग आयटम हटवणे

स्पष्टीकरण: कचरा प्रथम साफ करणे आवश्यक आहे (निष्क्रिय संसाधने बंद करणे, मोठ्या प्रमाणात संसाधने कमी करणे). अन्यथा, तुम्ही वाया गेलेला वापर 1-3 वर्षांसाठी सवलतीच्या दरात लॉक कराल. योग्य-आकार आणि निष्क्रिय साफसफाईसाठी कोणतीही वचनबद्धता आवश्यक नाही आणि जोखीम-मुक्त जवळ आहेत.

13. एआय-सुचवलेल्या स्क्रिप्टमध्ये 'rm -rf "$DIR"/' ओळ असल्यास सर्वात महत्त्वाचा सुरक्षा उपाय कोणता आहे?

  • अ) स्क्रिप्ट न वाचता थेट प्रॉडमध्ये रन केल्याने वेग वाढेल
  • ब) सेट -euo पाइपफेल आणि रिक्त व्हेरिएबल नियंत्रण जोडा आणि प्रथम ड्राय-रन वापरून पहा ✔
  • क) व्हेरिएबलचे नाव लहान करणे पुरेसे आहे
  • D) rm ऐवजी rm -rf --force वापरल्याने समस्या सुटते

स्पष्टीकरण: जर $DIR रिक्त असेल, तर हे विधान रूट निर्देशिका हटवण्याचा प्रयत्न करू शकते. 'सेट -यू' सह अपरिभाषित व्हेरिएबलवर थांबणे आणि ते हटवण्यापूर्वी व्हेरिएबल रिकामे नाही हे तपासणे (उदा. [ -n "$DIR" ] || निर्गमन 1) आपत्ती टाळते. याव्यतिरिक्त, विनाशकारी ऑपरेशन्स प्रथम ड्राय-रन वापरून पहाव्यात.

14. क्लाउड ऍक्सेस की चुकून सार्वजनिक भांडारात लीक झाल्यास प्रथम काय करावे?

  • अ) की ताबडतोब रद्द करा आणि नूतनीकरण करा (फिरवा); फक्त हटवणे पुरेसे नाही ✔
  • ब) स्टोरेजमधून फक्त फाइल हटवा आणि की सुरक्षित आहे
  • क) कोणीही पाहिले नाही म्हणून काहीही करत नाही
  • ड) स्टोरेज खाजगी केल्याने की फिरवण्याची गरज नाहीशी होते

स्पष्टीकरण: लीक केलेले रहस्य त्वरित रद्द करणे आणि फिरविणे आवश्यक आहे. फक्त फाइल हटवणे पुरेसे नाही कारण हे रहस्य Git इतिहासात राहते आणि सार्वजनिक भांडार काही सेकंदात बॉट्सद्वारे स्कॅन केले जातात. रद्द/रिटर्न केल्यानंतर, प्रभावाचे मूल्यांकन केले जाते आणि पुनरावृत्ती टाळण्यासाठी एक गुप्त स्कॅनर जोडला जातो.

15. प्रॉडची नवीन आवृत्ती जारी करताना खालीलपैकी कोणता दृष्टिकोन जोखीम कमी करतो?

  • अ) सर्व वापरकर्त्यांना एकाच वेळी नवीन आवृत्ती देणे (बिग-बँग) आणि रोलबॅक योजना तयार न करणे
  • ब) अतिरिक्त पडताळणी न करता, 'हिरवा' दिसू लागताच तैनाती पूर्ण झाली आहे.
  • क) कॅनरी/ब्लू-ग्रीन/फीचर फ्लॅग, रेडीमेड रोलबॅक प्लॅन आणि स्मोक टेस्ट + तैनातीनंतर मेट्रिक मॉनिटरिंग सारख्या नियंत्रित धोरणाचा वापर करणे ✔
  • डी) गंभीर व्यवसाय मार्गांची चाचणी पूर्णपणे कृत्रिम बुद्धिमत्तेवर सोडून देणे आणि ते निश्चित न करणे.

स्पष्टीकरण: नियंत्रित रिलीझ धोरणे (कॅनरीसह थोड्या टक्केवारीपासून सुरू होणारी, निळ्या-हिरव्यासह त्वरित रोलबॅक, वैशिष्ट्य ध्वजासह रिलीझपासून डिप्लॉयमेंट वेगळे करणे) जोखीम मर्यादित करते. याव्यतिरिक्त, तैनातीपूर्वी एक स्पष्ट रोलबॅक योजना आणि तैनातीनंतर धूर चाचणीसह गोल्डन सिग्नल मॉनिटरिंग आवश्यक आहे; 'हिरवे दिसणे' याचा अर्थ ते कार्य करत नाही.