DevOps म्हणजे काय

DevOps ची व्याख्या खूप गुंतागुंतीची आहे, म्हणून आम्हाला प्रत्येक वेळी त्याबद्दल पुन्हा चर्चा सुरू करावी लागेल. एकट्या Habré वर या विषयावर हजारो प्रकाशने आहेत. परंतु जर तुम्ही हे वाचत असाल, तर तुम्हाला कदाचित DevOps म्हणजे काय हे माहित असेल. कारण मी नाही. हॅलो माझे नाव आहे अलेक्झांडर टिटोव्ह (@osminog), आणि आम्ही फक्त DevOps बद्दल बोलू आणि मी माझा अनुभव सामायिक करेन.

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

एकेकाळी मी विलीनीकरण आणि अधिग्रहणाच्या लाटेवर स्वार होतो. प्रथम, मी किक नावाच्या छोट्या स्टार्टअपसाठी काम केले, नंतर ते स्काईप नावाच्या थोड्या मोठ्या कंपनीने विकत घेतले, जे नंतर मायक्रोसॉफ्ट नावाच्या थोड्या मोठ्या कंपनीने विकत घेतले. त्या क्षणी, मी वेगवेगळ्या आकाराच्या कंपन्यांमध्ये DevOps ची कल्पना कशी बदलत आहे हे पाहू लागलो. त्यानंतर, मला DevOps कडे बाजाराच्या दृष्टिकोनातून पाहण्याची आवड निर्माण झाली आणि मी आणि माझ्या सहकाऱ्यांनी एक्सप्रेस 42 ही कंपनी स्थापन केली. आता 6 वर्षांपासून आम्ही बाजाराच्या लहरींवर वाटचाल करत आहोत.

इतर गोष्टींबरोबरच, मी DevOps मॉस्को समुदायाचा आणि DevOps-Days 2017 च्या आयोजकांपैकी एक आहे, परंतु मी 2018 चे आयोजन केले नाही. एक्सप्रेस 42 अनेक कंपन्यांसोबत काम करते. आम्ही तिथे DevOps वाढवतो, ते कसे घडते ते पाहतो, निष्कर्ष काढतो, विश्लेषण करतो, सर्वांना आमचे निष्कर्ष सांगतो आणि लोकांना DevOps पद्धतींमध्ये प्रशिक्षण देतो. सर्वसाधारणपणे, या संदर्भात आमचा अनुभव आणि कौशल्य वाढवण्यासाठी आम्ही सर्वतोपरी प्रयत्न करत आहोत.

DevOps का

पहिला प्रश्न जो प्रत्येकाला सतावतो आणि नेहमीच असतो - का? बर्याच लोकांना असे वाटते की DevOps हे फक्त ऑटोमेशन आहे किंवा प्रत्येक कंपनीकडे आधीपासून असलेली समान गोष्ट आहे.

— आमच्याकडे सतत एकत्रीकरण होते - याचा अर्थ आमच्याकडे आधीच DevOps होते आणि या सर्व गोष्टींची गरज का आहे? ते परदेशात मजा करत आहेत, पण ते आम्हाला काम करण्यापासून थांबवत आहेत!

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

हे सर्व जग बदलत आहे या वस्तुस्थितीमुळे आहे. आमच्या सेंट पीटर्सबर्ग क्लासिकने गायल्याप्रमाणे, एंटरप्राइझच्या दृष्टीकोनातून तो दूर जातो, जेव्हा कंपन्या थेट स्वप्नाकडे जातात, एका विशिष्ट धोरणानुसार बिंदू A ते बिंदू B पर्यंत, त्यासाठी विशिष्ट रचना तयार केली जाते.

तत्वतः, आयटीमधील प्रत्येक गोष्ट या दृष्टिकोनानुसार तयार केली पाहिजे. येथे आयटीचा वापर केवळ प्रक्रिया स्वयंचलित करण्यासाठी केला जातो.

ऑटोमेशन अनेकदा बदलत नाही, कारण जेव्हा एखादी कंपनी चांगलीच घसरते तेव्हा त्यात बदल करण्यासारखे काय असते? हे कार्य करते - त्याला स्पर्श करू नका. आता जगातील दृष्टीकोन बदलत आहेत, आणि चपळ नावाचा एक सूचित करतो की शेवटचा बिंदू बी लगेच दिसत नाही.

जेव्हा एखादी कंपनी मार्केटमधून जाते, क्लायंटसोबत काम करते, तेव्हा ती सतत मार्केट एक्सप्लोर करते आणि शेवटचा बिंदू B बदलते. शिवाय, कंपनी जितक्या वेळा तिची दिशा बदलते तितकी ती शेवटी यशस्वी होते, कारण ती अधिक बाजारपेठ निवडते. कोनाडे

