उत्पादन प्रमाणीकरण, रिलीज रणनीतिहरू र अन्त-देखि-अन्त एआई कार्यप्रवाह

लाभ:

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

यो सम्पूर्ण मोड्युल एक बिन्दु तिर बग्यो: कोडको सुरक्षित डेलिभरी र उत्पादनमा पूर्वाधार (वास्तविक ग्राहकहरूले प्रयोग गरेको प्रत्यक्ष वातावरण)। अब हामी श्रृंखलाको सबैभन्दा महत्त्वपूर्ण र तनावपूर्ण लिङ्कमा छौं: परिवर्तन प्रत्यक्ष प्राप्त गर्दै र यो वास्तवमा त्यहाँ काम गर्दछ भनेर प्रमाणित गर्दै। यहाँ एउटा गल्ती सार होइन - यसले सीधै ग्राहक, राजस्व, र प्रतिष्ठामा असर गर्छ। त्यसकारण परिपक्व टोलीहरू "आशा" गरेर होइन तर नियन्त्रित रिलीज रणनीति र व्यवस्थित प्रमाणीकरणको साथ उत्पादनमा जान्छन्।

यस अन्तिम एकाईमा हामी दुई चीजहरू संयोजन गर्छौं: (१) जोखिम कम गर्ने विधिहरू (क्यानरी, निलो-हरियो, सुविधा झण्डा) र उत्पादन प्रमाणीकरणको अनुशासन; (2) कसरी हामीले मोड्युल भरि सिकेका प्रत्येक टुक्रा - CI/CD, IaC, कन्टेनर, निगरानी, ​​घटना, लागत, स्क्रिप्ट, सुरक्षा - एकल AI-संचालित अन्त-देखि-अन्त कार्यप्रवाहमा सँगै आउँछ। प्रारम्भिक उद्धरणलाई अन्तिम पटक दोहोर्याउनुहोस्: AI ले प्रत्येक चरणमा ड्राफ्टहरू उत्पन्न र गति दिन्छ; तर तपाईं एक हुनुहुन्छ जसले "म यो लाइभ लिँदैछु" बटन थिच्छ र परिणामको लागि वाउच गर्दछ।

जोखिम कम गर्ने रणनीतिहरू जारी गर्नुहोस्

एकै समयमा सबै प्रयोगकर्ताहरूलाई परिवर्तन पुस गर्नु सबैभन्दा जोखिमपूर्ण तरिका हो। परिपक्व विधिहरू:

• नीलो-हरियो डिप्लोइमेन्ट: दुई समान वातावरणहरू राखिएको छ - "निलो" (लाइभ) र "हरियो" (नयाँ संस्करण)। नयाँ संस्करण तयार र हरियो मा परीक्षण गरिएको छ, त्यसपछि ट्राफिक अचानक हरियो मा स्विच छ। यदि त्यहाँ समस्या छ भने, ट्राफिक तुरुन्तै निलोमा फर्कन्छ। द्रुत रोलब्याक यसको सबैभन्दा ठूलो फाइदा हो।
• क्यानरी डिप्लोइमेन्ट: नयाँ संस्करण पहिलो पटक प्रयोगकर्ताहरूको सानो प्रतिशत (जस्तै 5%) मा जारी गरिएको छ; यदि मेट्रिक्स राम्रो छ भने, बिस्तारै 100% मा बढाउनुहोस्। समस्याले प्रयोगकर्ताको सानो टुक्रालाई असर गर्छ, सम्पूर्ण प्रयोगकर्तालाई होइन।
• सुविधा झण्डा: नयाँ सुविधा कोड प्रविष्ट गर्दछ तर झण्डा द्वारा अवरुद्ध छ; अनुरोध गर्दा यो निश्चित प्रयोगकर्ताहरूको लागि खोलिएको छ। तैनाती र "रिलिज" बीचको भिन्नता छ; यदि त्यहाँ कुनै समस्या छ भने, कोड फिर्ता नगरी झण्डा बन्द गरिएको छ।

सुझाव: सबैभन्दा छिटो सुरक्षा जाल प्रत्येक तैनाती अघि रोलब्याक तयार हुनु हो। "यदि केहि गलत भयो भने, म कसरी 60 सेकेन्डमा पुरानो संस्करणमा फर्कन सक्छु?" यदि प्रश्नको कुनै स्पष्ट जवाफ छैन भने, तपाइँ त्यो तैनाती गर्न तयार हुनुहुन्न।

उत्पादन प्रमाणीकरण: डिप्लोयमेन्ट समाप्त हुँदा काम समाप्त हुँदैन

केवल डिप्लोइमेन्ट "हरियो" देखिन्छ यसको मतलब यो काम गरिरहेको छैन। व्यवस्थित प्रमाणीकरण:

1. स्वास्थ्य जाँचहरू: के सेवा छ, /हेल्थजले प्रतिक्रिया दिइरहेको छ?
2. धुम्रपान परीक्षणहरू: के केही महत्त्वपूर्ण प्रयोगकर्ता मार्गहरू (लगइन, भुक्तानी, खोज) वास्तवमा काम गर्छन्? स्वचालित र छिटो।
3. सुनौलो संकेतहरूको लागि हेर्नुहोस्: पोस्ट-डिप्लोइ त्रुटि दर, विलम्बता, के ट्राफिक सामान्य छ? (एकाइ 6 मा चार संकेतहरू।)
4. बिस्तारै विस्तार गर्नुहोस्: तपाईंले क्यानरी प्रतिशत बढाउँदा प्रत्येक चरणमा मेट्रिक्स हेर्नुहोस्।
5. अवलोकन सञ्झ्याल: तैनाती पछि समय अवधि (जस्तै 30 मिनेट) को लागी नजिकबाट निगरानी गर्नुहोस्; कपटी समस्याहरू तुरुन्तै देखिँदैनन्।

सावधानी: AI ले धुवाँ परीक्षण वा प्रमाणीकरणहरूको सूची उत्पादन गर्न सक्छ, तर कुन प्रयोगकर्ता मार्गहरू "महत्वपूर्ण" छन् भनेर निर्धारण गर्ने काम तपाईंको हो। AI ले सामान्य सूची दिन्छ; केवल तपाइँलाई थाहा छ कि तपाइँको भुक्तानी प्रवाह, तपाइँको सबैभन्दा राजस्व-उत्पादन मार्ग, परीक्षण गरिनु पर्छ।

रिलीज रणनीति तुलना

रणनीति

मुख्य फाइदा

लागत/जटिलता

सबैभन्दा उपयुक्त

नीलो-हरियो

तत्काल रोलब्याक

दुई वातावरण = 2x स्रोतहरू

यदि छिटो पुन: प्राप्ति महत्वपूर्ण छ

क्यानरी

प्रभावलाई सानो टुक्रामा सीमित गर्दछ

ट्राफिक व्यवस्थापन आवश्यक छ

विशाल प्रयोगकर्ता आधार

फीचर फ्ल्याग

रिलीजबाट डिप्लोय अलग हुन्छ

झण्डा व्यवस्थापन ऋण

क्रमिक/लक्षित उद्घाटन

रोलिङ अपडेट

सरल, स्रोत-मैत्री

ढिलो रोलब्याक

सरल सेवाहरू

अन्त-देखि-अन्त एआई-संचालित कार्यप्रवाह

अब सम्पूर्ण मोड्युललाई एउटै प्रवाहमा जोडौं। मानौँ तपाईँ नयाँ माइक्रोसर्भिस प्रकाशित गर्दै हुनुहुन्छ। AI ले प्रत्येक चरणमा ड्राफ्टहरू उत्पादन गर्दछ; तपाइँ प्रत्येक चरणमा प्रमाणित गर्नुहुन्छ:

1. कोड र कन्टेनर (इकाई ४): AI ले एक अनुकूलित, सुरक्षित डकरफाइल उत्पादन गर्छ; तपाईंले कुनै गोप्य र आकार प्रमाणित गर्नुहोस्।
2. CI/CD (एकाइ 2): AI परीक्षण-निर्माण-डिप्लोइ पाइपलाइन लेख्छ; तपाईंले अनुमतिहरू कम गर्नुहोस् र गोप्य सन्दर्भहरू जाँच गर्नुहोस्।
3. पूर्वाधार (एकाइ ३): AI Terraform सँग आवश्यक स्रोतहरू परिभाषित गर्दछ; तपाईंले योजना आउटपुट पढ्नुभयो र अप्रत्याशित मेटाउनेहरू नहेर्नुहोस्।
4. अर्केस्ट्रेशन (इकाई 5): AI ले Kubernetes manifests उत्पादन गर्छ; तपाईंले स्रोत सीमा, प्रोब, र RBAC प्रमाणित गर्नुहुन्छ।
5. सुरक्षा (एकाइ १०): एआई स्क्यान आउटपुटहरूलाई प्राथमिकता दिन्छ; तपाईंले पहिले शोषण गर्नेहरूलाई समात्नुहोस्।
6. निगरानी (इकाई 6): AI ले अलार्म नियम र ड्यासबोर्ड उत्पन्न गर्दछ; तपाइँ तपाइँको विगत डाटा संग थ्रेसहोल्ड परीक्षण।
7. रिलीज र प्रमाणीकरण (यो एकाई): AI धुवाँ परीक्षण र रोलब्याक योजना रूपरेखा; तपाईं क्यानरी सुरु गर्नुहोस्, मेट्रिक्स हेर्नुहोस्, बटन थिच्नुहोस्।
8. यदि घटना घट्छ (इकाई 7): AI ले परिकल्पना र पोस्टमार्टम स्केच उत्पन्न गर्दछ; तपाइँ प्रमाणित गर्नुहोस् र पाठ सिक्नुहोस्।
9. लागत (एकाइ 8): AI ले नयाँ स्रोतहरूको अपशिष्ट अनुगमन गर्दछ; तपाईं सही-साइजिंग निर्णयहरू गर्नुहुन्छ।

