DevOpsDays मास्को की समीक्षा करें: 6 रिपोर्टों से अंतर्दृष्टि

7 दिसंबर को, मास्को देवओपीएस समुदाय द्वारा Mail.ru Cloud Solutions के सहयोग से तीसरा DevOpsDays मास्को सम्मेलन आयोजित किया गया था। प्रमुख DevOps चिकित्सकों की रिपोर्टों के अलावा, प्रतिभागी खुले स्थानों पर लघु प्रेरक लाइटिंग टॉक्स, कार्यशालाओं और चैट में भाग ले सकते हैं।

हमने छह प्रस्तुतियों से महत्वपूर्ण अंतर्दृष्टि एकत्र की और कई वक्ताओं के साथ साक्षात्कार का आयोजन किया ताकि यह पता लगाया जा सके कि रिपोर्टों से क्या बचा था।

अंदर:

1. बारूक सदोगुरस्की, JFrog: "सॉफ़्टवेयर को उपयोगकर्ता से तरल की तरह प्रवाहित करें"
   
2. पावेल सेलिवानोव, साउथब्रिज: "देव और ऑप्स के पास एक सामान्य कार्य है - एक उत्पाद बनाने के लिए जो काम करता है"
   
3. व्लादिमीर Utratenko, X5 खुदरा समूह: "एंटरप्राइज में DevOps दर्द और आग के बिना विकास है"
   
4. सर्गेई पूज्येरेव, फेसबुक: "प्रोडक्शन इंजीनियर एक पूरे के रूप में सेवा का ख्याल रखता है: ताकि उपयोगकर्ताओं और डेवलपर्स दोनों को अच्छा लगे"
   
5. मिखाइल चिंकोव, एएमबीओएसएस: "एक इकाई DevOps पथ का अनुसरण नहीं कर सकती है, पूरी कंपनी को इसका पालन करना चाहिए"
   
6. Rosbank DevOps के प्रति उत्साही: "खूनी उद्यम में DevOps को लागू करने के लिए 1000 दिन"
   

1. बारूक सदोगुरस्की, JFrog: "सॉफ़्टवेयर को उपयोगकर्ता से तरल की तरह प्रवाहित करें"

सॉफ़्टवेयर को अपडेट करने में विफलताएं हर घंटे और सभी के लिए होती हैं। यहाँ भाषण से सिर्फ एक डरावनी कहानी है: एक असफल अपडेट के बाद नाइट कैपिटल ने $ 440 मिलियन प्रति घंटे खो दिए।

बारूक ने निरंतर अपडेट के DevOps पैटर्न के बारे में बात की, जो उपयोगकर्ता की विफलताओं और घृणा से बचने में मदद करेगा:

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

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

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

स्वचालित तैनाती - मशीनों के साथ लोगों को प्रतिस्थापित करें, क्योंकि लोगों को पता नहीं है कि नियमित क्रियाएं कैसे की जाती हैं।

लगातार अपडेट - एक आदत विकसित करने और डर से छुटकारा पाने में मदद करें। दुर्लभ अपडेट एक आपातकालीन घटना में बदल जाते हैं।

डिवाइस की स्थिति का ज्ञान - परीक्षण अपडेट, खरोंच से स्थापना नहीं। यह महत्वपूर्ण है, क्योंकि अपडेट डिवाइस की स्थिति के आधार पर अलग-अलग व्यवहार कर सकता है।

कैनरी रिलीज़ - अपडेट को कम संख्या में उपयोगकर्ताओं और घड़ी के लिए रोल आउट करें। यह क्षति को कम करता है अगर कुछ गलत हो जाता है।

दुर्गमता के बिना अपडेट - ग्राहकों को केवल नई सुविधाओं को नोटिस करने दें, और जब तक आप अपडेट को रोल नहीं करते हैं, तब तक कई हफ्तों तक सेवा के बिना नहीं रहेंगे।

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

2. पावेल सेलिवानोव, साउथब्रिज: "देव और ऑप्स के पास एक सामान्य कार्य है - एक उत्पाद बनाने के लिए जो काम करता है"