ही रणनीती एका मनोरंजक कंपनीद्वारे दर्शविली आहे ज्याबद्दल मी अलीकडेच शिकलो. वन बॉक्स शेव्ह ही एक बॉक्समधील रेझर आणि शेव्हिंग अॅक्सेसरीजसाठी सदस्यता वितरण सेवा आहे. वेगवेगळ्या क्लायंटसाठी त्यांचा “बॉक्स” कसा सानुकूलित करायचा हे त्यांना माहीत आहे. हे एका विशिष्ट सॉफ्टवेअरद्वारे केले जाते, जे नंतर उत्पादन तयार करणार्‍या कोरियन कारखान्याला ऑर्डर पाठवते.

हे उत्पादन युनिलिव्हरने $1 बिलियनला विकत घेतले होते. ती आता जिलेटशी स्पर्धा करते आणि अमेरिकन बाजारपेठेतील ग्राहकांचा लक्षणीय वाटा काढून घेतला आहे. एक बॉक्स शेव्ह म्हणा:

- 4 ब्लेड? तुम्ही गंभीर आहात का? आपल्याला याची आवश्यकता का आहे - यामुळे शेवची गुणवत्ता सुधारत नाही. दोन ब्लेडसह खास निवडलेली क्रीम, सुगंध आणि उच्च-गुणवत्तेचा रेझर त्या मूर्ख 4 जिलेट ब्लेडपेक्षा कितीतरी जास्त समस्या सोडवतो! आम्ही लवकरच 10 पर्यंत पोहोचू का?

हे जग कसे बदलते. युनिलिव्हरचा दावा आहे की त्यांच्याकडे एक छान IT प्रणाली आहे जी तुम्हाला हे करू देते. शेवटी ती एक संकल्पना दिसते मार्केट टू मार्केट, ज्याबद्दल कोणीही आधीच बोलले नाही.

टाईम-टू-मार्केटचा मुद्दा हा नाही की आम्ही किती वेळा तैनात करतो. तुम्ही बर्‍याचदा उपयोजित करू शकता, परंतु रिलीझ चक्र लांब असेल. जर तीन महिन्यांची रिलीझ सायकल एकमेकांवर लादली गेली, त्यांना एका आठवड्याने हलवल्यास, असे दिसून येते की कंपनी आठवड्यातून एकदा तैनात करत आहे. आणि कल्पना ते अंतिम अंमलबजावणी पर्यंत 3 महिने लागतात.

टाइम-टू-मार्केट म्हणजे कल्पनेपासून अंतिम अंमलबजावणीपर्यंतचा वेळ कमी करणे.

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

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

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

1968 मध्ये, एक दूरदर्शी माणूस, मेल्विन कॉनवे, खालील कल्पना तयार केली.

प्रणाली तयार करणारी संस्था त्या संस्थेच्या संप्रेषण संरचनेची प्रतिकृती बनवणाऱ्या डिझाइनद्वारे मर्यादित असते.

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

वाचा कॉनवेच्या कायद्याबद्दल करू शकता लिंक्स द्वारे. DevOps संस्कृती किंवा तत्वज्ञान समजून घेणे महत्वाचे आहे कारण DevOps मध्ये मूलभूतपणे बदलणारी एकमेव गोष्ट म्हणजे संघांमधील संवादाची रचना.

प्रक्रियेच्या दृष्टिकोनातून, DevOps पूर्वी, सर्व टप्पे: विश्लेषण, विकास, चाचणी, ऑपरेशन, रेखीय होते.
DevOps च्या बाबतीत, या सर्व प्रक्रिया एकाच वेळी होतात.

टाईम-टू-मार्केट हा एकमेव मार्ग आहे. जुन्या प्रक्रियेत काम करणार्‍या लोकांसाठी, हे काहीसे वैश्विक आणि सामान्यतः तसे दिसते.

मग तुम्हाला DevOps ची गरज का आहे?

डिजिटल उत्पादन विकासासाठी. तुमच्या कंपनीकडे डिजिटल उत्पादन नसल्यास, DevOps ची आवश्यकता नाही - हे खूप महत्वाचे आहे.

DevOps अनुक्रमिक सॉफ्टवेअर उत्पादनाच्या गती मर्यादांवर मात करते. त्यामध्ये सर्व प्रक्रिया एकाच वेळी होतात.

अडचण वाढते. जेव्हा DevOps प्रचारक तुम्हाला सांगतात की ते तुमच्यासाठी सॉफ्टवेअर रिलीझ करणे सोपे करेल, तेव्हा हे मूर्खपणाचे आहे.

DevOps सह, गोष्टी फक्त अधिक क्लिष्ट होतील.

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

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

तज्ञांसाठी प्रश्न

तुझ्याकडे काय आहे? कंपनीत काम करताना आणि विशेषज्ञ म्हणून विकसित होत असताना तुम्ही स्वतःला विचारू शकता असे प्रश्न.

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

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

तुमची कंपनी डिजिटल उत्पादनाच्या कोनाड्यातील मार्केट लीडर्सपैकी एक आहे का? Spotify, Yandex, Uber या कंपन्या आता तांत्रिक प्रगतीच्या शिखरावर आहेत.