प्रत्येक चरणमा, सामान्य नियम स्थिर रहन्छ: एआई उत्पादन र गति, मानव प्रमाणीकरण र वाउच। यो मोड्युल को सार हो।

तीन मिनी केसहरू

केस 1 - क्यानरीले प्रकोपलाई 5% मा सीमित गर्यो। एउटा टोलीले क्यानरीको साथ 5% प्रयोगकर्ताहरूलाई नयाँ संस्करण दियो। AI ले तुरुन्तै उत्पादन गरेको ड्यासबोर्डले यस स्लाइसमा त्रुटि दर 8% मा पुगेको देखाएको छ। टोलीले यसलाई 100% मा नबढाई फिर्ता लियो; मुद्दाले प्रयोगकर्ताहरूको 5% मात्र प्रभावित गर्यो, र त्यो केही मिनेटको लागि थियो। यदि त्यहाँ ठूलो-बैंग तैनाती थियो भने, सबै ग्राहकहरू प्रभावित हुनेछन्।

केस २ - धुवाँ परीक्षणले छुटेको बाटो समात्यो। AI ले धुवाँ परीक्षण सेट प्रस्ताव गर्‍यो, तर यसमा "भुक्तानी" प्रवाह थिएन। इन्जिनियरले यसलाई थपे, सबैभन्दा महत्त्वपूर्ण राजस्व स्ट्रिम भुक्तान थियो भन्ने थाहा पाएर। पोस्ट-डिप्लोय परीक्षण चेकआउट चरणमा ठीक भयो - तेस्रो-पक्ष कुञ्जीको म्याद सकिएको थियो। प्रमाणीकरणले केही मिनेटमा राजस्वको मौन हानि समात्यो।

केस ३ — तयार रोलब्याक ९० सेकेन्डमा सुरक्षित गरियो। नीलो-हरियो स्थापना गर्ने टोलीले नयाँ संस्करणलाई हरियो बनायो; 2 मिनेट पछि ढिलाइ दोब्बर भयो। तिनीहरूले अग्रिम तयार रोलब्याकको साथ 90 सेकेन्डमा ट्राफिकलाई निलोमा परिणत गरे। तिनीहरूले मूल कारण फेला पारे (नयाँ संस्करणमा ढिलो प्रश्न) दबाबमा होइन, त्यसपछि शान्त रूपमा। तयार रोलब्याक मार्गले अवरोधलाई लगभग अदृश्य बनायो।

चार प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू

1) रणनीति चयन रिलीज:

म निम्न सेवा उत्पादन गर्नेछु: [सेवा/CONTEXT: प्रयोगकर्ताहरूको संख्या, आउटेज सहनशीलता, पूर्वाधार]। नीलो-हरियो, क्यानरी र फिचर झण्डाहरू बीचको तपाईं कुनलाई सिफारिस गर्नुहुन्छ? यस सन्दर्भमा प्रत्येकको फाइदा, लागत र रोलब्याक गति तुलना गर्नुहोस्। सुझाव दिनुहोस्, तर अन्तिम निर्णय म गर्नेछु भनी भन।

2) धुम्रपान परीक्षण / प्रमाणीकरण सूची:

[SERVICE] को लागि मस्यौदा धुम्रपान परीक्षण र प्रमाणिकरण सूची उत्पादन गर्नुहोस् जुन मैले डिप्लोयमेन्ट पछि चलाउनेछु: स्वास्थ्य जाँच, सबैभन्दा महत्त्वपूर्ण प्रयोगकर्ता मार्गहरू, कुन मेट्रिक्स मैले कति मिनेटको लागि निगरानी गर्नुपर्छ? मान्नुहोस् कि म सबैभन्दा महत्त्वपूर्ण व्यापार मार्गहरू चिन्ह लगाउनेछु र त्यो क्षेत्र खाली छोड्नेछु।

3) रोलब्याक योजना:

म [DEPLOY METHOD] प्रयोग गर्छु। मलाई स्पष्ट रोलब्याक योजना लेख्नुहोस्: कुन आदेश/चरणको साथ म पुरानो संस्करणमा रोल ब्याक गर्छु, यसले कति समय लिन्छ, रोलब्याकको जोखिमहरू के हुन् (जस्तै डाटाबेस माइग्रेसन रोलब्याक गर्न सकिँदैन), मैले रोलब्याक गर्नु अघि के जाँच गर्नुपर्छ?

4) अन्त देखि अन्त रिलीज चेकलिस्ट:

