DevOps अभियंते नाहीत. मग कोण अस्तित्वात आहे आणि त्याचे काय करावे?

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

या पोस्टमध्ये मी जीवनाच्या या टप्प्यावर कसे पोहोचलो, DevOps खरोखर काय आहे आणि आता त्याचे काय करावे याबद्दल थोडेसे बोलू इच्छितो.

अशा रिक्त पदांचा प्रत्येक संभाव्य मार्गाने निषेध केला जाऊ शकतो, परंतु वस्तुस्थिती कायम आहे: त्यापैकी बरेच आहेत आणि या क्षणी बाजार अशा प्रकारे कार्य करतो. आम्ही डेव्हॉप्स कॉन्फरन्स आयोजित केली आणि उघडपणे घोषित केले: “DevOops - DevOps अभियंत्यांसाठी नाही." हे अनेकांना विचित्र आणि जंगली वाटेल: जे लोक पूर्णपणे व्यावसायिक कार्यक्रम करत आहेत ते बाजाराच्या विरोधात का जातात. आता आम्ही सर्वकाही स्पष्ट करू.

संस्कृती आणि प्रक्रियांबद्दल

DevOps ही अभियांत्रिकी शाखा नाही या वस्तुस्थितीपासून सुरुवात करूया. हे सर्व या वस्तुस्थितीपासून सुरू झाले की भूमिकांचे ऐतिहासिकदृष्ट्या स्थापित केलेले विभाजन उत्पादनांच्या गुणवत्तेसाठी कार्य करत नाही. जेव्हा प्रोग्रामर फक्त प्रोग्राम करतात, परंतु चाचणीबद्दल काहीही ऐकू इच्छित नाहीत, तेव्हा सॉफ्टवेअर बग्सने भरलेले असते. सॉफ्टवेअर कसे आणि का लिहिले आहे याची प्रशासकांना काळजी नसते, तेव्हा समर्थन नरकात बदलते.

उदाहरणार्थ, सिस्टम प्रशासक आणि सेवा व्यवस्थापनासाठी SRE दृष्टिकोन यांच्यातील फरकाचे वर्णन करणे प्रसिद्ध Google SRE पुस्तक सुरू होते. मनोरंजक अभ्यास आत चालते आहेत DORA सर्वेक्षण — हे स्पष्ट आहे की सर्वोत्तम विकसक कसे तरी उत्पादनात नवीन बदल तासातून एकदापेक्षा अधिक वेगाने तैनात करण्यास व्यवस्थापित करतात. ते त्यांच्या हातांनी 10% पेक्षा जास्त चाचणी घेत नाहीत (यावरून पाहिले जाऊ शकते गेल्या वर्षीचा DORA). ते हे कसे करतात? “एक्सेल ऑर डाय” या अहवालाच्या शीर्षकांपैकी एक म्हणते. चाचणीच्या संदर्भात या आकडेवारीच्या तपशीलवार चर्चेसाठी, आपण बारुच सदोगुर्स्कीच्या मुख्य गोष्टीचा संदर्भ घेऊ शकता “आमच्याकडे DevOps आहेत. चला सर्व परीक्षकांना काढून टाकूया." आमच्या दुसर्‍या परिषदेत, हायझेनबग.

"जेव्हा कॉम्रेड्समध्ये कोणताही करार नसतो,
त्यांच्यासाठी काही चांगले होणार नाही,
आणि त्यातून काहीही बाहेर येणार नाही, फक्त यातना.
एकेकाळी हंस, क्रेफिश आणि पाईक..."

तुम्हाला असे वाटते की वेब प्रोग्रामरचा कोणता भाग उत्पादनामध्ये त्यांचे अनुप्रयोग वापरल्या जाणार्‍या परिस्थितींना खरोखर समजतो? त्यापैकी कितीजण अॅडमिन्सकडे जातील आणि डेटाबेस क्रॅश झाल्यास काय होईल हे शोधण्याचा प्रयत्न करतील? आणि त्यापैकी कोण परीक्षकांकडे जाईल आणि त्यांना चाचण्या योग्यरित्या कशा लिहायच्या हे शिकवण्यास सांगतील? आणि तेथे सुरक्षा रक्षक, उत्पादन व्यवस्थापक आणि इतर लोकांचा समूह देखील आहे.

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

दुष्टचक्र

