DevOps के हो

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

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

कुनै बेला म मर्जर र एक्विजिसनको लहरमा सवार थिएँ । पहिले, मैले Qik भनिने एउटा सानो स्टार्टअपको लागि काम गरें, त्यसपछि यो Skype भनिने अलिकति ठूलो कम्पनीले किनेको थियो, जुन त्यसपछि माइक्रोसफ्ट नामको अलि ठूलो कम्पनीले किनेको थियो। त्यस क्षणमा, मैले विभिन्न आकारका कम्पनीहरूमा DevOps को विचार कसरी रूपान्तरण हुँदैछ भनेर हेर्न थालें। त्यस पछि, मलाई बजारको दृष्टिकोणबाट DevOps हेर्ने रुचि बढ्यो, र मेरा सहकर्मीहरू र मैले एक्सप्रेस 42 कम्पनीको स्थापना गरेका थियौं। 6 वर्षदेखि हामी बजारको लहरहरूसँगै अघि बढिरहेका छौं।

अन्य चीजहरू मध्ये, म DevOps Moscow समुदायको आयोजक र DevOps-Days 2017 को आयोजक हुँ, तर मैले 2018 को आयोजना गरिन। एक्सप्रेस 42 धेरै कम्पनीहरु संग काम गर्दछ। हामी त्यहाँ DevOps बढाउँछौं, यो कसरी हुन्छ हेर्नुहोस्, निष्कर्ष निकाल्नुहोस्, विश्लेषण गर्नुहोस्, सबैलाई हाम्रो निष्कर्ष बताउनुहोस्, र मानिसहरूलाई DevOps अभ्यासहरूमा तालिम दिनुहोस्। सामान्यतया, हामी यस सम्बन्धमा हाम्रो अनुभव र विशेषज्ञता बढाउन सक्दो प्रयास गरिरहेका छौं।

किन DevOps

पहिलो प्रश्न जसले सबैलाई सताउँछ र सधैं यो हो - किन? धेरै मानिसहरू सोच्छन् कि DevOps केवल स्वचालन वा समान चीज हो जुन प्रत्येक कम्पनी पहिले नै थियो।

— हामीसँग निरन्तर एकीकरण थियो - यसको मतलब हामीसँग पहिले नै DevOps छ, र किन यी सबै सामानहरू आवश्यक छ? तिनीहरू विदेशमा रमाइलो गर्दैछन्, तर तिनीहरूले हामीलाई काम गर्नबाट रोकिरहेका छन्!

समुदाय र पद्धतिको विकासको 9 वर्ष भन्दा बढी, यो पहिले नै स्पष्ट भएको छ कि यो अझै पनि मार्केटिङ चमक छैन, तर यो अझै पनि पूर्ण रूपमा स्पष्ट छैन किन यो आवश्यक छ। कुनै पनि उपकरण र प्रक्रिया जस्तै, DevOps सँग विशेष लक्ष्यहरू छन् जुन यसले अन्ततः प्राप्त गर्दछ।

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

सिद्धान्तमा, IT मा सबै कुरा यो दृष्टिकोण अनुसार निर्माण गर्नुपर्छ। यहाँ IT प्रक्रियाहरू स्वचालित रूपमा प्रयोग गरिन्छ।

स्वचालन प्रायः परिवर्तन हुँदैन, किनकि जब एक कम्पनी राम्रो तरिकाले ट्रोडेड रट तल जान्छ, त्यहाँ परिवर्तन गर्न के छ? यसले काम गर्छ - यसलाई नछुनुहोस्। अब संसारमा दृष्टिकोणहरू परिवर्तन हुँदैछन्, र एजाइल भनिने एउटाले सुझाव दिन्छ कि अन्तिम बिन्दु B तुरुन्तै देखिँदैन।

जब कम्पनी बजारमा जान्छ, ग्राहकसँग काम गर्दछ, यसले निरन्तर बजार अन्वेषण गर्दछ र अन्तिम बिन्दु B परिवर्तन गर्दछ। यसबाहेक, कम्पनीले जति धेरै पटक आफ्नो दिशा परिवर्तन गर्दछ, त्यो अन्तमा उति सफल हुन्छ, किनभने यसले धेरै बजार छान्छ। niches।

रणनीति एक रोचक कम्पनी द्वारा प्रदर्शन गरिएको छ जुन मैले भर्खरै बारे सिकेको छु। One Box Shave एउटा बक्समा रेजर र सेभिङ सामानहरूका लागि सदस्यता वितरण सेवा हो। उनीहरूलाई थाहा छ कसरी विभिन्न ग्राहकहरूको लागि आफ्नो "बक्स" अनुकूलित गर्ने। यो एक निश्चित सफ्टवेयर द्वारा गरिन्छ, जसले त्यसपछि सामान उत्पादन गर्ने कोरियाली कारखानामा अर्डर पठाउँछ।