हे प्रश्न स्वतःला विचारा आणि जर सर्व उत्तरे नाही असतील, तर कदाचित तुम्ही या कंपनीत DevOps करू नये. DevOps चा विषय तुमच्यासाठी खरोखरच मनोरंजक असल्यास, कदाचित... तुम्ही दुसऱ्या कंपनीत जावे? जर तुमच्या कंपनीला DevOps मध्ये जायचे असेल, परंतु तुम्ही सर्व प्रश्नांना “नाही” असे उत्तर दिले, तर ते त्या सुंदर गेंड्यासारखे आहे जे कधीही बदलणार नाही.

संघटना

मी म्हटल्याप्रमाणे, कॉनवेच्या कायद्यानुसार, कंपनीची संघटना बदलते. संस्थात्मक दृष्टिकोनातून DevOps ला कंपनीमध्ये प्रवेश करण्यापासून काय प्रतिबंधित करते ते मी सुरू करेन.

"विहिरींची" समस्या

इंग्रजी शब्द "Silo" येथे रशियन भाषेत " well" असे भाषांतरित केले आहे. या समस्येचा मुद्दा असा आहे की संघांमध्ये माहितीची देवाणघेवाण होत नाही. प्रत्येक कार्यसंघ नेव्हिगेट करण्यासाठी सामान्य नकाशा तयार न करता, त्याच्या कौशल्यामध्ये खोलवर शोध घेतो.

काही मार्गांनी हे मला अशा व्यक्तीची आठवण करून देते जो नुकताच मॉस्कोमध्ये आला आहे आणि मेट्रो नकाशा कसा नेव्हिगेट करायचा हे अद्याप माहित नाही. Muscovites सहसा त्यांचे क्षेत्र चांगले ओळखतात आणि संपूर्ण मॉस्कोमध्ये ते मेट्रो नकाशा वापरून नेव्हिगेट करू शकतात. जेव्हा तुम्ही पहिल्यांदा मॉस्कोला आलात, तेव्हा तुमच्याकडे हे कौशल्य नाही आणि तुम्ही फक्त विचलित आहात.

DevOps या विचलिततेच्या क्षणातून बाहेर पडण्याचा सल्ला देते आणि सर्व विभाग एकत्र काम करून एक समान संवाद नकाशा तयार करतात.

यात दोन घटक अडथळा आणतात.

कॉर्पोरेट व्यवस्थापन प्रणालीचा परिणाम. हे स्वतंत्र श्रेणीबद्ध "विहिरी" मध्ये बांधले आहे. उदाहरणार्थ, या प्रणालीला समर्थन देणाऱ्या कंपन्यांमध्ये काही विशिष्ट KPIs आहेत. दुसरीकडे, एखाद्या व्यक्तीचे मेंदू ज्याला त्यांच्या कौशल्याच्या सीमांच्या पलीकडे जाणे आणि संपूर्ण प्रणाली नेव्हिगेट करणे कठीण वाटते. हे फक्त अस्वस्थ आहे. कल्पना करा की तुम्ही बँकॉक विमानतळावर आहात - तुम्हाला तुमचा मार्ग लवकर सापडणार नाही. DevOps नेव्हिगेट करणे देखील कठीण आहे आणि म्हणूनच लोक म्हणतात की तुम्हाला तेथे जाण्यासाठी मार्गदर्शक शोधण्याची आवश्यकता आहे.

पण सर्वात महत्त्वाची गोष्ट म्हणजे DevOps च्या भावनेने ओतप्रोत असलेल्या, Fowler आणि इतर पुस्तके वाचलेल्या अभियंत्यासाठी “विहिरी” ची समस्या यातून व्यक्त होते. "विहिरी" तुम्हाला "स्पष्ट" गोष्टी करू देत नाहीत. आम्ही अनेकदा DevOps मॉस्को नंतर एकत्र होतो, एकमेकांशी बोलतो आणि लोक तक्रार करतात:

- आम्हाला फक्त CI लाँच करायचे होते, परंतु व्यवस्थापनाला त्याची गरज नसल्याचे दिसून आले.

हे तंतोतंत घडते कारण CI и सतत वितरण प्रक्रिया अनेक परीक्षांच्या सीमेवर आहेत. फक्त संघटनात्मक स्तरावर “विहिरी” च्या समस्येवर मात केल्याशिवाय, तुम्ही काहीही केले आणि कितीही दुःखी असले तरीही तुम्ही पुढे जाऊ शकणार नाही.

कंपनीतील प्रक्रियेतील प्रत्येक सहभागी: बॅकएंड आणि फ्रंटएंड डेव्हलपर, चाचणी, डीबीए, ऑपरेशन, नेटवर्क, त्यांच्या स्वत: च्या दिशेने खोदतात आणि व्यवस्थापकाशिवाय कोणाकडेही सामान्य नकाशा नाही, जो कसा तरी "विभाजन" वापरून त्यांचे निरीक्षण करतो आणि त्यांचे व्यवस्थापन करतो. आणि विजय" पद्धत.

लोक काही तारे किंवा ध्वजांसाठी लढत आहेत, प्रत्येकजण आपले कौशल्य खणत आहे.

