DevOpsForum 2019. तुम्ही DevOps लागू करण्यासाठी प्रतीक्षा करू शकत नाही

Logrocon द्वारे होस्ट केलेल्या DevOpsForum 2019 मध्ये मी अलीकडेच उपस्थित होतो. या परिषदेत, सहभागींनी व्यवसाय आणि विकास आणि माहिती तंत्रज्ञान सेवा विशेषज्ञ यांच्यातील प्रभावी संवादासाठी उपाय आणि नवीन साधने शोधण्याचा प्रयत्न केला.

परिषद यशस्वी ठरली: खरोखर बरेच उपयुक्त अहवाल, मनोरंजक सादरीकरण स्वरूप आणि स्पीकर्सशी भरपूर संवाद होता. आणि हे विशेषतः महत्वाचे आहे की कोणीही मला काहीही विकण्याचा प्रयत्न केला नाही, ज्यासाठी मोठ्या कॉन्फरन्समधील वक्ते अलीकडे दोषी आहेत.

Raiffeisenbank, Alfastrakhovanie, Mango Telecom चा ऑटोमेशन आणि कट अंतर्गत इतर तपशीलांच्या अंमलबजावणीतील अनुभवाच्या भाषणांचा एक उतारा.

माझे नाव याना आहे, मी परीक्षक म्हणून काम करतो, मी ऑटोमेशन तसेच DevOps करतो आणि मला कॉन्फरन्स आणि मीटअपमध्ये जायला आवडते. गेल्या दोन वर्षांत, मी ओलेग बुनिनच्या कॉन्फरन्सेस (HighLoad++, TeamLead Conf), Jug इव्हेंट्स (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow येथे गेलो आहे.

सर्वप्रथम, मी परिषदेच्या कार्यक्रमाकडे लक्ष वेधतो. अहवाल काय असेल याकडे मी कमी आणि स्पीकरकडे जास्त पाहतो. जरी अहवाल अतिशय तांत्रिक आणि मनोरंजक असल्याचे निष्पन्न झाले तरीही, हे तथ्य नाही की तुम्ही तुमच्या कंपनीतील अहवालातील काही सर्वोत्तम पद्धती लागू करू शकाल. आणि मग तुम्हाला स्पीकरची गरज आहे.

रायफिसेनबँक येथे पाइपलाइनच्या शेवटी प्रकाश

सहसा, मी माझ्या आवडीच्या स्पीकर्सची शोधाशोध करतो. DevOpsForum 2019 मध्ये, Raiffeisenbank चे वक्ते, Mikhail Bizhan, यांनी माझी आवड जाणून घेतली. त्यांच्या भाषणादरम्यान, त्यांनी हळूहळू त्यांच्या संघांना DevOps वर कसे जोडले जात आहे, त्यांना याची आवश्यकता का आहे आणि DevOps परिवर्तनाची कल्पना व्यवसायात कशी विकायची याबद्दल बोलले. बरं, सर्वसाधारणपणे, मी पाइपलाइनच्या शेवटी प्रकाश कसा पाहायचा याबद्दल बोललो.

मिखाईल बिझान, रायफिसेनबँकचे ऑटोमेशन संचालक

आता त्यांच्या कंपनीत "DevOps" नाहीत. म्हणजेच, तो कार्य करतो, परंतु सर्व संघांमध्ये नाही. DevOps कार्यान्वित करताना, ते विशिष्ट अभियंत्यांच्या दृष्टीने आणि उत्पादनाची आवश्यकता आणि हे उत्पादन ज्या प्लॅटफॉर्मवर तयार केले आहे त्या प्लॅटफॉर्मची परिपक्वता या दोन्ही बाबतीत ते संघांच्या तयारीवर अवलंबून असतात. मिशाने व्यवसायाला DevOps का आवश्यक आहे हे कसे समजावे हे सांगितले.

बँकिंग विभागामध्ये अनेक वाढीचे चालक आहेत: सेवांची किंमत आणि क्लायंट बेसचा विस्तार. सेवांची किंमत वाढवणे हे फार चांगले ड्रायव्हर नाही, परंतु क्लायंट बेस वाढवणे उलट आहे. जर स्पर्धकांनी वस्तुनिष्ठपणे छान उत्पादन सोडले, तर सर्व ग्राहक तेथे जातात, नंतर कालांतराने बाजाराची पातळी खाली येते. म्हणून, नवीन उत्पादने बाजारात आणणे आणि त्यांच्या परिचयाची गती ही मुख्य गोष्ट आहे ज्यावर बँकांचे लक्ष आहे. DevOps साठी नेमके हेच आहे आणि व्यवसायांना हे समजते.

पुढील महत्त्वाची टीप: DevOps नेहमी बाजारासाठी वेळ कमी करत नाही. DevOps एकट्याने काम करू शकत नाही, हे उत्पादन तयार करणे आणि विकासापासून उत्पादनापर्यंत (कोडपासून ग्राहकापर्यंत) बाजारात आणण्याच्या प्रक्रियेचा एक भाग आहे. परंतु कोडपूर्वीची प्रत्येक गोष्ट थेट DevOps शी संबंधित नाही. म्हणजेच, मार्केटर वर्षानुवर्षे बाजाराचा अभ्यास करू शकतात आणि त्यांचे संपूर्ण आयुष्य स्पर्धकांना पकडण्यात घालवू शकतात. क्लायंटला काय आवश्यक आहे हे त्वरीत समजून घेणे आणि या किंवा त्या वैशिष्ट्याच्या अंमलबजावणीची योजना करणे आवश्यक आहे - बहुतेकदा हेच आहे जे DevOps कार्य करण्यासाठी आणि कंपनीला त्याचे ध्येय साध्य करण्यासाठी पुरेसे नसते. म्हणून, सर्वप्रथम, Raiffeisenbank ने व्यवसायाशी सहमती दर्शविली की DevOps कसे वापरायचे हे शिकणे आवश्यक आहे. ऑटोमेशनच्या फायद्यासाठी नवीन ग्राहकांच्या लढ्यात फारसा मदत होणार नाही.

सर्वसाधारणपणे, मिशाचा असा विश्वास आहे की DevOps ची अंमलबजावणी करणे आवश्यक आहे, परंतु हुशारीने. आणि आपण या वस्तुस्थितीसाठी तयार असले पाहिजे की परिवर्तनाच्या सुरूवातीस संघाची उत्पादकता कमी होईल, ते कमी पैसे कमवेल, परंतु नंतर ते न्याय्य होईल.

मँगो टेलिकॉमवर चाचणीचे ऑटोमेशन

परीक्षक म्हणून माझ्यासाठी आणखी एक मनोरंजक अहवाल मँगो टेलिकॉमच्या एगोर मास्लोव्हने दिला. सादरीकरणाला "SCRUM टीममधील पूर्ण चाचणी चक्राचे ऑटोमेशन" असे म्हटले गेले. एगोरचा असा विश्वास आहे की DevOps विशेषतः SCRUM साठी तयार केले गेले होते, परंतु त्याच वेळी, DevOps ला SCRUM टीममध्ये सादर करणे खूप समस्याप्रधान आहे. असे घडते कारण SCRUM टीम नेहमी कुठेतरी धावत असते, नवनवीन शोधांमुळे विचलित होण्याची आणि प्रक्रिया पुन्हा तयार करण्याची वेळ नसते. SCRUM मध्ये संघातील उप-संघ (चाचणी संघ, विकास संघ आणि असेच) वेगळे करणे समाविष्ट नाही या वस्तुस्थितीतही समस्या आहे. बरं, याशिवाय, विद्यमान प्रक्रिया स्वयंचलित करण्यासाठी, दस्तऐवजीकरण आवश्यक आहे आणि SCRUM मध्ये, बहुतेकदा कोणतेही दस्तऐवज पूर्णपणे नसतात - "उत्पादन हे काही प्रकारच्या लेखनापेक्षा अधिक महत्वाचे आहे."

SCRUM वर स्विच केल्यानंतर, परीक्षकांनी वैशिष्ट्यांची चाचणी कशी करावी याबद्दल विकसकांशी सल्लामसलत करण्यास सुरुवात केली. हळूहळू, कार्यक्षमतेचे प्रमाण वाढले, कोणतेही दस्तऐवजीकरण नव्हते आणि त्यांनी कार्यक्षमतेमध्ये बरेच बग पकडण्यास सुरुवात केली जी चाचण्यांमध्ये समाविष्ट नव्हती आणि सर्वसाधारणपणे ते कोणी आणि केव्हा तपासले हे आता स्पष्ट होत नाही. थोडक्यात - गोंधळ आणि अस्थिरता. आम्ही चाचणी ऑटोमेशनवर स्विच करण्याचा निर्णय घेतला. मात्र त्यानंतरही पूर्ण अपयश आले. त्यांनी आउटसोर्स ऑटोमेशन तज्ञांना नियुक्त केले ज्यांनी इन-हाउस टेस्टर्सना अज्ञात स्टॅकवर लिहिले. ऑटोटेस्ट्सच्या फ्रेमवर्कने नक्कीच काम केले, परंतु आउटसोर्सर निघून गेल्यानंतर, ते दोन आठवडे चालले. पुढे ऑटोटेस्टिंग नंबर दोन सादर करण्याचा प्रयत्न होता. याची सुरुवात या वस्तुस्थितीपासून झाली की प्रत्येक गोष्ट कंपनीमध्ये, तुमच्या स्वतःवर (योग्य वेक्टर: अंतर्गत कौशल्य तयार करणे), SCRUM च्या चौकटीत तयार करणे आणि प्रक्रियेत दस्तऐवजीकरण तयार करणे आवश्यक आहे. ऑटोमेशनसाठीचा स्टॅक उत्पादनाच्या स्टॅकच्या बरोबरीचा असावा (येथे मी ते जोडत आहे, तुमच्या JavaScript प्रोजेक्टची इतर कोणत्याही गोष्टीसह चाचणी करू नका). स्प्रिंटच्या शेवटी, त्यांनी संपूर्ण टीमसह ऑटोटेस्ट कशी कार्य करते याचा डेमो केला (उपयुक्त). अशा प्रकारे, ऑटोमेशन प्रक्रियेत सर्व कार्यसंघ सदस्यांचा सहभाग वाढला, तसेच ऑटोटेस्टवर विश्वास आणि ही ऑटोटेस्ट निश्चितपणे वापरली जाण्याची शक्यता वाढली (आणि सततच्या अपयशामुळे एका महिन्यात टिप्पणी दिली जाणार नाही).

तसे, DevOpsForum 2019 मध्ये एक खुला मायक्रोफोन होता - एक दीर्घ-प्रसिद्ध आणि, माझ्या मते, भाषणांचे उपयुक्त स्वरूप. तुम्ही असे फिरता, अहवाल ऐका आणि मग ठरवा की कॉन्फरन्समध्ये एखाद्या विशिष्ट विषयावर किंवा समस्येवर चर्चा करणे, समस्येचे निराकरण करण्यासाठी संबंधित अनुभव सामायिक करणे योग्य आहे.

आयोजकांनी छोटे छोटे अहवाल तयार केल्याचेही माझ्या लक्षात आले. प्रत्येक अहवाल 10 मिनिटांपेक्षा जास्त काळ टिकत नाही, त्यानंतर प्रश्न येतात. अशा प्रकारे तुम्ही एकाच वेळी अनेक विषय कव्हर करू शकता आणि तुम्हाला स्वारस्य असलेल्या स्पीकर्सना प्रश्न विचारू शकता.

सादरीकरणांदरम्यान, मी कॉन्फरन्स पार्टनर्सच्या बूथभोवती फिरलो आणि बरीच सामग्री चोरली/ जिंकली. अरे, मला हँडआउट आवडते!

Alfastrakhovanie येथे विकास संचालकांसह गोल टेबल आणि DevOps समस्या

माझ्यासाठी DevOpsForum 2019 केकवरील आयसिंग हे DevOps तज्ञांसह तासभराचे पूर्ण सत्र होते. चार सत्रातील सहभागींना वेगवेगळ्या कोनातून DevOps पाहण्यासाठी आमंत्रित केले होते: अँटोन इसानिन (अल्फास्ट्राखोवानी, विकास संचालक), नैल्या झामाश्किना (फिनटेक लॅब, ऑपरेटिंग डायरेक्टर), ओलेग एगोरकिन (रोस्टेलेकॉम, चपळ प्रशिक्षक) आणि अँटोन मार्त्यानोव्ह (स्वतंत्र तज्ञ, DevOps कडे पाहिले. व्यवसायाच्या दृष्टिकोनातून).

तज्ञ लोकांच्या जवळ बसले आणि नंतर गोष्टी घडू लागल्या: संपूर्ण तासभर, प्रेक्षकांमधील सहभागींनी त्यांचे प्रश्न विचारले आणि तज्ञांनी रॅप घेतला. कधी कधी खऱ्या वादविवादही व्हायचे. प्रश्न खूप भिन्न होते, उदाहरणार्थ: DevOps अभियंत्यांची अजिबात गरज आहे का, त्यांना सिस्टम प्रशासक म्हणून प्रशिक्षित का केले जाऊ शकत नाही, DevOps प्रत्येकासाठी ऑफर केले जावे, त्याचे मूल्य काय आहे इत्यादी.

मग, मी अँटोन इसानिनशी वैयक्तिकरित्या बोललो. आम्ही प्रत्येक घरात DevOps संस्कृती आणण्याच्या गरजेवर चर्चा केली आणि DevOps परिवर्तनाची काळी बाजू उघड केली.

चला अशी कल्पना करूया की सर्वांनी एकत्र येऊन निर्णय घेतला की DevOps ची उत्पादनासाठी आणि व्यवसायासाठी आणि टीमला आवश्यक आहे. चला ते अंमलात आणूया. सर्व काही पार पडले. आम्ही श्वास सोडला. DevOps ने आम्हाला क्लायंटच्या जवळ आणले आहे, आता आम्ही त्याच्या सर्व इच्छा त्वरीत पूर्ण करू शकतो. परिणामी, आमच्याकडे कठोर नियम आणि आवश्यकता असलेला एक मोठा Ops विभाग आहे आणि तो सतत उत्पादनात दोष शोधतो आणि विनंत्यांचा समूह तयार करतो. शिवाय, सर्व दोषांना "तातडीची" स्थिती नियुक्त केली जाते, जरी क्लायंटला अनपेक्षितपणे बटण हिरव्याऐवजी पिवळे रंगवायचे असेल. प्रकल्प वाढत आहे, रिलीझची संख्या वाढत आहे आणि त्यानुसार, क्लायंटद्वारे नवीन कार्यक्षमतेचे दोष आणि गैरसमजांची संख्या. Ops अहवाल दोषांची माहिती ठेवण्यासाठी आणखी 10 लोकांना कामावर घेते आणि त्यांना बंद करणे सुरू ठेवण्यासाठी विकास आणखी 15 लोकांना कामावर घेते. आणि नवीन वैशिष्‍ट्ये सादर करण्‍याऐवजी, टीम अंतहीन SD सह कार्य करते, वापरकर्त्याला कार्यक्षमता आणि समर्थन एकाच वेळी समजावून सांगते. परिणामी, Ops आणि विकास दोन्ही काम करत आहेत, परंतु क्लायंट आणि व्यवसाय नाखूष आहेत: नवीन वैशिष्ट्ये अडकतात. असे दिसून आले की DevOps अस्तित्त्वात आहे असे दिसते, परंतु ते अस्तित्वात असल्याचे दिसत नाही.

DevOps लागू करण्याच्या गरजेबद्दल, अँटोनने स्पष्टपणे सांगितले की हे थेट व्यवसायाच्या प्रमाणात अवलंबून असते. वर्षातून एका क्लायंटला सेवा दिल्यास कंपनीला अब्जावधी मिळत असल्यास, DevOps ची गरज नाही (परंतु तुम्हाला या क्लायंटमध्ये नियमितपणे नवीन बदल करण्याची आवश्यकता नाही). सर्व काही चॉकलेटमध्ये झाकलेले आहे. परंतु जर व्यवसाय वाढला आणि अधिक ग्राहक दिसले तर तुम्हाला त्याचे पालन करणे आवश्यक आहे. नियमानुसार, कंपनीमध्ये सुरुवातीला कोणतेही कूल ऑप्स नाहीत. प्रथम आम्ही उत्पादन कापतो आणि त्यानंतरच आम्हाला समजते की उत्पादन कार्य करण्यासाठी, आम्हाला सर्व्हरवर लक्ष ठेवणे आणि पुरवठ्याचे निरीक्षण करणे आवश्यक आहे. तेव्हा ऑप्स अस्तित्वात येतात. हे समजून घेणे बाकी आहे की Ops, एक स्वतंत्र विभाग म्हणून, विकासामध्ये अनेक अडथळे आणण्यास सुरवात करेल आणि सर्व वितरणे थांबण्यास सुरवात होईल. म्हणजेच, या प्रकरणात, DevOps संस्कृती आधीपासूनच संबंधित आहे, परंतु आपण तिच्या गडद बाजूबद्दल विसरू नये.

स्त्रोत: www.habr.com