रूस २०२० मा DevOps को राज्य

कुनै चीजको अवस्था कसरी बुझ्ने?

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

तर त्यो दिन आएको छ जब यस्तो अध्ययन गरिएको थियो, र आज हामी परिणाम बारेमा कुरा गर्नेछौं। रूस मा DevOps को राज्य कम्पनीहरु द्वारा संयुक्त रूपमा अध्ययन गरिएको थियो "एक्सप्रेस 42"र"ओन्टिको"। Express 42 ले टेक्नोलोजी कम्पनीहरूलाई DevOps अभ्यास र उपकरणहरू लागू गर्न र विकास गर्न मद्दत गर्दछ र रूसमा DevOps बारे कुरा गर्ने पहिलो मध्ये एक थियो। अध्ययनका लेखकहरू, इगोर कुरोचकिन र भिटाली खाबरोभ, एक्सप्रेस 42 मा विश्लेषण र परामर्शमा संलग्न छन्, जबकि विभिन्न कम्पनीहरूमा सञ्चालन र अनुभवको प्राविधिक पृष्ठभूमि छ। 8 वर्षदेखि, सहकर्मीहरूले दर्जनौं कम्पनीहरू र परियोजनाहरू - स्टार्टअपदेखि उद्यमहरू - विभिन्न समस्याहरू, साथै विभिन्न सांस्कृतिक र इन्जिनियरिङ परिपक्वताहरू हेरेका छन्।

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

DevOps अनुसन्धान

कुराकानी इगोर कुरोचकिन द्वारा सुरु भएको थियो।

हामी नियमित रूपमा DevOps सम्मेलनहरूमा दर्शकहरूलाई सोध्छौं, "के तपाईंले यो वर्षको लागि DevOps स्थिति रिपोर्ट पढ्नुभयो?" थोरैले आफ्नो हात उठाउँछन्, र हाम्रो अध्ययनले देखाएको छ कि तेस्रोले मात्र तिनीहरूलाई अध्ययन गर्दछ। यदि तपाईंले त्यस्ता रिपोर्टहरू कहिल्यै देख्नुभएको छैन भने, तुरुन्तै भनौं कि तिनीहरू सबै धेरै समान छन्। प्रायः त्यहाँ वाक्यांशहरू छन्: "गत वर्षको तुलनामा ..."

यहाँ हामीसँग पहिलो समस्या छ, र यो पछि दुई थप:

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

DevOps राज्य विश्लेषणहरू विश्वभरि कसरी गरिएको छ भनेर हेरौं।

ऐतिहासिक पृष्ठभूमि

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

2013 मा, IT क्रान्ति देखा पर्‍यो, DevOps मा सबै प्रमुख पुस्तकहरूको प्रकाशक। Puppet सँगसँगै, तिनीहरूले DevOps प्रकाशनको पहिलो राज्य तयार गरे, जहाँ 4 प्रमुख मेट्रिकहरू पहिलो पटक देखा परे। अर्को वर्ष, ThoughtWorks, उद्योग अभ्यास र उपकरणहरूमा नियमित टेक्नोलोजी रडारहरूको लागि परिचित एक परामर्श फर्म, संलग्न भयो। र 2015 मा, पद्धतिको साथ एक खण्ड थपियो, र यो स्पष्ट भयो कि तिनीहरूले कसरी विश्लेषण गर्छन्।

2016 मा, अध्ययनका लेखकहरूले आफ्नै कम्पनी DORA (DevOps अनुसन्धान र मूल्याङ्कन) सिर्जना गरी वार्षिक रिपोर्ट प्रकाशित गरे। अर्को वर्ष, DORA र Puppet ले आफ्नो अन्तिम संयुक्त रिपोर्ट जारी गर्यो।

र त्यसपछि केहि रोचक सुरु भयो:

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

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

तर DORA र Google बाट अझै कुनै घोषणा छैन। मे मा, जब सर्वेक्षण सामान्यतया सुरु भयो, जानकारी आयो कि निकोल फोर्सग्रेन, DORA को संस्थापक मध्ये एक, अर्को कम्पनी मा सरेको थियो। त्यसैले यस वर्ष डोराबाट कुनै अनुसन्धान र प्रतिवेदन नआउने हामीले अनुमान गरेका छौं।

रूस मा चीजहरू कस्तो छ?