परिणामी, जेव्हा हे सर्व एकत्र जोडण्याचे आणि एक सामान्य पाइपलाइन तयार करण्याचे कार्य उद्भवते आणि यापुढे तारे आणि झेंडे यासाठी संघर्ष करण्याची आवश्यकता नाही, तेव्हा प्रश्न उद्भवतो - तरीही काय करावे? आम्हाला कसा तरी करार करणे आवश्यक आहे, परंतु शाळेत हे कसे करावे हे कोणीही आम्हाला शिकवले नाही. आम्हाला शाळेपासून शिकवले जाते: आठवी इयत्ता - व्वा! - सातव्या इयत्तेच्या तुलनेत! इथेही तेच आहे.

तुमच्या कंपनीतही असेच आहे का?

हे तपासण्यासाठी, तुम्ही स्वतःला खालील प्रश्न विचारू शकता.

कार्यसंघ सामान्य साधने वापरतात आणि त्या सामान्य साधनांमधील बदलांमध्ये योगदान देतात?

संघ किती वेळा पुनर्रचना करतात—एका संघातील काही विशेषज्ञ दुसऱ्या संघात जातात? DevOps वातावरणात हे सामान्य बनते, कारण काहीवेळा एखाद्या व्यक्तीला हे समजू शकत नाही की तज्ञांचे दुसरे क्षेत्र काय करत आहे. तो दुसर्‍या विभागात जातो, दोन आठवडे तेथे काम करतो आणि या विभागाशी स्वतःसाठी अभिमुखता आणि संवादाचा नकाशा तयार करतो.

परिवर्तन समिती स्थापन करून गोष्टी बदलणे शक्य आहे का? की सर्वोच्च व्यवस्थापन आणि दिग्दर्शनाच्या भक्कम हाताची गरज आहे? मी नुकतेच Facebook वर लिहिले आहे की एक अल्प-ज्ञात बँक ऑर्डरद्वारे साधने कशी कार्यान्वित करत आहे: आम्ही ऑर्डर लिहितो, आम्ही ते एका वर्षासाठी लागू करतो आणि काय होते ते पहा. हे, अर्थातच, लांब आणि दुःखी आहे.

कंपनीच्या यशाचा विचार न करता वैयक्तिक यश मिळवणे व्यवस्थापकांसाठी किती महत्त्वाचे आहे?

जर तुम्ही स्वतःसाठी या प्रश्नांची उत्तरे दिली तर तुम्हाला तुमच्या कंपनीत अशी समस्या आहे की नाही हे स्पष्ट होईल.

कोड म्हणून पायाभूत सुविधा

ही समस्या उत्तीर्ण झाल्यानंतर, पहिला महत्त्वाचा सराव, ज्याशिवाय DevOps मध्ये पुढे जाणे कठीण आहे कोड म्हणून पायाभूत सुविधा.

बर्याचदा, कोड म्हणून पायाभूत सुविधा खालीलप्रमाणे समजल्या जातात:

— चला सर्व काही बॅशमध्ये स्वयंचलित करूया, स्क्रिप्टने स्वतःला झाकून टाकूया जेणेकरून प्रशासकांना कमी मॅन्युअल काम करता येईल!

पण ते खरे नाही.

कोड म्‍हणून इन्फ्रास्ट्रक्‍चरचा अर्थ असा आहे की तुम्‍ही ज्या IT सिस्‍टमसह कार्य करता ते कोडच्‍या स्‍वरूपात त्‍याची स्थिती सतत समजण्‍यासाठी वर्णन करता.

इतर संघांसह, तुम्ही कोडच्या स्वरूपात एक नकाशा तयार करता जो प्रत्येकजण समजू शकेल आणि नेव्हिगेट आणि नेव्हिगेट करू शकेल. ते काय केले आहे याने काही फरक पडत नाही - शेफ, अॅन्सिबल, सॉल्ट किंवा कुबर्नेट्समध्ये YAML फाइल्स वापरणे - यात काही फरक नाही.

कॉन्फरन्समध्ये, 2GIS मधील एका सहकाऱ्याने सांगितले की त्यांनी कुबर्नेट्ससाठी स्वतःची अंतर्गत गोष्ट कशी बनवली, जी वैयक्तिक प्रणालींच्या संरचनेचे वर्णन करते. 500 प्रणालींचे वर्णन करण्यासाठी, त्यांना हे वर्णन व्युत्पन्न करणारे स्वतंत्र साधन आवश्यक आहे. जेव्हा हे वर्णन असते, तेव्हा प्रत्येकजण एकमेकांशी तपासू शकतो, बदलांचे निरीक्षण करू शकतो, ते कसे बदलायचे आणि ते कसे सुधारायचे, काय गहाळ आहे.

सहमत आहे, वैयक्तिक बॅश स्क्रिप्ट सहसा ही समज प्रदान करत नाहीत. मी काम केलेल्या एका कंपनीत, "फक्त लिहा" स्क्रिप्टचे नाव देखील होते - जेव्हा स्क्रिप्ट लिहिली जाते, परंतु आता ती वाचणे शक्य नाही. मला वाटते की हे तुम्हालाही परिचित आहे.