कुबेरनेट को लागू करने से DevOps को प्राप्त करने में मदद नहीं मिलेगी, और इसके विपरीत - यह सब कुछ तोड़ सकता है। पावेल ने बताया कि प्रौद्योगिकियां (यहां तक ​​कि सबसे अच्छे) आपकी सभी समस्याओं को हल नहीं कर सकती हैं:

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

DevOps के लागू होने के बाद डेवलपर्स बदलाव नहीं चाहते हैं । नतीजतन, कुबेरनेट्स के साथ वर्कफ़्लो एक दीवार के माध्यम से देव से ऑप्स तक कार्यों को फेंकने की तरह दिखता है, लेकिन अब रूपक नहीं - गिट ऐसी दीवार बन जाता है। डेवलपर वहां कोड डालता है और पहले की तरह काम करता है, और प्रवेशकर्ताओं के पास Kubernetes, CI / CD और सब कुछ है।

हालांकि, डेवलपर्स को परिवर्तनों को स्वीकार करने की आवश्यकता है । ऐसी स्थिति जब डेवलपर्स को यह नहीं पता होता है कि प्रशासक क्या करते हैं, और प्रशासक यह नहीं जानते हैं कि डेवलपर्स के साथ क्या हो रहा है, समस्याएं पैदा करता है।

यदि डेवलपर्स ने कुछ भी नहीं बदला है, तो वे महसूस नहीं करते हैं कि आवेदन का काम उनकी जिम्मेदारी है - विभिन्न तकनीकी चालें काम नहीं करेंगी।

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

पावेल सेलिवानोव ने 5 वर्षों में कुबेरनेट्स का क्या होगा और आधुनिक स्टार्टअप के लिए तकनीकी स्टैक का निर्माण करने के बारे में बात की - साक्षात्कार देखें:

3. व्लादिमीर Utratenko, X5 खुदरा समूह: "एंटरप्राइज में DevOps दर्द और आग के बिना विकास है"

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

व्लादिमीर ने बताया कि यह कैसे होता है, और क्या पकड़ है:

1. सबसे पहले, कंपनियां एक DevOps इंजीनियर को नियुक्त करती हैं। यह एक वरिष्ठ प्रणाली प्रशासक है, वह उत्पादन में रिलीज की तैनाती, विकास पर्यावरण के मानकीकरण, बुनियादी ढांचे के विन्यास, विभिन्न समस्याओं का पता लगाने और फिक्सिंग, प्रक्रिया स्वचालन और अन्य तकनीकी कार्यों में लगा हुआ है।
   
2. फिर एक DevOps इंजीनियर अब पर्याप्त नहीं है, और कंपनी एक DevOps टीम को काम पर रखती है। यह क्षमता का एक केंद्र है, जो असमान इंजीनियरों के प्रयासों का आयोजन करता है, आपको उन्हें एक दिशा में केंद्रित करने की अनुमति देता है।
   
3. वास्तव में, DevOps इंजीनियर और DevOps टीमें DevOps के रूपांतरणों की एंटीपैटर्न हैं। चूंकि DevOps प्रथाओं और संस्कृति के बारे में है, इसके अलावा, प्रौद्योगिकी कंपनियों (SRE, उत्पादन इंजीनियरिंग) में DevOps के कार्यान्वयन हैं।
   

क्या करें? देवओप्स परिवर्तन को लागू करने में मदद करने के लिए एक अस्थायी DevOps टीम को किराए पर लेना प्रथाओं पर ले जाएगा, एक विकास संस्कृति और तकनीकी संस्कृति की खेती करेगा।

जब कोई व्यवसाय खेल में प्रवेश करता है और DevOps में निवेश करता है, तो कई परिदृश्य संभव हैं: सब कुछ टेक-ऑफ पर अलग हो जाएगा; SRE / प्रोडक्शन इंजीनियरिंग या एंबेडेड ऑप्स के रूप में रहेगा; जब बिज़नेस मेट्रिक्स पर भरोसा करते हैं तो BizOps में चले जाएंगे।

व्लादिमीर Utratenko हमें बताया कि कैसे "खूनी" उद्यम में DevOps वास्तव में हैं और प्रथाओं को बड़े खुदरा स्टोरों के अंदर कैसे लागू किया जा रहा है

