DevOps: यह वास्तव में क्या है

सभी को नमस्कार!

हमने "DevOps Philosophy" पुस्तक छापी है, और इस विषय पर एक नई पुस्तक बनाने की भी हमारी योजना है।


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

हम पढ़ते हैं और टिप्पणी करते हैं!

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

DevOps सॉफ्टवेयर उद्योग में एक नया मूलमंत्र है। यह अवधारणा व्यापार और विकास को एकीकृत करने के साथ-साथ एक कथा तैयार करने के बारे में कई ध्वनि विचारों को जोड़ती है, जो हमें एक ही संदर्भ में सॉफ्टवेयर के विकास, वितरण और संचालन के बारे में बात करने की अनुमति देती है।



DevOps एक दृष्टिकोण है जिसमें विकास इंजीनियर और प्रशासनिक इंजीनियर एक सॉफ्टवेयर उत्पाद के संपूर्ण जीवन चक्र में, डिजाइन और विकास से लेकर पूरी तरह से उत्पाद समर्थन में एक साथ भाग लेते हैं। इस प्रकार, DevOps को पारंपरिक असंगति को खत्म करने के लिए डिज़ाइन किया गया है, जहां एक टीम कोड लिखती है, दूसरा इसका परीक्षण करता है, तीसरा डिप्लॉयज़, और चौथा ऑपरेशन के लिए जिम्मेदार है।

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

हमारी कंपनी में कई प्रमुख DevOps विषय हैं: मूल्य, सिद्धांत, तरीके, अभ्यास और उपकरण।



मान

किसी भी इंजीनियर को समाधान खोजने के लिए कैद किया जाता है, और ऐसी आकांक्षा कभी-कभी नई तकनीकों की अस्वीकृति में बदल जाती है, नई चीजों के साथ प्रयोग करने की अनिच्छा, जो अलग-अलग तरीकों से व्यक्त की जाती है: एक दूसरे के बचाव के लिए जवाबी प्रयास के "दूसरे के विकास की अस्वीकृति" के सिंड्रोम से। वास्तव में DevOps में संक्रमण के लिए, इन पूर्वाग्रहों को पहले पहचान लिया जाना चाहिए और फिर दूर किया जाना चाहिए। कोई तकनीक नहीं, और न ही डोकर, कुबेरनेट्स या अमेज़ॅन वेब सेवाएँ आपकी समस्याओं को हल करेंगे यदि आप यह नहीं समझते हैं कि मूल्य प्रस्ताव क्या है।



"हाथ पकड़ लो दोस्तों!" रॉस्पिक्सल स्नैपशॉट Unsplash से

सिद्धांतों

हमारी कंपनी के सिद्धांत तीन तरीकों के मॉडल पर आधारित हैं। यह जीन किम द्वारा विकसित किया गया था, जो "दृश्यमान ऑप्स" और "फीनिक्स प्रोजेक्ट" के लेखक और "लीन आईटी" के लेखक माइक ओरजेन द्वारा विकसित किया गया था। हम एक ऐसे वातावरण का निर्माण करने की सलाह देते हैं जिसमें प्रणालीगत सोच उत्तेजित हो, प्रतिक्रिया चक्र मजबूत हो, और निरंतर प्रयोग और सीखने की संस्कृति पैदा हो।
पूरी प्रणाली के बारे में लगातार सोचें। अपने आप से पूछें: "आपको और भी अधिक प्रतिक्रिया कैसे मिलती है?" निगरानी, ​​मैट्रिक्स और लॉगिंग इनमें से तीन चक्र हैं जो व्यवस्थापकों को डिज़ाइन में भाग लेने में मदद करते हैं। एक स्वस्थ DevOps पर्यावरण में, छोटी और प्रभावी प्रतिक्रिया चक्रों के निर्माण को बढ़ावा देने वाली प्रक्रियाओं को उत्तेजित किया जाता है, ऐसी प्रक्रियाओं के उदाहरण हैं घटना प्रबंधन, पोस्टमार्टम का उद्देश्य विश्लेषण, पारदर्शिता ...



