सिस्टम एडमिनिस्ट्रेटर से लेकर व्यक्ति तक

DevOps में कम से कम दो सुव्यवस्थित विचार हैं - सिस्टम प्रशासकों की तरफ से और डेवलपर्स की तरफ से। पूर्व में आमतौर पर दावा किया जाता है कि वे 200X से शेफ / कठपुतली / Ansible / Docker का उपयोग कर रहे हैं, बाद वाले मानते हैं कि DevOps या तो खुद आउट हो गया है और NoOps की ओर जाता है, या यह कि "मैंने एक कंटेनर में सब कुछ लपेटा, और फिर यह कैसे जाता है।"

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

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

सामग्री हमारे अक्टूबर DevOops 2017 सम्मेलन से अलेक्जेंडर ऑस्मिनोग टिटोव की रिपोर्ट के प्रतिलेख पर आधारित है।



उन लोगों के लिए जो रिकॉर्डिंग में सम्मेलनों से रिपोर्ट देखने के आदी हैं, हम एक वीडियो संलग्न करते हैं।



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

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

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

नतीजतन, मुझे नहीं पता था कि इन कंपनियों में आगे कहां जाना है, और मेरे सहयोगियों और मैंने एक्सप्रेस 42 खोला, जो देवओप को जनता तक पहुंचाता है। यह विचार ओवरान-स्कालासी में उत्पन्न हुआ, और यह मुझे प्रेरित करता है। अन्य बातों के अलावा, मैं रूस में DevOps समुदाय के लिए बहुत महत्वपूर्ण हूं। मैं DevOpsDays मास्को और मास्को DevOps- बैठकों का आयोजक हूं।

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

कंपनी में DevOps कैसे दिखते हैं?

DevOps डेवलपर

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

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

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

Sysadmin DevOps

देवओप्स-सिसदिन जैसी कोई चीज है। आमतौर पर ये बहुत शक्तिशाली लोग होते हैं जिन्होंने खुद को अच्छी तरह साबित किया है। वे आते हैं और कहते हैं: "दोस्तों, आप इस तरह नहीं रह सकते हैं, हम इस तरल पदार्थ को खींचते हुए थक गए हैं। अब हम सब कुछ स्वचालित कर रहे हैं, हम वितरण पाइपलाइन को बनाएंगे, जैसे कि एक मिठाई, अद्भुत, अच्छी तरह से काम करना। हम यह अच्छी तरह से जानते हैं कि आवेदन को उत्पादन में कैसे काम करना चाहिए। Node.js. पर लिखने वाले इन उल्लुओं से बहुत बेहतर और हम जानते हैं कि क्या उपयोग करने की आवश्यकता है ताकि सब कुछ सही हो। ”

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

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

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

यहाँ से sysadmins का पारंपरिक विचार आया: यह एक बहु-सशस्त्र व्यक्ति है जो कुछ करता है, लेकिन आप इसे बिल्कुल नहीं समझ रहे हैं। वैसे, ज्यादातर एचआर अब ऐसे ही तलाश रहे हैं। मैं आपको बता सकता हूं कि कंपनी में ऐसे व्यक्ति को खोजने से आप समस्याओं से 100% बच नहीं पाएंगे।

व्यापार के लिए DevOps

DevOps के उद्भव के लिए एक और तरीका व्यापार की ओर से है। आपके कुछ शीर्ष प्रबंधक कुछ व्यावसायिक सम्मेलन में गए, उदाहरण के लिए, घाटी में, जहां उन्होंने उनसे कहा कि यदि आपके पास डॉकटर नहीं है, कुछ निरंतर एकीकरण (CI) और कुछ और, तो आप नहीं माने जा सकते प्रौद्योगिकी कंपनी। प्रबंधक लौटता है, कर्मचारियों को इकट्ठा करता है और एक नोटबुक से शब्द पढ़ता है: DevOps, Docker, Concourse CI। लोग समझना शुरू करते हैं, और फिर ऊपर वर्णित मिश्रित परिदृश्य होते हैं: DevOps-developer, DevOps-sysadmin, और यह सब एक गड़बड़ की ओर जाता है जिसे आप बाहर नहीं कर सकते।

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

एंटरप्राइज से एजाइल तक

सबसे पहले, व्यवसाय के दृष्टिकोण से, हम एक महत्वपूर्ण मोड़ का अनुभव कर रहे हैं: हम एक ऐसे उद्यम से दूर जा रहे हैं, जो स्मारकीय परियोजनाओं को लागू कर रहा है, व्यापार को बिंदु A से बिंदु B पर स्थानांतरित करने के लिए (उदाहरण के लिए, बाजार का 70% कब्जा करने के लिए पांच साल की रणनीति) ...

