DevOps दृष्टिकोण के प्रशंसकों के लिए सम्मेलन

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

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

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

पर्दे के पीछे

हमारे लिए न केवल यह जानना महत्वपूर्ण है कि विभिन्न कंपनियां DevOps दृष्टिकोण के ढांचे के भीतर क्या कर रही हैं, बल्कि यह भी समझना महत्वपूर्ण है कि यह सब क्यों है। इसलिए, हमने न केवल विशेषज्ञों को कार्यक्रम समिति में शामिल होने के लिए आमंत्रित किया, बल्कि ऐसे विशेषज्ञों को भी आमंत्रित किया जो विभिन्न पदों से DevOps प्रवचन को देखते हैं:

• वरिष्ठ इंजीनियर;
• डेवलपर्स;
• टीम का नेतृत्व;
• सीटीओ।

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

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

सम्मेलन अनुभाग पहले जैसे ही रहेंगे पिछली बार.

• बुनियादी ढांचा मंच.
• कोड के रूप में इन्फ्रास्ट्रक्चर।
• निरंतर वितरण.
• प्रतिपुष्टि।
• DevOps में आर्किटेक्चर, CTO के लिए DevOps।
• एसआरई अभ्यास.
• प्रशिक्षण और ज्ञान प्रबंधन.
• सुरक्षा, DevSecOps.
• डेवऑप्स परिवर्तन।

कागजात के लिए कॉल करें: हम किस प्रकार की रिपोर्ट की तलाश कर रहे हैं

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

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

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

साइबर सुरक्षा विशेषज्ञ यह समझना महत्वपूर्ण है कि सुरक्षा प्रक्रिया कैसे स्थापित की जाए ताकि यह कंपनी के भीतर विकास और परिवर्तन प्रक्रियाओं को न रोके। ऐसे विशेषज्ञों के लिए DevOps द्वारा रखी जाने वाली आवश्यकताओं के विषय भी दिलचस्प होंगे।

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

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

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

ठीक है, अगर आपको सार्वजनिक रूप से बोलने की ज़रूरत नहीं है, तो बस एक टिकट खरीदें और सहकर्मियों के साथ संवाद करने के लिए 30 सितंबर और 1 अक्टूबर को आएं। हम वादा करते हैं कि यह दिलचस्प और प्रेरणादायक होगा।

हम DevOps को कैसे देखते हैं

यह समझने के लिए कि DevOps से हमारा क्या मतलब है, मैं अपनी रिपोर्ट पढ़ने (या दोबारा पढ़ने) की सलाह देता हूं।डेवऑप्स क्या है?" बाज़ार की लहरों के बीच चलते हुए, मैंने देखा कि कैसे DevOps का विचार विभिन्न आकार की कंपनियों में बदल रहा था: एक छोटे स्टार्टअप से लेकर बहुराष्ट्रीय कंपनियों तक। रिपोर्ट सवालों की एक श्रृंखला पर बनी है, जिनका उत्तर देकर आप समझ सकते हैं कि क्या आपकी कंपनी DevOps की ओर बढ़ रही है या कहीं कुछ समस्याएं हैं।

DevOps एक जटिल प्रणाली है, इसमें शामिल होना चाहिए:

• डिजिटल उत्पाद.
• व्यावसायिक मॉड्यूल जो इस डिजिटल उत्पाद को विकसित करते हैं।
• उत्पाद टीमें जो कोड लिखती हैं।
• सतत वितरण प्रथाएँ।
• एक सेवा के रूप में प्लेटफार्म.
• एक सेवा के रूप में बुनियादी ढाँचा।
• कोड के रूप में इन्फ्रास्ट्रक्चर।
• विश्वसनीयता बनाए रखने के लिए DevOps में निर्मित अलग-अलग प्रथाएँ।
• एक फीडबैक अभ्यास जो यह सब बताता है।

रिपोर्ट के अंत में एक आरेख है जो कंपनी में DevOps प्रणाली का एक विचार देता है। यह आपको यह देखने की अनुमति देगा कि आपकी कंपनी में कौन सी प्रक्रियाएं पहले ही सुव्यवस्थित हो चुकी हैं और कौन सी अभी बनाई जानी बाकी हैं।

आप रिपोर्ट का वीडियो देख सकते हैं यहां.

और अब एक बोनस होगा: RIT++ 2019 के कई वीडियो, जो DevOps परिवर्तन के सबसे सामान्य मुद्दों को छूते हैं।

एक उत्पाद के रूप में कंपनी का बुनियादी ढांचा

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

माइक्रोसर्विसेज की राह पर

निक्सीज़ कंपनी व्यस्त वेब परियोजनाओं और वितरित प्रणालियों के लिए सहायता प्रदान करती है। इसके तकनीकी निदेशक, बोरिस एर्शोव ने बताया कि सॉफ्टवेयर उत्पादों का अनुवाद कैसे किया जाए, जिसका विकास 5 साल पहले (या उससे भी अधिक) पहले शुरू हुआ था, एक आधुनिक मंच पर।

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

ऐसी परियोजनाओं के प्रबंधकों को अनिवार्य रूप से सभी तकनीकी प्रक्रियाओं को बदलने की आवश्यकता का सामना करना पड़ता है। बोरिस ने अपनी रिपोर्ट में कहा:

• परियोजना के लिए सही वास्तुकला का चयन कैसे करें और बुनियादी ढांचे को कैसे व्यवस्थित करें;
• परिवर्तन के मार्ग पर किन उपकरणों का उपयोग करना है और किन कठिनाइयों का सामना करना पड़ता है;
• आगे क्या करना है।

