त्यहाँ कुनै पनि DevOps इन्जिनियरहरू छैनन्। त्यसपछि को अवस्थित छ, र यसलाई के गर्ने?

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

यस पोष्टमा म कसरी हामी जीवनको यस बिन्दुमा पुग्यौं, DevOps वास्तवमा के हो र यसलाई अब के गर्ने भन्ने बारे थोरै कुरा गर्न चाहन्छु।

त्यस्ता रिक्तताहरू हरेक सम्भावित तरिकामा निन्दा गर्न सकिन्छ, तर तथ्य यो रहन्छ: तिनीहरूमध्ये धेरै छन्, र यो समय बजारले कसरी काम गर्दछ। हामीले डेभोप्स सम्मेलन आयोजना गर्यौं र खुला रूपमा घोषणा गर्यौं: "DevOops - DevOps इन्जिनियरहरूको लागि होइन।" यो धेरैलाई अनौठो र जंगली लाग्नेछ: किन मानिसहरू जसले पूर्ण रूपमा व्यावसायिक कार्यक्रम गरिरहेका छन् बजारको विरुद्धमा जान्छन्। अब हामी सबै कुरा व्याख्या गर्नेछौं।

संस्कृति र प्रक्रियाहरूको बारेमा

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

उदाहरणका लागि, प्रणाली प्रशासक र सेवा व्यवस्थापनको लागि SRE दृष्टिकोण बीचको भिन्नता वर्णन गर्दै प्रसिद्ध Google SRE पुस्तक सुरु हुन्छ। भित्र रोचक अध्ययनहरू गरिएको छ DORA सर्वेक्षण - यो स्पष्ट छ कि उत्कृष्ट विकासकर्ताहरूले कुनै न कुनै रूपमा उत्पादनमा नयाँ परिवर्तनहरू एक घण्टामा एक पटक भन्दा छिटो डिप्लोय गर्न व्यवस्थापन गर्छन्। तिनीहरूले आफ्नो हातले परीक्षण 10% भन्दा बढी छैन (यसबाट देख्न सकिन्छ गत वर्षको DORA)। तिनीहरूले यो कसरी गर्छन्? "एक्सेल वा मर" रिपोर्ट शीर्षक मध्ये एक भन्छ। परीक्षणको सन्दर्भमा यी तथ्याङ्कहरूको विस्तृत छलफलको लागि, तपाइँ बारुच सदोगुर्स्कीको मुख्य टिप्पणीलाई सन्दर्भ गर्न सक्नुहुन्छ। "हामीसँग DevOps छ। सबै परीक्षकहरूलाई बर्खास्त गरौं।" हाम्रो अर्को सम्मेलन, Heisenbug मा।

"जब कामरेडहरूबीच सहमति हुँदैन,
तिनीहरूको लागि चीजहरू राम्रो हुनेछैन,
र यसबाट केहि बाहिर आउँदैन, केवल यातना।
एक पटक एक हंस, एक क्रेफिश र एक पाइक ..."

वेब प्रोग्रामरहरूको कुन भागले तपाईलाई वास्तवमा सर्तहरू बुझ्दछ जुन तिनीहरूको अनुप्रयोगहरू उत्पादनमा प्रयोग गरिन्छ? तिनीहरूमध्ये कति जना प्रशासकहरूमा जानेछन् र डाटाबेस क्र्यास भएमा के हुन्छ भनेर पत्ता लगाउन प्रयास गर्नेछन्? र तिनीहरूमध्ये कसले परीक्षकहरूकहाँ गएर उनीहरूलाई परीक्षा कसरी सही रूपमा लेख्ने भनेर सिकाउन सोध्नेछ? र त्यहाँ सुरक्षा गार्डहरू, उत्पादन प्रबन्धकहरू, र अन्य मानिसहरूको गुच्छा पनि छन्।

DevOps को समग्र विचार भूमिका र विभागहरू बीचको सहकार्य सिर्जना गर्नु हो। सबै भन्दा पहिले, यो केहि चलाखीपूर्वक कन्फिगर गरिएको सफ्टवेयर द्वारा प्राप्त गरिएको छैन, तर संचार को अभ्यास द्वारा। DevOps संस्कृति, अभ्यास, पद्धति र प्रक्रियाहरूको बारेमा हो। यी प्रश्नहरूको जवाफ दिन सक्ने कुनै इन्जिनियरिङ विशेषता छैन।

दुष्ट सर्कल

त्यसपछि "devops ईन्जिनियरिङ्" को अनुशासन कहाँबाट आयो? हामीसँग संस्करण छ! DevOps विचारहरू राम्रो थिए - यत्ति राम्रो कि तिनीहरू आफ्नै सफलताको शिकार भए। आफ्नै वातावरण भएका केही छायादार भर्ती गर्ने र मानव बेचबिखन गर्नेहरूले यो सम्पूर्ण विषयलाई वरिपरि घुमाउन थाले।