यो उत्पादन युनिलिभरले १ अर्ब डलरमा किनेको थियो। यसले अब जिलेटसँग प्रतिस्पर्धा गर्छ र अमेरिकी बजारमा उपभोक्ताहरूको ठूलो हिस्सा खोसेको छ। एक बक्स दाढी भन्नुहोस्:

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

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

टाइम-टु-मार्केटको बिन्दु हामीले कति पटक प्रयोग गर्छौं भन्ने होइन। तपाइँ प्राय: डिप्लोय गर्न सक्नुहुन्छ, तर रिलीज चक्र लामो हुनेछ। यदि तीन-महिनाको रिलिज चक्रहरू एकअर्कामा सुपरइम्पोज गरिएको छ, तिनीहरूलाई एक हप्तामा सार्दै, यो बाहिर जान्छ कि कम्पनीले हप्तामा एक पटक तैनाथ गरेको देखिन्छ। र आइडियादेखि अन्तिम कार्यान्वयनसम्म ३ महिना लाग्छ ।

टाइम-टु-बजार भनेको आइडियादेखि अन्तिम कार्यान्वयनसम्मको समयलाई न्यूनीकरण गर्ने हो।

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

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

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

1968 मा, एक दूरदर्शी केटा, मेल्विन कोनवेले निम्न विचार तयार गरे।

संगठन जसले प्रणाली सिर्जना गर्दछ त्यो संगठनको सञ्चार संरचनालाई नक्कल गर्ने डिजाइनद्वारा सीमित हुन्छ।

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

पढ्नुहोस् Conway को कानून को बारे मा गर्न सक्छन् लिङ्कहरू मार्फत। यो DevOps संस्कृति वा दर्शन बुझ्नको लागि महत्त्वपूर्ण छ किनभने DevOps मा मौलिक रूपमा परिवर्तन हुने एक मात्र चीज टोलीहरू बीच सञ्चारको संरचना हो.

प्रक्रियाको दृष्टिकोणबाट, DevOps अघि, सबै चरणहरू: विश्लेषण, विकास, परीक्षण, सञ्चालन, रैखिक थिए।
DevOps को मामलामा, यी सबै प्रक्रियाहरू एकै साथ हुन्छन्।

टाइम-टु-बजार मात्र यो गर्न सकिन्छ। पुरानो प्रक्रियामा काम गर्ने व्यक्तिहरूका लागि, यो केहि हदसम्म ब्रह्माण्डीय देखिन्छ, र सामान्यतया यस्तै।

त्यसोभए तपाईलाई किन DevOps चाहिन्छ?

डिजिटल उत्पादन विकासको लागि। यदि तपाईंको कम्पनीसँग डिजिटल उत्पादन छैन भने, DevOps आवश्यक छैन - यो धेरै महत्त्वपूर्ण छ।

DevOps ले क्रमिक सफ्टवेयर उत्पादनको गति सीमितताहरू पार गर्दछ। यसमा सबै प्रक्रियाहरू एकैसाथ हुन्छन्।

कठिनाइ बढ्छ। जब DevOps प्रचारकहरूले तपाईंलाई सफ्टवेयर जारी गर्न सजिलो बनाउनेछ भनी बताउँछन्, यो बकवास हो।

DevOps को साथ, चीजहरू मात्र थप जटिल हुनेछन्।

Avito स्ट्यान्डको सम्मेलनमा, तपाईंले डकर कन्टेनर तैनाथ गर्न कस्तो थियो देख्न सक्नुहुन्छ - एक अवास्तविक कार्य। कठिनाई निषेधात्मक हुन्छ; तपाईंले एकै समयमा धेरै बलहरू जग्गल गर्नुपर्नेछ।

DevOps ले कम्पनीमा प्रक्रिया र संगठनलाई पूर्ण रूपमा परिवर्तन गर्दछ - अधिक स्पष्ट रूपमा, यो DevOps होइन जुन परिवर्तन हुन्छ, तर डिजिटल उत्पादन। DevOps मा आउन, तपाईंले अझै पनि यो प्रक्रिया पूर्ण रूपमा परिवर्तन गर्न आवश्यक छ।

एक विशेषज्ञ को लागी प्रश्न

तपाईंसँग के छ? कम्पनीमा काम गर्दा र विशेषज्ञको रूपमा विकास गर्दा आफैलाई सोध्न सक्ने प्रश्नहरू।

के तपाइँसँग डिजिटल उत्पादन सिर्जना गर्ने रणनीति छ? यदि त्यहाँ छ भने, त्यो पहिले नै राम्रो छ। यसको मतलब तपाईंको कम्पनी DevOps तर्फ सर्दैछ।

के तपाइँको कम्पनी पहिले नै डिजिटल उत्पादन सिर्जना गर्दै हुनुहुन्छ? यसको मतलब यो हो कि तपाईं अर्को स्तर माथि उठ्न सक्नुहुन्छ र चीजहरू अझ चाखलाग्दो रूपमा गर्न सक्नुहुन्छ - फेरि DevOps दृष्टिकोणबाट। म यो दृष्टिकोणबाट मात्र बोल्दै छु।