कोड म्हणून पायाभूत सुविधा पायाभूत सुविधांच्या सद्य स्थितीचे वर्णन करणारा कोड. अनेक उत्पादन, पायाभूत सुविधा आणि सेवा संघ या कोडवर एकत्र काम करतात आणि सर्वात महत्त्वाचे म्हणजे हा कोड प्रत्यक्षात कसा कार्य करतो हे त्या सर्वांना समजून घेणे आवश्यक आहे.

कोड सर्वोत्तम कोड पद्धतींनुसार राखला जातो: संयुक्त विकास, कोड पुनरावलोकन, XP-प्रोग्रामिंग, चाचणी, पुल विनंत्या, कोड पायाभूत सुविधांसाठी CI - हे सर्व योग्य आहे आणि वापरले जाऊ शकते.

सर्व अभियंत्यांसाठी कोड ही एक सामान्य भाषा बनते.

कोडमधील पायाभूत सुविधा बदलण्यास जास्त वेळ लागत नाही. होय, पायाभूत सुविधा कोडमध्ये तांत्रिक कर्ज देखील असू शकते. सहसा संघांना ते स्क्रिप्टच्या गुच्छाच्या स्वरूपात किंवा अगदी अॅन्सिबलच्या रूपात “कोड म्हणून पायाभूत सुविधा” लागू करण्यास सुरुवात केल्यानंतर दीड वर्षानंतर येते, जे ते स्पॅगेटी कोडप्रमाणे लिहितात आणि ते मिश्रणात बॅश स्क्रिप्ट देखील टाकतात!

महत्वाचे: तुम्ही अजून ही सामग्री वापरून पाहिली नसेल, तर लक्षात ठेवा उत्तरदायी म्हणजे बाश नाही! दस्तऐवज काळजीपूर्वक वाचा, ते त्याबद्दल काय लिहितात याचा अभ्यास करा.

कोड म्हणून पायाभूत सुविधा म्हणजे इन्फ्रास्ट्रक्चर कोडचे विभक्त स्तरांमध्ये विभाजन.

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


बेस लेयर - अशा प्रकारे ओएस, बॅकअप आणि इतर निम्न-स्तरीय गोष्टी कॉन्फिगर केल्या जातात, उदाहरणार्थ, कुबर्नेट्स मूलभूत स्तरावर कसे तैनात केले जातात.

सेवा पातळी - तुम्ही डेव्हलपरला पुरवलेल्या या सेवा आहेत: सेवा म्हणून लॉगिंग, सेवा म्हणून देखरेख, सेवा म्हणून डेटाबेस, सेवा म्हणून बॅलन्सर, सेवा म्हणून रांग, सेवा म्हणून सतत वितरण - सेवांचा एक समूह ज्या वैयक्तिक संघ करतात विकासासाठी प्रदान करू शकतात. हे सर्व तुमच्या कॉन्फिगरेशन मॅनेजमेंट सिस्टममध्ये स्वतंत्र मॉड्यूलमध्ये वर्णन करणे आवश्यक आहे.

ज्या स्तरावर अनुप्रयोग केले जातात आणि मागील दोन स्तरांच्या वर ते कसे उलगडतील याचे वर्णन करते.

प्रश्नांवर नियंत्रण ठेवा

तुमच्या कंपनीकडे सामान्य पायाभूत सुविधा भांडार आहे का? तुम्ही तुमच्या पायाभूत सुविधांमध्ये तांत्रिक कर्ज व्यवस्थापित करत आहात का? तुम्ही पायाभूत सुविधा भांडारात विकास पद्धती वापरता का? तुमची पायाभूत सुविधा थरांमध्ये कापली गेली आहे का? तुम्ही बेस-सर्व्हिस-एपीपी डायग्राम तपासू शकता. बदल करणे किती कठीण आहे?

बदल करण्यासाठी दीड दिवस लागल्याचा तुम्हाला अनुभव आला असेल, तर याचा अर्थ तुमच्यावर तांत्रिक कर्ज आहे आणि त्यासोबत काम करणे आवश्यक आहे. तुमच्या इन्फ्रास्ट्रक्चर कोडमधील तांत्रिक कर्ज रेकवर तुम्ही नुकतेच अडखळले. मला अशा अनेक कथा आठवतात जेव्हा, काही सीसीटीएल बदलण्यासाठी, तुम्हाला अर्धा इन्फ्रास्ट्रक्चर कोड पुन्हा लिहावा लागेल, कारण सर्जनशीलता आणि सर्वकाही स्वयंचलित करण्याची इच्छा यामुळे सर्व काही सर्वत्र गंजलेले आहे, सर्व हँडल काढले गेले आहेत आणि रिफॅक्टर करणे आवश्यक आहे.

सतत वितरण

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

तुमच्याकडे ते आहे आणि ते कसे व्यवस्थापित करायचे हे स्पष्ट झाल्यावर, तुम्ही विकसक कोड शक्य तितक्या लवकर उत्पादनासाठी कसा पाठवायचा ते शोधू लागतो. म्हणजे विकसकासह - आम्हाला "विहिरी" च्या समस्येबद्दल आठवते, म्हणजेच हे वैयक्तिक लोक नसून एक संघ आहे.