कल्पना गर्नुहोस्: हिजो तपाईंले खिम्कीमा शवर्मा बनाउनुभएको थियो, र आज तपाईं पहिले नै ठूलो मान्छे, एक वरिष्ठ भर्तीकर्ता हुनुहुन्छ। त्यहाँ उम्मेदवारहरू खोज्ने र छनोट गर्ने सम्पूर्ण प्रक्रिया छ, सबै कुरा सजिलो छैन, तपाईंले बुझ्न आवश्यक छ। मानौं एउटा विभागको प्रमुखले भन्छन्: X मा विशेषज्ञ खोज्नुहोस्। हामीले X लाई "इन्जिनियर" शब्द तोक्यौं, र हामीले सकियौं। लिनक्स चाहिन्छ? ठिक छ, यो निश्चित रूपमा लिनक्स इन्जिनियर हो, यदि तपाइँ DevOps चाहनुहुन्छ भने, त्यसपछि एक DevOps ईन्जिनियर। खाली ठाउँमा शीर्षक मात्र नभई केही पाठ पनि भित्र भर्नुपर्छ। तपाईको कल्पनाको आधारमा गुगलबाट खोजशब्दहरूको सेट प्रविष्ट गर्ने सबैभन्दा सजिलो तरिका हो। DevOps मा दुई शब्दहरू हुन्छन् - "Dev" र "Ops", जसको अर्थ हामीले विकासकर्ताहरू र प्रशासकहरूसँग सम्बन्धित कुञ्जी शब्दहरू सबैलाई एउटै ढेरमा जोड्न आवश्यक छ। यसरी 42 प्रोग्रामिङ भाषाहरूमा प्रवीणता र Kubernetes र Swarm एकै साथ प्रयोग गरेको 20 वर्षको बारेमा रिक्त स्थानहरू देखा पर्दछ। कार्य रेखाचित्र।

यसरी एक निश्चित "devops" सुपरहीरोको अर्थहीन र निर्दयी छविले मानिसहरूको दिमागमा जरा गाडेको छ, जसले सबैलाई जेनकिन्समा तैनाथ गर्न कन्फिगर गर्नेछ, र खुशी आउनेछ। ओह, यदि केवल सबै कुरा यति सरल थियो। "र यो पनि हो कि तपाइँ कसरी प्रणाली प्रशासकहरूको खोजी गर्न सक्नुहुन्छ," HR सोच्छन्, "यो एक फैशनेबल शब्द हो, किवर्डहरू समान छन्, तिनीहरूले चारा लिनुपर्दछ।"

मागले आपूर्ति सिर्जना गर्छ, र यी सबै रद्दीटोकरी खाली ठाउँहरू प्रणाली प्रशासकहरूको पागल संख्याले भरिएको छ जसले महसुस गर्यो: तपाईंले पहिले जस्तै सबै कुरा गर्न सक्नुहुन्छ, तर आफैलाई "devops" बोलाएर धेरै गुणा प्राप्त गर्नुहोस्। जसरी तपाईंले SSH मार्फत सर्भरहरू म्यानुअल रूपमा एक पटकमा कन्फिगर गर्नुभयो, तपाईंले तिनीहरूलाई कन्फिगर गर्न जारी राख्नुहुनेछ, तर अब यो मानिन्छ कि यो डेभप्स अभ्यास हो। यो केहि प्रकारको जटिल घटना हो, आंशिक रूपमा क्लासिक प्रशासकहरूको अवमूल्यन र DevOps वरपरको प्रचारसँग सम्बन्धित छ, तर सामान्यतया, के भयो, भयो।

त्यसैले हामीसँग आपूर्ति र माग छ। एउटा दुष्ट सर्कल जसले आफैलाई खुवाउँछ। यो के विरुद्ध हामी लडिरहेका छौं (devOops सम्मेलन सिर्जना गरेर सहित)।

निस्सन्देह, प्रणाली प्रशासकहरू बाहेक जसले आफैंलाई "devops" नाम दिएका छन्, त्यहाँ अन्य सहभागीहरू छन् - उदाहरणका लागि, व्यावसायिक SREs वा पूर्वाधार-एज-कोड विकासकर्ताहरू।

DevOps मा मानिसहरू के गर्छन् (वास्तवमा)

त्यसैले तपाईं DevOps अभ्यासहरू सिक्न र लागू गर्नमा अगाडि बढ्न चाहनुहुन्छ। तर यो कसरी गर्ने, कुन दिशामा हेर्ने? जाहिर छ, तपाईंले लोकप्रिय कुञ्जी शब्दहरूमा अन्धाधुन्ध भर पर्नु हुँदैन।