"मैकबुक प्रो से पहले हैंडशेक", अनप्लैश से रॉस्पिक्सल का एक स्नैपशॉट

तरीकों

लचीला प्रबंधन

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

लोग पहले, फिर प्रक्रियाएं, फिर उपकरण

DevOps अग्रदूतों द्वारा प्रस्तावित पहले तरीकों में से एक "पहले लोगों, फिर प्रक्रियाओं, फिर उपकरणों" के रूप में तैयार किया गया है। हमारी कंपनी में, यह अनुशंसा की जाती है कि आप पहले इस बात पर सहमत हों कि एक विशिष्ट कार्य के लिए कौन जिम्मेदार है। फिर हम निर्धारित करते हैं कि इस समस्या को हल करने के लिए किन प्रक्रियाओं की आवश्यकता है। उसके बाद, प्रक्रिया के कार्यान्वयन के लिए आवश्यक उपकरण चुने गए हैं। कागज पर, यह सब तर्कसंगत लगता है, हालांकि, इंजीनियरों और प्रबंधकों को अक्सर आकर्षक "इसे प्राप्त करने की जल्दी!" आपूर्तिकर्ताओं से और इस मामले में वे बिल्कुल विपरीत करने की कोशिश कर रहे हैं: एक उपकरण खरीदें, और फिर इसके लिए कार्यों का संपूर्ण प्रवाह बनाएं।

निरंतर वितरण

यह शब्द हर किसी के होठों पर ऐसा है कि इसे कभी-कभी गलती से देवो के बराबर भी माना जाता है। सिद्धांत रूप में, यह गतिशील प्रोग्रामिंग और सॉफ्टवेयर परीक्षण का अभ्यास है, जो बहुत छोटे, पूर्ण, तैयार टुकड़ों के त्वरित रिलीज प्रदान करता है। सामान्य तौर पर, निरंतर वितरण समग्र गुणवत्ता और गति में सुधार कर सकता है। सतत वितरण परियोजना का एक प्रमुख घटक है, जिसे जल्द से जल्द स्थापित किया जाना चाहिए, DevOps के सफल कार्यान्वयन के लिए ड्राइविंग कारक।

प्रबंधन बदलें



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

कोड में इन्फ्रास्ट्रक्चर (कोड में कॉन्फ़िगरेशन ... कोड में सब कुछ)

एक रहस्योद्घाटन कि वर्तमान कंपनी ने मुझे समृद्ध किया है, यह है कि किसी भी प्रणाली को कोड के रूप में व्याख्या और किया जा सकता है। सिस्टम विनिर्देशों को संस्करण नियंत्रण प्रणालियों और सहकर्मी की समीक्षा में दर्ज किया गया है। आधुनिक तैनाती तंत्रों का उपयोग करते हुए, विशेष रूप से, डॉकर और कुबेरनेट्स, आप स्वचालित रूप से विनिर्देश के आधार पर वास्तविक सिस्टम का निर्माण, परीक्षण और निर्माण कर सकते हैं और उन्हें व्यवस्थित रूप से प्रबंधित कर सकते हैं। यह दृष्टिकोण आपको सिस्टम को संकलित करने और चलाने की अनुमति देता है, और श्रमसाध्य दीर्घकालिक बैसाखी नहीं बनाता है, जो समय के साथ विकसित करना बहुत मुश्किल हो जाता है।

अभ्यास

पिछले सभी आईटी संगठनों में जहां मैंने काम किया था, परियोजनाओं के लिए दृष्टिकोण था: "चलो कुछ लिखें ... और फिर हम किसी को इसे परीक्षण और तैनात करने के लिए निर्देश देंगे।" यह विधि योजनाओं के साथ अच्छी तरह से फिट नहीं है। समय परिवर्तन, और जब विकास टीम अगली परियोजना के लिए आगे बढ़ती है, तो परिचालन लागत असहनीय हो जाती है।