नयाँ [SERVICE] परियोजनामा रिलीजको लागि अन्तिम-देखि-अन्त तयारी चेकलिस्ट उत्पादन गर्नुहोस्: कोड/छवि सुरक्षा, पाइपलाइन, पूर्वाधार योजना, निगरानी र चिन्ताजनक, सुरक्षा स्क्यानिङ, रिलीज रणनीति, रोलब्याक र प्रमाणीकरण। "के म तयार छु?" प्रश्नको साथ प्रत्येक वस्तु जाँच गर्नुहोस्। यसलाई प्रश्नमा परिणत गर्नुहोस्।

कमजोर प्रम्प्ट / बलियो प्रम्प्ट

कमजोर: "म यसलाई उत्पादनमा कसरी प्राप्त गर्न सक्छु?"

परिणाम: कुनै सन्दर्भ; AI ले सामान्य तैनाती चरणहरू सूचीबद्ध गर्दछ, यसले तपाईंको जोखिम सहिष्णुता, प्रयोगकर्ता स्केल र रोलब्याक आवश्यकतालाई सम्बोधन गर्दैन।

Güçlü: "म 10 मिलियन प्रयोगकर्ताहरूसँग भुक्तान सेवा उत्पादन गर्नेछु, डाउनटाइमको लागि मेरो सहनशीलता धेरै कम छ। के तपाईं क्यानरी वा ब्लू-ग्रीन सिफारिस गर्नुहुन्छ, किन? मैले डिप्लोइमेन्ट पछि कुन महत्वपूर्ण मार्गहरू परीक्षण गर्नुपर्छ, कुन मेट्रिक्स कति मिनेटको लागि अनुगमन गर्नुपर्छ, र 60-सेकेन्ड रोलब्याक योजना कस्तो हुनुपर्छ? म अन्तिम निर्णय गर्नेछु।"

भिन्नता: दोस्रो प्रम्प्टले स्केल, सहिष्णुता र रोलब्याक अपेक्षा दिन्छ; यसलाई रणनीति + प्रमाणिकरण + पूर्ववत गर्न आवश्यक छ र निर्णय मानवमा छोड्छ।

सामान्य गल्तीहरू

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

संक्षेपमा

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

आवेदन कार्य

प्रकाशित गर्नको लागि सेवा (वास्तविक वा काल्पनिक) छनौट गर्नुहोस्। (१) "रिलीज रणनीति चयन" टेम्प्लेटसँग तपाईंको सन्दर्भमा मिल्ने रणनीति छान्नुहोस् र किन लेख्नुहोस्। (२) "धूम्रपान परीक्षण / प्रमाणीकरण सूची" टेम्प्लेटको साथ उत्पन्न भएको प्रमाणीकरण सूची राख्नुहोस् र सबैभन्दा महत्त्वपूर्ण व्यापार मार्गहरू आफैं थप्नुहोस्। (३) "रोलब्याक योजना" टेम्प्लेटको साथ ६०-सेकेन्डको रोलब्याक योजना तयार गर्नुहोस् र यसमा कुनै अपरिवर्तनीय चरणहरू छन् कि छैनन् भनी जाँच गर्नुहोस्।

चेकलिस्ट

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

मोड्युल परीक्षा

1. क्लाउडमा DevOps र AI को लागि निम्न मध्ये कुन राम्रो स्थिति हो?

• क) कृत्रिम बुद्धिमत्ता एक सहायक र निर्णय समर्थन उपकरण हो; उत्पादनलाई असर गर्ने महत्वपूर्ण निर्णयहरूको लागि मानिसहरू जिम्मेवार छन् ✔
• B) कृत्रिम बुद्धिमत्ताले मानव अनुमोदन बिना उत्पादन डिप्लोइमेन्ट र गोप्य रोटेशनलाई अन्तिम रूप दिन सक्छ।
• ग) आर्टिफिसियल इन्टेलिजेन्स कागजात लेख्नका लागि मात्र उपयोगी छ, यसको पूर्वाधारसँग कुनै सरोकार छैन
• D) लेखापरीक्षण अनावश्यक छ किनभने कृत्रिम बुद्धिमत्ताले सधैं इन्जिनियर भन्दा बढी भरपर्दो आदेशहरू उत्पादन गर्दछ।

विवरण: यो एक सहायक र निर्णय समर्थन उपकरण हो जसले पाठ-गहन कार्यहरू जस्तै कृत्रिम बुद्धिमत्ता पाइपलाइन, कन्फिगरेसन, स्क्रिप्ट र लगलाई गति दिन्छ। उत्पादन रिलीज, गोप्य व्यवस्थापन र अन्तिम आवेदन जस्ता डाउनटाइम, पैसा र सुरक्षालाई असर गर्ने निर्णयहरूको जिम्मेवारी सक्षम इन्जिनियरसँग रहन्छ।