मग "डेव्हप्स इंजिनीअरिंग" ची शिस्त कुठून आली? आमच्याकडे एक आवृत्ती आहे! DevOps कल्पना चांगल्या होत्या-एवढ्या चांगल्या होत्या की ते त्यांच्या स्वतःच्या यशाचे बळी ठरले. काही संदिग्ध भरती करणारे आणि मानव तस्कर, ज्यांचे स्वतःचे वातावरण आहे, त्यांनी या संपूर्ण विषयावर फेर धरायला सुरुवात केली.

कल्पना करा: काल तुम्ही खिमकीमध्ये शावरमा बनवत होता आणि आज तुम्ही आधीच एक मोठा माणूस, वरिष्ठ भर्ती करणारे आहात. उमेदवार शोधण्याची आणि निवडण्याची संपूर्ण प्रक्रिया आहे, सर्व काही सोपे नाही, हे समजून घेणे आवश्यक आहे. समजा विभागाचे प्रमुख म्हणतात: X मध्ये एक विशेषज्ञ शोधा. आम्ही X ला "इंजिनियर" हा शब्द नियुक्त करतो आणि आम्ही पूर्ण केले. लिनक्सची गरज आहे? बरं, हा नक्कीच लिनक्स अभियंता आहे, जर तुम्हाला DevOps हवा असेल तर DevOps अभियंता. रिक्त जागेमध्ये केवळ शीर्षकच नाही तर आत काही मजकूर देखील प्रविष्ट करणे आवश्यक आहे. तुमच्या कल्पनेवर अवलंबून Google वरून कीवर्डचा संच प्रविष्ट करणे हा सर्वात सोपा मार्ग आहे. DevOps मध्ये दोन शब्द असतात - “Dev” आणि “Ops”, ज्याचा अर्थ असा आहे की आपल्याला विकासक आणि प्रशासकांशी संबंधित कीवर्ड एकत्र चिकटविणे आवश्यक आहे. अशा प्रकारे 42 प्रोग्रामिंग भाषांमधील प्राविण्य आणि कुबर्नेट्स आणि स्वॉर्म एकाच वेळी वापरल्याच्या 20 वर्षांच्या रिक्त जागा दिसतात. कार्यरत आकृती.

अशाप्रकारे एका विशिष्ट “डेव्हप्स” सुपरहिरोची निरर्थक आणि निर्दयी प्रतिमा लोकांच्या मनात रुजली आहे, जो प्रत्येकाला जेनकिन्सवर तैनात करण्यासाठी कॉन्फिगर करेल आणि आनंद मिळेल. अरे, सर्वकाही इतके सोपे असते तर. "आणि अशा प्रकारे तुम्ही सिस्टम प्रशासकांचा शोध घेऊ शकता," HR विचार करतो, "हा एक फॅशनेबल शब्द आहे, कीवर्ड समान आहेत, त्यांनी आमिष घ्यावे."

मागणीमुळे पुरवठा निर्माण होतो, आणि या सर्व कचर्‍याच्या रिक्त जागा सिस्टीम प्रशासकांच्या विक्षिप्त संख्येने भरल्या गेल्या आहेत ज्यांना हे समजले आहे: तुम्ही पूर्वीप्रमाणेच सर्वकाही करू शकता, परंतु स्वत: ला "डेव्हप्स" म्हणवून अनेक पटींनी अधिक मिळवा. जसे तुम्ही एसएसएच द्वारे सर्व्हर स्वहस्ते एका वेळी कॉन्फिगर केले, तुम्ही ते कॉन्फिगर करणे सुरू ठेवाल, परंतु आता ही एक डेव्हॉप्स सराव आहे. ही एक प्रकारची गुंतागुंतीची घटना आहे, अंशतः क्लासिक प्रशासकांच्या कमी लेखण्याशी आणि DevOps भोवतीच्या प्रचाराशी संबंधित आहे, परंतु सर्वसाधारणपणे, जे घडले ते घडले.

त्यामुळे आमच्याकडे मागणी आणि पुरवठा आहे. एक दुष्ट वर्तुळ जे स्वतःला फीड करते. याच्या विरोधात आम्ही लढत आहोत (देवओप्स कॉन्फरन्स तयार करून).

अर्थात, स्वतःचे नाव बदलून “डेव्हॉप्स” केलेल्या सिस्टम प्रशासकांव्यतिरिक्त, इतर सहभागी आहेत - उदाहरणार्थ, व्यावसायिक SRE किंवा इन्फ्रास्ट्रक्चर-एज-कोड डेव्हलपर.

DevOps मध्ये लोक काय करतात (खरोखर)