जेव्हा आपण सोबत असतो वान्या एव्हतुखोविच पहिले पुस्तक पाहिले जेझ नम्र आणि लेखकांचे गट "सतत वितरण", जे 2009 मध्ये रिलीज झाले होते, आम्ही त्याचे शीर्षक रशियनमध्ये कसे भाषांतरित करावे याबद्दल बराच काळ विचार केला. त्यांना त्याचे भाषांतर “सतत वितरण” असे करायचे होते, परंतु, दुर्दैवाने, त्याचे भाषांतर “सतत वितरण” असे केले गेले. मला असे वाटते की आमच्या नावात काहीतरी रशियन आहे, दबावासह.

सतत वितरण साधन

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

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

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

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

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

"सातत्याने वितरित करा" असे दिसते.

वितरण प्रक्रिया Dev, CI, Test, PreProd, Prod हे वेगळे वातावरण नाही, ही अग्निरोधक रक्कम असलेले टप्पे किंवा स्टेशन आहेत ज्यातून तुमची कलाकृती जाते.

जर तुमच्याकडे पायाभूत सुविधा कोड असेल ज्याचे वर्णन बेस सर्व्हिस एपीपी म्हणून केले असेल तर ते मदत करते सर्व स्क्रिप्ट विसरू नका, आणि त्यांना या कलाकृतीसाठी कोड म्हणून लिहा, कलाकृतीचा प्रचार करा आणि तुम्ही जाता तसे बदला.

स्वयं-चाचणी प्रश्न

वैशिष्ट्य वर्णन पासून 95% प्रकरणांमध्ये उत्पादनात रिलीज होण्याचा कालावधी एका आठवड्यापेक्षा कमी आहे? पाइपलाइनच्या प्रत्येक टप्प्यावर आर्टिफॅक्टची गुणवत्ता सुधारते का? त्यातून जाणारी कथा आहे का? तुम्ही विविध उपयोजन धोरण वापरता का?

जर सर्व उत्तरे होय असतील, तर तुम्ही आश्चर्यकारकपणे छान आहात! टिप्पण्यांमध्ये तुमची उत्तरे लिहा - मला आनंद होईल).

अभिप्राय

ही सगळ्यात अवघड सराव आहे. DevOpsConf कॉन्फरन्समध्ये, Infobip मधील एक सहकारी, याबद्दल बोलत असताना, त्याच्या शब्दात थोडा गोंधळ झाला, कारण ही खरोखर एक अतिशय गुंतागुंतीची सराव आहे की आपल्याला प्रत्येक गोष्टीचे निरीक्षण करणे आवश्यक आहे!

उदाहरणार्थ, बर्याच काळापूर्वी, जेव्हा मी Qik येथे काम केले आणि आम्हाला समजले की आम्हाला प्रत्येक गोष्टीचे निरीक्षण करणे आवश्यक आहे. आम्ही हे केले आणि आता आमच्याकडे Zabbix मध्ये 150 आयटम आहेत, ज्यांचे सतत निरीक्षण केले जाते. हे भितीदायक होते, तांत्रिक दिग्दर्शकाने त्याच्या मंदिराकडे बोट फिरवले:

- अगं, तुम्ही अस्पष्ट काहीतरी सर्व्हरवर बलात्कार का करत आहात?

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

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

आम्हाला धक्का बसला, झब्बीक्समध्ये आमचे चार्ट उघडले आणि असे दिसून आले की दीड आठवड्यापूर्वी, हे ब्रोकर वापरत असलेल्या API सेवेतील विनंत्यांचे वर्तन मोठ्या प्रमाणात बदलले आहे. पुढे आपण पाहिले की विशिष्ट प्रकारचे संदेश पाठवण्याची वारंवारता बदलली आहे. नंतर आम्हाला कळले की हे अँड्रॉइड क्लायंट होते. आम्ही विचारले:

- मित्रांनो, दीड आठवड्यापूर्वी तुम्हाला काय झाले?

प्रतिसादात, त्यांनी UI ची पुनर्रचना कशी केली याबद्दल आम्ही एक मनोरंजक कथा ऐकली. कोणीही लगेच म्हणेल की त्यांनी HTTP लायब्ररी बदलली आहे हे संभव नाही. Android क्लायंटसाठी, हे बाथरूममध्ये साबण बदलण्यासारखे आहे - त्यांना फक्त आठवत नाही. परिणामी, 40 मिनिटांच्या संभाषणानंतर, आम्हाला आढळले की त्यांनी HTTP लायब्ररी बदलली आहे आणि त्याची डीफॉल्ट वेळ बदलली आहे. यामुळे एपीआय सर्व्हरवरील ट्रॅफिक वर्तन बदलले, ज्यामुळे ब्रोकरमध्ये शर्यत निर्माण झाली आणि ती क्रॅश होऊ लागली.

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

