DevOps क्या है

DevOps को परिभाषित करना बहुत जटिल है, इसलिए आपको हर बार इसके बारे में चर्चा फिर से शुरू करनी होगी। केवल इस विषय पर एक हजार प्रकाशनों पर। लेकिन अगर आप इसे पढ़ते हैं, तो आप शायद जानते हैं कि DevOps क्या है। क्योंकि मैं नहीं। नमस्ते, मेरा नाम अलेक्जेंडर टिटोव (@ ऑस्मिनोग ) है और हम सिर्फ देवो के बारे में बात करेंगे और मैं अपना अनुभव साझा करूंगा।



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


एक समय मैं विलय और अधिग्रहण की लहरों के साथ चला। सबसे पहले मैंने एक छोटे स्टार्टअप Qik में काम किया, फिर इसे एक बड़ी कंपनी Skype ने खरीद लिया, जिसे बाद में एक बड़ी कंपनी Microsoft ने खरीद लिया। उस समय, एक दृष्टि मेरे लिए उपलब्ध हो गई कि कैसे विभिन्न कंपनियों में DevOps के विचार को रूपांतरित किया जा रहा था। उसके बाद, बाजार के दृष्टिकोण से DevOps को देखना मेरे लिए दिलचस्प हो गया, और मैंने और मेरे सहयोगियों ने कंपनी एक्सप्रेस 42 का आयोजन किया। 6 वर्षों से हम बाजार की लहरों के साथ इस पर आगे बढ़ रहे हैं।

अन्य बातों के अलावा, मैं DevOps मास्को समुदाय के आयोजकों और DevOps -Days 2017 के आयोजक में से एक हूं, लेकिन मैंने 2018 का आयोजन नहीं किया। एक्सप्रेस 42 कई कंपनियों के साथ काम करता है। हम वहां DevOps को अंकुरित करते हैं, देखते हैं कि यह कैसे होता है, निष्कर्ष निकालना, विश्लेषण करना, हमारे निष्कर्षों को सभी को बताना, लोगों को DevOps प्रथाओं को सिखाना। सामान्य तौर पर, हर तरह से हम अनुभव और विशेषज्ञता को बढ़ाते हैं।

क्यों DevOps

पहला सवाल जो हर किसी को परेशान करता है और हमेशा - क्यों? बहुत से लोग सोचते हैं कि DevOps सिर्फ स्वचालन या एक समान चीज है जो हर कंपनी के पास पहले से थी।

- हमारे पास निरंतर एकीकरण था - इसका मतलब है, पहले से ही DevOps था, और इस सभी टॉपर्स की आवश्यकता क्यों है? वे विदेश में मज़े करते हैं, लेकिन वे हमारे काम में हस्तक्षेप करते हैं!

समुदाय और पद्धति के विकास के 9 वर्षों में, यह पहले से ही स्पष्ट हो गया है कि ये स्पैंगल विपणन नहीं कर रहे हैं, लेकिन यह अभी भी पूरी तरह से स्पष्ट नहीं है कि इसकी आवश्यकता क्यों है। किसी भी उपकरण और प्रक्रिया की तरह, DevOps के विशिष्ट लक्ष्य होते हैं जो अंततः हल करता है।

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

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

स्वचालन में अक्सर बदलाव नहीं होता है, क्योंकि जब कोई कंपनी एक रूखे ट्रैक के साथ चलती है - तो क्या बदलना है? यह काम करता है - स्पर्श न करें। अब दुनिया में, दृष्टिकोण बदल रहे हैं, और जिसे एजाइल कहा जाता है वह कहता है कि समापन बिंदु बी तुरंत दिखाई नहीं देता है।



जब कोई कंपनी बाज़ार में घूमती है, क्लाइंट के साथ काम करती है, तो वह लगातार बाज़ार पर शोध करती है और अपने अंतिम बिंदु को बदलती है। इसके अलावा, जितनी अधिक बार कंपनी दिशा बदलती है, अंत में वह उतनी ही सफल होती है, क्योंकि वह अधिक बाज़ार की पसंद का चयन करती है।

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