त्यामुळे तुम्हाला DevOps पद्धती शिकण्यात आणि लागू करण्यात पुढे जायचे आहे. पण हे कसे करायचे, कोणत्या दिशेने पाहायचे? अर्थात, आपण लोकप्रिय कीवर्डवर आंधळेपणाने अवलंबून राहू नये.

नोकरी असेल तर कोणी करावी. आम्हाला आधीच कळले आहे की हे "डेव्हप इंजिनियर" नाहीत, मग कोण आहेत? हे पदांच्या संदर्भात नव्हे, तर कामाच्या विशिष्ट क्षेत्रांच्या संदर्भात मांडणे अधिक योग्य वाटते.

प्रथम, तुम्ही DevOps-प्रक्रिया आणि संस्कृतीच्या हृदयाला संबोधित करू शकता. संस्कृती हा एक संथ आणि कठीण व्यवसाय आहे आणि जरी ती पारंपारिकपणे व्यवस्थापकांची जबाबदारी असली तरी, प्रोग्रामरपासून प्रशासकांपर्यंत प्रत्येकजण कोणत्या ना कोणत्या प्रकारे गुंतलेला असतो. काही महिन्यांपूर्वी टिम लिस्टर एका मुलाखतीत सांगितले:

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

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

• भूमिका आणि विभागांमधील सुधारित संवाद
• कामाचा अविभाज्य भाग म्हणून चुका स्वीकारणे
• हळूहळू बदल करणे
• टूलिंग आणि इतर ऑटोमेशन वापरणे
• मोजता येण्याजोग्या प्रत्येक गोष्टीचे मोजमाप करणे

हे केवळ विधानांचा काही संच नाही तर विशिष्ट आहे कृतीसाठी मार्गदर्शक. उदाहरणार्थ, चुका स्वीकारण्याच्या मार्गावर, तुम्हाला जोखीम समजून घेणे आवश्यक आहे, SLI (सेवा पातळी निर्देशक) आणि SLO (सेवा पातळी उद्दिष्टे), पोस्टमॉर्टेम लिहायला शिका आणि ते लिहायला घाबरू नका.

SRE शिस्तीत, साधनांचा वापर हा यशाचा एक भाग आहे, जरी एक महत्त्वाचा भाग आहे. आपण सतत तांत्रिकदृष्ट्या विकसित केले पाहिजे, जगात काय चालले आहे आणि ते आपल्या कामात कसे लागू केले जाऊ शकते ते पहा.

या बदल्यात, क्लाउड नेटिव्ह सोल्यूशन्स आता खूप लोकप्रिय झाले आहेत. क्लाउड नेटिव्ह कंप्युटिंग फाउंडेशनने आज परिभाषित केल्याप्रमाणे, क्लाउड नेटिव्ह तंत्रज्ञान संस्थांना आजच्या गतिशील वातावरणात, जसे की सार्वजनिक, खाजगी आणि हायब्रिड क्लाउड्समध्ये स्केल करण्यायोग्य अनुप्रयोग विकसित करण्यास आणि चालविण्यास सक्षम करते. उदाहरणांमध्ये कंटेनर, सर्व्हिस मेश, मायक्रो सर्व्हिसेस, अपरिवर्तनीय पायाभूत सुविधा आणि घोषणात्मक API यांचा समावेश आहे. ही सर्व तंत्रे सैलपणे जोडलेल्या प्रणालींना लवचिक, आटोपशीर आणि अत्यंत निरीक्षण करण्यायोग्य राहण्याची परवानगी देतात. चांगले ऑटोमेशन अभियंत्यांना कामाचे काम न करता वारंवार आणि अंदाजे परिणामांसह मोठे बदल करण्यास अनुमती देते. हे सर्व डॉकर आणि कुबर्नेट्स सारख्या सुप्रसिद्ध साधनांच्या स्टॅकद्वारे समर्थित आहे.

ही ऐवजी क्लिष्ट आणि व्यापक व्याख्या या वस्तुस्थितीमुळे आहे की क्षेत्र देखील खूप गुंतागुंतीचे आहे. एकीकडे, असा युक्तिवाद केला जातो की या प्रणालीमध्ये नवीन बदल अगदी सहज जोडले जावेत. दुसरीकडे, एक प्रकारचे कंटेनरीकृत वातावरण कसे तयार करावे हे शोधण्यासाठी ज्यामध्ये सॉफ्टवेअर-परिभाषित पायाभूत सुविधांवर हलक्या जोडलेल्या सेवा राहतात आणि सतत CI/CD वापरून तेथे वितरित केल्या जातात आणि या सर्वांभोवती DevOps पद्धती तयार करा - या सर्व गोष्टींची अधिक आवश्यकता आहे. एकापेक्षा एक कुत्रा खातात.