4. सेर्गेई पूज्येरेव, फेसबुक: "प्रोडक्शन इंजीनियर सेवा का पूरा ध्यान रखता है: ताकि उपयोगकर्ताओं और डेवलपर्स दोनों को अच्छा महसूस हो"

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

सर्गेई ने बताया कि फेसबुक पर प्रोडक्शन इंजीनियर क्या कर रहा है:

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

5. मिखाइल चिंकोव, एएमबीओएसएस: "एक इकाई DevOps पथ का अनुसरण नहीं कर सकती है, पूरी कंपनी को इसका पालन करना चाहिए"

माइकल का मानना ​​है कि DevOps एक सतत विकास है। आप किसी भी उपकरण को पेश नहीं कर सकते हैं और वहां रुक सकते हैं। क्या समस्याएं कंपनियों को DevOps बनने से रोकती हैं और प्रथाओं को कैसे लागू करें?

DevOps को समझने में अंतर । कैनोनिकल देवोप्स, जैसा कि इंजीलवादी इसे देखते हैं, 5 स्तंभों पर टिकी हुई है:

• संस्कृति - लोगों और सहयोग पर ध्यान केंद्रित;
  
• स्वचालन - वर्कफ़्लो के लिए दिनचर्या का प्रतिनिधिमंडल;
  
• दुबला - उपयोगकर्ता के लिए मूल्य के वितरण पर जोर;
  
• शेयरिंग - निरंतर ज्ञान साझा करना;
  
• मैट्रिक्स और उनकी मदद से प्रतिक्रिया प्राप्त करना।
  

कंपनियां आमतौर पर उपयोगकर्ता को केवल स्वचालन और मूल्य के वितरण पर ध्यान केंद्रित करती हैं। लेकिन संस्कृति, ज्ञान साझाकरण और DevOps मेट्रिक्स, जिसके द्वारा आप विकास को ट्रैक कर सकते हैं, रास्ते से जा सकते हैं।

समस्याएं DevOps मानकीकरण । सभी कंपनियों के लिए उत्पाद लक्ष्य अलग हैं; उनका मानकीकरण नहीं किया जा सकता है। कंपनी में DevOps की स्थिति कंपनी पर ही निर्भर करती है, लेकिन कई लोग इसे नहीं समझते हैं और मानते हैं कि यह DevOps इंजीनियर को नौकरी देने के लिए पर्याप्त है।

हम अभी तक DevOps क्यों नहीं हैं? दो प्रमुख मुद्दे हैं। एंटरप्राइज़ में - संगठन का धीमा विकास, हजारों कर्मचारियों के सिर में वेक्टर को बदलने की कठिनाई। स्टार्टअप्स में, ज्ञान के स्रोतों की कमी है, परिवर्तन के लिए संसाधनों के आवंटन के साथ एक समस्या है।

कंपनी में DevOps का विकास चरण :

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

आदर्श योजना - सभी के पास बुनियादी ढांचे की समान पहुंच है, सभी इंजीनियरों को उत्पाद तक पहुंच प्राप्त होती है और समझते हैं कि वे क्या कर रहे हैं।

सभी सांस्कृतिक और तकनीकी गेस्टाल्ट को बंद करते हुए, कंपनी के DevOps परिवर्तन व्यवसाय मेट्रिक्स और प्लेटफ़ॉर्म मेट्रिक्स से फीडबैक लेंगे।

6. Rosbank के DevOps उत्साही: "खूनी उद्यम में DevOps को लागू करने के लिए 1000 दिन"

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

यहाँ प्राप्त परिणाम हैं:

उत्पाद टीमों के लिए परिणाम : 30 गुना तेजी से विधानसभा, 6 गुना तेजी से स्थापना, एक पूर्ण चक्र पर 30% तक की बचत। हमें उत्पादक में बटन को रोल करने का अवसर मिला

प्लेटफ़ॉर्म टीमों के लिए परिणाम : असेंबली और इंस्टॉलेशन 10 गुना तेज है, इंस्टॉलेशन की संख्या में 87% की वृद्धि हुई है, ऑटोटेस के साथ कवरेज 46% है। एकीकरण टीम एक अड़चन होने के नाते रोक दिया