काम छ भने कसैले गर्नुपर्छ । हामीले पहिले नै पत्ता लगाइसकेका छौं कि यिनीहरू "डेप इन्जिनियरहरू" होइनन्, त्यसपछि को हुन्? यसलाई पदका हिसाबले नभई कामका विशिष्ट क्षेत्रका हिसाबले तयार गर्नु बढी सही देखिन्छ।

पहिले, तपाईंले DevOps- प्रक्रिया र संस्कृतिको मुटुलाई सम्बोधन गर्न सक्नुहुन्छ। संस्कृति एक ढिलो र कठिन व्यवसाय हो, र यद्यपि यो परम्परागत रूपमा प्रबन्धकहरूको जिम्मेवारी हो, प्रोग्रामरहरूदेखि प्रशासकहरूसम्म सबैजना कुनै न कुनै रूपमा संलग्न छन्। केहि महिना पहिले टिम लिस्टर एक अन्तर्वार्तामा भने:

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

पक्कै पनि मुद्दाको प्राविधिक पक्ष छ। यदि तपाइँको नयाँ कोड एक महिनामा परीक्षण गरिन्छ, तर एक वर्ष पछि मात्र जारी हुन्छ, र यो सबै गति बढाउन शारीरिक रूपमा असम्भव छ, तपाइँ राम्रो अभ्यासहरूमा बाँच्न सक्नुहुन्न। राम्रो अभ्यासहरू राम्रो उपकरणहरू द्वारा समर्थित छन्। उदाहरणका लागि, इन्फ्रास्ट्रक्चर-एज-कोडलाई दिमागमा राखेर, तपाईंले AWS CloudFormation र Terraform देखि Chef-Ansible-Puppet सम्म कुनै पनि कुरा प्रयोग गर्न सक्नुहुन्छ। तपाईंले यो सबै गर्न जान्न र सक्षम हुन आवश्यक छ, र यो पहिले नै एक ईन्जिनियरिङ् अनुशासन हो। कारणलाई प्रभावसँग भ्रमित नगर्नु महत्त्वपूर्ण छ: पहिले तपाईंले SRE को सिद्धान्तहरू अनुसार काम गर्नुहुन्छ र त्यसपछि मात्र यी सिद्धान्तहरूलाई केही विशिष्ट प्राविधिक समाधानहरूको रूपमा लागू गर्नुहोस्। एकै समयमा, SRE एक धेरै व्यापक पद्धति हो जसले तपाईंलाई जेनकिन्स कसरी सेटअप गर्ने भनेर बताउँदैन, तर लगभग पाँच आधारभूत सिद्धान्तहरू:

• भूमिका र विभागहरू बीच सुधारिएको संचार
• कामको अभिन्न अंगको रूपमा गल्तीहरू स्वीकार गर्दै
• बिस्तारै परिवर्तन गर्दै
• उपकरण र अन्य स्वचालन प्रयोग गर्दै
• मापन गर्न सकिने सबै कुरा नाप्दै