हामीले DevOps अनुसन्धान गरेका छैनौं। हामीले सम्मेलनहरूमा बोलेका थियौं, अन्य मानिसहरूका खोजहरू पुन: बताउँदै, र Raiffeisenbank ले 2019 को लागि "State of DevOps" अनुवाद गर्‍यौं (तपाईंले Habré मा उनीहरूको घोषणा पाउन सक्नुहुन्छ), उहाँहरूलाई धेरै धन्यवाद। र यो सबै छ।

त्यसैले, हामीले DORA विधि र निष्कर्षहरू प्रयोग गरेर रूसमा हाम्रो आफ्नै अनुसन्धान सञ्चालन गर्यौं। हामीले हाम्रो अनुसन्धानको लागि Raiffeisenbank का सहकर्मीहरूको रिपोर्ट प्रयोग गर्यौं, शब्दावली र अनुवादको सिंक्रोनाइजेसन सहित। र उद्योग-सम्बन्धित प्रश्नहरू DORA रिपोर्टहरू र यस वर्षको पपेट प्रश्नावलीबाट लिइयो।

अनुसन्धान प्रक्रिया

रिपोर्ट अन्तिम भाग मात्र हो। सम्पूर्ण अनुसन्धान प्रक्रियाले चार प्रमुख चरणहरू समावेश गर्दछ:

तयारी चरणमा, हामीले उद्योग विशेषज्ञहरूसँग अन्तर्वार्ता लियौं र परिकल्पनाहरूको सूची तयार गर्यौं। तिनीहरूको आधारमा, प्रश्नहरू संकलित गरियो र अगस्टको सम्पूर्ण लागि सर्वेक्षण सुरु गरियो। त्यसपछि हामीले आफैं विश्लेषण गरेर प्रतिवेदन तयार गर्‍यौं। DORA को लागि, यो प्रक्रिया 6 महिना लाग्छ। हामीले 3 महिना भित्र भेट्यौं, र अब हामी बुझ्छौं कि हामीसँग पर्याप्त समय छैन: केवल विश्लेषण प्रदर्शन गरेर तपाईले के सोध्नु पर्ने प्रश्नहरू बुझ्नुहुन्छ।

सहभागीहरू

सबै विदेशी रिपोर्टहरू सहभागीहरूको चित्रबाट सुरु हुन्छन्, र तिनीहरूमध्ये धेरैजसो रूसका छैनन्। रूसी उत्तरदाताहरूको प्रतिशत प्रत्येक वर्ष 5 देखि 1% बाट उतार-चढ़ाव हुन्छ, र यसले कुनै पनि निष्कर्ष निकाल्न अनुमति दिँदैन।

Accelerate State of DevOps 2019 रिपोर्टको नक्सा:

हाम्रो अध्ययनमा, हामीले 889 जनासँग अन्तर्वार्ता लिन सफल भयौं - यो धेरै हो (DORA ले आफ्नो रिपोर्टमा वार्षिक एक हजार मानिसहरूको सर्वेक्षण गर्छ) र यहाँ हामीले लक्ष्य हासिल गरेका छौं:

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

उद्योग र पदहरू

हाम्रा उत्तरदाताहरूले एक दर्जन उद्योगहरूको प्रतिनिधित्व गर्छन्। सूचना प्रविधिमा आधा काम। यसपछि वित्तीय सेवा, व्यापार, दूरसञ्चार र अन्य छन्। पदहरू मध्ये विशेषज्ञहरू (विकासकर्ता, परीक्षक, अपरेशन इन्जिनियर) र व्यवस्थापन कर्मचारीहरू (दलहरू, समूहहरू, क्षेत्रहरू, निर्देशकहरू) छन्:

दुई मध्ये एकले मध्यम आकारको कम्पनीमा काम गर्छ। प्रत्येक तेस्रो व्यक्ति ठूला कम्पनीहरूमा काम गर्दछ। अधिकांशले ९ जनासम्मको टोलीमा काम गर्छन्। अलग रूपमा, हामीले मुख्य गतिविधिहरूको बारेमा सोध्यौं, र अधिकांश कुनै न कुनै रूपमा सञ्चालनसँग सम्बन्धित छन्, र लगभग 9% विकासमा संलग्न छन्:

त्यसैले हामीले विभिन्न उद्योग, कम्पनी, टोलीका प्रतिनिधिहरूको तुलना र विश्लेषणको लागि जानकारी सङ्कलन गर्‍यौं। मेरो सहकर्मी Vitaly Khabarov विश्लेषण बारे बताउनुहुनेछ।