के तपाईंको कम्पनी डिजिटल उत्पादन आलामा बजार नेताहरू मध्ये एक हो? Spotify, Yandex, Uber अहिले प्राविधिक प्रगतिको शिखरमा रहेका कम्पनीहरू हुन्।

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

संगठन

मैले भनें, कन्वेको कानून अनुसार, कम्पनीको संगठन परिवर्तन हुन्छ। संगठनात्मक दृष्टिकोणबाट DevOps लाई कम्पनी भित्र प्रवेश गर्नबाट रोक्ने कुराबाट म सुरु गर्नेछु।

"इनार" को समस्या

अङ्ग्रेजी शब्द "Silo" लाई यहाँ रूसीमा "ठीक" रूपमा अनुवाद गरिएको छ। यो समस्याको पाटो यही हो टोलीहरू बीच कुनै सूचना आदान प्रदान छैन। प्रत्येक टोलीले नेभिगेट गर्नको लागि साझा नक्सा निर्माण नगरी आफ्नो विशेषज्ञतामा गहिरो खन्ने गर्छ।

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

DevOps ले यो विचलनको क्षणबाट गुज्रिरहेको सुझाव दिन्छ र सबै विभागहरू मिलेर एक साझा अन्तरक्रिया नक्शा निर्माण गर्न काम गरिरहेका छन्।

दुईवटा कारकले यसमा बाधा पु¥याउँछन् ।

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

तर सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि एक इन्जिनियरको लागि "इनार" को समस्या जो DevOps को भावना संग प्रभावित छ, Fowler र अन्य पुस्तकहरु को एक गुच्छा पढेको छ, यो तथ्य मा व्यक्त गरिएको छ। "कुवाहरू" ले तपाईंलाई "स्पष्ट" चीजहरू गर्न अनुमति दिँदैन। हामी अक्सर DevOps मस्को पछि सँगै हुन्छौं, एक अर्कासँग कुरा गर्छौं, र मानिसहरूले गुनासो गर्छौं:

- हामीले भर्खरै CI सुरु गर्न चाहन्थ्यौं, तर व्यवस्थापनलाई यसको आवश्यक पर्दैन भन्ने थाहा भयो।

यो ठीक कारणले हुन्छ CI и निरन्तर वितरण प्रक्रिया धेरै परीक्षाको सिमानामा छन्। केवल संगठनात्मक स्तरमा "कुवाहरू" को समस्या परास्त नगरी, तपाईं अगाडि बढ्न सक्षम हुनुहुने छैन, तपाईंले जे गरे पनि र जतिसुकै दुःखी किन नहोस्।

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

मानिसहरु कुनै न कुनै तारा वा झण्डाको लागि लडिरहेका छन्, सबैले आफ्नो विज्ञता खोजिरहेका छन्।

फलस्वरूप, जब यी सबैलाई जोडेर साझा पाइपलाइन बनाउने काम उठ्छ र तारा र झण्डाका लागि लडाइँ गर्नुपर्दैन, प्रश्न उठ्छ- हामीले के गर्ने? हामी कुनै न कुनै रूपमा सम्झौतामा आउन आवश्यक छ, तर कसैले हामीलाई स्कूलमा यो कसरी गर्ने भनेर सिकाएन। हामीलाई विद्यालयदेखि नै सिकाइएको छ: आठौं कक्षा - वाह! - सातौं कक्षाको तुलनामा! यहाँ पनि त्यस्तै छ।

के तपाईको कम्पनीमा पनि त्यस्तै छ?

यो जाँच गर्न, तपाईं आफैलाई निम्न प्रश्नहरू सोध्न सक्नुहुन्छ।

के टोलीहरूले साझा उपकरणहरू प्रयोग गर्छन् र ती साझा उपकरणहरूमा परिवर्तन गर्न योगदान गर्छन्?

टोलीहरू कति पटक पुनर्गठन गर्छन्—एउटा टोलीका केही विशेषज्ञहरू अर्को टोलीमा सर्छन्? यो एक DevOps वातावरणमा छ कि यो सामान्य हुन्छ, किनकि कहिलेकाहीँ एक व्यक्तिले मात्र विशेषज्ञताको अर्को क्षेत्र के गरिरहेको छ भनेर बुझ्न सक्दैन। ऊ अर्को विभागमा जान्छ, त्यहाँ दुई हप्ता काम गर्छ र यस विभागसँगको अभिमुखीकरण र अन्तरक्रियाको नक्सा बनाउँछ।

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

कम्पनीका उपलब्धिहरूलाई विचार नगरी व्यक्तिगत उपलब्धिहरू प्राप्त गर्नु व्यवस्थापकहरूको लागि कत्तिको महत्त्वपूर्ण छ?

