डेवलपर की नजर से देवओप्स 2019

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

DevOops, JUG Ru Group द्वारा आयोजित कार्यक्रमों में से एक है। और मुझे स्वीकार करना चाहिए कि संगठन और स्तर की रिपोर्ट स्तर पर थी। सम्मेलन दो दिनों तक चला, तीन धाराओं में। इसके अलावा, वक्ताओं, कार्यशालाओं के साथ संचार के लिए चर्चा क्षेत्र थे, साथ ही बिजली की वार्ता - आसान और छोटी प्रस्तुतियां, उन लोगों के लिए, जिन्होंने पहले प्रदर्शन नहीं किया है और स्पीकर के रूप में खुद को आजमाना चाहते हैं।

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

पहला दिन

वर्ण, समुदाय और संस्कृति: समृद्धि के महत्वपूर्ण कारक (टिमोथी लिस्टर, द अटलांटिक सिस्टम्स गिल्ड इंक)

सम्मेलन को टिमोथी लिस्टर द्वारा खोला गया था, जिन्होंने 1987 में वापस (!) में DevOps प्रथाओं के बारे में एक किताब लिखी थी। टिम ने इस बारे में बहुत बात की कि एक स्वस्थ और सुखद वातावरण के साथ एक मजबूत, सफल टीम में क्या फर्क पड़ता है। मुझे विशेष रूप से याद आया:

"एक अच्छी कंपनी ऐसे लोगों से भरी होती है जो कहते हैं कि" मुझे नहीं पता। "

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

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

एक और विचार जो मुझे सही लगता है: एक कंपनी में संस्कृति के निर्माण का कोई एक सच्चा सूत्र नहीं है।

“किसी भी संस्कृति को आदर्श नहीं कहा जा सकता है। और किसी एक संस्कृति को पूर्ण विफलता नहीं कहा जा सकता है। ”

हाल की प्रवृत्ति: अधिक से अधिक सम्मेलनों में प्रबंधन, संचार, टीम निर्माण और संस्कृति पर रिपोर्ट शामिल हैं। DevOops कोई अपवाद नहीं था। मेरा मानना ​​है कि यह एक सकारात्मक प्रवृत्ति है, क्योंकि इन कारकों का तकनीकी कठिनाइयों की तुलना में अंतिम परिणाम पर अधिक प्रभाव पड़ता है।

"नेता टीम का प्रबंधन नहीं करता है, लेकिन इसे बढ़ता है।"

इसे कोड में करें (YAML नहीं)! कुबरनेट्स (विक्टर गामो, कंफ्लुएंट, और फेडर कोरोटकोव, सिरस लैब्स) के लिए कोटलिन डीएसएल की बिजली अनलॉक करें।

अर्ध-अंतिम संस्कार की रिपोर्ट, लेकिन यह पूरी तरह से अंतहीन YAML फाइलें, उनके समर्थन और (ओह, हॉरर!) एक त्रुटि या टाइपो के मामले में डीबग लिखने के दर्द को व्यक्त करता है। यहां तक ​​कि यह YAML इंजीनियर के अलग-अलग पदों के उभरने का कारण बना।

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

रिपोर्ट के लेखकों ने सोचा और कहा: "कंज़र्वेटरी में कुछ गलत है।"

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

रिपोर्ट का मुख्य आकर्षण कुबेरनेट्स के लिए एक अमान्य कॉन्फ़िगरेशन का अपलोड था, जिसके लिए उन्होंने शांति से उत्तर दिया: बहुत अधिक त्रुटियां ।

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

पाइपलाइन और फली: कुबेरनेट्स के साथ देवोप्स (बरटर, रेड हैट)

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

लेकिन StringBuilder का उपयोग करके जावा कोड से JSON बनाने के लिए किसी तरह बहुत ज्यादा है। यहां तक ​​कि यह देखते हुए कि यह एक डेमो प्रोजेक्ट है।

