अलेक्जेंडर टिटोव के साथ साक्षात्कार, हमारे
जून हाईलेड ++ सम्मेलन की कार्यक्रम समिति के सदस्यों में से एक, एक अलग अनुभाग जो कि DevOps को समर्पित होगा।
देवोप्स "हवा" किस दिशा में चल रही है, इस बारे में कटौती के तहत, और इस अवधारणा के बिल्कुल पहलुओं पर मंच पर चर्चा की जाएगी।
अलेक्जेंडर हमारे समुदाय के लिए काफी परिचित हैं, वह DevOps मास्को और DevOpsDays मास्को सम्मेलन के आयोजक हैं, वह कई वर्षों से हमारे कार्यक्रमों में बोल रहे हैं और उनके कार्यक्रमों के निर्माण में मदद करते हैं। वह वर्तमान में एक्सप्रेस 42 में एक प्रबंध भागीदार है, जो प्रौद्योगिकी कंपनियों में DevOps बढ़ता है। इससे पहले, 2010 से 2012 तक, अलेक्जेंडर एक तेजी से बढ़ते स्टार्टअप को संचालित करने से लेकर एक बड़ी अंतरराष्ट्रीय कंपनी माइक्रोसॉफ्ट में परिचालन करने तक, क्यूक के साथ एक आकर्षक अधिग्रहण मार्ग से गुजरा। इससे पहले, 2009-2010 में, वह रूस में पहले क्लाउड होस्टिंग के तकनीकी निदेशक थे, स्केलेक्सी।- दूर से शुरू करते हैं: DevOps संस्कृति विकसित हो रही है? हाल के वर्षों में इस क्षेत्र में क्या बदलाव देखे गए हैं? और रूस में DevOps कैसा दिखता है?बेशक, एक ऐसी दुनिया में जहां हर तीन साल में तकनीक एक दूसरे को बदलती है, सब कुछ लगातार और बहुत बदल रहा है। प्रारंभ में, मूल समस्या डिजिटल युग में स्वयं सॉफ्टवेयर के उत्पादन और संचालन की थी। इस समस्या के आसपास, DevOps आंदोलन एकत्र हो गया है। अब बुनियादी समस्या को कई उपश्रेणियों में विभाजित किया गया है - बुनियादी ढांचा प्रबंधन, निगरानी, निरंतर एकीकरण, निरंतर वितरण, लोगों के साथ काम करना (विशेष रूप से, शोषण और विकास दोनों में लगे लोगों की बर्नआउट की समस्या), कुछ तकनीकी चीजें (उदाहरण के लिए, कुबेरनेट्स की उपस्थिति) कंपनियों में संपूर्ण बुनियादी ढाँचे के लिए ऐसा वास्तविक मानक)। यही है, कई मामलों में, विशिष्टताएं दिखाई दीं: हम यह समझने के चरण से गुजरे कि पहले की तरह अलग-अलग तरीके से क्या करने की जरूरत है, कई नए तरीकों की कोशिश की और आम (सामान्य) समस्याओं को हल करने के लिए कुछ मानकीकृत प्रक्रियाओं के गठन के लिए आए। लेकिन एक ही समय में, दुनिया भर की कई कंपनियों में उपकरण और प्रक्रियाएं अभी भी खराब गुणवत्ता या बहुत खराब औपचारिक रूप से बनी हुई हैं।
रूसी संदर्भ में, एक अतिरिक्त समस्या यह है कि हम यह नहीं समझते हैं कि यह सब क्यों आवश्यक है। यह बहुतों को भटकाता है। हमारे पास अलग से विकास, परीक्षण और संचालन है, और फिर कुछ समस्याओं को हल करने के लिए कुछ कुबेरनेट्स आते हैं, लेकिन वे लोगों की प्रक्रियाओं, दृष्टिकोण और दक्षताओं को बदलने के बिना इसे लागू करने का प्रयास करते हैं। सब कुछ टूट जाता है। और ये नई तकनीकें स्पष्ट क्यों नहीं हैं।
- और इस तरह के कट्टरपंथी परिवर्तन का कारण क्या है?जैसा कि मैंने पहले ही उल्लेख किया है, हमने एक और समस्या को हल करना शुरू कर दिया। प्रारंभ में, क्लासिक आईटी ने एक निगम के भीतर व्यावसायिक प्रक्रियाओं को स्वचालित करने की समस्या को हल किया। संपूर्ण अवसंरचना को इसके लिए समायोजित किया गया था - डेटाबेस, बसें आदि। 2000 के बाद से, डॉट-कॉम संकट के बाद, आईटी ने डिजिटल उत्पादों को बनाने के लिए स्विच किया है जो बड़े पैमाने पर अनुकूलित सेवाएं प्रदान कर सकते हैं, कुछ मूल्य प्रदान करते हैं। अगर इससे पहले कि कंपनी कार के एक निश्चित मॉडल का उत्पादन करती है, तो अब यह प्रत्येक ग्राहक के लिए अनुकूलन के लिए बदल गया है। यह एक और समस्या का समाधान है, जिसके लिए मूलभूत रूप से विभिन्न दृष्टिकोणों और प्रौद्योगिकियों की आवश्यकता है - एक अलग सॉफ्टवेयर उत्पादन प्रक्रिया। यहां क्रमिक रूप से विकास, परीक्षण और संचालन करना संभव नहीं है। अब ये प्रक्रिया एक साथ शुरू होती है।
वैसे, इसके बावजूद, एक गलत धारणा है कि DevOps ऑपरेशन के बारे में है। शास्त्रीय कार्य प्रशासक जो संचालन कार्य करते हैं, उनका नाम बदलकर DevOps इंजीनियर रखा जाता है, सिद्धांत में इस शब्द को बदनाम करते हुए। वास्तव में, अवधारणा बहुत व्यापक है। यह प्रथाओं का एक अलग सेट है, एक अलग ढांचा जो आपको कुछ परिस्थितियों में विशिष्ट समस्याओं को हल करने की अनुमति देता है और एक निश्चित क्षमता के लोगों के साथ - कोई और अधिक, कोई कम नहीं। बस कुछ लोग समझते हैं कि यह क्यों आवश्यक है। और यह उन समस्याओं में से एक है जिन्हें हम सम्मेलनों के माध्यम से हल करने की कोशिश कर रहे हैं।
-
साइबेरियाई हाईलाड के भीतर किन धाराओं पर ध्यान देने की योजना है?यदि पहले मुख्य रूप से परिचालन रिपोर्टें थीं, तो इस वर्ष हम विकास के साथ कनेक्शन के बारे में अधिक जानकारी जोड़ना चाहते हैं, उदाहरण के लिए, निरंतर वितरण, निरंतर एकीकरण, परीक्षण की प्रक्रियाओं के बारे में। बॉक्स विकास में DevOps का उपयोग करने के तरीके पर RIT ++ (वसंत रूटकॉनफ 2018 के भाग के रूप में) पर मैक्सिम लापिशिन द्वारा एक शांत उदाहरण एक रिपोर्ट है। ऐसी कंपनी का मूल रूप से कोई शोषण नहीं है - यह एक बॉक्स बनाता है जिसे वह ग्राहक को बेचता है। उसी समय, वह अंदर DevOps है। यह दृष्टिकोण पैटर्न को तोड़ता है, लेकिन एक ही समय में इस मिथक का उल्लेख करने में मदद करता है कि DevOps केवल ऑपरेशन के बारे में है। यह हमारा पहला मूल ध्यान है।
दूसरा ध्यान नई तकनीकों का है। अब कुबेरनेट्स, प्रोमेथियस और अन्य लोगों के बारे में बात करना फैशनेबल है। और हम उन लोगों की तलाश कर रहे हैं जो व्यवहार में इन तकनीकों को महसूस करने में सक्षम थे। यही है, न केवल कॉन्फ़िगर और काम करने के लिए बनाया गया है, बल्कि इसे अपनी विकास प्रक्रिया में भी शामिल किया है। सामान्य तौर पर, हम प्रिज्म के तहत सभी तकनीकों पर विचार करने की कोशिश करते हैं कि उन्हें सॉफ्टवेयर उत्पादन प्रक्रिया में कैसे शामिल किया जाता है - वे किस समस्या का समाधान करते हैं, वे किस लक्ष्य को निर्धारित करते हैं, आदि यदि आप इस बारे में बात नहीं करते हैं, तो लोग प्रौद्योगिकी के साथ कार्गो पंथ के रूप में काम करना शुरू करते हैं: "चलो कुबेरनेट्स पर डालते हैं और हम Google बना सकते हैं।" यह उस तरह से काम नहीं करेगा।
- निरंतर एकीकरण की अवधारणा पहले से ही बाजार द्वारा अच्छी तरह से स्वीकार की जाती है। विशिष्ट उपकरणों के अलावा, क्या इसके बारे में बात करने के लिए कुछ है?बेशक। बुनियादी, एक भी कह सकते हैं, महत्वपूर्ण अवधारणा यह है कि DevOps के संदर्भ में, उत्पादों को निरंतर एकीकरण प्रक्रिया के अंदर गुणवत्ता के लिए परीक्षण नहीं किया जाता है। यही है, इससे कोई फर्क नहीं पड़ता कि उत्पाद कितना कार्यात्मक है। यह जांचना महत्वपूर्ण है कि यह कितनी अच्छी तरह से शुरू होता है और क्या यह अन्य घटकों के साथ एकीकृत करने के लिए तैयार है।
यह एक बड़ा बदलाव है, क्योंकि निरंतर विकास, संचालन और परीक्षण में निरंतर एकीकरण है। लेकिन इस स्तर पर उपयोगकर्ता की आवश्यकताओं के अनुसार उत्पाद की गुणवत्ता की जांच की जाती है, और DevOps के ढांचे के भीतर, कार्यात्मक गुणों की जांच की जाती है। यह वह चरण है, जो कि माइक्रो सर्विस इन्फ्रास्ट्रक्चर के ढांचे के भीतर व्यक्तिगत सेवाओं के सबसे तेजी से संभव एकीकरण की अनुमति देता है (और एक पूरे के रूप में DevOps एक माइक्रो सर्विस आर्किटेक्चर के बिना मौजूद नहीं है)।
- इस वर्ष कौन से उपकरण फोकस में हैं?सबसे पहले, पहले से ही वर्णित कुबेरनेट्स। यह कुछ समय पहले दिखाई दिया था, लेकिन हाल ही में मंच पर पहुंच गया जब इसका उपयोग किया जा सकता है। अब इसका उपयोग अद्यतन डिजिटल सेवा विकसित करने वाली किसी भी कंपनी द्वारा किया जा सकता है, उदाहरण के लिए, वेबसाइट या मोबाइल एप्लिकेशन के माध्यम से सेवाएं प्रदान करना।
अक्सर प्रमेथियस के रूप में जाना जाता है - एक निगरानी प्रणाली, गिटलैब - एक निरंतर एकीकरण प्रणाली के रूप में। और पूरे हाशिकॉर्प स्टैक - वॉल्ट, टेराफॉर्म (दोनों हाशिकोर्प द्वारा विकसित)। खैर, निश्चित रूप से, डॉकर - एक डिलीवरी प्रारूप के रूप में।
- क्या "कोड के रूप में सब कुछ" की अवधारणा के ढांचे में कोई हालिया बदलाव हैं?"सब कुछ एक कोड के रूप में" का अभ्यास स्पष्ट रूप से उपयोगी है। यह उन मूलभूत सिद्धांतों में से एक है जिस पर DevOps प्रक्रिया आधारित है। कुबेरनेत्स इस विचारधारा को जारी रखे हुए है।
DevOps में, मुख्य कहानी "एक कोड के रूप में बुनियादी ढाँचा" है। और यह न केवल एक अवधारणा है, बल्कि एक ऐसी प्रक्रिया है जिसमें सभी घटकों को कोड के रूप में प्रस्तुत किया जाता है जो एक दूसरे के साथ बातचीत करने के लिए बुनियादी ढांचे के व्यक्तिगत "टुकड़ों" की अनुमति देता है। यहां कोई कठोर बदलाव नहीं हैं, लेकिन, एक अभ्यास के रूप में, यह अब कुबेरनेट्स के अंदर विकसित हो रहा है। उदाहरण के लिए, निर्भरता प्रबंधन उपकरण जैसे कि हेल्म विकसित किए जाते हैं, अलग-अलग मॉड्यूल बनाने के लिए उपकरण, बुनियादी ढांचे के विवरण, उदाहरण के लिए, ऑपरेटर (और कुबेरनेट्स में बयान लिखने के लिए रूपरेखाएं दिखाई देती हैं), आदि। दूसरे शब्दों में, साधन का एक स्वस्थ विकास और इसके भीतर अभ्यास का प्रवेश है।
- "सब कुछ एक कोड के रूप में" का अभ्यास किस साधन से अलग है?हमने अभी तक पूरी तरह से एक कार्यक्रम नहीं बनाया है, इसलिए मैं यह नहीं कह सकता कि क्या हम ऐसे विषयों को विशेष रूप से HighLoad ++ पर उठाएंगे। लेकिन यह अपने आप में संभव है।
बुनियादी ढाँचे को व्यवस्थित करने, बुनियादी ढाँचे के भीतर निर्भरता को प्रबंधित करने और इसका परीक्षण करने के कई दृष्टिकोण हैं। बेशक, हम अभ्यास के साथ काम करने के लिए अवधारणाओं के बारे में बात करेंगे - उदाहरण के लिए, कि बुनियादी ढांचे के कोड को मॉड्यूल में विभाजित किया जाना चाहिए। यह मुझे लगता है कि परिष्कृत, अभ्यास से अलगाव में, ऐसे विषय बहुत अच्छी तरह से फिट नहीं होते हैं। लेकिन, शायद, हम एक रिपोर्ट का चयन करेंगे जहां एकल प्रणाली विवरण के ढांचे के भीतर सभी संभावित दृष्टिकोण एकत्र किए जाएंगे। हालांकि, यह बहुत अधिक मूल्यवान है जब लोग बताते हैं और दिखाते हैं कि वास्तविकता में इन सैद्धांतिक अवधारणाओं को कैसे महसूस किया जाता है। उस सिद्धांत के बारे में जो प्रथाओं को रेखांकित करता है, आप फिर उसी लोगों के साथ बात कर सकते हैं।
- एक राय है कि घटना-संचालित वास्तुकला की लोकप्रियता समय के साथ बढ़ रही है। क्या आप इस कथन से सहमत हैं?इवेंट-संचालित इन्फ्रास्ट्रक्चर हमेशा चैट्स दृष्टिकोण का हिस्सा रहा है - घटना से, हम चैट में एक निर्णय लेते हैं कि बुनियादी ढांचे के एक टुकड़े के साथ क्या होना चाहिए। यह कहानी बड़ी बड़ी कंपनियों के लिए बहुत आवश्यक है, लेकिन बाकी दर्शकों के लिए यह अभी भी काफी परिपक्व नहीं है। क्या होना चाहिए (हमें क्या करना चाहिए) के बारे में निर्णय लेने के लिए, टीमों के भीतर नियमों के लिए कुछ रूपरेखा विकसित करना आवश्यक है कि हम ये निर्णय कैसे लेते हैं, ताकि हर कोई इसे कमोबेश उसी तरह से करे - एक तरफ से देखें। और इसके साथ, सब कुछ जटिल है। इस तरह के ढांचे को विकसित करने का प्रारूप सभी के बारे में बात कर रहा है: यह कैसे स्वचालित हो सकता है, एक उपकरण पर ले जाया जा सकता है, यह टीम के निर्माण के स्तर पर कैसे किया जाना चाहिए और विभिन्न टीमों के साथ समन्वय कैसे करना चाहिए।
- क्या यह किसी तरह सम्मेलन की रिपोर्ट में परिलक्षित होता है?नहीं, HighLoad ++ अत्यधिक लोड सिस्टम और टूल के बारे में अधिक है, इसलिए यहां हम टूल के बारे में बात कर सकते हैं, लेकिन इस तरह के ढांचे को विकसित करने के बारे में नहीं। लेकिन गिरावट में हमारे पास एक अलग रूटकॉन्फ सम्मेलन होगा, जो 1-2 अक्टूबर को होगा। 2011 तक, यह परिचालन मुद्दों (जो पूरी प्रक्रिया "विकास-परीक्षण-संचालन" का केवल एक घटक है) के लिए समर्पित था। 2015 में, हमने इसे पूरे DevOps के संदर्भ में पुनर्जन्म दिया - इसलिए हमने धीरे-धीरे विषय का विस्तार किया। रूटकॉन्फ़ में, हम चर्चा करते हैं कि डेवलपर्स और रखरखाव इंजीनियरों की बातचीत को कैसे सुनिश्चित किया जाए, हम नई प्रक्रियाओं और प्रौद्योगिकियों के बारे में बात करते हैं, बुनियादी ढांचे के प्लेटफार्मों और बुनियादी ढांचे के प्रबंधन के बारे में, जो न केवल संचालन में शामिल है, बल्कि विकास में भी है (वे सिर्फ अलग-अलग काम करते हैं)।
- क्या पिछले कुछ वर्षों में परियोजनाओं की लचीलापन में सुधार करने के लिए दिलचस्प तकनीकें आई हैं? क्या सम्मेलन में उनकी चर्चा की जाएगी?आज हम इस तथ्य से संबंधित विरोधाभास पर आए हैं कि "गलती सहिष्णुता" का अर्थ "विश्वसनीयता" नहीं है। दोष सहिष्णुता अब विश्वसनीयता द्वारा दबा दी गई है।
दोष सहिष्णुता अखंड प्रणालियों के प्रतिमान से एक अवधारणा है, जहां दोहराव, बढ़ते संसाधनों आदि के माध्यम से विश्वसनीयता की समस्या का समाधान किया गया था। अब ऐसे दृष्टिकोण काम नहीं करते हैं। विश्वसनीयता मूलभूत रूप से अलग-अलग तरीकों पर आधारित है - इसका मतलब है कि सिस्टम की "विरोधी-नाजुकता"। यही है, सिस्टम "सॉफ्ट" बन जाता है: अगर हम इस पर कार्य करते हैं, तो यह बदल जाता है, ढह नहीं जाता है। दूसरे शब्दों में, यदि आप किसी प्रकार की नई सेवा का निर्माण करने जा रहे हैं, तो आपको इसके व्यवहार के ऐसे प्रकार प्रदान करने चाहिए, जिसमें यदि उपयोगकर्ता या वातावरण जिसमें वह काम करता है, उसे नष्ट करने का प्रयास करता है, तो सेवा बस इसके गुणों को बदल देती है, जबकि सेवा अभी भी प्रदान की जाती है। , कुछ परिणाम दिया जाता है।
प्रवृत्ति का एक अच्छा मार्कर एक प्रथा और व्यक्तिगत विशेषज्ञों के रूप में साइट विश्वसनीयता इंजीनियरिंग का उद्भव है - सिस्टम प्रशासक के पिछले दक्षताओं के प्रतिस्थापन के रूप में साइट विश्वसनीयता इंजीनियर (एसआरई)। इस प्रक्रिया के दृष्टांत के रूप में, मैंने उल्लेख किया है कि Google ने साइट विश्वसनीयता इंजीनियरिंग पर एक पुस्तक के रूप में अपना DevOps कार्यान्वयन अभ्यास जारी किया है और इस विचार को आम जनता तक सक्रिय रूप से बढ़ावा दे रहा है।
हम रूटकॉन्फ़ में भी इस बारे में बात करेंगे। अब यह विषय पश्चिम में प्रचार पर है, और हम (DevOps मास्को समुदाय द्वारा) धीरे-धीरे इसे हमारे सामने लाने की कोशिश कर रहे हैं।