रिलीज़ का स्वचालन या त्वरित और दर्द रहित तरीके से वितरण कैसे करें

अलेक्जेंडर कोरोटकोव CIAN में CI/CD प्रणाली के अग्रणी डेवलपर हैं। उन्होंने स्वचालन उपकरणों के बारे में बात की जिससे गुणवत्ता में सुधार करना और उत्पादन तक कोड पहुंचाने में लगने वाले समय को 5 गुना कम करना संभव हो गया। लेकिन ऐसे परिणाम केवल स्वचालन से प्राप्त नहीं किए जा सकते थे, इसलिए अलेक्जेंडर ने विकास प्रक्रियाओं में बदलाव पर भी ध्यान दिया।

दुर्घटनाएँ आपको सीखने में कैसे मदद करती हैं?

एलेक्सी किरपिचनिकोव 5 वर्षों से एसकेबी कोंटूर में डेवऑप्स और बुनियादी ढांचे को लागू कर रहे हैं। तीन वर्षों के दौरान, उनकी कंपनी में महाकाव्य की अलग-अलग डिग्री के लगभग 1000 फैकैप हुए। उनमें से, उदाहरण के लिए, 36% उत्पादन में निम्न-गुणवत्ता वाली रिलीज़ शुरू करने के कारण हुए, और 14% डेटा सेंटर में हार्डवेयर रखरखाव कार्य के कारण हुए।

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

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

हम समझते हैं कि DevOps के बारे में आपका दृष्टिकोण हमारे दृष्टिकोण से मेल नहीं खा सकता है। यह जानना दिलचस्प होगा कि आप DevOps परिवर्तन को कैसे देखते हैं। इस विषय पर अपना अनुभव और दृष्टिकोण टिप्पणियों में साझा करें।

हमने कार्यक्रम में कौन सी रिपोर्ट पहले ही स्वीकार कर ली है?

इस सप्ताह कार्यक्रम समिति ने 4 रिपोर्टें अपनाईं: सुरक्षा, बुनियादी ढांचे और एसआरई प्रथाओं पर।

शायद DevOps परिवर्तन का सबसे दर्दनाक विषय: यह कैसे सुनिश्चित किया जाए कि सूचना सुरक्षा विभाग के लोग विकास, संचालन और प्रशासन के बीच पहले से बने संबंधों को नष्ट न करें। कुछ कंपनियाँ सूचना सुरक्षा विभाग के बिना प्रबंधन करती हैं. इस मामले में सूचना सुरक्षा कैसे सुनिश्चित करें? इसके बारे में बताऊंगा sudo.su से मोना आर्किपोवा. उसकी रिपोर्ट से हमें पता चलता है:

• क्या संरक्षित करने की आवश्यकता है और किससे;
• नियमित सुरक्षा प्रक्रियाएँ क्या हैं;
• आईटी और सूचना सुरक्षा प्रक्रियाएँ कैसे प्रतिच्छेद करती हैं;
• सीआईएस सीएससी क्या है और इसे कैसे लागू करें;
• नियमित सूचना सुरक्षा जाँच कैसे और किन संकेतकों द्वारा की जाए।

अगली रिपोर्ट कोड के रूप में बुनियादी ढांचे के विकास से संबंधित है। मैन्युअल दिनचर्या की मात्रा कम करें और पूरे प्रोजेक्ट को अराजकता में न बदल दें, क्या यह संभव है? इस सवाल पर जवाब देंगे Ixtens से मैक्सिम कोस्ट्रिकिन. उनकी कंपनी उपयोग करती है terraform AWS बुनियादी ढांचे के साथ काम करने के लिए। उपकरण सुविधाजनक है, लेकिन सवाल यह है कि इसका उपयोग करते समय कोड का एक बड़ा ब्लॉक बनाने से कैसे बचा जाए। ऐसी विरासत का रखरखाव हर साल और अधिक महंगा होता जाएगा। 

मैक्सिम दिखाएगा कि कोड प्लेसमेंट पैटर्न कैसे काम करते हैं, जिसका उद्देश्य स्वचालन और विकास को सरल बनाना है।

एक और रिपोर्ट हम बुनियादी ढांचे के बारे में सुनेंगे प्लेकी से व्लादिमीर रयाबोव. यहां हम इंफ्रास्ट्रक्चर प्लेटफॉर्म के बारे में बात करेंगे और सीखेंगे:

• कैसे समझें कि भंडारण स्थान का प्रभावी ढंग से उपयोग किया जा रहा है या नहीं;
• यदि केवल 10 टीबी भंडारण का उपयोग किया जाता है तो कितने सौ उपयोगकर्ता 20 टीबी सामग्री प्राप्त कर सकते हैं;
• डेटा को 5 बार कैसे संपीड़ित करें और इसे वास्तविक समय में उपयोगकर्ताओं को कैसे प्रदान करें;
• कई डेटा केंद्रों के बीच तुरंत डेटा को कैसे सिंक्रनाइज़ करें;
• क्रमिक रूप से एक वर्चुअल मशीन का उपयोग करते समय एक दूसरे पर उपयोगकर्ताओं के किसी भी प्रभाव को कैसे खत्म किया जाए।

इस जादू का रहस्य है तकनीक फ्रीबीएसडी के लिए ZFS और इसका ताजा कांटा लिनक्स पर ZFS. व्लादिमीर प्लेकी से मामले साझा करेंगे।

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

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

स्रोत: www.habr.com