यदि तपाइँ आफैले यी प्रश्नहरूको जवाफ दिनुभयो भने, यो तपाइँको कम्पनीमा यस्तो समस्या छ कि छैन स्पष्ट हुनेछ।

कोडको रूपमा पूर्वाधार

यो समस्या पारित भएपछि, पहिलो महत्त्वपूर्ण अभ्यास, जसको बिना DevOps मा अगाडि बढ्न गाह्रो छ कोडको रूपमा पूर्वाधार.

प्रायः, कोडको रूपमा पूर्वाधारलाई निम्नानुसार मानिन्छ:

— ब्याशमा सबै कुरा स्वचालित गरौं, आफैलाई स्क्रिप्टले कभर गरौं ताकि प्रशासकहरूसँग कम म्यानुअल काम होस्!

तर त्यो सत्य होइन।

कोडको रूपमा इन्फ्रास्ट्रक्चरको अर्थ हो कि तपाईले काम गर्ने IT प्रणालीलाई कोडको रूपमा यसको स्थिति निरन्तर बुझ्नको लागि वर्णन गर्नुहुन्छ।

अन्य टोलीहरूसँग मिलेर, तपाईंले कोडको रूपमा नक्सा सिर्जना गर्नुहुन्छ जुन सबैले बुझ्न सक्छन् र नेभिगेट गर्न र नेभिगेट गर्न सक्छन्। यसले के गरेको छ भन्ने कुराले फरक पार्दैन - शेफ, उत्तरदायी, नुन, वा Kubernetes मा YAML फाइलहरू प्रयोग गरेर - त्यहाँ कुनै फरक छैन।

सम्मेलनमा, 2GIS का एक सहकर्मीले बताए कि कसरी तिनीहरूले Kubernetes को लागि आफ्नै आन्तरिक चीज बनाए, जसले व्यक्तिगत प्रणालीहरूको संरचना वर्णन गर्दछ। 500 प्रणालीहरू वर्णन गर्न, तिनीहरूलाई यो विवरण उत्पन्न गर्ने छुट्टै उपकरण चाहिन्छ। जब यो विवरण हुन्छ, सबैले एक अर्कासँग जाँच गर्न सक्छन्, परिवर्तनहरू निगरानी गर्न सक्छन्, यसलाई कसरी परिवर्तन गर्ने र सुधार गर्ने, के छुटेको छ।

सहमत हुनुहुन्छ, व्यक्तिगत bash स्क्रिप्टहरूले सामान्यतया यो बुझाइ प्रदान गर्दैन। मैले काम गरेको एक कम्पनीमा, "केवल लेख्नुहोस्" लिपिको नाम पनि थियो - जब स्क्रिप्ट लेखिएको छ, तर अब यसलाई पढ्न सम्भव छैन। मलाई लाग्छ यो तपाईलाई पनि परिचित छ।

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

कोड उत्तम कोड अभ्यास अनुसार राखिएको छ: संयुक्त विकास, कोड समीक्षा, XP-प्रोग्रामिङ, परीक्षण, पुल अनुरोध, कोड पूर्वाधारहरूको लागि CI - यो सबै उपयुक्त छ र प्रयोग गर्न सकिन्छ।

कोड सबै इन्जिनियरहरूको लागि साझा भाषा हुन्छ।

कोडमा पूर्वाधार परिवर्तन गर्न धेरै समय लाग्दैन। हो, पूर्वाधार संहितामा प्राविधिक ऋण पनि हुन सक्छ। सामान्यतया टोलीहरूले यसको सामना डेढ वर्ष पछि तिनीहरूले "कोडको रूपमा पूर्वाधार" लाई स्क्रिप्टको गुच्छाको रूपमा वा Ansible को रूपमा लागू गर्न थालेपछि भेट्छन्, जुन तिनीहरूले स्पेगेटी कोड जस्तै लेख्छन्, र तिनीहरूले ब्यास लिपिहरू पनि मिश्रणमा फ्याँक्छन्!

महत्त्वपूर्ण: यदि तपाईंले अहिलेसम्म यो सामान प्रयास गर्नुभएको छैन भने, याद गर्नुहोस् उत्तरदायी कुरा होइन! कागजातहरू ध्यानपूर्वक पढ्नुहोस्, तिनीहरूले यसको बारेमा के लेख्छन् अध्ययन गर्नुहोस्।

कोडको रूपमा पूर्वाधार भनेको पूर्वाधार कोडलाई अलग-अलग तहहरूमा विभाजन गर्नु हो।

हाम्रो कम्पनीमा, हामी 3 आधारभूत तहहरू छुट्याउन सक्छौं, जुन धेरै स्पष्ट र सरल छन्, तर तिनीहरूमध्ये धेरै हुन सक्छन्। तपाईं आफ्नो पूर्वाधार कोड हेर्न सक्नुहुन्छ र तपाईंसँग यो अवस्था छ वा छैन भन्न सक्नुहुन्छ। यदि कुनै तहहरू हाइलाइट गरिएको छैन भने, तपाईंले केही समय र अलिकति रिफ्याक्टर लिन आवश्यक छ।


