DevOpsForum 2019। तपाईं DevOps लागू गर्न पर्खन सक्नुहुन्न

मैले भर्खरै Logrocon द्वारा होस्ट गरिएको DevOpsForum 2019 मा भाग लिएको छु। यस सम्मेलनमा, सहभागीहरूले व्यापार र विकास र सूचना प्रविधि सेवा विशेषज्ञहरू बीच प्रभावकारी अन्तरक्रियाको लागि समाधान र नयाँ उपकरणहरू खोज्ने प्रयास गरे।

सम्मेलन सफल भयो: त्यहाँ वास्तवमै धेरै उपयोगी रिपोर्टहरू, रोचक प्रस्तुतीकरण ढाँचाहरू र वक्ताहरूसँग धेरै सञ्चार थिए। र यो विशेष गरी महत्त्वपूर्ण छ कि कसैले मलाई केहि बेच्ने प्रयास गरेन, ठूला सम्मेलनहरूमा वक्ताहरू हालसालै दोषी ठहरिएका छन्।

Raiffeisenbank, Alfastrakhovanie, Mango Telecom को स्वचालन र कटौती अन्तर्गत अन्य विवरणहरू लागू गर्ने अनुभवका भाषणहरूबाट एक अंश।

मेरो नाम याना हो, म परीक्षकको रूपमा काम गर्छु, म स्वचालन गर्छु, साथै DevOps पनि गर्छु, र मलाई सम्मेलन र भेटघाटहरूमा जान मन पर्छ। विगत दुई वर्षमा, म ओलेग बुनिनको सम्मेलनहरू (HighLoad++, TeamLead Conf), Jug Events (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow मा गएको छु।

सर्वप्रथम, म सम्मेलन कार्यक्रममा ध्यानाकर्षण गर्दछु। म प्रतिवेदन के हुनेछ भनेर कम हेर्छु, र स्पिकरमा बढी। यदि रिपोर्ट धेरै प्राविधिक र चाखलाग्दो देखिए पनि, यो तथ्य होइन कि तपाइँ तपाइँको कम्पनीमा रिपोर्टबाट केहि उत्कृष्ट अभ्यासहरू लागू गर्न सक्षम हुनुहुनेछ। र त्यसपछि तपाईलाई स्पिकर चाहिन्छ।

Raiffeisenbank मा पाइपलाइनको अन्त्यमा प्रकाश

सामान्यतया, म छेउमा वक्ताहरूको खोजी गर्छु जसले मलाई चासो दिन्छ। DevOpsForum 2019 मा, Raiffeisenbank का एक वक्ता, Mikhail Bizhan ले मेरो चासो लिए। आफ्नो भाषणको क्रममा, उनले कसरी उनीहरूको टोलीहरू बिस्तारै DevOps मा जोडिँदैछन्, किन तिनीहरूको आवश्यकता छ, र कसरी व्यापारमा DevOps रूपान्तरणको विचार बेच्ने बारे कुरा गरे। खैर, सामान्यतया, मैले पाइपलाइनको अन्त्यमा कसरी प्रकाश हेर्ने बारे कुरा गरें।

मिखाइल बिझान, Raiffeisenbank मा स्वचालन निर्देशक

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

बैंकिङ खण्डमा धेरै वृद्धि चालकहरू छन्: सेवाहरूको लागत र ग्राहक आधारको विस्तार। सेवाहरूको लागत बढाउनु धेरै राम्रो ड्राइभर होइन, तर ग्राहक आधार बढाउनु उल्टो छ। यदि प्रतिस्पर्धीहरूले वस्तुगत रूपमा राम्रो उत्पादन जारी गरे, सबै ग्राहकहरू त्यहाँ जान्छन्, त्यसपछि समयसँगै बजार स्तर बाहिर जान्छ। त्यसकारण, बजारमा नयाँ उत्पादनहरू प्रस्तुत गर्नु र तिनीहरूको परिचयको गति मुख्य कुरा हो जुन बैंकहरूले ध्यान केन्द्रित गर्दछ। यो वास्तवमा DevOps को लागि हो, र व्यवसायहरूले यो बुझ्छन्।

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

सामान्यतया, मिशा विश्वास गर्छिन् कि DevOps लागू गर्न आवश्यक छ, तर बुद्धिमानीपूर्वक। र हामी यस तथ्यको लागि तयार हुनुपर्छ कि रूपान्तरणको सुरुमा टोलीको उत्पादकता घट्नेछ, यसले कम पैसा कमाउनेछ, तर त्यसपछि यो जायज हुनेछ।

Mango Telecom मा परीक्षण को स्वचालन

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

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

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

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

प्रस्तुतीकरणहरू बीच, म सम्मेलन साझेदारहरूको बुथ वरिपरि हिंडें र धेरै सामानहरू चोरे/जिते। ए, मलाई ह्यान्डआउट मन पर्छ!

Alfastrakhovanie मा विकास निर्देशक संग गोल तालिका र DevOps मुद्दाहरू

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

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

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

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

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

स्रोत: www.habr.com