विश्लेषण र तुलना

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

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

कुञ्जी मेट्रिक्स

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

प्रमुख मेट्रिक्स:

1. परिनियोजन आवृत्ति। एप्लिकेसनको नयाँ संस्करण उत्पादन वातावरणमा कति पटक प्रयोग गरिन्छ (योजनाबद्ध परिवर्तनहरू, हटफिक्सहरू र घटना प्रतिक्रियाहरू बाहेक)?
2. डेलिभरी समय। परिवर्तन गर्न (कोडको रूपमा कार्यक्षमता लेख्ने) र उत्पादन वातावरणमा परिवर्तन लागू गर्ने बीचको औसत समय के हो?
3. रिकभरी समय। कुनै घटना, सेवा ह्रास, वा अनुप्रयोग प्रयोगकर्ताहरूलाई असर गर्ने बगको खोज पछि उत्पादन वातावरणमा अनुप्रयोग पुनर्स्थापना गर्न औसतमा कति समय लाग्छ?
4. असफल परिवर्तनहरू। उत्पादन वातावरणमा परिनियोजनको कति प्रतिशतले अनुप्रयोगको ह्रास वा घटनाहरू निम्त्याउँछ र सुधारको आवश्यकता पर्दछ (परिवर्तनहरूको रोलब्याक, हटफिक्स वा प्याचको विकास)?

DORA ले आफ्नो अनुसन्धानमा यी मेट्रिक्स र संगठनात्मक कार्यसम्पादन बीचको सम्बन्ध फेला पारेको छ। हामीले हाम्रो अध्ययनमा पनि परीक्षण गर्छौं।

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

सैद्धान्तिक रूपमा, अधिकांश उत्तरदाताहरूले उत्पादनमा घटनाहरूको संख्या कम छ भनी जवाफ दिन्छन्। यद्यपि हामी पछि देख्नेछौं कि उत्तरदाताहरूको समूहहरू बीच असफल परिवर्तनहरूको सन्दर्भमा अझै पनि महत्त्वपूर्ण भिन्नता छ, हामी अझै यस विभाजनको लागि यो मेट्रिक प्रयोग गर्न सक्दैनौं।

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

यहाँ महत्त्वपूर्ण छ कि हामीले डेलिभरी समय, रिकभरी समय, र डिप्लोयमेन्ट फ्रिक्वेन्सी बीचको महत्त्वपूर्ण सम्बन्ध फेला पार्यौं। त्यसकारण, हामीले उत्तरदाताहरूलाई प्रदर्शन समूहहरूमा विभाजन गर्न यी तीन मेट्रिक्स लिएका छौं।

ग्राममा कति तौल गर्ने ?

हामीले पदानुक्रमिक क्लस्टर विश्लेषण प्रयोग गर्यौं:

• हामी उत्तरदाताहरूलाई n-आयामी ठाउँमा वितरण गर्छौं, जहाँ प्रत्येक उत्तरदाताको समन्वय प्रश्नहरूको जवाफ हो।
• प्रत्येक उत्तरदातालाई सानो क्लस्टर घोषणा गरिएको छ।
• हामी एकअर्काको नजिकका दुईवटा क्लस्टरहरूलाई एउटा ठूलो क्लस्टरमा मिलाउँछौं।
• हामी क्लस्टरहरूको अर्को जोडी फेला पार्छौं र तिनीहरूलाई ठूलो क्लस्टरमा जोड्छौं।

यसरी हामी हाम्रा सबै उत्तरदाताहरूलाई हामीलाई चाहिने क्लस्टरहरूको सङ्ख्यामा समूहबद्ध गर्छौं। डेन्ड्रोग्राम (क्लस्टरहरू बीचको जडानको रूख) को मद्दतले हामी दुई छिमेकी क्लस्टरहरू बीचको दूरी देख्छौं। हाम्रो लागि बाँकी रहेका यी क्लस्टरहरू बीचको निश्चित दूरी सीमा सेट गर्नु र भन्नु हो: "यी दुई समूहहरू एकअर्काबाट धेरै भिन्न छन् किनभने तिनीहरू बीचको दूरी विशाल छ।"

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