इस उत्पाद को यूनिलीवर ने $ 1 बिलियन में खरीदा था। अब वह जिलेट के साथ प्रतिस्पर्धा कर रहा है और उसे अमेरिकी बाजार में उपभोक्ताओं के एक महत्वपूर्ण हिस्से को लूट लिया है। एक बॉक्स शेव का कहना है:

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

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



समय-समय पर बाजार की बात यह नहीं है कि हम कितनी बार तैनात करते हैं। आप अक्सर तैनात कर सकते हैं, लेकिन रिलीज चक्र लंबा होगा। यदि तीन महीने की रिलीज़ साइकिल एक-दूसरे को ओवरलैप करती है, तो एक हफ्ते में शिफ्ट हो जाती है, यह पता चलता है कि कंपनी को सप्ताह में एक बार तैनात किया गया है। और विचार से अंतिम कार्यान्वयन तक, 3 महीने बीत जाते हैं।

टाइम-टू-मार्केट एक विचार से अंतिम कार्यान्वयन तक के समय को कम करने के बारे में है।

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

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

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



1968 में, दूरदर्शी व्यक्ति मेल्विन कॉनवे ने निम्नलिखित विचार तैयार किया।

सिस्टम बनाने वाला संगठन एक डिज़ाइन तक सीमित है जो उस संगठन में संचार संरचना की प्रतिलिपि बनाता है।

अधिक विस्तार से, एक अलग प्रकार की प्रणालियों का उत्पादन करने के लिए, किसी अन्य प्रकार की कंपनी के भीतर एक संचार संरचना भी होनी चाहिए। यदि आपकी संचार संरचना शीर्ष पदानुक्रमित है, तो यह आपको सिस्टम बनाने की अनुमति नहीं देगा जो बहुत उच्च समय-से-बाज़ार संकेतक प्रदान कर सकता है।

लिंक का पालन करके आप कॉनवे के नियम के बारे में पढ़ सकते हैं । यह DevOps की संस्कृति या दर्शन को समझने के लिए महत्वपूर्ण है, क्योंकि केवल एक चीज जो DevOps में मौलिक रूप से बदलती है वह टीमों के बीच संचार संरचना है ।

इस प्रक्रिया के दृष्टिकोण से, DevOps से पहले, सभी चरण: विश्लेषिकी, विकास, परीक्षण, संचालन, रैखिक थे।
DevOps के मामले में, ये सभी प्रक्रियाएँ एक साथ चलती हैं।



समय से बाजार केवल इस तरह से किया जा सकता है। पुरानी प्रक्रिया में काम करने वाले लोगों के लिए, यह कुछ हद तक लौकिक लगता है, और आम तौर पर ऐसा-ऐसा।

तो आपको DevOps की आवश्यकता क्यों है?

डिजिटल उत्पादों के विकास के लिए । यदि आपकी कंपनी में डिजिटल उत्पाद नहीं है, तो DevOps की आवश्यकता नहीं है - यह बहुत महत्वपूर्ण है।

DevOps एक सुसंगत सॉफ़्टवेयर उत्पादन योजना की गति सीमा को पार कर जाता है । इसमें, सभी प्रक्रियाएं एक साथ होती हैं।

कठिनाई बढ़ाता है। जब DevOps इंजीलवादी आपको बताते हैं कि आपके लिए इसके साथ सॉफ़्टवेयर जारी करना आसान होगा, तो यह बकवास है।

DevOps के साथ, चीजें केवल अधिक जटिल हो जाएंगी।

एविटो के स्टैंड पर सम्मेलन में, कोई यह देख सकता था कि डॉकटर कंटेनर को तैनात करना क्या है - एक अवास्तविक कार्य। जटिलता निषेधात्मक हो जाती है, आपको एक ही समय में कई गेंदों से जूझना पड़ता है।

DevOps कंपनी में प्रक्रिया और संगठन को पूरी तरह से बदल देता है - अधिक सटीक रूप से, यह DevOps को नहीं बदलता है, लेकिन एक डिजिटल उत्पाद। DevOps में आने के लिए, आपको अभी भी इस प्रक्रिया को पूरी तरह से बदलना होगा।

किसी विशेषज्ञ के लिए प्रश्न

आपके बारे में क्या? प्रश्न जो आप किसी कंपनी में काम करने और विशेषज्ञ के रूप में विकसित होने पर खुद से पूछ सकते हैं।