DevOps प्रैक्टिस में निरंतर अपडेट के पैटर्न और एंटीपैर्टेन (बारूक सडोगर्स्की, जेफ्रॉग)

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

विशेष रूप से इस रिपोर्ट से मुझे कहानी याद आ गई, जब तैनाती प्रक्रिया में एक त्रुटि के कारण, नाइट कैपिटल ग्रुप ने 45 मिनट में $ 440,000,000 खो दिए और दिवालिया हो गया।

अंत में, बारूक ने एयरबस ए 350 सॉफ्टवेयर में एक बग के बारे में एक कहानी बताई। इस बग की वजह से एयरलाइंस को हर 149 घंटे में विमान को फिर से चालू करने के लिए मजबूर होना पड़ा, और इसके लिए इसे जमीन पर लगाना पड़ा। और अगर कोई ऐसा करना भूल जाता है, तो विमान जम जाएगा। इस तरह के एक अप्रिय बग। समस्या सरल है - कोड में अतिप्रवाह होता है। फिक्स भी सरल है। लेकिन मान लीजिए कि वे अभी भी विमान को फिर से शुरू करना भूल गए, तो लॉस एंजिल्स → लंदन की उड़ान पर उतर गया और लैंडिंग से 3 घंटे पहले, पायलटों ने महसूस किया कि एक घंटे में विमान जम जाएगा। "ह्यूस्टन, हमें एक समस्या है।" "अब हम इसे ठीक करते हैं!" डिस्पैचर्स ने जवाब दिया, एयरबस प्रोग्रामर्स को इकट्ठा किया, इसे ठीक किया, सब कुछ काम करता है। आगे क्या करना है? हवाई जहाज पर एक नया संस्करण तैनात करें? या जोखिम नहीं लेते? बारूक निर्धारित किया गया था: “तैनात करें। यह कोई बुरा नहीं होगा। ”

दूसरा दिन

एक कोड के रूप में सीडीके और बुनियादी ढांचा (सर्गेई कुर्सन, एडब्ल्यूएस)

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

हमें सेवा छलनी की आवश्यकता क्यों है? (एंटोन वीस, ओटोमेटो सॉफ्टवेयर)

शायद इस सम्मेलन की सबसे अच्छी और गहरी रिपोर्ट में से एक। "सेवा छलनी" द्वारा एक वक्ता का अर्थ है एक सेवा जाल - बादल बुनियादी ढांचे की एक अलग परत जो आपस में सेवाओं के संचार को नियंत्रित करती है। सेवा जाल पैटर्न सेवा स्तर से कई कार्यों को दर्शाता है (यानी, एप्लिकेशन डेवलपर से) सेवा चलनी स्तर पर ही (DevOps पर):

• सुरक्षा प्रबंधन;
• यातायात की निगरानी;
• यातायात प्रबंधन।

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

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

इंटरनेट अनुरोध और शांति से सोते हुए तेजी (सर्गेई फेडोरोव, नेटफ्लिक्स)

सर्गेई नेटफ्लिक्स में यह सुनिश्चित करने के लिए काम करता है कि सेवा अंत उपयोगकर्ताओं के लिए जितनी जल्दी हो सके काम करती है। इसमें सभी अनुरोध दो बड़े समूहों में विभाजित हैं:

• क्लाउड अनुरोध (गतिशीलता);
• CDN क्वेरी (स्थिर)।

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

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

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

तकनीकी चुनौतियों से पीछे नहीं हटने का यह एक अच्छा उदाहरण है। आपको साहसी होने और एक समझौता विकल्प चुनने की आवश्यकता है यदि यह उत्पाद को बेहतर बनाता है, और उपयोगकर्ताओं का जीवन आसान है।

क्यों आईटी उद्योग अंधेरे समय से गुजर रहा है, कैसे DevOps को दोष देना है, और क्यों पूंजी मदद कर सकती है (रोमन Shaposhnik, ZEDEDA Inc.)

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

DevOops विकास के बारे में है

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