या सगळ्याचं काय करायचं

प्रत्येकजण या समस्या त्यांच्या स्वत: च्या मार्गाने सोडवतो: उदाहरणार्थ, आपण दुष्ट वर्तुळ तोडण्यासाठी सामान्य रिक्त जागा प्रकाशित करू शकता. DevOps आणि क्लाउड नेटिव्ह सारख्या शब्दांचा अर्थ काय आहे ते तुम्ही शोधू शकता आणि त्यांचा योग्य आणि बिंदूपर्यंत वापर करू शकता. तुम्ही DevOps मध्ये विकसित करू शकता आणि तुमच्या उदाहरणाद्वारे योग्य दृष्टिकोन दाखवू शकता.

आम्ही एक परिषद करत आहोत DevOops 2020 मॉस्को, जे आम्ही नुकतेच बोललो त्या गोष्टींचा सखोल अभ्यास करण्याची संधी देते. यासाठी अहवालांचे अनेक गट आहेत:

• प्रक्रिया आणि संस्कृती;
• साइट विश्वसनीयता अभियांत्रिकी;
• मेघ नेटिव्ह;

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

अर्थात, कॉन्फरन्समध्येच तुम्ही एकाच वेळी तीन ट्रॅकवर जाऊ शकत नाही, म्हणून आम्ही कार्यक्रम अशा प्रकारे आयोजित करतो की प्रत्येक वेळेच्या स्लॉटमध्ये प्रत्येक चवसाठी विषय असतात.

तुम्ही DevOps अभियंता असल्यास काय करावे हे समजून घेणे बाकी आहे! प्रथम, आपण खरोखर काय करता हे निर्धारित करण्याचा प्रयत्न करा. सहसा त्यांना हा शब्द म्हणायला आवडते:

• विकासक जे पायाभूत सुविधांवर काम करतात. SRE आणि क्लाउड नेटिव्ह बद्दलच्या अहवालांचे गट तुमच्यासाठी सर्वात योग्य आहेत.
• सिस्टम प्रशासक. येथे अधिक क्लिष्ट आहे. DevOops सिस्टम प्रशासनाबद्दल नाही. सुदैवाने, सिस्टम अॅडमिनिस्ट्रेशन या विषयावर अनेक उत्कृष्ट परिषदा, पुस्तके, लेख, इंटरनेटवरील व्हिडिओ इत्यादी आहेत. दुसरीकडे, जर तुम्हाला संस्कृती आणि प्रक्रिया समजून घेण्याच्या दृष्टीने, क्लाउड तंत्रज्ञानाबद्दल आणि क्लाउड नेटिव्हसह जीवनाचे तपशील शिकण्यात स्वारस्य असेल, तर आम्हाला तुम्हाला भेटायला आवडेल! याचा विचार करा: तुम्ही प्रशासन करत आहात आणि मग तुम्ही काय कराल? अचानक एखाद्या अप्रिय परिस्थितीत स्वतःला सापडू नये म्हणून, आपण आता शिकले पाहिजे.

दुसरा पर्याय आहे: तुम्ही टिकून राहा आणि तुम्ही आहात असा दावा करत रहा विशेषतः एक DevOps अभियंता आणि दुसरे काहीही नाही, याचा अर्थ काहीही असो. मग आम्हाला तुमची निराशा करावी लागेल, DevOops ही DevOps अभियंत्यांची परिषद नाही!

पासून स्लाइड करा कॉन्स्टँटिन डायनरचा अहवाल म्युनिक मध्ये

DevOops 2020 मॉस्को मॉस्कोमध्ये 29-30 एप्रिल रोजी होणार आहे, तिकिटे आधीच उपलब्ध आहेत अधिकृत वेबसाइटवर खरेदी करा.

वैकल्पिकरित्या, आपण हे करू शकता तुमचा अहवाल सबमिट करा 8 फेब्रुवारी पर्यंत. कृपया लक्षात घ्या की फॉर्म भरताना, तुम्ही लक्ष्यित प्रेक्षक निवडले पाहिजेत ज्यांना तुमच्या अहवालाचा सर्वाधिक फायदा होईल (यादीत एक आश्चर्य दडले आहे).

स्त्रोत: www.habr.com