यह, ज़ाहिर है,
DevOpsConf के बारे में है। यदि आप विवरण में नहीं जाते हैं, तो 30 सितंबर और 1 अक्टूबर को हम विकास, परीक्षण और संचालन प्रक्रियाओं के एकीकरण पर एक सम्मेलन आयोजित करेंगे, और यदि आप इसमें जाते हैं, तो मैं बिल्ली से पूछता हूं।
DevOps दृष्टिकोण के ढांचे के भीतर, परियोजना के तकनीकी विकास के सभी हिस्से परस्पर जुड़े हुए हैं, समानांतर में होते हैं और एक दूसरे को प्रभावित करते हैं। यहां विशेष महत्व की स्वचालित विकास प्रक्रियाओं का निर्माण होता है जिन्हें वास्तविक समय में बदला, अनुकरण और परीक्षण किया जा सकता है। यह बाजार में बदलावों का तुरंत जवाब देने में मदद करता है।
सम्मेलन में, हम यह दिखाना चाहते हैं कि यह दृष्टिकोण उत्पाद विकास को कैसे प्रभावित करता है। क्लाइंट के लिए सिस्टम की विश्वसनीयता और अनुकूलनशीलता कैसी है। DevOps कैसे वर्कफ़्लो के संगठन के लिए कंपनी की संरचना और दृष्टिकोण को बदलता है।
पर्दे के पीछे
हमारे लिए यह जानना महत्वपूर्ण है कि देवोप्स दृष्टिकोण के तहत विभिन्न कंपनियां न केवल क्या कर रही हैं, बल्कि यह भी समझें कि यह सब क्यों है। इसलिए, हमने न केवल विशेषज्ञों को कार्यक्रम समिति में आमंत्रित किया, बल्कि विभिन्न दृष्टिकोणों से देवो के प्रवचन देखने वाले विशेषज्ञ:
- वरिष्ठ इंजीनियर;
- डेवलपर्स;
- टीम का नेतृत्व;
- सीटीओ।
एक ओर, यह रिपोर्ट के लिए अनुप्रयोगों पर चर्चा करते समय कठिनाइयों और संघर्ष पैदा करता है। यदि एक इंजीनियर एक बड़ी दुर्घटना का विश्लेषण करने में रुचि रखता है, तो डेवलपर के लिए यह समझना अधिक महत्वपूर्ण है कि कैसे सॉफ्टवेयर बनाने के लिए जो बादलों और अवसंरचना में काम करता है। लेकिन सहमत होकर, हम एक कार्यक्रम बनाते हैं जो मूल्यवान और सभी के लिए दिलचस्प होगा: इंजीनियरों से सीटीओ तक।
हमारे सम्मेलन का कार्य केवल अधिक उच्च तकनीक वाली रिपोर्टों का चयन करना नहीं है, बल्कि बड़ी तस्वीर पेश करना है: अभ्यास में देवओप्स कैसे काम करता है, नई प्रक्रियाओं में जाने पर आप किस तरह की रेक चला सकते हैं। उसी समय, हम सामग्री भाग का निर्माण करते हैं, जो व्यवसाय कार्य से विशिष्ट प्रौद्योगिकियों तक नीचे जा रहा है।
सम्मेलन के अनुभाग
पिछली बार की तरह ही रहेंगे।
- इंफ्रास्ट्रक्चर प्लेटफॉर्म।
- एक कोड के रूप में बुनियादी ढाँचा।
- निरंतर वितरण।
- हमसे संपर्क करें।
- देवो पर वास्तुकला, सीटीओ के लिए DevOps।
- SRE प्रैक्टिस।
- प्रशिक्षण और ज्ञान प्रबंधन।
- सुरक्षा, DevSecOps।
- DevOps परिवर्तन।
पत्रों के लिए कॉल करें: हम किन रिपोर्टों की तलाश कर रहे हैं
हमने सम्मेलन के संभावित दर्शकों को सशर्त रूप से पांच समूहों में विभाजित किया है: इंजीनियर, डेवलपर्स, सुरक्षा विशेषज्ञ, टीम लीडर और सीटीओ। सम्मेलन में आने के लिए प्रत्येक समूह की अपनी प्रेरणा है। और, यदि आप इन पदों से DevOps को देखते हैं, तो आप समझ सकते हैं कि अपने विषय को कैसे केंद्रित किया जाए और कहां जोर दिया जाए।
इंजीनियरों के लिए जो एक बुनियादी ढांचा मंच बना रहे हैं, मौजूदा रुझानों को समझना महत्वपूर्ण है, यह समझने के लिए कि कौन सी प्रौद्योगिकियां अब सबसे उन्नत हैं। वे इन प्रौद्योगिकियों और विनिमय विचारों का उपयोग करने के वास्तविक अनुभव से परिचित होने के लिए इच्छुक होंगे। एक इंजीनियर ख़ुशी से कुछ कट्टर दुर्घटना के विश्लेषण के साथ एक रिपोर्ट को सुनेगा, हम, बदले में, ऐसी रिपोर्ट को चुनने और चमकाने की कोशिश करेंगे।
डेवलपर्स के लिए, क्लाउड नेटिव एप्लिकेशन जैसी अवधारणा को समझना महत्वपूर्ण
है । यही है, सॉफ्टवेयर को कैसे विकसित किया जाए ताकि यह बादलों और विभिन्न अवसंरचना में काम करे। डेवलपर को सॉफ़्टवेयर से लगातार प्रतिक्रिया प्राप्त करने की आवश्यकता होती है। यहां हम ऐसे मामलों को सुनना चाहते हैं कि कंपनियां इस प्रक्रिया का निर्माण कैसे करती हैं, सॉफ्टवेयर प्रदर्शन की निगरानी कैसे करती हैं और वितरण की पूरी प्रक्रिया कैसे काम करती है।
साइबर सुरक्षा पेशेवरों के लिए यह समझना महत्वपूर्ण है कि सुरक्षा प्रक्रिया कैसे स्थापित करें ताकि यह कंपनी के भीतर विकास प्रक्रियाओं और परिवर्तनों को रोक न सके। ऐसे विशेषज्ञों के लिए DevOps द्वारा की जाने वाली आवश्यकताओं के विषय दिलचस्प होंगे।
द टाइमलीड्स यह जानना चाहता है कि अन्य कंपनियों में निरंतर वितरण प्रक्रिया कैसे
काम करती है । किस तरह से कंपनी इस पर गई, कैसे विकास की प्रक्रियाएं बनीं, DevOps के भीतर गुणवत्ता आश्वासन। क्लाउड देशी टीम के साथी भी दिलचस्प हैं। और यह भी - टीम के भीतर और डेवलपर्स और इंजीनियरों की टीमों के बीच बातचीत के बारे में सवाल।
सीटीओ के लिए, सबसे महत्वपूर्ण बात यह पता लगाना है कि इन सभी प्रक्रियाओं को कैसे मिलाएं और उन्हें व्यावसायिक आवश्यकताओं के साथ समायोजित करें। वह यह सुनिश्चित करता है कि आवेदन व्यापार और ग्राहक दोनों के लिए विश्वसनीय है। और यहां आपको यह समझने की आवश्यकता है कि कौन से प्रौद्योगिकियां किस व्यावसायिक कार्य के तहत काम करेंगी, पूरी प्रक्रिया का निर्माण कैसे करें आदि। सीटीओ भी बजट के लिए जिम्मेदार है। उदाहरण के लिए, उन्हें यह समझना चाहिए कि रिट्रीटिंग विशेषज्ञों पर उन्हें कितना पैसा खर्च करना है ताकि वे DevOps में काम कर सकें।
यदि आपको इन अवसरों पर कुछ कहना है, तो चुप न रहें,
एक रिपोर्ट प्रस्तुत करें । 20 अगस्त को पेपर्स की समय सीमा का आह्वान किया गया है। जितनी जल्दी आप दिखाते हैं, उतना ही समय रिपोर्ट को अंतिम रूप देने और प्रस्तुति की तैयारी के लिए होगा। तो, कस मत करो।
ठीक है, अगर आपको सार्वजनिक रूप से बोलने की ज़रूरत नहीं है, तो बस
एक टिकट खरीदें और 30 सितंबर और 1 अक्टूबर को सहयोगियों के साथ बातचीत करने के लिए आएं। हम वादा करते हैं कि यह दिलचस्प और प्रेरणादायक होगा।
जैसा कि हम DevOps देखते हैं
यह समझने के लिए कि देवओप्स से हमारा क्या तात्पर्य है, मैं अपनी बात "
क्या देवोप्स है " पढ़ने (या फिर से पढ़ने) की सलाह देता हूं। बाजार की लहरों के साथ चलते हुए, मैंने देखा कि कैसे देवो के विचार को विभिन्न आकार की कंपनियों में बदला जा रहा है: एक छोटे स्टार्टअप से लेकर बहुराष्ट्रीय कंपनियों तक। रिपोर्ट सवालों की एक श्रृंखला पर बनाई गई है, उनका जवाब देते हुए, आप समझ सकते हैं कि क्या आपकी कंपनी देवओपीएस पर जा रही है या कहीं समस्याएं हैं।
DevOps एक जटिल प्रणाली है, यह होनी चाहिए:
- डिजिटल उत्पाद।
- व्यापार मॉड्यूल है कि इस डिजिटल उत्पाद विकसित कर रहा है।
- उत्पाद टीमें जो कोड लिखती हैं।
- सतत प्रसव अभ्यास।
- एक सेवा के रूप में प्लेटफार्म।
- सेवा के रूप में अवसंरचना।
- एक कोड के रूप में बुनियादी ढाँचा।
- अलग विश्वसनीयता प्रथाओं DevOps अंदर वायर्ड।
- फीडबैक अभ्यास जो यह सब बताता है।
रिपोर्ट के अंत में एक योजना है जो कंपनी में DevOps प्रणाली का विचार देती है। यह आपको यह देखने की अनुमति देगा कि आपकी कंपनी में कौन सी प्रक्रियाएं पहले से ही डीबग की गई हैं, और जिसे केवल बनाया जाना है।
आप
यहां वीडियो रिपोर्ट देख सकते
हैं ।
और अब एक बोनस होगा: RIT ++ 2019 के कई वीडियो जो कि DevOps परिवर्तन के सबसे सामान्य मुद्दों से संबंधित हैं।
उत्पाद के रूप में कंपनी का बुनियादी ढांचा
आर्टीम में Artyom Naumenko ने DevOps टीम का नेतृत्व किया और अपनी कंपनी के बुनियादी ढांचे के विकास का ध्यान रखा। उन्होंने बताया कि स्काईवॉघ में बुनियादी ढांचा व्यवसाय प्रक्रियाओं को कैसे प्रभावित करता है: इसके लिए आरओआई की गणना कैसे करें, गणना के लिए क्या मेट्रिक्स चुना जाना चाहिए, और उन्हें सुधारने के लिए कैसे काम करना चाहिए।
Microservices के रास्ते पर
निक्स व्यस्त वेब परियोजनाओं और वितरित प्रणालियों का समर्थन करने के लिए प्रतिबद्ध है। इसके तकनीकी निदेशक बोरिस एर्शोव ने बताया कि सॉफ्टवेयर उत्पादों को कैसे स्थानांतरित किया जाए, जिसका विकास लगभग 5 साल पहले (या इससे भी अधिक) आधुनिक जेलों में शुरू हुआ था।
एक नियम के रूप में, ऐसी परियोजनाएं एक विशेष दुनिया हैं जहां बुनियादी ढांचे के ऐसे अंधेरे और प्राचीन कोने हैं जो कि वर्तमान इंजीनियरों को उनके बारे में नहीं पता है। और वास्तुकला और विकास के लिए एक बार चयनित दृष्टिकोण पुराने हैं और नए संस्करणों के विकास और रिलीज की समान गति के साथ व्यापार प्रदान नहीं कर सकते हैं। नतीजतन, उत्पाद की हर रिलीज एक अविश्वसनीय साहसिक में बदल जाती है जहां कुछ लगातार गिरता है, और सबसे अप्रत्याशित जगह में।
ऐसी परियोजनाओं के प्रबंधकों को अनिवार्य रूप से सभी तकनीकी प्रक्रियाओं को बदलने की आवश्यकता होती है। अपनी रिपोर्ट में, बोरिस ने कहा:
- परियोजना के लिए उपयुक्त वास्तुकला का चयन कैसे करें और बुनियादी ढांचे को साफ करें;
- क्या उपकरण का उपयोग करें और क्या परिवर्तन के रास्ते पर नुकसान पाए जाते हैं;
- आगे क्या करना है।
स्वचालन जारी करें या दर्द के बिना और जल्दी से कैसे वितरित करें
अलेक्जेंडर कोरोटकोव सीआईए में सीआई / सीडी सिस्टम का एक प्रमुख डेवलपर है। उन्होंने ऑटोमेशन टूल्स के बारे में बात की, जिन्होंने गुणवत्ता में सुधार किया और उत्पादन में कोड के वितरण समय को 5 गुना कम कर दिया। लेकिन इस तरह के परिणाम केवल एक स्वचालन से हासिल नहीं किए जा सकते थे, इसलिए अलेक्जेंडर ने विकास प्रक्रियाओं में बदलाव पर ध्यान आकर्षित किया।
दुर्घटनाएं आपको कैसे सीखने में मदद करती हैं?
एलेक्सी किर्पीचनिकोव 5 वर्षों से SKB कोंटूर में DevOps और बुनियादी ढांचे को लागू कर रहे हैं। तीन वर्षों के लिए, महाकाव्य की बदलती डिग्री के लगभग 1,000 फेकैप्स उनकी कंपनी में हुए। उनमें से, उदाहरण के लिए, 36% उत्पादन में कम-गुणवत्ता वाले रिलीज को बाहर करने के कारण हुए, और 14% डेटा सेंटर में लोहे के रखरखाव के काम के कारण हुए।
दुर्घटनाओं के बारे में ऐसी सटीक जानकारी प्राप्त करने से रिपोर्टों के संग्रह (पोस्टमार्टम) की अनुमति मिलती है, जिसे कंपनी के इंजीनियर लगातार कई वर्षों से आयोजित कर रहे हैं। पोस्टमॉर्टम में ड्यूटी पर इंजीनियर लिखते हैं, जो दुर्घटना के बारे में संकेत का जवाब देने वाले पहले व्यक्ति थे और सब कुछ ठीक करने लगे। रात को फेकैप्स से लड़ने वाले इंजीनियर क्यों रिपोर्ट लिखते हैं? यह डेटा आपको पूरी तस्वीर देखने और बुनियादी ढांचे के विकास को सही दिशा में ले जाने की अनुमति देता है।
अपने भाषण में, एलेक्सी ने साझा किया कि वास्तव में एक उपयोगी पोस्टमार्टम कैसे लिखा जाए और एक बड़ी कंपनी में ऐसी रिपोर्टों के अभ्यास को कैसे लागू किया जाए। यदि आप कहानियों से प्यार करते हैं कि किसी ने कैसे पंगा लिया, तो प्रदर्शन का एक वीडियो देखें।
हम समझते हैं कि देवो की आपकी दृष्टि हमारे विचारों से मेल नहीं खाती। यह जानना दिलचस्प होगा कि आप DevOps का रूपांतरण कैसे देखते हैं। इस विषय पर अपने अनुभव और विज़न को टिप्पणियों में साझा करें।हमने पहले ही कार्यक्रम में कौन सी रिपोर्ट स्वीकार कर ली हैं?
इस सप्ताह, कार्यक्रम समिति ने 4 रिपोर्टों को अपनाया: सुरक्षा, बुनियादी ढांचे और एसआरई प्रथाओं पर।
शायद DevOps परिवर्तन का सबसे दर्दनाक विषय: यह सुनिश्चित करने के लिए कि सूचना सुरक्षा विभाग के लोग विकास, संचालन और प्रशासन के बीच पहले से निर्मित कनेक्शन को बर्बाद नहीं करते हैं।
कुछ कंपनियां बिना सूचना सुरक्षा विभाग के काम करती हैं । फिर सूचना सुरक्षा कैसे सुनिश्चित करें? यह
sudo.su से मोना आर्किपोवा को बताएगा। उसकी रिपोर्ट से हम सीखते हैं:
- क्या और किससे रक्षा करना आवश्यक है;
- नियमित सुरक्षा प्रक्रियाएं क्या हैं;
- कैसे आईटी और आईएस प्रक्रियाओं को काटते हैं
- CIS CSC क्या है और इसे कैसे लागू किया जाए;
- कैसे और किन संकेतकों द्वारा नियमित आईएस जांच की जाती है।
अगली रिपोर्ट कोड के रूप में बुनियादी ढांचे के विकास को संबोधित करती है। मैनुअल रूटीन की मात्रा कम करें और पूरे प्रोजेक्ट को अराजकता में न बदलें, क्या यह संभव है?
Ixtens के मैक्सिम कोस्ट्रिंक इस सवाल का
जवाब देंगे । उनकी कंपनियां AWS इन्फ्रास्ट्रक्चर के साथ काम करने के लिए
टेराफॉर्म का उपयोग करती हैं। उपकरण सुविधाजनक है, लेकिन सवाल यह है कि कोड की एक बड़ी गांठ की उपस्थिति से बचने के लिए इसका उपयोग कैसे किया जाए। ऐसी धरोहर के रखरखाव पर हर साल ज्यादा से ज्यादा खर्च होगा।
मैक्सिम दिखाएगा कि स्वचालन और विकास कार्यों को सरल बनाने के उद्देश्य से कोड प्लेसमेंट पैटर्न कैसे हैं।
हम
Playkey से
व्लादिमीर रयाबोव के बुनियादी ढांचे पर एक और
रिपोर्ट सुनेंगे । यहां हम बुनियादी ढांचे के मंच के बारे में बात करेंगे, और हम सीखेंगे:
- कैसे समझें कि भंडारण क्षमता का कुशलता से उपयोग किया जा रहा है;
- यदि केवल 20 टीबी भंडारण का उपयोग किया जाता है तो कितने सौ उपयोगकर्ता 10 टीबी सामग्री प्राप्त कर सकते हैं;
- 5 बार डेटा को कैसे संपीड़ित करें और वास्तविक समय में उपयोगकर्ताओं को प्रदान करें;
- कई डेटा केंद्रों के बीच डेटा को सिंक्रनाइज़ करने के लिए मक्खी पर कैसे;
- कैसे एक आभासी मशीन के अनुक्रमिक उपयोग में एक दूसरे पर उपयोगकर्ताओं के किसी भी प्रभाव को बाहर करने के लिए।
इस जादू का रहस्य
फ्रीबीएसडी के लिए जेडएफएस तकनीक
में है और
लिनक्स पर जेडएफएस का नवीनतम कांटा है। व्लादिमीर प्लेकी से मामलों को साझा करेगा।
Amixr.IO का मैटिवे कुकु जीवन के उदाहरणों से यह
बताने के लिए तैयार है कि
SRE क्या
है और कैसे विश्वसनीय प्रणालियों के निर्माण में मदद करता है। Amixr.IO अपने बैकएंड के माध्यम से ग्राहकों की घटनाओं को पार करता है, दुनिया भर में दर्जनों ड्यूटी टीमों ने पहले ही 150 हजार मामलों को सुलझा लिया है। सम्मेलन में, मैटवे सांख्यिकी और अंतर्दृष्टि साझा करेगा कि उसकी कंपनी जमा हो गई है, ग्राहकों की समस्याओं को हल करने और फेकैपी का विश्लेषण कर रही है।
एक बार फिर, मैं आपसे आग्रह करता हूं कि आप लालची न हों और अपने अनुभव को DevOps-samurai के साथ साझा करें। रिपोर्ट के लिए आवेदन करें , और हमारे पास एक उत्कृष्ट प्रस्तुति तैयार करने के लिए 2.5 महीने होंगे। यदि आप एक श्रोता बनना चाहते हैं, तो प्रोग्राम अपडेट के साथ समाचार पत्र की सदस्यता लें और टिकट बुकिंग के बारे में गंभीरता से सोचें, क्योंकि वे सम्मेलन की तारीखों के करीब बढ़ जाएंगे।