2. कृत्रिम बुद्धिमत्ता द्वारा उत्पादित DevOps आदेश वा कन्फिगरेसन लागू गर्नु अघि प्रमाणीकरण अनुशासनको लागि सबैभन्दा सही अभिव्यक्ति कुन हो?

• A) यदि आउटपुट चिकनी र विश्वस्त देखिन्छ भने यसलाई सीधा उत्पादनमा चलाउन सकिन्छ
• B) कुनै सिन्ट्याक्स त्रुटिहरू नभएमा मात्र आउटपुट सुरक्षित हुन्छ, थप जाँचहरू आवश्यक पर्दैन
• C) स्रोतमा आउटपुट जडान गर्नुहोस्, योजना/ड्राइ-रन गर्नुहोस्, र यसलाई तपाईंको प्रणाली सन्दर्भसँग फिल्टर गर्नुहोस्; त्यसपछि आवेदन दिनुहोस् ✔
• D) प्रोडमा सिधै पहिलो प्रयास गर्नु र नतिजा हेर्नु सबैभन्दा छिटो प्रमाणीकरण हो

स्पष्टीकरण: तीन-चरण प्रमाणिकरण आवश्यक छ: स्रोतमा आउटपुट जडान गर्दै (आधिकारिक कागजातहरूमा कमाण्ड/फ्ल्याग हो), यसलाई सुक्खा चलाउने (योजना/--ड्राइ-रनसँग के हुन्छ हेर्दै), र प्रणाली फिल्टर मार्फत पार गर्दै (के यो यसको वास्तुकला र सुरक्षा सन्दर्भमा फिट हुन्छ)। प्रवाहको अर्थ शुद्धता होइन।

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

• A) <PLACEHOLDER> सँग वास्तविक रहस्यहरू मास्क गर्नुहोस्; मास्क गरिएको त्रुटि र सन्दर्भ मात्र साझा गर्नुहोस् ✔
• B) सम्पूर्ण .env फाइललाई जस्तै टाँस्दा समस्या छिटो समाधान हुन्छ
• C) गोप्यहरू पहिले नै आधार 64 भएकोले, यो सादा टाँस्न सुरक्षित छ
• D) पासवर्ड टाँस्नु सुरक्षित छ किनभने कृत्रिम बुद्धिमत्ताले यसलाई कहिल्यै भण्डार गर्दैन

विवरण: एआई प्रम्प्टमा कुनै वास्तविक रहस्य टाँसिएको छैन। मानहरू जस्तै पासवर्ड र टोकनहरू <PLACEHOLDER> मा मास्क गरिएका छन्; केवल त्रुटि सन्देश र आवश्यक सन्दर्भ साझेदारी गरिएको छ। यदि गोप्य पहिले नै लीक भइसकेको छ भने, यसलाई तुरुन्तै रद्द गरी घुमाउनुपर्छ।

4. CI/CD पाइपलाइनमा गोप्य (पासवर्ड, टोकन) को सही व्यवस्थापन निम्न मध्ये कुन हो?

• A) यो प्लेटफर्मको गोप्य भण्डारमा राखिएको छ र सन्दर्भद्वारा बोलाइन्छ (जस्तै ${{ secrets.X }}), सादा पाठमा लेखिएको छैन ✔
• B) सुविधाको लागि पाइपलाइन YAML लाई सादा पाठमा लेखिएको
• C) प्रत्येक कामको सुरुमा इको र लग थिचेर यसलाई प्रमाणित गरिन्छ।
• D) यदि फराकिलो अनुमतिको साथ परिभाषित गरिएको छ (लेख्नुहोस्-सबै), सुरक्षा बढ्छ

स्पष्टीकरण: गोप्यहरू YAML लाई सादा पाठमा लेखिएको छैन; यसलाई प्लेटफर्मको गोप्य भण्डारमा राखिएको छ र ${{ secrets.X }} जस्ता सन्दर्भहरूसँग बोलाइन्छ। थप रूपमा, न्यूनतम अधिकारको सिद्धान्तको साथ, टोकन अनुमतिहरू संकुचित छन् र गोप्य लग रेकर्ड गरिएको छैन।

5. टेराफर्मको साथ पूर्वाधार व्यवस्थापनमा, परिवर्तन लाइभ लागू गर्नु अघि लिनु पर्ने सबैभन्दा महत्त्वपूर्ण कदम के हो?

• क) सीधा 'टेराफार्म लागू' चलाउने; योजना समयको बर्बादी हो
• ख) सार्वजनिक भण्डारमा राज्य फाइल जगेडा गर्दै
• ग) 'टेराफर्म प्लान' चलाउनुहोस् र आउटपुटमा नष्ट/बदल्ने लाइनहरू जाँच गर्नुहोस्, त्यसपछि लागू गर्नुहोस् ✔
• D) प्रदायक संस्करणको स्थापना रद्द गर्नुहोस् र नयाँ संस्करण स्वचालित रूपमा आउँछ भनेर सुनिश्चित गर्नुहोस्