आधार तह - यो कसरी OS, ब्याकअप र अन्य निम्न-स्तर चीजहरू कन्फिगर गरिएको छ, उदाहरणका लागि, आधारभूत स्तरमा Kubernetes कसरी तैनात गरिन्छ।

सेवा स्तर - यी हुन् तपाईंले विकासकर्तालाई प्रदान गर्ने सेवाहरू: सेवाको रूपमा लगिङ, सेवाको रूपमा निगरानी, ​​सेवाको रूपमा डाटाबेस, सेवाको रूपमा ब्यालेन्सर, सेवाको रूपमा लाम, सेवाको रूपमा निरन्तर डेलिभरी - सेवाहरूको गुच्छा जुन व्यक्तिगत टोलीहरू विकास प्रदान गर्न सक्छ। यो सबै तपाइँको कन्फिगरेसन व्यवस्थापन प्रणाली मा अलग मोड्युल मा वर्णन गर्न आवश्यक छ।

तह जहाँ अनुप्रयोगहरू बनाइन्छ र तिनीहरू अघिल्लो दुई तहहरूको शीर्षमा कसरी प्रकट हुनेछन् भनेर वर्णन गर्दछ।

प्रश्नहरू नियन्त्रण गर्नुहोस्

के तपाईको कम्पनीसँग साझा पूर्वाधार भण्डार छ? के तपाईं आफ्नो पूर्वाधारमा प्राविधिक ऋण व्यवस्थापन गर्दै हुनुहुन्छ? के तपाइँ पूर्वाधार भण्डारमा विकास अभ्यासहरू प्रयोग गर्नुहुन्छ? के तपाईंको पूर्वाधार तहहरूमा काटिएको छ? तपाईं आधार-सेवा-एपीपी रेखाचित्र जाँच गर्न सक्नुहुन्छ। परिवर्तन गर्न कत्तिको गाह्रो छ?

यदि तपाईंले अनुभव गर्नुभएको छ कि परिवर्तनहरू गर्न डेढ दिन लाग्यो भने, यसको मतलब तपाईंसँग प्राविधिक ऋण छ र यसको साथ काम गर्न आवश्यक छ। तपाईंले भर्खरै आफ्नो पूर्वाधार कोडमा प्राविधिक ऋण रेकमा ठोकर खानुभयो। मलाई त्यस्ता धेरै कथाहरू सम्झना छ जब, केही CCTL परिवर्तन गर्नको लागि, तपाईंले पूर्वाधार कोडको आधा पुन: लेख्न आवश्यक छ, किनकि रचनात्मकता र सबै चीज स्वचालित गर्ने इच्छाले सबै कुरा जताततै क्षरण गरिएको छ, सबै ह्यान्डलहरू हटाइएको छ, र। यो refactor आवश्यक छ।

निरन्तर वितरण

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

एकचोटि यो स्पष्ट हुन्छ कि तपाईंसँग यो छ र यसलाई कसरी व्यवस्थापन गर्ने, तपाईंले विकासकर्ता कोडलाई सकेसम्म चाँडो उत्पादनमा कसरी पठाउने भनेर पत्ता लगाउन थाल्नुहुन्छ। मेरो मतलब विकासकर्तासँग मिलेर - हामी "कुवाहरू" को समस्याको बारेमा सम्झन्छौं, त्यो हो, यो व्यक्तिगत व्यक्तिहरू होइनन्, तर एक टोली हो।

जब हामी साथमा छौं Vanya Evtukhovich पहिलो किताब देखे जेज नम्र र लेखकहरूको समूह "निरन्तर वितरण", जुन 2009 मा जारी भएको थियो, हामीले यसको शीर्षक रूसीमा कसरी अनुवाद गर्ने भन्ने बारे लामो समय सोच्यौं। तिनीहरू यसलाई "निरन्तर डेलिभरी" को रूपमा अनुवाद गर्न चाहन्थे, तर दुर्भाग्यवश, यसलाई "निरन्तर डेलिभरी" को रूपमा अनुवाद गरिएको थियो। मलाई लाग्छ कि हाम्रो नाममा दबाब सहित केहि रूसी छ।

निरन्तर साधन उपलब्ध गराउने

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

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

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