वितरण प्रक्रियेच्या प्रत्येक टप्प्यावर आर्टिफॅक्टचे काय होते याबद्दल सर्व माहिती गोळा करा - उत्पादनात नाही.

CI वर मॉनिटरिंग अपलोड करा आणि काही मूलभूत गोष्टी तिथे आधीच दिसतील. नंतर तुम्हाला ते Test, PredProd आणि लोड टेस्टिंगमध्ये दिसेल. सर्व टप्प्यांवर माहिती संकलित करा, केवळ मेट्रिक्स, आकडेवारीच नाही तर लॉग देखील: अनुप्रयोग कसा रोल आउट झाला, विसंगती - सर्वकाही गोळा करा.

अन्यथा ते काढणे कठीण होईल. मी आधीच सांगितले आहे की DevOps अधिक जटिल आहे. या जटिलतेचा सामना करण्यासाठी, आपल्याकडे सामान्य विश्लेषणे असणे आवश्यक आहे.

आत्म-नियंत्रणासाठी प्रश्न

तुमचे निरीक्षण आणि लॉगिंग तुमच्यासाठी विकास साधन आहे का? कोड लिहिताना, तुमच्यासह तुमचे विकासक त्याचे निरीक्षण कसे करायचे याचा विचार करतात का?

तुम्ही ग्राहकांच्या समस्यांबद्दल ऐकता का? तुम्ही क्लायंटला मॉनिटरिंग आणि लॉगिंगमधून चांगले समजता का? मॉनिटरिंग आणि लॉगिंगमधून तुम्हाला सिस्टम अधिक चांगले समजते का? तुम्ही सिस्टीम बदलत आहात का कारण तुम्ही पाहिले की सिस्टीममध्ये ट्रेंड वाढत आहे आणि तुम्हाला समजले आहे की आणखी 3 आठवड्यात सर्वकाही मरेल?

एकदा तुमच्याकडे हे तीन घटक आले की, तुम्ही तुमच्या कंपनीमध्ये कोणत्या प्रकारचे इन्फ्रास्ट्रक्चर प्लॅटफॉर्म आहे याचा विचार करू शकता.

पायाभूत सुविधा मंच

मुद्दा असा नाही की हा प्रत्येक कंपनीकडे असमान्य साधनांचा संच आहे.

इन्फ्रास्ट्रक्चर प्लॅटफॉर्मचा मुद्दा असा आहे की सर्व संघ ही साधने वापरतात आणि एकत्रितपणे विकसित करतात.

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

सर्व टीम इन्फ्रास्ट्रक्चर प्लॅटफॉर्म विकसित करतात आणि ते त्यांच्या स्वतःच्या IDE म्हणून काळजीपूर्वक हाताळतात. तुमच्या IDE मध्ये तुम्ही सर्वकाही छान आणि जलद करण्यासाठी आणि हॉटकीज कॉन्फिगर करण्यासाठी वेगवेगळे प्लगइन इन्स्टॉल करता. जेव्हा तुम्ही सबलाइम, अॅटम किंवा व्हिज्युअल स्टुडिओ कोड उघडता तेव्हा कोड एरर येत असतात आणि तुम्हाला हे लक्षात येते की ते काम करणे अशक्य आहे, तुम्हाला लगेच वाईट वाटते आणि तुम्ही तुमचा IDE दुरुस्त करण्यासाठी धावता.

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

पायाभूत सुविधा प्लॅटफॉर्म गुणवत्तेत सतत सुधारणा करून विकासापासून क्लायंटकडे कलाकृतीचे हस्तांतरण सुनिश्चित करते. प्रोडक्शनमधील कोडला घडणाऱ्या कथांच्या संचासह IP प्रोग्राम केला जातो. विकासाच्या वर्षांमध्ये, या अनेक कथा आहेत, त्यापैकी काही अद्वितीय आहेत आणि फक्त तुमच्याशी संबंधित आहेत - त्यांना Google केले जाऊ शकत नाही.

या टप्प्यावर, पायाभूत सुविधा मंच हा तुमचा स्पर्धात्मक फायदा बनतो, कारण त्यामध्ये काहीतरी अंतर्भूत आहे जे प्रतिस्पर्ध्याच्या साधनामध्ये नाही. तुमचा IP जितका सखोल असेल तितका तुमचा टाइम-टू-मार्केटच्या दृष्टीने स्पर्धात्मक फायदा जास्त. येथे दिसते विक्रेता लॉक समस्या: तुम्ही दुसर्‍याचे व्यासपीठ घेऊ शकता, परंतु दुसर्‍याचा अनुभव वापरून, ते तुमच्यासाठी किती समर्पक आहे हे तुम्हाला समजणार नाही. होय, प्रत्येक कंपनी Amazon सारखे प्लॅटफॉर्म तयार करू शकत नाही. ही एक कठीण ओळ आहे जिथे कंपनीचा अनुभव त्याच्या बाजारपेठेतील स्थानाशी संबंधित आहे आणि आपण तेथे विक्रेता लॉक वापरू शकत नाही. याचाही विचार करणे गरजेचे आहे.

योजना