स्पष्टीकरण: 'टेराफर्म लागू' अघि 'टेराफर्म प्लान' चलाउनु पर्छ। योजनाले के थप्ने, के परिवर्तन गर्ने, र विशेष गरी के मेटाउने (नष्ट) गर्ने, केही नगरी देखाउँछ। यदि अप्रत्याशित रूपमा नष्ट वा प्रतिस्थापन लाइन देखियो भने, लागू गर्नु हुँदैन।

6. यसको अर्थ के हो र यदि उत्पादन डाटाबेसको लागि '-/+ प्रतिस्थापन' रेखा Terraform योजना आउटपुटमा देखा पर्यो भने के गर्नुपर्छ?

• क) स्रोत साइटमा मात्र अद्यावधिक हुनेछ, त्यहाँ कुनै जोखिम छैन
• ख) स्रोत मेटाइनेछ र पुन: सिर्जना गरिनेछ; त्यहाँ डाटा हराउने जोखिम छ, अपेक्षित छैन भने आवेदन रोकिनुपर्छ ✔
• C) नयाँ स्रोत थप्दा, अवस्थित डाटाबेस प्रभावित हुँदैन
• D) यो केवल एक चेतावनी हो, सुरक्षित रूपमा बेवास्ता गर्न सकिन्छ

स्पष्टीकरण: '-/+ बदल्नुहोस्' को अर्थ स्रोत मेटाइनेछ र पुन: सिर्जना गरिनेछ; डाटाबेसको लागि, यसको मतलब डाटा हराउनु हो। यदि अपेक्षित छैन भने, आवेदन रोकिनुपर्छ, परिवर्तनलाई सुरक्षित विधिमा रूपान्तरण गरिनुपर्छ, वा अपरिवर्तनीय क्षेत्रलाई छोइँदैन।

7. डकरफाइलको सुरक्षा र साइजको हिसाबले उत्पादन तयार हुनको लागि निम्न मध्ये कुन सही छ?

• A) सुविधाको लागि, ENV सँग छविमा गोप्य इम्बेड गर्दै र यसलाई रूटको रूपमा चलाउनुहोस्
• ख) सधैं ': नवीनतम' ट्याग प्रयोग गर्नुहोस् र आधार छविलाई सकेसम्म ठूलो राख्नुहोस्
• C) एकल-चरण निर्माण र अन्तिम छविमा सबै निर्माण उपकरणहरू छोड्दै
• D) गोप्य इम्बेड नगर्ने, अनाधिकृत USER सँग काम गर्ने, सानो र स्थिर आधार छवि र बहु-चरण निर्माण ✔

विवरण: उत्पादन-तयार छवि: गोप्य इम्बेड गर्दैन (रनटाइममा इन्जेक्सन गर्छ), रूटको सट्टा अनधिकृत USER सँग चल्छ, सानो र संस्करण गरिएको आधार छवि प्रयोग गर्दछ (स्लिम/अल्पाइन, पछिल्लो होइन), र बहु-चरण निर्माणको साथ मापन गरिएको छ। यो प्रकाशन अघि कमजोरीहरूको लागि स्क्यान पनि गरिन्छ।

8. Kubernetes मा तैनाती को लागी संसाधन सीमा को परिभाषित गर्न को लागी सबैभन्दा महत्त्वपूर्ण जोखिम के हो?

• A) पोड कहिल्यै सुरु हुँदैन किनभने सीमा आवश्यक क्षेत्र हो
• ख) अनुगमन बोर्डमा चेतावनी मात्र देखिन्छ, सञ्चालन प्रभावित हुँदैन
• C) Kubernetes स्वचालित रूपमा सुरक्षित पूर्वनिर्धारित सीमाहरू लागू गर्दछ, कुनै जोखिम छैन
• D) पोड असीमित रूपमा बढ्न सक्छ र नोडको स्रोतहरू उपभोग गर्न सक्छ, यसरी छिमेकी सेवाहरू क्र्यास गर्न सक्छ ✔

स्पष्टीकरण: कुनै स्रोत सीमा नभएको पोडले असीमित रूपमा बढ्न सक्छ, यो चलिरहेको नोडका सबै स्रोतहरू खपत गर्न सक्छ, र छिमेकी सेवाहरू क्र्यास गर्न सक्छ, उदाहरणका लागि, मेमोरी चुहावटको साथ। त्यसैले अनुरोधहरू/सीमाहरू परिभाषित गर्नु दृढताको आधार हो।

9. निगरानी र अलार्म सेटअपमा 'अलर्ट थकान' कसरी बच्ने?