क्या आपके पास एक डिजिटल उत्पाद रणनीति है? अगर वहाँ है, तो यह पहले से ही अच्छा है। इसका मतलब है कि आपकी कंपनी DevOps की ओर बढ़ रही है।

क्या आपकी कंपनी पहले से ही एक डिजिटल उत्पाद बना रही है? इसका मतलब यह है कि आप एक और पायदान पर जा सकते हैं और चीजों को और अधिक दिलचस्प बना सकते हैं - फिर से, DevOps के दृष्टिकोण से। मैं केवल इस दृष्टिकोण से बोलता हूं।

क्या आपकी कंपनी बाजार के नेताओं में से एक डिजिटल उत्पाद के साथ एक जगह है? Spotify, Yandex, Uber - ऐसी कंपनियां जो अब तकनीकी प्रगति के चरम पर हैं।

अपने आप से ये प्रश्न पूछें, और यदि सभी उत्तर नकारात्मक हैं, तो शायद आपको इस कंपनी में DevOps के साथ व्यवहार नहीं करना चाहिए। यदि DevOps विषय वास्तव में आपके लिए दिलचस्प है, तो शायद ... आपको किसी अन्य कंपनी में जाना चाहिए? यदि आपकी कंपनी DevOps में जाना चाहती है, लेकिन आपने सभी सवालों के जवाब "नहीं" दिए, तो यह इस सुंदर गैंडे से मिलता जुलता है जो कभी नहीं बदलेगा।

संगठन

जैसा कि मैंने कहा, कॉनवे के नियम के अनुसार, एक कंपनी में एक संगठन बदलता है। शुरू करने के लिए, जो संगठन के दृष्टिकोण से DevOps को कंपनी में प्रवेश करने से रोकता है।

"कुओं" की समस्या

अंग्रेजी शब्द "साइलो" का यहां रूसी में "अच्छी तरह से" अनुवाद किया गया है। इस समस्या का अर्थ यह है कि टीमों के बीच सूचनाओं का आदान-प्रदान नहीं होता है । प्रत्येक टीम अपनी विशेषज्ञता को गहराई से खोदती है, जबकि एक सामान्य नक्शा नहीं बना सकती है जिसमें आप नेविगेट कर सकें।

कुछ मायनों में, यह एक ऐसे व्यक्ति से मिलता-जुलता है, जो अभी-अभी मास्को आया है और अभी भी यह नहीं जानता कि मेट्रो का नक्शा कैसे बनाया जाए। Muscovites आमतौर पर अपने क्षेत्र को बहुत अच्छी तरह से जानते हैं, और पूरे मास्को में वे मेट्रो के नक्शे द्वारा निर्देशित होते हैं। जब आप पहली बार मास्को आते हैं, तो यह कौशल नहीं है, और आप बस भटकाव में हैं।

DevOps, भटकाव के इस क्षण को और सभी विभागों को एक साथ सहभागिता का एक सामान्य नक्शा बनाने के लिए प्रदान करता है।

इसके साथ दो कारक हस्तक्षेप करते हैं।

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

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

- हम सिर्फ CI लॉन्च करना चाहते थे, लेकिन यह पता चला कि प्रबंधन को इसकी आवश्यकता नहीं थी।

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



कंपनी में प्रक्रिया में प्रत्येक भागीदार: बैकएंड और फ्रंटेंड डेवलपर्स, परीक्षण, डीबीए, ऑपरेशन, नेटवर्क, अपने स्वयं के निर्देशन में खोदता है, और किसी के पास एक आम कार्ड नहीं है सिवाय एक प्रबंधक के जो किसी भी तरह से विभाजन और जीत विधि को देखता है और नियंत्रित करता है।

लोग कुछ छोटे सितारों या झंडे के लिए लड़ते हैं, प्रत्येक अपनी खुद की विशेषज्ञता खोदता है।

नतीजतन, जब कार्य यह सब एक साथ जोड़ने और एक आम पाइपलाइन बनाने के लिए प्रकट होता है, और तारों और झंडे के लिए लड़ने की कोई आवश्यकता नहीं है, तो सवाल उठता है - मुझे क्या करना चाहिए? हमें किसी तरह सहमत होना चाहिए, लेकिन किसी ने हमें यह नहीं सिखाया कि यह कैसे करना है। हमें स्कूल से सिखाया गया है: आठवीं कक्षा - वाह! - सातवीं कक्षा की तुलना में! यहाँ भी ऐसा ही है।