यो केहि हदसम्म Pac-Man खेलको सम्झना दिलाउने हो - कलाकृति कुनै प्रकारको कथा मार्फत जान्छ। एकै समयमा, कोड वास्तवमा कथा मार्फत जान्छ कि छैन र यो कुनै न कुनै रूपमा तपाईंको उत्पादनसँग सम्बन्धित छ कि छैन भनेर नियन्त्रण गर्न महत्त्वपूर्ण छ। उत्पादनका कथाहरू निरन्तर डेलिभरी प्रक्रियामा तान्न सकिन्छ: यो यस्तो थियो जब केहि खस्यो, अब प्रणाली भित्र यो परिदृश्य कार्यक्रम गरौं। प्रत्येक पटक कोड यस परिदृश्यबाट पनि जान्छ, र तपाईंले अर्को पटक यो समस्या सामना गर्नुहुने छैन। तपाइँ यसको बारेमा तपाइँको ग्राहकमा पुग्नु भन्दा धेरै पहिले जान्नुहुनेछ।

विभिन्न तैनाती रणनीतिहरू। उदाहरणका लागि, तपाईले AB परीक्षण वा क्यानरी डिप्लोयमेन्टहरू प्रयोग गर्नुहुन्छ कोड फरक-फरक ग्राहकहरूमा परीक्षण गर्न, कोड कसरी काम गर्छ भन्ने बारे जानकारी प्राप्त गर्न, र 100 मिलियन प्रयोगकर्ताहरूमा रोल आउट भएको भन्दा धेरै अघि।

"लगातार डेलिभर" यस्तो देखिन्छ।

डेलिभरी प्रक्रिया Dev, CI, Test, PreProd, Prod छुट्टै वातावरण होइन, यी फायरप्रूफ रकमहरू भएका चरणहरू वा स्टेशनहरू हुन् जसबाट तपाईंको कलाकृति पास हुन्छ।

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

आत्म परीक्षण प्रश्नहरु

95% केसहरूमा सुविधा विवरणबाट उत्पादनमा रिलीज हुने समय एक हप्ता भन्दा कम छ? पाइपलाइनको प्रत्येक चरणमा कलाकृतिको गुणस्तर सुधार हुन्छ? त्यहाँ कुनै कथा छ कि यो मार्फत जान्छ? के तपाइँ विभिन्न परिनियोजन रणनीतिहरू प्रयोग गर्नुहुन्छ?

यदि सबै उत्तरहरू हो भने, तब तपाईं अविश्वसनीय रूपमा राम्रो हुनुहुन्छ! आफ्नो जवाफ कमेन्टमा लेख्नुहोस् - म खुसी हुनेछु)।

प्रतिक्रिया

यो सबै भन्दा कठिन अभ्यास हो। DevOpsConf सम्मेलनमा, Infobip का एक सहकर्मी, यसको बारेमा कुरा गर्दै, उहाँका शब्दहरूमा अलिकति भ्रममा परे, किनभने यो वास्तवमै धेरै जटिल अभ्यास हो जुन तथ्यलाई तपाईंले सबै कुराको निगरानी गर्न आवश्यक छ!

उदाहरण को लागी, एक लामो समय पहिले, जब मैले Qik मा काम गरे र हामीले महसुस गर्यौं कि हामीले सबै कुरा निगरानी गर्न आवश्यक छ। हामीले यो गर्यौं, र अब हामीसँग Zabbix मा 150 वस्तुहरू छन्, जुन निरन्तर निगरानी गरिन्छ। यो डरलाग्दो थियो, प्राविधिक निर्देशकले आफ्नो मन्दिरमा आफ्नो औंला घुमाए:

- साथीहरू, तपाइँ किन केहि अस्पष्ट संग सर्भर बलात्कार गर्दै हुनुहुन्छ?

तर त्यसपछि एउटा घटना घट्यो जसले देखाएको छ कि यो साँच्चै एक धेरै राम्रो रणनीति हो।

एउटा सेवा निरन्तर क्र्यास हुन थाल्यो। प्रारम्भमा, यो क्र्यास भएन, जुन चाखलाग्दो छ, कोड त्यहाँ थपिएको थिएन, किनकि यो एक आधारभूत ब्रोकर थियो, जसमा व्यावहारिक रूपमा कुनै व्यापारिक कार्यक्षमता थिएन - यसले व्यक्तिगत सेवाहरू बीच सन्देशहरू पठाएको थियो। सेवा 4 महिनाको लागि परिवर्तन भएन, र अचानक यो "विभाजन दोष" त्रुटि संग दुर्घटना हुन थाल्यो।

हामी छक्क पर्यौं, Zabbix मा हाम्रो चार्ट खोल्यौं, र यो पत्ता लाग्यो कि डेढ हप्ता अघि, यस ब्रोकरले प्रयोग गर्ने API सेवामा अनुरोधहरूको व्यवहार धेरै परिवर्तन भयो। अर्को हामीले देख्यौं कि एक निश्चित प्रकारको सन्देश पठाउने आवृत्ति परिवर्तन भएको थियो। पछि हामीले पत्ता लगायौं कि यी एन्ड्रोइड ग्राहकहरू थिए। हामीले सोध्यौ:

- साथीहरू, डेढ हप्ता अघि तपाईलाई के भयो?