यो केही कथनहरूको सेट मात्र होइन, तर एक विशिष्ट हो कार्य गर्न गाइड। उदाहरणका लागि, त्रुटिहरू स्वीकार गर्ने बाटोमा, तपाईंले जोखिमहरू बुझ्न आवश्यक छ, SLI (सेवा स्तर सूचकहरू) र SLO (सेवा स्तर उद्देश्यहरूपोस्टमार्टम लेख्न सिक्नुहोस् र तिनीहरूलाई डरलाग्दो नहोस् भनेर लेख्नुहोस्।

SRE अनुशासनमा, उपकरणहरूको प्रयोग सफलताको एउटा मात्र भाग हो, यद्यपि एक महत्त्वपूर्ण। हामीले प्राविधिक रूपमा निरन्तर विकास गर्न आवश्यक छ, संसारमा के भइरहेको छ र यसलाई हाम्रो काममा कसरी लागू गर्न सकिन्छ।

बदलामा, क्लाउड नेटिभ समाधानहरू अब धेरै लोकप्रिय भएका छन्। क्लाउड नेटिभ कम्प्युटिङ फाउन्डेसनले आज परिभाषित गरे अनुसार, क्लाउड नेटिभ टेक्नोलोजीहरूले संस्थाहरूलाई आजको गतिशील वातावरण, जस्तै सार्वजनिक, निजी र हाइब्रिड क्लाउडहरूमा स्केलेबल अनुप्रयोगहरू विकास गर्न र चलाउन सक्षम बनाउँछ। उदाहरणहरूमा कन्टेनरहरू, सेवा जालहरू, माइक्रोसेवाहरू, अपरिवर्तनीय पूर्वाधारहरू, र घोषणात्मक API हरू समावेश छन्। यी सबै प्रविधिहरूले ढिलो जोडिएको प्रणालीहरूलाई लोचदार, व्यवस्थित र अत्यधिक अवलोकन गर्न अनुमति दिन्छ। राम्रो स्वचालनले इन्जिनियरहरूलाई काम नगरीकन ठूला परिवर्तनहरू बारम्बार र अनुमानित परिणामहरू गर्न अनुमति दिन्छ। यो सबै डकर र Kubernetes जस्ता प्रसिद्ध उपकरणहरूको स्ट्याक द्वारा समर्थित छ।

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

यो सबै संग के गर्ने

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

हामी सम्मेलन गर्दैछौं DevOops २०२० मस्को, जसले हामीले भर्खरै कुरा गरेका कुराहरूमा गहिरो अध्ययन गर्ने अवसर प्रदान गर्दछ। यसका लागि रिपोर्टहरूको धेरै समूहहरू छन्:

• प्रक्रिया र संस्कृति;
• साइट विश्वसनीयता ईन्जिनियरिङ्;
• क्लाउड नेटिभ;

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

जाहिर छ, सम्मेलनमा नै तपाईं एकै पटक तीनवटा ट्र्याकहरूमा जान सक्नुहुन्न, त्यसैले हामी कार्यक्रमलाई यसरी व्यवस्थित गर्छौं कि प्रत्येक पटक स्लटमा प्रत्येक स्वादको लागि विषयहरू छन्।

यदि तपाईं एक DevOps इन्जिनियर हुनुहुन्छ भने के गर्ने भनेर बुझ्न बाँकी छ! पहिले, तपाईले वास्तवमा के गर्नुहुन्छ भनेर निर्धारण गर्ने प्रयास गर्नुहोस्। सामान्यतया तिनीहरू यो शब्दलाई कल गर्न मन पराउँछन्:

• पूर्वाधारमा काम गर्ने विकासकर्ताहरू। SRE र क्लाउड नेटिभ बारे रिपोर्टहरूको समूहहरू तपाईंको लागि सबैभन्दा उपयुक्त छन्।
• प्रणाली प्रशासकहरू। यहाँ थप जटिल छ। DevOops प्रणाली प्रशासनको बारेमा होइन। सौभाग्य देखि, त्यहाँ धेरै उत्कृष्ट सम्मेलनहरू, पुस्तकहरू, लेखहरू, इन्टरनेटमा भिडियोहरू, आदि प्रणाली प्रशासनको विषयमा छन्। अर्कोतर्फ, यदि तपाईं संस्कृति र प्रक्रियाहरू बुझ्न, क्लाउड टेक्नोलोजीहरू र क्लाउड नेटिभसँग जीवनका विवरणहरू सिक्ने सन्दर्भमा आफूलाई विकास गर्न इच्छुक हुनुहुन्छ भने, हामी तपाईंलाई भेट्न चाहन्छौं! यो कुरा सोच्नुहोस्: तपाई प्रशासन गर्दै हुनुहुन्छ, त्यसपछि तपाई के गर्नुहुन्छ? अचानक आफैलाई अप्रिय परिस्थितिमा फेला पार्नबाट बच्नको लागि, तपाईंले अहिले सिक्नुपर्छ।

त्यहाँ अर्को विकल्प छ: तपाईं दृढ रहनुहोस् र तपाईं हुनुहुन्छ भनेर दाबी गर्न जारी राख्नुहोस् विशेष गरी एक DevOps ईन्जिनियर र अरु केहि छैन, जे भए पनि यसको मतलब। त्यसोभए हामीले तपाईंलाई निराश पार्नु पर्छ, DevOops DevOps इन्जिनियरहरूको लागि सम्मेलन होइन!

बाट स्लाइड गर्नुहोस् Konstantin Diener द्वारा रिपोर्ट म्युनिख मा

DevOops 2020 मस्को अप्रिल 29-30 मा मस्कोमा आयोजित हुनेछ, टिकटहरू पहिले नै उपलब्ध छन् आधिकारिक वेबसाइटमा खरिद गर्नुहोस्.

वैकल्पिक रूपमा, तपाईं सक्नुहुन्छ आफ्नो रिपोर्ट पेश गर्नुहोस् फेब्रुअरी 8 सम्म। कृपया ध्यान दिनुहोस् कि फारम भर्दा, तपाईंले आफ्नो प्रतिवेदनबाट सबैभन्दा बढी लाभ उठाउने लक्षित दर्शकहरू चयन गर्नुपर्छ (सूची भित्र दफन एक आश्चर्य छ).

स्रोत: www.habr.com