क्या आपकी कंपनी में भी ऐसा ही है?

इसे जांचने के लिए, आप स्वयं से निम्नलिखित प्रश्न पूछ सकते हैं।

क्या टीमें सामान्य साधनों का उपयोग करती हैं, क्या वे इन सामान्य साधनों में परिवर्तन में योगदान करती हैं?

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

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

कंपनी की उपलब्धियों को ध्यान में रखे बिना प्रबंधकों के लिए व्यक्तिगत उपलब्धियाँ प्राप्त करना कितना महत्वपूर्ण है?

यदि आप अपने लिए इन सवालों का जवाब देते हैं, तो कंपनी में इस तरह की समस्या होने पर यह स्पष्ट हो जाएगा।

कोड के रूप में अवसंरचना

इस समस्या को हल करने के बाद, पहला महत्वपूर्ण अभ्यास, जिसके बिना DevOps में आगे बढ़ना मुश्किल है, एक कोड के रूप में बुनियादी ढाँचा है ।

सबसे अधिक, एक कोड के रूप में बुनियादी ढांचे को निम्नानुसार माना जाता है:

- चलो बैश पर सब कुछ स्वचालित करें, स्क्रिप्ट के साथ खुद को कवर करें ताकि व्यवस्थापक क्षेत्र में कम मैनुअल काम हो!

लेकिन ऐसा है नहीं।

एक कोड के रूप में इंफ्रास्ट्रक्चर का अर्थ है कि आप आईटी प्रणाली का वर्णन करते हैं जिसके साथ आप इसकी स्थिति को लगातार समझने के लिए काम करते हैं।

अन्य टीमों के साथ मिलकर, आप एक कोड के रूप में एक नक्शा बनाते हैं जिसे हर कोई समझता है, जिसे आप नेविगेट और नेविगेट कर सकते हैं। यह क्या किया जाता है, इस पर कोई फर्क नहीं पड़ता - कुबेरनेट्स में शेफ, अन्सिबल, साल्ट या YAML फ़ाइलों का उपयोग किया जाता है - कोई अंतर नहीं है।

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

सहमत, अलग बैश स्क्रिप्ट आमतौर पर यह समझ नहीं देती है। जिन कंपनियों में मैंने काम किया था, उनमें से एक नाम "केवल लिखना" भी था - एक स्क्रिप्ट - जब स्क्रिप्ट लिखी जाती है, और इसे पढ़ना पहले से ही असंभव है। मुझे लगता है कि यह आपके लिए भी परिचित है।

एक कोड के रूप में इन्फ्रास्ट्रक्चर एक कोड है जो बुनियादी ढांचे की वर्तमान स्थिति का वर्णन करता है । कई उत्पाद, बुनियादी ढांचे, और सेवा दल इस कोड पर एक साथ काम करते हैं, और सबसे महत्वपूर्ण बात, वे सभी को यह समझने की आवश्यकता है कि यह कोड आम तौर पर कैसे काम करता है।

कोड के साथ काम करने के सर्वोत्तम तरीकों के अनुसार कोड होता है : संयुक्त विकास, कोड समीक्षा, एक्सपी-प्रोग्रामिंग, परीक्षण, पुल- quests, कोड इन्फ्रास्ट्रक्चर के लिए CI - यह सब उपयुक्त है और इसका इस्तेमाल किया जा सकता है।

सभी इंजीनियरों के लिए कोड एक आम भाषा बनती जा रही है।

कोड में बुनियादी ढांचे को बदलने में ज्यादा समय नहीं लगता है । हां, इन्फ्रास्ट्रक्चर कोड में तकनीकी ऋण भी हो सकता है। आमतौर पर, टीमें एक या डेढ़ साल बाद इसका सामना करती हैं, जब उन्होंने स्क्रिप्ट के एक समूह के रूप में "इन्फ्रास्ट्रक्चर" को लागू करना शुरू कर दिया, या यहां तक ​​कि अन्सिबल, जिसे वे स्पेगेटी कोड के रूप में लिखते हैं, और यहां तक ​​कि बैश स्क्रिप्ट ने इसे फायरबॉक्स में डाल दिया!

