DevOpsForum 2019। नियत DevOps इंतजार नहीं कर सकता

मैं हाल ही में लॉगऑनक द्वारा होस्ट किए गए DevOpsForum 2019 का दौरा किया। इस सम्मेलन में, प्रतिभागियों ने विकास और सूचना प्रौद्योगिकी सेवाओं में व्यापार और विशेषज्ञों की प्रभावी बातचीत के लिए समाधान और नए उपकरण खोजने की कोशिश की।



सम्मेलन एक सफलता थी: वास्तव में बहुत सारी उपयोगी रिपोर्टें, दिलचस्प प्रस्तुति प्रारूप और वक्ताओं के साथ बहुत सारे संचार थे। और यह विशेष रूप से महत्वपूर्ण है कि किसी ने मुझे कुछ भी बेचने की कोशिश नहीं की, बड़े सम्मेलनों में वक्ताओं ने हाल ही में दोषी ठहराया है।

Raiffeisenbank के भाषणों से निचोड़, Alfastrakhovanie, स्वचालन के कार्यान्वयन में मैंगो टेलीकॉम का अनुभव और कटौती के तहत अन्य विवरण।

मेरा नाम याना है, मैं एक परीक्षक के रूप में काम करता हूं, मैं स्वचालन में संलग्न हूं, साथ ही साथ DevOps और मुझे सम्मेलनों और बैठकों में जाना पसंद है। पिछले दो वर्षों में, मैं ओलेग ब्यून के सम्मेलनों (हाईलाड ++, टीमलाइड कॉन्फ), जुग इवेंट्स (हाइजेनबग, जेपॉइंट), टेस्टकॉन मॉस्को, डेवॉप्स प्रो मॉस्को, बिग डेटा मॉस्को में गया हूं।

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

Raiffeisenbank में पाइपलाइन के अंत में प्रकाश

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


^{मिखाइल बिशन, राइफेनबैंक में ऑटोमेशन के निदेशक}

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

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

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

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

मैंगो टेलीकॉम में टेस्ट ऑटोमेशन

मैंगो टेलीकॉम के येगोर मास्लोव ने एक परीक्षक के रूप में मेरे लिए एक और दिलचस्प रिपोर्ट बनाई। प्रस्तुति को "SCRUM टीम में पूर्ण परीक्षण चक्र का स्वचालन" कहा जाता था। Egor का मानना ​​है कि DevOps विशेष रूप से SCRUM के लिए बनाया गया था, लेकिन साथ ही, DevOps को SCRUM टीम में पेश करना काफी समस्याग्रस्त है। ऐसा इसलिए है क्योंकि SCRUM टीम हमेशा कहीं न कहीं भाग रही है, नवाचारों से विचलित होने और प्रक्रिया के पुनर्निर्माण का कोई समय नहीं है। यह समस्या इस तथ्य में भी निहित है कि SCRUM उप-टीमों (परीक्षकों, विकास टीम, आदि की टीम) का अर्थ नहीं है। ठीक है, इसके अलावा, मौजूदा प्रक्रिया को स्वचालित करने के लिए दस्तावेज़ीकरण की आवश्यकता होती है, और SCRUM में सबसे अधिक बार कोई प्रलेखन नहीं होता है - "किसी उत्पाद की तुलना में कुछ अधिक महत्वपूर्ण है"।

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

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

मैंने यह भी देखा कि आयोजकों ने छोटी रिपोर्टों की एक धारा बनाई। प्रत्येक रिपोर्ट 10 मिनट से अधिक नहीं रहती है, फिर प्रश्न आते हैं। इस प्रकार, आप एक ही बार में कई विषयों को कवर कर सकते हैं और उन वक्ताओं को प्रश्न पूछ सकते हैं जो रुचि रखते हैं।

---

^{रिपोर्टों के बीच, मैं सम्मेलन के भागीदारों के स्टैंड के आसपास चला गया और बहुत सारे सामान खींच / जीत लिया। एह, मैं razdatku प्यार करता हूँ!}

गोलमेज और DevOps के साथ Alfastrah विकास निदेशक के प्रश्न

मेरे लिए DevOpsForum 2019 केक पर चेरी, DevOps विशेषज्ञों के साथ एक घंटे का पूर्ण सत्र था। चार प्रतिभागियों को अलग-अलग कोणों से DevOps देखने के लिए आमंत्रित किया गया: एंटोन इसानिन (अलिफ़्रात्रोवैनी, डेवलपमेंट डायरेक्टर), नैला ज़माशकिना (फिनटेक लैब, ऑपरेशंस डायरेक्टर), ओलेग एगोरकिन (रोस्टेलकॉम, एजाइल-कोच) और एंटोन मार्टेनोव (स्वतंत्र विशेषज्ञ, एक व्यावसायिक दृष्टिकोण से DevOps को देखा)।

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

फिर, मैंने एंटोन इसानिन के साथ व्यक्तिगत रूप से बात की। हमने हर घर में DevOps संस्कृति लाने की आवश्यकता पर चर्चा की और DevOps रूपांतरण के अंधेरे पक्ष का खुलासा किया।

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

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