• A) सकेसम्म धेरै मेट्रिक्समा अलार्महरू सेट गर्नुहोस् र प्रत्येक उतार-चढ़ावको साथ अलर्टहरू उत्पन्न गर्नुहोस्।
• B) सबै अलार्महरूलाई उच्चतम गम्भीरता स्तरमा सेट गर्नुहोस्
• C) कुनै समय सेट नगरी तात्कालिक मानहरूसँग अलार्म ट्रिगर गर्दै (का लागि)
• घ) अलार्महरूलाई कार्य-उन्मुख र सही तुरुन्तै राख्दै, ऐतिहासिक डेटाको साथ थ्रेसहोल्डहरू परीक्षण गर्दै, अनावश्यकहरूलाई मर्ज गर्दै ✔

विवरण: प्रत्येक अलार्म कार्ययोग्य र सही अत्यावश्यक हुनुपर्छ; कार्य आवश्यक नहुने जानकारी बोर्डमा प्रदर्शित हुन्छ, यसले कसैलाई जागृत गर्दैन। अलार्म थ्रेसहोल्डहरू प्रणालीको ऐतिहासिक डेटा विरुद्ध परीक्षण गरिन्छ र अनावश्यक/दोहोरिने अलार्महरू समेकित हुन्छन्। यस तरिकाले वास्तविक अलार्म शोरमा हराउने छैन।

10. उत्पादन घटनाको समयमा सबैभन्दा राम्रो प्राथमिकता आदेश के हो?

• क) पहिले ठ्याक्कै मूल कारण पत्ता लगाउनुहोस् र कारण स्पष्ट भएपछि मात्र यसलाई घटाउनुहोस्।
• ख) पहिले पोस्टमार्टम रिपोर्ट लेख्नुहोस्, त्यसपछि सेवा छुनुहोस्
• C) पहिले घटाउनुहोस् (सेवा पुनर्स्थापना/पुनर्स्थापना गर्नुहोस्), पछिको लागि मूल कारण विश्लेषण छोड्नुहोस् ✔
• घ) पहिले घटनाको लागि जिम्मेवार व्यक्ति पत्ता लगाउनुहोस् र रिपोर्ट गर्नुहोस्

व्याख्या: सुनौलो नियम ‘पहिले घटाउ, पछि छानबिन’ हो। लक्ष्य भनेको पहिले सेवा पुनर्स्थापना गर्नु वा यसलाई ज्ञात-राम्रो संस्करण (शमन) मा फिर्ता गर्नु हो। दबाब कम भएपछि शान्त रूपमा मूल कारण विश्लेषण गरिन्छ। सही मूल कारण पत्ता लगाउन पर्खनुले रिकभरी टाइम (MTTR) बढाउँछ।

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

• क) गल्ती गर्ने व्यक्तिको पहिचान गर्ने र उसलाई जिम्मेवारी दिने
• ख) प्रणाली र प्रक्रियाहरूमा ध्यान केन्द्रित गर्ने र सिकाइलाई प्रोत्साहन गर्ने; ✔ दोष लगाउनु भन्दा दोहोर्याउन रोक्ने पाठहरू सिक्ने
• ग) घटनालाई कहिल्यै रिपोर्ट नगर्नुहोस् र यो बिर्सिएको छ भनेर सुनिश्चित गर्नुहोस्
• घ) प्राविधिक विवरणहरू मात्र लेख्ने र कार्ययोग्य वस्तुहरू थप नगर्ने

स्पष्टीकरण: दोषरहित पोस्टमार्टमले 'यो गल्ती कसले गर्यो' भन्ने होइन, 'कुन प्रणाली र प्रक्रियाले यो गल्तीलाई अनुमति दियो' भन्ने प्रश्नमा केन्द्रित हुन्छ। मानिसहरूले गल्ती खुला रूपमा साझा गर्छन् यदि उनीहरूलाई थाहा छ कि उनीहरूलाई सजाय हुनेछैन; लुकेको त्रुटि दोहोर्याइएको छ। प्रतिवेदन आरोप प्रतिवेदन होइन, तर कार्य-उन्मुख वस्तुहरूले भरिएको सिकाउने कागजात हो।

12. क्लाउड लागत अप्टिमाइजेसन (फिनओप्स) मा, प्रतिबद्ध छुटहरू (आरक्षित/बचत योजना) मा जानु अघि सबैभन्दा तार्किक कदम के हो?

• क) सबैभन्दा लामो सम्भावित प्रतिबद्धता पहिले लिनुहोस्, बर्बादको बारेमा पछि सोच्नुहोस्
• ख) पहिले, फोहोर सफा गर्नुहोस् (निष्क्रिय बन्द, दायाँ साइजिङ), त्यसपछि प्रतिबद्ध प्रयोग गर्न प्रतिबद्ध ✔
• C) तुरुन्तै स्पट क्षमतामा सबै स्रोतहरू सार्नुहोस्
• D) बीजक डेटा समीक्षा नगरी सबैभन्दा महँगो वस्तु मेटाउने