महत्वपूर्ण : यदि आपने अभी तक इस सामान की कोशिश नहीं की है, तो याद रखें कि Ansible बैश नहीं है ! प्रलेखन को ध्यान से पढ़ें, अध्ययन करें कि वे आम तौर पर इसके बारे में क्या लिखते हैं।

कोड के रूप में इंफ्रास्ट्रक्चर अलग-अलग परतों में इंफ्रास्ट्रक्चर कोड का विभाजन है।

हमारी कंपनी में, हम 3 बुनियादी परतों को भेद करते हैं, जो बहुत स्पष्ट और सरल हैं, लेकिन और भी हो सकते हैं। आप अपने इन्फ्रास्ट्रक्चर कोड को देख सकते हैं और कह सकते हैं कि आपके पास यह शर्त है या नहीं। यदि कोई परतें हाइलाइट नहीं की जाती हैं, तो आपको समय आवंटित करने और थोड़ा रिफैक्ट करने की आवश्यकता है।


आधार परत यह है कि ओएस, बैकअप और अन्य निम्न-स्तरीय चीजों को कैसे कॉन्फ़िगर किया जाता है, उदाहरण के लिए, कुबेरनेट्स को एक बुनियादी स्तर पर कैसे तैनात किया जाता है।

सेवाओं का स्तर उन सेवाओं को है जो आप डेवलपर को देते हैं: सेवा के रूप में लॉगिंग, सेवा के रूप में निगरानी, ​​सेवा के रूप में डेटाबेस, सेवा के रूप में एक बैलेंसर, सेवा के रूप में एक कतार, सेवा के रूप में सतत वितरण - सेवाओं का एक गुच्छा - व्यक्तिगत टीम विकास प्रदान कर सकती है। यह सब आपके विन्यास प्रबंधन प्रणाली में अलग मॉड्यूल के रूप में वर्णित किया जाना चाहिए।

वह परत जहां आवेदन किए जाते हैं और उन्हें पिछली दो परतों के शीर्ष पर कैसे तैनात किया जाएगा।

सुरक्षा के सवाल

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

यदि आपको इस तथ्य का सामना करना पड़ रहा है कि परिवर्तनों की शुरुआत में एक-डेढ़ दिन लगा, तो इसका मतलब है कि आपके पास एक तकनीकी ऋण है और आपको इसके साथ काम करने की आवश्यकता है। आप बुनियादी ढांचे के कोड में तकनीकी ऋण की एक लकीर पर ठोकर खाई। मुझे ऐसी कई कहानियां याद हैं जब किसी भी सीसीएल को बदलने के लिए, आधे इन्फ्रास्ट्रक्चर कोड को फिर से लिखना आवश्यक है, क्योंकि रचनात्मकता और सब कुछ को स्वचालित करने की इच्छा ने इस तथ्य को जन्म दिया कि हर जगह सब कुछ छोटा है, सभी पेन हटा दिए जाते हैं, और आपको रिफ्लेक्टर की आवश्यकता होती है।

निरंतर वितरण

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

यह स्पष्ट हो जाने के बाद कि आपके पास इसे प्रबंधित करने का तरीका है, आप यह सोचना शुरू करते हैं कि कैसे डेवलपर कोड को उत्पादन में जल्दी से जल्दी भेजें। मेरा मतलब है, डेवलपर के साथ - हम "कुओं" की समस्या को याद करते हैं, अर्थात्, व्यक्तिगत लोग इसके साथ नहीं आते हैं, लेकिन टीम द्वारा।

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

लगातार वितरित - इसका मतलब है कि

किराना भंडार में निहित कोड को हमेशा उत्पादन में डाउनलोड किया जा सकता है । यह अपवित्र नहीं हो सकता है, लेकिन यह इसके लिए हमेशा तैयार है। तदनुसार, आप हमेशा टेलबोन के नीचे कुछ चिंता की भावना को समझाने के लिए एक मुश्किल कोड लिखते हैं। जब आप इन्फ्रास्ट्रक्चर कोड रोल आउट करते हैं तो यह अक्सर दिखाई देता है। — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

प्रतिक्रिया

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20