तो, खूनी उद्यम में DevOps प्रथाओं को कैसे लागू किया जाए?

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

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

पायलट के बाद, एक सफल समाधान को बढ़ाया जाना चाहिए ।

1. जितना संभव हो सके कन्वेयर को "सीधा" करना महत्वपूर्ण है, इससे अनावश्यक लिंक को समाप्त करना, मूल्य प्रदाताओं को उजागर करना, और शेष घटकों को निकालना। मध्यवर्ती एंटीपैटर्न हैं। उदाहरण के लिए, रोसबैंक में, कई टीमों का आंतरिक विकास नहीं हुआ, केवल बाहरी बने रहे। इससे एक समर्पित DevOps टीम का उदय हुआ, जिसने बाहरी डेवलपर्स से आंतरिक लोगों को कोड ट्रांसफर प्रदान किया। बाहरी विकास को CI / CD में एकीकृत करके समस्या का समाधान किया गया ताकि वे न केवल स्वयं को बैंक से कोड स्थानांतरित करें, बल्कि इसकी सफलता के लिए भी जिम्मेदार होंगे।
   
2. देवओप्स अभ्यास के तत्वों को परिपक्वता मॉडल में शामिल किया गया था, उपकरण सूचीबद्ध किए गए थे, और बाहरी आपूर्तिकर्ताओं के साथ काम करने की विशेषताओं को ध्यान में रखा गया था - भविष्य में नई टीमों में लागू होने पर कार्यों के बैकलॉग को जल्दी से काटने में मदद मिली।
   
3. नरम नियंत्रण और सिफारिशों के रूप में शासन की आवश्यकता है। DevOps हैंडबुक अच्छी तरह से काम करती है - यह संगठनात्मक और वाद्य विशेषताओं का एक सेट है जो टीमों को प्लेटफॉर्म का सही उपयोग करने में मदद करता है।
   
4. यह संस्कृति पर तुरंत ध्यान देने योग्य है, फिर कई बदलाव तेज और आसान होंगे। आंतरिक समुदाय विकसित करें, बैठकें, तकनीकी कार्यशालाएं, प्रशिक्षण, मजेदार गतिविधियां करें। यह फल देता है: लोग अपनी प्रथाओं को साझा करते हैं, देखते हैं कि किसने क्या किया है, पता है कि कहां मोड़ना है, कंपनी के भीतर प्रचार और स्वस्थ प्रतियोगिता है।
   
5. यह उन लोगों के साथ काम करने का कोई मतलब नहीं है जो प्रक्रिया में शामिल नहीं हैं, उन टीमों के साथ जो पके नहीं हैं, इच्छुक टीमों और वफादार लोगों में निवेश करना बेहतर है।
   
6. चयनित समाधान उन इंजीनियरों के लिए सुविधाजनक होना चाहिए जो इसका उपयोग करते हैं।
   
7. बाहरी विकास एक अवरोधक नहीं है, आप वहां प्रथाओं को भी लागू कर सकते हैं, मुख्य बात यह है कि टीम की खुद की इच्छा है।
   

थोड़ा और अच्छा

अलेक्जेंडर चिश्त्यकोव, vdsina.com से उन पुस्तकों की सूची जिन्हें देवो में पढ़ा जाना चाहिए:

1. इरीना याकुतेंको "इच्छा और आत्म-नियंत्रण"।
   
2. डैनियल कहमैन "सोच, तेज और धीमी।"
   
3. बारबरा ओकले "ए माइंड फॉर नंबर्स"।
   
4. मैक्सिम डोरोफ़ेव "जेडी तकनीक।"
   
5. विक्टर फ्रेंकल "अर्थ के लिए आदमी की खोज"।
   

देखते रहो

हम भी DevOps से प्यार करते हैं। हमारे टेलीग्राम चैनल में @DevOps और @Kubernetes श्रृंखला, साथ ही अन्य Mail.ru Cloud Solutions की घटनाओं की घोषणाओं का पालन करें: t.me/k8s_mail