अर्को, हामीले क्लस्टरहरूद्वारा प्रोफाइल निर्धारण गर्यौं: हामीले प्रत्येक समूहको लागि प्रत्येक मेट्रिकको लागि मध्यक लियौं र प्रदर्शन प्रोफाइलहरूको तालिका कम्पाइल गर्यौं। वास्तवमा, हामीले प्रत्येक समूहमा औसत सहभागीको प्रदर्शन प्रोफाइलहरू पायौं। हामीले तीन दक्षता प्रोफाइलहरू पहिचान गरेका छौं: कम, मध्यम, उच्च:

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

त्यसपछि प्रश्न उठ्छ: यो सबै कसरी प्रयोग गर्ने?

कसरी प्रयोग गर्ने

यदि हामीले कुनै पनि टोली, 4 प्रमुख मेट्रिक्स लिन्छौं र यसलाई तालिकामा लागू गर्छौं भने, त्यसपछि 85% केसहरूमा हामीले पूर्ण मिलान पाउने छैनौं - यो केवल एक औसत सहभागी हो, र वास्तविकतामा के होइन। हामी सबै (र प्रत्येक टोली) थोरै फरक छौं।

हामीले जाँच गर्यौं: हामीले हाम्रा उत्तरदाताहरू र DORA कार्यसम्पादन प्रोफाइल लियौं, र कतिजना उत्तरदाताहरू यो वा त्यो प्रोफाइलमा फिट छन् भनेर हेर्‍यौं। हामीले पत्ता लगायौं कि उत्तरदाताहरूको केवल 16% निश्चित रूपमा प्रोफाइलहरू मध्ये एकमा परेका थिए। बाँकी सबै बीचमा कतै छरिएका छन्:

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

• DORA क्यालकुलेटर
• क्याल्कुलेटर एक्सप्रेस ४२* (विकासमा)
• आफ्नै विकास (तपाईं आफ्नो आन्तरिक क्यालकुलेटर सिर्जना गर्न सक्नुहुन्छ)।

तिनीहरूको लागि के आवश्यक छ? बुझ्नलाई:

• के हाम्रो संगठन भित्रको टोली हाम्रो मापदण्ड अनुसार छ?
• यदि होइन भने, के हामी यसलाई मद्दत गर्न सक्छौं, हाम्रो कम्पनीको विशेषज्ञताको ढाँचा भित्र यसलाई गति दिन सक्छौं?
• यदि त्यसो हो भने, के हामी अझ राम्रो गर्न सक्छौं?

तपाईं कम्पनी भित्र तथ्याङ्क सङ्कलन गर्न पनि तिनीहरूलाई प्रयोग गर्न सक्नुहुन्छ:

• हामीसँग कस्ता टोलीहरू छन्?
• टोलीहरूलाई प्रोफाइलहरूमा विभाजन गर्नुहोस्;
• हेर्नुहोस्: ओह, यी आदेशहरू कमजोर छन् (तिनीहरूले अलिकति तान्दैनन्), तर यी राम्रो छन्: तिनीहरू हरेक दिन डिप्लोइ गर्छन्, त्रुटिहरू बिना, तिनीहरूसँग एक घण्टा भन्दा कमको नेतृत्व समय छ।

र त्यसपछि तपाईंले पत्ता लगाउन सक्नुहुन्छ कि हाम्रो कम्पनी भित्र ती टोलीहरूको लागि आवश्यक विशेषज्ञता र उपकरणहरू छन् जुन अझै बराबर छैन।

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

राम्रो। र यदि तपाईं DORA क्याल्कुलेटरमा एलिट समूहमा हुनुहुन्छ भने, तपाईंले के गर्नुपर्छ? यहाँ कुनै राम्रो समाधान छैन। तपाईं सम्भवतः उद्योगको अगाडि हुनुहुन्छ, र थप प्रवेग र विश्वसनीयता आन्तरिक R&D र थप स्रोतहरू खर्च गरेर सम्भव छ।

सबैभन्दा मीठो - तुलनामा जाऔं।

तुलना

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

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

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

तर यो वर्ष विशेष छ, र हामीले महामारीमा कम्पनीहरूले कसरी गरिरहेको छ भनेर जाँच गर्ने निर्णय गर्‍यौं: उच्च प्रोफाइल टोलीहरूले धेरै राम्रो गरिरहेका छन् र उद्योग औसत भन्दा राम्रो महसुस गरिरहेका छन्:

• नयाँ उत्पादनहरू जारी गर्ने सम्भावना 1,5-2 गुणा बढी,
• अनुप्रयोग पूर्वाधारको विश्वसनीयता र / वा प्रदर्शन सुधार गर्न 2 गुणा बढी सम्भावना।

अर्थात्, उनीहरूले पहिले नै उनीहरूलाई छिटो विकास गर्न, नयाँ उत्पादनहरू लन्च गर्न, अवस्थित उत्पादनहरू परिमार्जन गर्न, नयाँ बजारहरू र नयाँ प्रयोगकर्ताहरूलाई जित्न मद्दत गरेको दक्षताहरू:

हाम्रो टोलीलाई अरू के मद्दत गर्‍यो?

इन्जिनियरिङ अभ्यासहरू

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

सेवाको रूपमा प्लेटफर्म

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

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

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

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

एकीकरण र वितरण

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

वास्तुकला

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

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

हामीले यो सबै कसरी पत्ता लगायौं?

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

हामीले प्रत्येक प्रोफाइलमा टोलीहरूमा ईन्जिनियरिङ् अभ्यासहरूको वितरणलाई हेर्यौं र पत्ता लगायौं कि उच्च प्रोफाइल टोलीहरू, औसतमा, इन्जिनियरिङ अभ्यासहरू प्रयोग गर्ने सम्भावना बढी थियो। तपाईं हाम्रो मा यो सबै बारे थप पढ्न सक्नुहुन्छ रिपोर्ट.

परिवर्तनको लागि, जटिल तथ्याङ्कबाट साधारण तथ्याङ्कहरूमा स्विच गरौं।

हामीले अरू के पत्ता लगाएका छौं?

उपकरणहरू

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

अर्केस्ट्रेटरहरू मध्ये, यो कसैको लागि गोप्य छैन, Kubernetes नेतृत्वमा छ (52%)। अर्को लाइन अर्केस्ट्रेटर हो डकर स्वार्म (लगभग 12%)। सबैभन्दा लोकप्रिय CI प्रणालीहरू जेनकिन्स र GitLab हुन्। सबैभन्दा लोकप्रिय कन्फिगरेसन व्यवस्थापन प्रणाली उत्तरदायी छ, हाम्रो प्रिय शेल पछि।

अमेजन हाल अग्रणी क्लाउड होस्टिंग प्रदायक हो। रूसी बादलहरूको अंश बिस्तारै बढ्दै छ। अर्को वर्ष यो हेर्न रोचक हुनेछ कि रूसी क्लाउड प्रदायकहरूले कस्तो महसुस गर्नेछन्, तिनीहरूको बजार साझेदारी बढ्छ कि छैन। तिनीहरू हुन्, तिनीहरू प्रयोग गर्न सकिन्छ, र यो राम्रो छ:

म इगोरलाई भुइँ पास गर्छु, जसले केही थप तथ्याङ्कहरू दिनेछ।

अभ्यास को प्रसार

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

फुर्तिलो र DevOps

Agile र DevOps बीचको जडानको प्रश्न प्रायः उद्योगमा छलफल गरिन्छ। यो मुद्दा २०१९/२०२० को स्टेट अफ एजाइल रिपोर्टमा पनि उठाइएको छ, त्यसैले हामीले कम्पनीहरूमा Agile र DevOps गतिविधिहरू कसरी जोडिएका छन् भनेर तुलना गर्ने निर्णय गर्यौं। हामीले फेला पार्‍यौं कि Agile बिना DevOps दुर्लभ छ। आधा उत्तरदाताहरूको लागि, एजाइलको फैलावट धेरै पहिले सुरु भयो, र लगभग 2019% ले एकै साथ सुरु भएको अवलोकन गर्‍यो, र कम प्रोफाइलको संकेतहरू मध्ये एउटा एजाइल र DevOps अभ्यासहरूको अनुपस्थिति हुनेछ:

आदेश टोपोलोजी

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

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

DevQaOps अनुपात

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

२०२१ को लागि योजनाहरू

अर्को वर्षको योजनाहरूमा, उत्तरदाताहरूले निम्न गतिविधिहरू नोट गरे:

यहाँ तपाईंले DevOps लाइभ 2020 सम्मेलनको प्रतिच्छेदन देख्न सक्नुहुन्छ। हामीले कार्यक्रमलाई ध्यानपूर्वक समीक्षा गर्यौं:

• उत्पादनको रूपमा पूर्वाधार
• DevOps रूपान्तरण
• DevOps अभ्यासहरूको वितरण
• DevSecOps
• केस क्लब र छलफल

तर हाम्रो प्रस्तुतिको समय सबै विषयहरू समेट्न पर्याप्त छैन। पर्दा पछाडि छोडियो:

• प्लेटफर्म सेवाको रूपमा र उत्पादनको रूपमा;
• कोड, वातावरण र क्लाउडको रूपमा पूर्वाधार;
• निरन्तर एकीकरण र वितरण;
• वास्तुकला;
• DevSecOps ढाँचाहरू;
• प्लेटफर्म र क्रस-कार्यात्मक टोलीहरू।

रिपोर्ट गर्नुहोस् हामीले एक विशाल, 50 पृष्ठहरू पायौं, र तपाइँ यसलाई थप विवरणमा हेर्न सक्नुहुन्छ।

संक्षेप हुँदै

हामी आशा गर्छौं कि हाम्रो अनुसन्धान र प्रतिवेदनले तपाईंलाई विकास, परीक्षण र सञ्चालनका लागि नयाँ दृष्टिकोणहरू प्रयोग गर्न प्रेरित गर्नेछ, साथै तपाईंलाई नेभिगेट गर्न, अध्ययनका अन्य सहभागीहरूसँग आफूलाई तुलना गर्न, र तपाईंले आफ्नो दृष्टिकोण सुधार गर्न सक्ने क्षेत्रहरू पहिचान गर्न मद्दत गर्नेछ।

रूस मा DevOps को राज्य को पहिलो अध्ययन को परिणाम:

• कुञ्जी मेट्रिक्स। हामीले फेला पारेका छौं कि मुख्य मेट्रिक्स (डिलिभरी समय, डिप्लोयमेन्ट फ्रिक्वेन्सी, रिकभरी समय, र परिवर्तन विफलताहरू) विकास, परीक्षण, र सञ्चालन प्रक्रियाहरूको प्रभावकारिता विश्लेषण गर्न उपयुक्त छन्।
• प्रोफाइल उच्च, मध्यम, कम। सङ्कलन गरिएको तथ्याङ्कको आधारमा, हामीले मेट्रिक्स, अभ्यासहरू, प्रक्रियाहरू र उपकरणहरूको सन्दर्भमा विशिष्ट सुविधाहरू सहित उच्च, मध्यम, न्यूनका सांख्यिकीय रूपमा विभिन्न समूहहरू छुट्याउन सक्छौं। हाई प्रोफाइलका प्रतिनिधिहरूले न्यूनभन्दा राम्रो नतिजा देखाउँछन्। तिनीहरूले आफ्नो लक्ष्य प्राप्त गर्न र पार गर्न अधिक सम्भावना छ।
• सन् २०२१ को लागि सूचक, महामारी र योजनाहरू। यस वर्षको एउटा विशेष सूचक हो कि कम्पनीहरूले कसरी महामारीको सामना गरे। उच्च प्रतिनिधिहरूले राम्रो प्रदर्शन गरे, अनुभव बढेको प्रयोगकर्ता संलग्नता, र सफलताको मुख्य कारणहरू कुशल विकास प्रक्रियाहरू र बलियो इन्जिनियरिङ संस्कृति थिए।
• DevOps अभ्यासहरू, उपकरणहरू र तिनीहरूको विकास। अर्को वर्षका लागि कम्पनीहरूको मुख्य योजनाहरूमा DevOps अभ्यास र उपकरणहरूको विकास, DevSecOps अभ्यासहरूको परिचय, र संगठनात्मक संरचनामा परिवर्तनहरू समावेश छन्। र DevOps अभ्यासहरूको प्रभावकारी कार्यान्वयन र विकास पाइलट प्रोजेक्टहरू, समुदायहरूको गठन र उत्कृष्टता केन्द्रहरू, कम्पनीको माथिल्लो र तल्लो तहहरूमा पहलहरूको सहयोगमा गरिन्छ।

हामी तपाईंको प्रतिक्रिया, कथाहरू, प्रतिक्रिया सुन्न चाहन्छौं। हामी अध्ययनमा भाग लिने सबैलाई धन्यवाद दिन्छौं र अर्को वर्ष तपाईंको सहभागिताको लागि तत्पर छौं।

स्रोत: www.habr.com