स्पष्टीकरण: फोहोरलाई पहिले सफा गर्नुपर्छ (निष्क्रिय स्रोतहरू बन्द गर्दै, ठूलो स्रोतहरू घटाउँदै)। अन्यथा, तपाईंले 1-3 वर्षको लागि छुट मूल्यमा बर्बाद उपयोग लक गर्नुहुनेछ। दायाँ-आकार र निष्क्रिय सफाईलाई कुनै प्रतिबद्धता आवश्यक छैन र जोखिम-मुक्तको नजिक छ।

13. AI-सुझाव लिपिमा 'rm -rf "$DIR"/' लाइन छ भने सबैभन्दा महत्त्वपूर्ण सुरक्षा उपाय के हो?

• A) स्क्रिप्टलाई नपढिकन सीधा प्रोडमा चलाउँदा गति बढ्छ
• B) सेट -euo pipefail र खाली चर नियन्त्रण थप्नुहोस् र ड्राई-रन पहिले प्रयास गर्नुहोस् ✔
• C) चर नाम छोटो गर्न पर्याप्त छ
• D) rm को सट्टा rm -rf --force प्रयोग गर्दा समस्या समाधान हुन्छ

स्पष्टीकरण: यदि $DIR खाली छ भने, यो कथनले रूट डाइरेक्टरी मेटाउने प्रयास गर्न सक्छ। अपरिभाषित चरमा 'set -u' को साथ रोकेर र मेटाउनु अघि चर खाली छैन भनी जाँच गर्नाले (जस्तै [ -n "$DIR" ] || बाहिर निस्कनुहोस् 1) विपत्तिबाट बच्न सकिन्छ। थप रूपमा, विनाशकारी अपरेशनहरू ड्राई-रनको साथ प्रयास गरिनु पर्छ।

14. यदि क्लाउड पहुँच कुञ्जी दुर्घटनावश सार्वजनिक भण्डारमा चुहावट भयो भने के गर्नुपर्छ?

• A) तुरुन्तै रद्द गर्नुहोस् र नविकरण गर्नुहोस् (घुमाउनुहोस्) कुञ्जी; एक्लै मेटाउनु पर्याप्त छैन ✔
• B) केवल भण्डारणबाट फाइल मेटाउनुहोस् र कुञ्जी सुरक्षित छ
• ग) कसैले नदेखेको कारणले केही नगर्ने
• D) भण्डारणलाई निजी बनाउनुले कुञ्जी घुमाउने आवश्यकतालाई हटाउँछ

स्पष्टीकरण: लीक भएको गोप्य रद्द गरी तुरुन्तै घुमाउनुपर्छ। केवल फाइल मेटाउन पर्याप्त छैन किनभने गोप्य Git इतिहासमा रहन्छ र सार्वजनिक भण्डारहरू सेकेन्ड भित्र बटहरू द्वारा स्क्यान गरिन्छ। रद्द / फिर्ता पछि, प्रभाव मूल्याङ्कन गरिन्छ र पुनरावृत्ति रोक्न गोप्य स्क्यानर थपिएको छ।

15. निम्न मध्ये कुन दृष्टिकोणले प्रोडको नयाँ संस्करण जारी गर्दा जोखिम कम गर्छ?

• A) सबै प्रयोगकर्ताहरूलाई एकै समयमा नयाँ संस्करण दिने (बिग-बैंग) र रोलब्याक योजना तयार नगर्ने
• ख) 'हरियो' देखिने बित्तिकै डिप्लोइमेन्ट समाप्त भएको विचार गर्दै, थप प्रमाणीकरण नगरी
• C) क्यानरी/निलो-हरियो/सुविधा झण्डा, रेडिमेड रोलब्याक योजना र धुम्रपान परीक्षण + तैनाती पछि मेट्रिक निगरानी जस्ता नियन्त्रित रणनीति प्रयोग गर्दै ✔
• D) महत्वपूर्ण व्यापार मार्गहरूको परीक्षणलाई पूर्णतया कृत्रिम बुद्धिमत्तामा छोडेर र तिनीहरूलाई निर्धारण नगर्ने।

स्पष्टीकरण: नियन्त्रित रिलीज रणनीतिहरू (क्यानरीको साथ सानो प्रतिशतबाट सुरु हुने, नीलो-हरियोसँग तत्काल रोलब्याक, सुविधा झण्डाको साथ रिलीजबाट डिप्लोयमेन्ट अलग गर्ने) जोखिम सीमित गर्दछ। थप रूपमा, डिप्लोइमेन्ट अघि स्पष्ट रोलब्याक योजना र तैनाती पछि धुवाँ परीक्षणको साथ गोल्डेन सिग्नल अनुगमन आवश्यक छ; 'हरियो देखिने' को मतलब यो काम गर्दैन।