जवाफमा, हामीले उनीहरूले कसरी UI पुन: डिजाइन गरेका थिए भन्ने बारेमा एउटा रोचक कथा सुन्यौं। यो सम्भव छैन कि कसैले तुरुन्तै भन्नुहुनेछ कि उनीहरूले HTTP पुस्तकालय परिवर्तन गरे। एन्ड्रोइड क्लाइन्टहरूका लागि, यो बाथरूममा साबुन परिवर्तन गर्नु जस्तै हो - उनीहरूलाई याद छैन। नतिजाको रूपमा, कुराकानीको 40 मिनेट पछि, हामीले पत्ता लगायौं कि उनीहरूले HTTP पुस्तकालय परिवर्तन गरेका थिए, र यसको पूर्वनिर्धारित समय परिवर्तन भएको थियो। यसले API सर्भरमा ट्राफिक व्यवहार परिवर्तन गर्न नेतृत्व गर्‍यो, जसले ब्रोकर भित्र दौड निम्त्याउने स्थिति निम्त्यायो, र यो क्र्यास हुन थाल्यो।

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

वितरण प्रक्रियाको प्रत्येक चरणमा कलाकृतिलाई के हुन्छ भन्ने बारे सबै जानकारी सङ्कलन गर्नुहोस् - उत्पादनमा होइन।

CI मा अनुगमन अपलोड गर्नुहोस्, र केहि आधारभूत चीजहरू पहिले नै त्यहाँ देखिने छन्। पछि तपाईंले तिनीहरूलाई परीक्षण, PredProd, र लोड परीक्षणमा देख्नुहुनेछ। सबै चरणहरूमा जानकारी सङ्कलन गर्नुहोस्, न केवल मेट्रिक्स, तथ्याङ्कहरू, तर लगहरू पनि: कसरी अनुप्रयोग रोल आउट भयो, विसंगतिहरू - सबै सङ्कलन गर्नुहोस्।

अन्यथा यो पत्ता लगाउन गाह्रो हुनेछ। मैले पहिले नै भनेको छु कि DevOps अधिक जटिल छ। यस जटिलताको सामना गर्न, तपाइँसँग सामान्य विश्लेषणहरू हुन आवश्यक छ.

आत्म-नियन्त्रणका लागि प्रश्नहरू

के तपाइँको अनुगमन र तपाइँको लागि विकास उपकरण लग गर्दै हुनुहुन्छ? कोड लेख्दा, तपाईं लगायत तपाईंका विकासकर्ताहरूले यसलाई कसरी अनुगमन गर्ने भनेर सोच्नुहुन्छ?

के तपाइँ ग्राहकहरु को समस्या को बारे मा सुन्नुहुन्छ? के तपाइँ ग्राहकलाई निगरानी र लगिङबाट राम्रोसँग बुझ्नुहुन्छ? के तपाइँ अनुगमन र लगिङबाट प्रणाली राम्रोसँग बुझ्नुहुन्छ? के तपाईंले प्रणालीमा प्रवृत्ति बढ्दै गएको देख्नुभयो र अर्को 3 हप्तामा सबै मर्नेछ भनेर बुझ्नुभएकोले मात्र प्रणाली परिवर्तन गर्नुहुन्छ?

एकचोटि तपाईंसँग यी तीन घटकहरू भएपछि, तपाईं आफ्नो कम्पनीमा कस्तो प्रकारको पूर्वाधार प्लेटफर्म छ भनेर सोच्न सक्नुहुन्छ।

पूर्वाधार प्लेटफार्म

बिन्दु यो होइन कि यो भिन्न उपकरणहरूको सेट हो जुन प्रत्येक कम्पनीसँग छ।

एक पूर्वाधार प्लेटफर्मको बिन्दु यो हो कि सबै टोलीहरूले यी उपकरणहरू प्रयोग गर्छन् र तिनीहरूलाई सँगै विकास गर्छन्।

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

सबै टोलीहरूले पूर्वाधार प्लेटफर्म विकास गर्छन् र यसलाई आफ्नै IDE को रूपमा हेरचाहका साथ व्यवहार गर्छन्। तपाईको IDE मा तपाईले सबै चीज राम्रो र छिटो बनाउन र हटकीहरू कन्फिगर गर्न विभिन्न प्लगइनहरू स्थापना गर्नुहुन्छ। जब तपाइँ सब्लाइम, एटम वा भिजुअल स्टुडियो कोड खोल्नुहुन्छ, कोड त्रुटिहरू खन्याइन्छन् र तपाइँले यो काम गर्न असम्भव छ भनेर महसुस गर्नुहुन्छ, तपाइँ तुरुन्तै दुखी महसुस गर्नुहुन्छ र तपाइँ आफ्नो IDE लाई ठीक गर्न दौडनुहुन्छ।

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

