DevOpsForum 2019. आप DevOps को लागू करने के लिए इंतजार नहीं कर सकते

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

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

कट के तहत स्वचालन और अन्य विवरणों को लागू करने में रायफिसेनबैंक, अल्फ़ास्ट्राखोवानी, मैंगो टेलीकॉम के भाषणों का एक अंश।

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

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

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

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

मिखाइल बिज़ान, राइफ़ेसेनबैंक में स्वचालन के निदेशक

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

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

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

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

मैंगो टेलीकॉम में परीक्षण का स्वचालन

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

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

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

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

प्रस्तुतियों के बीच, मैं सम्मेलन भागीदारों के बूथों पर घूमा और बहुत सारा सामान चुराया/जीत लिया। ओह, मुझे हैंडआउट पसंद है!

अल्फ़ास्ट्राखोवानी में विकास निदेशक के साथ गोलमेज और डेवऑप्स मुद्दे

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

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

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

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

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

स्रोत: www.habr.com