"एक नीले आकाश और सफेद बादलों के नीचे रोलर कोस्टर", अनस्प्लैश से प्रिस्किल्ला डू प्रीज़ का एक स्नैपशॉट

वर्तमान संगठन में, हम डेवलपर्स को उनके द्वारा बनाई गई सेवा और आंशिक रूप से इसके संचालन के लिए जिम्मेदार रखने के लिए प्रयास करते हैं। परिणाम अधिक कुशल प्रतिक्रिया चक्र है जो टीम को न केवल बग के लिए, बल्कि नई सुविधाओं के लिए भी अधिक तेज़ी से प्रतिक्रिया करने में मदद करते हैं और यह सुनिश्चित करते हैं कि उत्पाद सही दिशा में विकसित हो।

उपकरण

हम अपने औजारों से प्यार करते हैं! वे इंजीनियर प्रोग्राम, असेंबल, टेस्ट, पैकेज, रिलीज़, कॉन्फ़िगर और ट्रैक दोनों सिस्टम और एप्लिकेशन को मदद करते हैं। हम अपने औजारों के मालिक हैं और उन समाधानों की पूरी श्रृंखला को जानते हैं जो हमारी रुचि रखते हैं - दोनों खुले स्रोत और वाणिज्यिक। इससे पहले कि DevOps प्रतिमान विकसित होने लगे, नवाचार और उपकरण गतिरोध में थे। लंबे समय तक मैंने अपने करियर की शुरुआत में उसी उपकरण का इस्तेमाल किया (2000 से मैं प्रोग्रामिंग कर रहा हूं)। DevOps में उपयोग किए गए कई उपकरण आश्चर्यजनक रूप से बहुमुखी हैं और सेवा जीवन चक्र को पूरी तरह से नए तरीके से व्यवस्थित करने में मदद करते हैं।



"कार्यशाला में सभी प्रकार के बढ़ईगीरी उपकरण" अनस्प्लैश से बार्न इमेजेज संग्रह से

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

आपको ऐसे उपकरण चुनने की आवश्यकता होती है जो आपकी सूची के बाकी हिस्सों के साथ अच्छी तरह से काम करते हैं। टूल्स को किसी भी काम को स्वचालित करने में मदद करनी चाहिए। उन्हें एपीआई या कमांड लाइन से कॉल करना आसान होना चाहिए। सिद्धांत रूप में, उपकरण जो UI पर अत्यधिक निर्भर हैं, वे अच्छी तरह से एकीकृत टूल में भी बहुत अच्छी तरह से फिट नहीं होते हैं।

आगे क्या ...

डॉकटर छवि डाउनलोड करें और प्रयोग करना शुरू करें। किसी और का कोड फोर्क करें और इसे बनाना शुरू करें। कुबेरनेट्स के साथ एक सर्वर या सर्वर क्लस्टर तैनात करें। तो आप DevOps करते हैं। अपने खुद के कंप्यूटर पर शुरू करें, और फिर क्लाउड पर जाएं।



"एक लड़का सीढ़ियों पर खड़ा है और बादलों के लिए पहुँच रहा है," शमूएल ज़ेलर ने अनप्लाश से गोली मार दी

जब आप पहली बार "कोड में बुनियादी ढांचे" या "निरंतर वितरण" के प्रतिमान के बारे में सुनते हैं, तो आप तुरंत "नहीं, यह हमारे साथ अलग तरह से काम करना चाहते हैं" कहना चाहते हैं। हालांकि, DevOps के साथ सफल होने के लिए, आपको धीरे-धीरे इन तकनीकों में महारत हासिल करने की आवश्यकता है, वे इतने जटिल नहीं हैं। कई वर्षों के लिए, उद्योग ने ऐसे तरीकों का उपयोग किया है जो कि DevOps के बिल्कुल विपरीत हैं, लेकिन DevOps वास्तव में काम करते हैं।