... और चंचल की दुनिया में आते हैं। Agile की बात लचीली नहीं होनी है, लेकिन वह बिंदु A ज्ञात है और B नहीं है। और यह सबसे गहरा है जो हो सकता है। क्योंकि न तो हम और न ही व्यवसाय इसके साथ काम करने के आदी हैं। कल्पना कीजिए कि आपको पता नहीं होगा कि एक या दो सप्ताह में क्या होगा, कि नेता आपके पास आए और कहा: "इसलिए, मुझे कुछ पाने की कोशिश करें जो कि नहीं हो सकता है, अपना नाम लिख दें ताकि आप जल्दी में भूल न जाएं । " और आप नहीं जानते कि क्या करना है, लेकिन दुनिया और व्यवसाय इस तरह से बन रहे हैं, और आपको इसकी आदत डालने की आवश्यकता है। और ये सभी प्रथाएं, जैसे कि एजाइल, स्क्रैम, कानबन, इसके साथ रहने के तरीके के बारे में नहीं हैं।


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

DevOps प्रकट नहीं होता है क्योंकि आप में से एक को आरामदायक होना चाहिए, और इसलिए नहीं कि आपको कूलर प्रौद्योगिकियों का उपयोग करने की आवश्यकता है। NoSQL SQL की तुलना में कूलर नहीं है, इसके अलावा, यह राज्य द्वारा 3-4 साल पहले SQL की तुलना में बहुत खराब है। SQL डेटाबेस को 20 साल के लिए और NoSQL डेटाबेस को 1 साल के लिए विकसित किया गया है। और हमें 4 साल पहले मोंगोडीबी के बारे में याद है, जब यह एक डेटाबेस नहीं था।


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

DevOps का इतिहास

यहाँ DevOps के इतिहास की ओर मुड़ने का समय है। यह सब कैसे हुआ? मैं यह रहता था, लगातार समाचार पढ़ता था, ऐतिहासिक श्रृंखला का पालन करता था, यह सब कैसे दिखाई दिया। और अब अलग-अलग वर्षों के अलग-अलग लोग मुझे बताते हैं कि DevOps क्या है और यह कैसे आया। और मुझे जड़ों की ओर लौटना महत्वपूर्ण लगता है।

2003 में, Google में बेन ट्रेनर ने SRE टीम बनाई। Google दुनिया की पहली बड़ी डिजिटल कंपनी है। पहले से ही 2003 में, उन्हें इस समस्या का सामना करना पड़ा था कि सभी सॉफ्टवेयर डेवलपर्स के लिए उपयोग किए जाने वाले क्लासिक तरीके से, वे वह नहीं कर सकते जो वे चाहते हैं। और उन्होंने SRE टीम की शुरुआत करके नवाचार किया, और तब से इस अभ्यास को विकसित किया है।

2009 में, जॉन अलस्पॉ और पॉल हेमंड ने फ्लिकर के अंदर एक साथ काम करने के बारे में बात की और बताया कि वे दिन में 10 बार कैसे साझा करते हैं। उस समय यह एक सनसनी और एक विस्फोट था। और पैट्रिक डेबिट ने इस रिपोर्ट पर जासूसी की और देवओप्स शब्द गढ़ा, इस प्रथा को और विकसित करने के लिए विश्व समुदाय को संगठित किया।

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

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

DevOps कैसे लागू करें?

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

सभी टीमों को विकास टीमों में बदलना जरूरी है। अब एक अलग sysadmin, एक अलग डेवलपर नहीं है। क्योंकि जिन्हें हम सिस्टम एडमिनिस्ट्रेटर कहते हैं, वे वही लिखते हैं, जिसे इन्फ्रास्ट्रक्चर प्लेटफॉर्म कहा जाता है, और डेवलपर्स लिखते हैं कि प्रोडक्ट किसे कहते हैं, और इस तरह वे एक दूसरे को सेवा प्रदान करते हैं।

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

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

मैंने पहले ही सम्मेलन के आयोजकों से सुना है कि सभी को एक मेगा-हार्डकोर की आवश्यकता होती है। ठीक है, हो सकता है कि आप एक मेगाहार्डकोर नहीं बना सकते हैं, लेकिन इतना है कि एक व्यक्ति वास्तविक अनुभव साझा करता है और आप इसके बारे में बात कर सकते हैं, यह भी अच्छा है।

DevOps पर डेवलपर

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

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

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

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

इंफ्रास्ट्रक्चर इंजीनियर

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

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

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

टेक्नोलॉजिस्ट का परीक्षण

परीक्षक भी थोड़ा बदलता है और एक प्रौद्योगिकीविद् बन जाता है जो सॉफ्टवेयर गुणवत्ता में सुधार प्राप्त करता है और इस प्रक्रिया को कोड में बदल देता है।

रिलीज मैनेजर / सर्विस स्टेशन

, , . , , , .

, : , , .


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

, , , — ( ), . , — , , , , continuous delivery pipeline.

, . (- CTO) — . , — , , , .


42 base-service-app. — () . . : , load balancers, , , CI- (TeamCity Jenkins ). , API, . , , CI Kubernetes.


. , , , . , , . , , . , , . , , , . , , , ITIL, . - . . , .

, . , - : « , — » .
, , , ( , , ). यह बहुत महत्वपूर्ण है।

, DevOps, , , , , (Kubernetes, Prometheus, Docker . .), , .

, DevOps- . , , , . , continuous delivery, — , , . , , , . , , , « ». , .

- , , . 3-4 , , .

, DevOops 2018 : , . 14 , .