पूर्वाधार प्लेटफर्मले गुणस्तरमा निरन्तर सुधारको साथ विकासबाट ग्राहकमा कलाकृति हस्तान्तरण सुनिश्चित गर्दछ। IP लाई उत्पादनमा कोडमा हुने कथाहरूको सेटसँग प्रोग्राम गरिएको छ। विकासको वर्षहरूमा, यी कथाहरू धेरै छन्, ती मध्ये केही अद्वितीय छन् र तपाईंसँग मात्र सम्बन्धित छन् - तिनीहरू Googled गर्न सकिँदैन।

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

योजना

यो एक पूर्वाधार प्लेटफर्मको आधारभूत रेखाचित्र हो जसले तपाईंलाई DevOps कम्पनीमा सबै अभ्यास र प्रक्रियाहरू सेटअप गर्न मद्दत गर्नेछ।

यसमा के समावेश छ हेरौं।

स्रोत अर्केस्ट्रेशन प्रणाली, जसले अनुप्रयोगहरू र अन्य सेवाहरूलाई CPU, मेमोरी, डिस्क प्रदान गर्दछ। यस माथि - निम्न स्तर सेवाहरू: निगरानी, ​​लगिङ, CI/CD इन्जिन, कलाकृति भण्डारण, प्रणाली कोडको रूपमा पूर्वाधार।

उच्च स्तरीय सेवाहरू: सेवाको रूपमा डाटाबेस, सेवाको रूपमा लामहरू, सेवाको रूपमा लोड ब्यालेन्स, सेवाको रूपमा छवि रिसाइजिङ, सेवाको रूपमा बिग डाटा फ्याक्ट्री। यस माथि - पाइपलाइन जसले तपाईको ग्राहकलाई निरन्तर परिमार्जित कोड प्रदान गर्दछ.

तपाइँले तपाइँको सफ्टवेयर क्लाइन्टको लागि कसरी काम गर्दछ भन्ने बारे जानकारी प्राप्त गर्नुहुन्छ, यसलाई परिवर्तन गर्नुहुन्छ, यो कोड फेरि आपूर्ति गर्नुहुन्छ, जानकारी प्राप्त गर्नुहुन्छ - र त्यसैले तपाइँ निरन्तर पूर्वाधार प्लेटफर्म र तपाइँको सफ्टवेयर दुवै विकास गर्नुहुन्छ।

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

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

मञ्च निर्माण

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

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

तपाईंसँग के छ?

फेरि, प्रश्नहरू तपाईं आफैलाई सोध्न सक्नुहुन्छ।

के पूर्वाधार प्लेटफर्म समर्पित छ? यसको विकासको जिम्मेवारी कसको हो ? के तपाइँ तपाइँको पूर्वाधार प्लेटफर्म को प्रतिस्पर्धात्मक लाभहरु लाई बुझ्नुहुन्छ?

तपाईंले लगातार आफैलाई यी प्रश्नहरू सोध्न आवश्यक छ। यदि केहि तेस्रो-पक्ष सेवाहरूमा स्थानान्तरण गर्न सकिन्छ भने, यसलाई स्थानान्तरण गरिनुपर्छ; यदि तेस्रो-पक्ष सेवाले तपाईंको आन्दोलनलाई रोक्न थाल्छ भने, तपाईंले आफैं भित्र प्रणाली निर्माण गर्न आवश्यक छ।

त्यसैले, DevOps...

... यो एक जटिल प्रणाली हो, यो हुनुपर्छ:

• डिजिटल उत्पादन।
• यो डिजिटल उत्पादन विकास गर्ने व्यापार मोड्युलहरू।
• कोड लेख्ने उत्पादन टोलीहरू।
• निरन्तर वितरण अभ्यासहरू।
• सेवाको रूपमा प्लेटफार्महरू।
• सेवाको रूपमा पूर्वाधार।
• कोडको रूपमा पूर्वाधार।
• विश्वसनीयता कायम राख्नका लागि छुट्टै अभ्यासहरू, DevOps मा निर्मित।
• यो सबै वर्णन गर्ने प्रतिक्रिया अभ्यास।

तपाइँ यो रेखाचित्र प्रयोग गर्न सक्नुहुन्छ, तपाइँसँग तपाइँको कम्पनीमा केहि रूप मा पहिले नै के छ भनेर हाइलाइट गर्दै: यो विकसित भएको छ वा अझै विकास गर्न आवश्यक छ।

यो एक दुई हप्तामा समाप्त हुनेछ DevOpsConf 2019। RIT++ को भागको रूपमा। सम्मेलनमा आउनुहोस्, जहाँ तपाईंले निरन्तर डेलिभरी, कोडको रूपमा पूर्वाधार र DevOps रूपान्तरणको बारेमा धेरै राम्रो रिपोर्टहरू पाउनुहुनेछ। आफ्नो टिकट बुक गर्नुहोस्, अन्तिम मूल्य समय सीमा मे २० हो

स्रोत: www.habr.com