DevOps इंजीनियर मौजूद नहीं हैं। फिर कौन मौजूद है, और इसके बारे में क्या करना है?

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

इस पोस्ट में, मैं इस बारे में थोड़ी बात करना चाहता हूं कि हमें इस बात की जानकारी कैसे प्राप्त हुई कि वास्तव में DevOps क्या है और इसके साथ क्या करना है।

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

संस्कृति और प्रक्रियाओं के बारे में

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

उदाहरण के लिए, प्रसिद्ध Google SRE बुक सेवा प्रबंधन के लिए sysadmin और SRE-shny दृष्टिकोण के बीच अंतर का वर्णन करने के साथ शुरू होता है । दिलचस्प अध्ययन DORA सर्वेक्षण के हिस्से के रूप में आयोजित किए गए थे - यह देखा जा सकता है कि सबसे अच्छा डेवलपर्स किसी भी तरह एक घंटे में एक बार से अधिक तेजी से उत्पादन के लिए नए परिवर्तनों को तैनात करने का प्रबंधन करते हैं। वे अपने हाथों से परीक्षण करते हैं 10% से अधिक नहीं (इसे पिछले वर्ष के डोरए से देखा जा सकता है)। वे इसे कैसे करते हैं? "एक्सेल या डाई" रिपोर्ट हेडर में से एक कहती है। परीक्षण के संदर्भ में इन आँकड़ों की विस्तृत चर्चा के लिए, आप बरूच सदोगुर्स्की की मुख्य पुस्तक "हमारे पास देवोपस " हो सकते हैं । चलो हमारे अन्य सम्मेलन में सभी परीक्षकों को आग लगाते हैं, हाइजेनबग।

“जब कामरेड में कोई समझौता नहीं है,
यह अच्छी तरह से काम नहीं कर रहा है,
और इससे नहीं निकलेगा, केवल आटा।
एक बार एक हंस, कैंसर और पाईक ... "

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

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

दुष्चक्र

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

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

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

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

इसलिए, हमारे पास आपूर्ति और मांग है। एक दुष्चक्र जो खुद को खिलाता है। यह वही है जिसके साथ हम लड़ रहे हैं (देवोप्स सम्मेलन बनाकर)।

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

लोग DevOps में क्या करते हैं (वास्तव में)

तो, आप DevOps प्रथाओं को सीखने और लागू करने में आगे बढ़ना चाहते हैं। लेकिन यह कैसे करना है, किस तरह से देखना है? जाहिर है, लोकप्रिय कीवर्ड द्वारा नेत्रहीन निर्देशित यह इसके लायक नहीं है।

अगर काम है, तो किसी को करना चाहिए। हमने पहले ही पता लगा लिया है कि ये "DevOps इंजीनियर" नहीं हैं, फिर कौन? यह पदों के संदर्भ में नहीं, बल्कि कार्य के विशिष्ट क्षेत्रों के संदर्भ में तैयार करना अधिक सही प्रतीत होता है।

सबसे पहले, आप DevOps के बहुत दिल कर सकते हैं - प्रक्रियाओं और संस्कृति। संस्कृति एक त्वरित और कठिन मामला नहीं है, और यद्यपि यह परंपरागत रूप से प्रबंधकों, एक तरह से या किसी अन्य की जिम्मेदारी है, हर कोई इसमें शामिल है, प्रोग्रामर से लेकर प्रशंसा तक। कुछ महीने पहले, टिम लिस्टर ने एक साक्षात्कार में कहा :

“संस्कृति संगठन के मूल मूल्यों से निर्धारित होती है। आमतौर पर लोग इसे नोटिस नहीं करते हैं, लेकिन हम, कई वर्षों से परामर्श में काम कर रहे हैं, इसका उपयोग करने के लिए उपयोग किया जाता है। आप कंपनी में प्रवेश करते हैं और सचमुच कुछ ही मिनटों में आपको महसूस होने लगता है कि क्या हो रहा है। हम इसे "सुगंध" कहते हैं। कभी-कभी यह स्वाद वास्तव में अच्छा होता है। कभी-कभी यह मतली का कारण बनता है। (...) ठोस क्रियाओं के पीछे मूल्यों और मान्यताओं का एहसास होने से पहले आप एक संस्कृति को नहीं बदल सकते। व्यवहार का निरीक्षण करना आसान है, और अनुनय मांगना मुश्किल है। DevOps इस बात का एक बड़ा उदाहरण है कि कैसे चीजें कठिन और कठिन होती जाती हैं। ”

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

• भूमिकाओं और विभागों के बीच बातचीत में सुधार
• गलतियों को काम के अभिन्न अंग के रूप में स्वीकार करना
• प्रगतिशील परिवर्तन
• ट्यूनिंग और अन्य स्वचालन का उपयोग करना
• हर चीज को मापा जा सकता है

यह केवल बयानों का एक सेट नहीं है, बल्कि कार्रवाई के लिए एक विशिष्ट मार्गदर्शिका है । उदाहरण के लिए, गलतियाँ करने के मार्ग पर, आपको जोखिमों से निपटना होगा, SLI ( सेवा स्तर संकेतक ) और SLO ( सेवा स्तर के उद्देश्यों ) जैसी किसी चीज़ का उपयोग करके सेवाओं की उपलब्धता और अक्षमता को मापना होगा, पोस्टमार्टम लिखना सीखना होगा और इसे लिखना आसान बनाना होगा। ।

एसआरई अनुशासन में, उपकरणों का उपयोग सफलता का केवल एक हिस्सा है, हालांकि, यह महत्वपूर्ण है। हमें तकनीकी रूप से लगातार विकास करने की जरूरत है, यह देखें कि दुनिया में क्या हो रहा है और इसे हमारे काम में कैसे लागू किया जा सकता है।

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

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

इस सबका क्या किया जाए

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

हम देवओप्स 2020 मॉस्को सम्मेलन कर रहे हैं, जो उन चीजों को बेहतर ढंग से समझने का अवसर प्रदान करता है जिनके बारे में हमने अभी बात की है। इसके लिए रिपोर्ट के कई समूह हैं:

• प्रक्रियाओं और संस्कृति;
• साइट विश्वसनीयता इंजीनियरिंग;
• क्लाउड नेटिव

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

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

यह केवल यह समझने के लिए रहता है कि यदि आप एक DevOps इंजीनियर हैं तो क्या करें! सबसे पहले, यह निर्धारित करने का प्रयास करें कि आप वास्तव में क्या कर रहे हैं। आमतौर पर वे इस शब्द को कॉल करना पसंद करते हैं:

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

एक और विकल्प है: आप लगातार बने रहते हैं और दावा करते रहते हैं कि आप एक DevOps इंजीनियर हैं और कुछ भी नहीं, जो भी इसका मतलब है। फिर शोक करने के लिए मजबूर, DevOops DevOps इंजीनियरों के लिए एक सम्मेलन नहीं है!

म्यूनिख में कॉन्स्टेंटिन डायनर की रिपोर्ट से स्लाइड

देवओप्स 2020 मॉस्को में 29-30 अप्रैल को आयोजित किया जाएगा, टिकट पहले ही आधिकारिक वेबसाइट पर खरीदे जा सकते हैं।

इसके अलावा, आप अपनी रिपोर्ट 8 फरवरी तक जमा कर सकते हैं। कृपया ध्यान दें कि फॉर्म भरते समय, आपको लक्षित दर्शकों को चुनना होगा, जिसके लिए आपकी रिपोर्ट अधिक अच्छी होगी ( सूची के अंदर एक आश्चर्य दफन है )।