हे इन्फ्रास्ट्रक्चर प्लॅटफॉर्मचे मूलभूत आकृती आहे जे तुम्हाला DevOps कंपनीमध्ये सर्व पद्धती आणि प्रक्रिया सेट करण्यात मदत करेल.

चला त्यात काय समाविष्ट आहे ते पाहूया.

संसाधन ऑर्केस्ट्रेशन प्रणाली, जे ऍप्लिकेशन्स आणि इतर सेवांना CPU, मेमरी, डिस्क प्रदान करते. ह्याच्यावर अजून - निम्न स्तरावरील सेवा: मॉनिटरिंग, लॉगिंग, सीआय/सीडी इंजिन, आर्टिफॅक्ट स्टोरेज, सिस्टम कोड म्हणून पायाभूत सुविधा.

उच्च स्तरीय सेवा: सेवा म्हणून डेटाबेस, सेवा म्हणून रांगा, सेवा म्हणून लोड बॅलन्स, सेवा म्हणून प्रतिमा आकार बदलणे, सेवा म्हणून बिग डेटा फॅक्टरी. ह्याच्यावर अजून - पाइपलाइन जी तुमच्या क्लायंटला सतत सुधारित कोड वितरीत करते.

तुमचे सॉफ्टवेअर क्लायंटसाठी कसे कार्य करते याबद्दल तुम्हाला माहिती मिळते, ते बदलता येते, हा कोड पुन्हा पुरवता येतो, माहिती मिळते - आणि त्यामुळे तुम्ही इन्फ्रास्ट्रक्चर प्लॅटफॉर्म आणि तुमचे सॉफ्टवेअर दोन्ही सतत विकसित करता.

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

हे समजणे महत्त्वाचे आहे की प्लॅटफॉर्मच्या प्रत्येक भागामध्ये एक कथा आहे आणि स्वतःला विचारा की ही वीट कोणती कथा आहे, कदाचित ती फेकून द्यावी आणि तृतीय-पक्ष सेवेने बदलली पाहिजे. उदाहरणार्थ, ईंटऐवजी ओकमीटर स्थापित करणे शक्य आहे का? कदाचित मुलांनी हे कौशल्य आपल्यापेक्षा खूप जास्त विकसित केले आहे. परंतु कदाचित नाही - कदाचित आमच्याकडे अद्वितीय कौशल्य आहे, आम्हाला प्रोमिथियस स्थापित करणे आणि ते आणखी विकसित करणे आवश्यक आहे.

व्यासपीठाची निर्मिती

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

संस्कृतीसह सर्वकाही अगदी सोपे आहे - हे सहकार्य आणि संप्रेषण बद्दल आहे, म्हणजे, एकमेकांसोबत सामान्य क्षेत्रात काम करण्याची इच्छा, एक साधन एकत्र चालवण्याची इच्छा. येथे कोणतेही रॉकेट विज्ञान नाही - सर्व काही अगदी सोपे आहे. उदाहरणार्थ, आम्ही सर्व प्रवेशद्वारामध्ये राहतो आणि ते स्वच्छ ठेवतो - संस्कृतीची अशी पातळी.

तुझ्याकडे काय आहे?

पुन्हा, प्रश्न तुम्ही स्वतःला विचारू शकता.

इन्फ्रास्ट्रक्चर प्लॅटफॉर्म समर्पित आहे का? त्याच्या विकासाची जबाबदारी कोणाची? तुम्हाला तुमच्या इन्फ्रास्ट्रक्चर प्लॅटफॉर्मचे स्पर्धात्मक फायदे समजले आहेत का?

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

तर, DevOps...

... ही एक जटिल प्रणाली आहे, त्यात असणे आवश्यक आहे:

• डिजिटल उत्पादन.
• हे डिजिटल उत्पादन विकसित करणारे व्यवसाय मॉड्यूल.
• कोड लिहिणारे उत्पादन संघ.
• सतत वितरण पद्धती.
• सेवा म्हणून प्लॅटफॉर्म.
• सेवा म्हणून पायाभूत सुविधा.
• कोड म्हणून पायाभूत सुविधा.
• विश्वासार्हता राखण्यासाठी वेगळ्या पद्धती, DevOps मध्ये अंतर्भूत.
• या सर्वांचे वर्णन करणारा अभिप्राय सराव.

तुम्ही या आकृतीचा वापर करू शकता, तुमच्या कंपनीमध्ये तुमच्याकडे आधीपासून काय आहे ते हायलाइट करून: ते विकसित झाले आहे किंवा अद्याप विकसित करणे आवश्यक आहे.

ते दोन आठवड्यांत संपेल DevOpsConf 2019. RIT++ चा भाग म्हणून. कॉन्फरन्समध्ये या, जिथे तुम्हाला सतत डिलिव्हरी, कोड म्हणून पायाभूत सुविधा आणि DevOps ट्रान्सफॉर्मेशनबद्दल अनेक छान अहवाल मिळतील. तुमची तिकिटे बुक करा, अंतिम किंमत अंतिम मुदत 20 मे आहे

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