रूस में DevOps की स्थिति 2020

किसी चीज़ की स्थिति को कैसे समझें?

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

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

अपनी रिपोर्ट में, इगोर और विटाली ने बताया कि अनुसंधान प्रक्रिया के दौरान क्या समस्याएं थीं, उन्होंने उन्हें कैसे हल किया, साथ ही सैद्धांतिक रूप से DevOps अनुसंधान कैसे किया जाता है और एक्सप्रेस 42 ने अपना स्वयं का संचालन करने का निर्णय क्यों लिया। आप उनकी रिपोर्ट देख सकते हैं यहां.

डेवऑप्स रिसर्च

बातचीत की शुरुआत इगोर कुरोच्किन ने की थी.

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

यहां हमारी पहली समस्या है, उसके बाद दो और हैं:

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

आइए एक नज़र डालें कि दुनिया भर में DevOps स्थिति का विश्लेषण कैसे किया गया है।

ऐतिहासिक जानकारी

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

2013 में, IT Revolution सामने आया, जो DevOps पर सभी प्रमुख पुस्तकों का प्रकाशक था। पपेट के साथ मिलकर, उन्होंने पहला प्रकाशन "स्टेट ऑफ़ डेवऑप्स" तैयार किया, जहाँ 4 प्रमुख मेट्रिक्स पहली बार सामने आए। अगले वर्ष, परामर्श कंपनी थॉटवर्क्स, जो उद्योग प्रथाओं और उपकरणों पर अपने नियमित प्रौद्योगिकी रडार के लिए जानी जाती है, इसमें शामिल हो गई। और 2015 में, कार्यप्रणाली वाला एक अनुभाग जोड़ा गया, और यह स्पष्ट हो गया कि वे विश्लेषण कैसे करते हैं।

2016 में, अध्ययन के लेखकों ने अपनी खुद की कंपनी DORA (DevOps रिसर्च एंड असेसमेंट) बनाकर एक वार्षिक रिपोर्ट प्रकाशित की। अगले वर्ष, डोरा और पपेट ने अपनी अंतिम संयुक्त रिपोर्ट जारी की।

और फिर चीजें दिलचस्प हो गईं:

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

इस साल चीजें जटिल हो गईं. मालूम हो कि पपेट ने अपना सर्वे लॉन्च किया था. उन्होंने इसे हमसे एक सप्ताह पहले किया और यह पहले ही पूरा हो चुका था। हमने इसमें हिस्सा लिया और देखा कि किस विषय में उनकी रुचि है. पपेट अब अपना विश्लेषण कर रहा है और रिपोर्ट प्रकाशित करने की तैयारी कर रहा है।

लेकिन DORA और Google की ओर से अभी भी कोई घोषणा नहीं हुई है। मई में, जब आम तौर पर सर्वेक्षण शुरू हुआ, तो जानकारी आई कि DORA के संस्थापकों में से एक, निकोल फ़ोर्सग्रेन, दूसरी कंपनी में चले गए हैं। इसलिए, हमने मान लिया कि इस वर्ष DORA की ओर से कोई शोध या रिपोर्ट नहीं होगी।

रूस में हालात कैसे हैं?

हमने DevOps पर कोई शोध नहीं किया है। हमने सम्मेलनों में बात की, अन्य लोगों के निष्कर्षों को दोहराया, और रायफ़ेसेनबैंक ने 2019 के लिए "डेवऑप्स की स्थिति" का अनुवाद किया (आप हैबे पर उनकी घोषणा पा सकते हैं), उनके लिए बहुत धन्यवाद। और यह सब है.

इसलिए, हमने DORA पद्धतियों और निष्कर्षों का उपयोग करके रूस में अपना स्वयं का शोध किया। हमने अपने शोध के लिए रायफ़ेसेनबैंक के सहकर्मियों की रिपोर्ट का उपयोग किया, जिसमें शब्दावली और अनुवाद का समन्वयन भी शामिल है। और उद्योग-प्रासंगिक प्रश्न DORA रिपोर्ट और इस वर्ष की पपेट प्रश्नावली से लिए गए थे।

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

रिपोर्ट केवल अंतिम भाग है. संपूर्ण शोध प्रक्रिया में चार प्रमुख चरण होते हैं:

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

प्रतिभागियों

सभी विदेशी रिपोर्टें प्रतिभागियों के चित्र के साथ शुरू होती हैं, और उनमें से अधिकांश रूस से नहीं हैं। रूसी उत्तरदाताओं का प्रतिशत साल-दर-साल 5 से 1% तक घटता-बढ़ता रहता है, और यह हमें कोई निष्कर्ष निकालने की अनुमति नहीं देता है।

Accelerate State of DevOps 2019 रिपोर्ट से मानचित्र:

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

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

उद्योग और पद

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

दो में से एक मध्यम आकार की कंपनी के लिए काम करता है। हर तीसरा व्यक्ति बड़ी कंपनियों में काम करता है। अधिकांश 9 लोगों की टीम में काम करते हैं। अलग से, हमने मुख्य गतिविधियों के बारे में पूछा, और अधिकांश किसी न किसी तरह ऑपरेशन से संबंधित हैं, और लगभग 40% विकास में लगे हुए हैं:

इस प्रकार हमने विभिन्न उद्योगों, कंपनियों और टीमों के प्रतिनिधियों की तुलना और विश्लेषण के लिए जानकारी एकत्र की। मेरे सहयोगी विटाली खाबरोव आपको विश्लेषण के बारे में बताएंगे।

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

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

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

प्रमुख मैट्रिक्स

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

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

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

DORA ने अपने शोध में इन मेट्रिक्स और संगठनात्मक प्रदर्शन के बीच एक संबंध पाया है। हम अपने अध्ययन में इसका परीक्षण भी करते हैं।

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

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

हम इसका श्रेय इस तथ्य को देते हैं कि (जैसा कि हमारे कुछ ग्राहकों के साथ विश्लेषण और संचार के दौरान पता चला) जिसे घटना माना जाता है उसकी धारणा में थोड़ा अंतर है। यदि हम तकनीकी विंडो के दौरान अपनी सेवा के प्रदर्शन को बहाल करने में कामयाब रहे, तो क्या इसे एक घटना माना जा सकता है? शायद नहीं, क्योंकि हमने सब कुछ ठीक कर दिया, हम महान हैं। क्या हम इसे एक घटना मान सकते हैं यदि हमें अपने एप्लिकेशन को हमारे लिए सामान्य, परिचित मोड में 10 बार पुनः रोल करना पड़े? ऐसा नहीं लगता. इसलिए, अन्य मेट्रिक्स के साथ असफल परिवर्तनों के संबंध का प्रश्न खुला रहता है। हम इसे और निखारेंगे.

यहां महत्वपूर्ण यह है कि हमें डिलीवरी समय, पुनर्प्राप्ति समय और परिनियोजन आवृत्ति के बीच एक महत्वपूर्ण सहसंबंध मिला। इसलिए, हमने उत्तरदाताओं को प्रदर्शन समूहों में विभाजित करने के लिए इन तीन मैट्रिक्स को लिया।

ग्राम में कितना लटका है?

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

• हम उत्तरदाताओं को एक एन-आयामी स्थान पर वितरित करते हैं, जहां प्रत्येक उत्तरदाता का समन्वय उनके प्रश्नों के उत्तर हैं।
• प्रत्येक उत्तरदाता को एक छोटा समूह घोषित किया जाता है।
• हम एक दूसरे के निकटतम दो समूहों को एक बड़े क्लस्टर में जोड़ते हैं।
• हम समूहों की अगली जोड़ी ढूंढते हैं और उन्हें एक बड़े क्लस्टर में जोड़ते हैं।

इस प्रकार हम अपने सभी उत्तरदाताओं को उन समूहों की संख्या में समूहित करते हैं जिनकी हमें आवश्यकता है। डेंड्रोग्राम (गुच्छों के बीच कनेक्शन का एक पेड़) का उपयोग करके हम दो पड़ोसी समूहों के बीच की दूरी देखते हैं। हमारे लिए बस इतना ही बचा है कि हम इन समूहों के बीच की दूरी पर एक निश्चित सीमा तय करें और कहें: "ये दोनों समूह एक-दूसरे से काफी अलग हैं क्योंकि उनके बीच की दूरी बहुत अधिक है।"

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

इसके बाद, हमने क्लस्टर द्वारा प्रोफ़ाइल निर्धारित की: हमने प्रत्येक समूह के लिए प्रत्येक मीट्रिक के लिए माध्यिकाएँ लीं और दक्षता प्रोफ़ाइल की एक तालिका संकलित की। वास्तव में, प्रत्येक समूह में औसत प्रतिभागी के परिणामी प्रदर्शन प्रोफ़ाइल प्राप्त किए गए थे। हमने तीन दक्षता प्रोफाइल की पहचान की है: निम्न, मध्यम, उच्च:

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

फिर सवाल उठता है कि इन सबका उपयोग कैसे करें?

कैसे उपयोग करें

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

हमने जाँच की: हमने अपने उत्तरदाताओं और DORA प्रदर्शन प्रोफ़ाइल को लिया, और देखा कि कितने उत्तरदाता इस या उस प्रोफ़ाइल में फिट बैठते हैं। हमने पाया कि केवल 16% उत्तरदाता निश्चित रूप से किसी एक प्रोफ़ाइल में शामिल हुए। बाकी सब बीच में कहीं बिखरे हुए हैं:

इसका मतलब है कि प्रदर्शन प्रोफ़ाइल का दायरा सीमित है। आप कहां हैं इसका पहला अनुमान लगाने के लिए, आप इस तालिका का उपयोग कर सकते हैं: "ओह, ऐसा लगता है कि हम मध्यम या उच्च के करीब हैं!" यदि आप समझते हैं कि आप आगे कहाँ जा रहे हैं, तो यह पर्याप्त हो सकता है। लेकिन यदि आपका लक्ष्य निरंतर, निरंतर सुधार है, और आप अधिक सटीक रूप से जानना चाहते हैं कि कहां विकास करना है और क्या करना है, तो अतिरिक्त धन की आवश्यकता है। हमने उन्हें कैलकुलेटर कहा:

• डोरा कैलकुलेटर
• कैलकुलेटर एक्सप्रेस 42* (विकास में)
• आपका स्वयं का विकास (आप अपना स्वयं का आंतरिक कैलकुलेटर बना सकते हैं)।

उनकी क्या आवश्यकता है? समझ में:

• क्या हमारे संगठन की टीम हमारे मानकों को पूरा करती है?
• यदि नहीं, तो क्या हम इसमें मदद कर सकते हैं, हमारी कंपनी के पास मौजूद विशेषज्ञता के ढांचे के भीतर इसे गति दे सकते हैं?
• यदि हां, तो क्या हम और भी बेहतर कर सकते हैं?

आप कंपनी के भीतर आँकड़े एकत्र करने के लिए भी उनका उपयोग कर सकते हैं:

• हमारे पास किस प्रकार की टीमें हैं?
• टीमों को प्रोफ़ाइल में विभाजित करें;
• देखें: ओह, ये टीमें खराब प्रदर्शन कर रही हैं (थोड़ा धीमा), लेकिन ये महान हैं: वे हर दिन तैनात होते हैं, त्रुटियों के बिना, उनका नेतृत्व समय एक घंटे से भी कम है।

और फिर आप पता लगा सकते हैं कि हमारी कंपनी के भीतर हमारे पास उन टीमों के लिए आवश्यक विशेषज्ञता और उपकरण हैं जो अभी भी कम पड़ रहे हैं।

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

अच्छा। और यदि आप DORA कैलकुलेटर पर एलीट समूह में हैं, तो आपको क्या करना चाहिए? यहां कोई अच्छा समाधान नहीं है. आप उद्योग में सबसे आगे होने की संभावना रखते हैं, और आंतरिक अनुसंधान एवं विकास और अधिक संसाधनों को खर्च करने के माध्यम से आगे की गति और विश्वसनीयता संभव है।

आइए सबसे मधुर तुलना की ओर बढ़ते हैं।

तुलना

हम शुरू में रूसी उद्योग की तुलना पश्चिमी उद्योग से करना चाहते थे। यदि हम सीधे तुलना करें, तो हम देखते हैं कि हमारे पास कम प्रोफ़ाइल हैं, और वे एक-दूसरे के साथ थोड़ी अधिक मिश्रित हैं, सीमाएँ थोड़ी अधिक धुंधली हैं:

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

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

लेकिन यह वर्ष विशेष है, और हमने यह जांचने का निर्णय लिया कि कंपनियां महामारी में कैसे जी रही हैं: हाई प्रोफाइल टीमें काफी बेहतर तरीके से सामना करती हैं और उद्योग के औसत से बेहतर महसूस करती हैं:

• नए उत्पाद 1,5-2 गुना अधिक बार जारी किए गए,
• एप्लिकेशन इंफ्रास्ट्रक्चर की विश्वसनीयता और/या प्रदर्शन में 2 गुना अधिक वृद्धि।

अर्थात्, पहले से मौजूद दक्षताओं ने उन्हें तेजी से विकसित होने, नए उत्पाद पेश करने, मौजूदा उत्पादों को संशोधित करने, नए बाजारों और नए उपयोगकर्ताओं पर विजय प्राप्त करने में मदद की:

हमारी टीमों को और किस चीज़ से मदद मिली?

इंजीनियरिंग अभ्यास

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

एक सेवा के रूप में मंच

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

कोड के रूप में बुनियादी ढांचा

यहां सब कुछ काफी मानक है। हमने इन्फ्रास्ट्रक्चर कोड के स्वचालन और इन्फ्रास्ट्रक्चर रिपॉजिटरी के भीतर कितनी जानकारी संग्रहीत है, के बीच एक संबंध पाया। हाई प्रोफाइल टीमें रिपॉजिटरी में अधिक जानकारी संग्रहीत करती हैं: इसमें बुनियादी ढांचा कॉन्फ़िगरेशन, सीआई/सीडी पाइपलाइन, पर्यावरण सेटिंग्स और बिल्ड पैरामीटर शामिल हैं। वे इस जानकारी को अधिक बार संग्रहीत करते हैं, इंफ्रास्ट्रक्चर कोड के साथ बेहतर काम करते हैं, और इंफ्रास्ट्रक्चर कोड के साथ काम करने के लिए अधिक प्रक्रियाओं और कार्यों को स्वचालित करते हैं।

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

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

सबसे उबाऊ अनुभाग, क्योंकि हमने पुष्टि की: आपके पास जितना अधिक स्वचालन होगा, आप कोड के साथ उतना ही बेहतर काम करेंगे, आपको बेहतर परिणाम मिलने की संभावना उतनी ही अधिक होगी।

आर्किटेक्चर

हम यह देखना चाहते थे कि माइक्रोसर्विसेज प्रदर्शन को कैसे प्रभावित करते हैं। ईमानदारी से कहें तो, वे ऐसा नहीं करते हैं, क्योंकि माइक्रोसर्विसेज का उपयोग दक्षता संकेतकों में वृद्धि से जुड़ा नहीं है। माइक्रोसर्विसेज का उपयोग हाई और लो प्रोफाइल दोनों टीमों द्वारा किया जाता है।

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

हमने यह सब कैसे खोजा?

हमारे पास DORA पद्धति को पूरी तरह से दोहराने की एक महत्वाकांक्षी योजना थी, लेकिन संसाधनों की कमी थी। यदि DORA बहुत अधिक प्रायोजन का उपयोग करता है और उनके शोध में आधा साल लगता है, तो हमने अपना शोध कम समय में किया। हम DORA जैसा एक DevOps मॉडल बनाना चाहते थे, और हम भविष्य में ऐसा करेंगे। अब तक हमने खुद को हीट मैप तक ही सीमित रखा है:

हमने प्रत्येक प्रोफ़ाइल में टीमों के बीच इंजीनियरिंग प्रथाओं के वितरण को देखा और पाया कि हाई प्रोफ़ाइल टीमें, औसतन, इंजीनियरिंग प्रथाओं का उपयोग करने की अधिक संभावना रखती थीं। आप इस सब के बारे में हमारे यहां पढ़ सकते हैं रिपोर्ट.

बदलाव के लिए, आइए जटिल आँकड़ों से सरल आँकड़ों की ओर जाएँ।

हमने और क्या खोजा है?

उपकरण

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

ऑर्केस्ट्रेटर्स के बीच, यह किसी के लिए रहस्य नहीं है, कुबेरनेट्स अग्रणी (52%) है। कतार में अगला ऑर्केस्ट्रेटर डॉकर स्वार्म (लगभग 12%) है। सबसे लोकप्रिय सीआई सिस्टम जेनकिंस और गिटलैब हैं। सबसे लोकप्रिय कॉन्फ़िगरेशन प्रबंधन प्रणाली Ansible है, इसके बाद हमारा प्रिय Shell है।

क्लाउड होस्टिंग प्रदाताओं में अमेज़न वर्तमान में अग्रणी स्थान पर है। रूसी बादलों की हिस्सेदारी धीरे-धीरे बढ़ रही है। अगले साल यह देखना दिलचस्प होगा कि रूसी क्लाउड प्रदाता कैसा महसूस करेंगे और क्या उनकी बाजार हिस्सेदारी बढ़ेगी। वे मौजूद हैं, उनका उपयोग किया जा सकता है, और यह अच्छा है:

मैं इगोर को मंच देता हूं, जो कुछ और आंकड़े देंगे।

प्रथाओं का प्रसार

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

एजाइल और डेवऑप्स

एजाइल और डेवऑप्स के बीच संबंध के सवाल पर उद्योग में अक्सर चर्चा होती है। यह मुद्दा 2019/2020 के लिए स्टेट ऑफ़ एजाइल रिपोर्ट में भी उठाया गया है, इसलिए हमने तुलना करने का निर्णय लिया कि कंपनियों में एजाइल और डेवऑप्स गतिविधियाँ कैसे जुड़ी हुई हैं। हमने पाया कि एजाइल के बिना डेवऑप्स दुर्लभ है। आधे उत्तरदाताओं के लिए, एजाइल का प्रसार बहुत पहले शुरू हुआ, और लगभग 20% ने एक साथ शुरुआत देखी, और लो प्रोफाइल के संकेतों में से एक एजाइल और डेवऑप्स प्रथाओं की अनुपस्थिति होगी:

टीम टोपोलॉजी

पिछले वर्ष के अंत में पुस्तक "टीम टोपोलॉजी", जो टीम टोपोलॉजी का वर्णन करने के लिए एक रूपरेखा का प्रस्ताव करता है। हमें आश्चर्य हुआ कि क्या यह रूसी कंपनियों पर लागू होगा। और हमने सवाल पूछा: "आप क्या पैटर्न देखते हैं?"

उत्तरदाताओं में से आधे में इन्फ्रास्ट्रक्चर टीमों के साथ-साथ अलग-अलग विकास, परीक्षण और संचालन टीमों को देखा जाता है। व्यक्तिगत DevOps टीमों ने 45% नोट किया, जिनमें से उच्च प्रतिनिधि अधिक सामान्य हैं। इसके बाद क्रॉस-फ़ंक्शनल टीमें आती हैं, जो हाई में भी अधिक सामान्य हैं। अलग-अलग एसआरई कमांड हाई, मीडियम प्रोफाइल में दिखाई देते हैं और लो प्रोफाइल में शायद ही कभी पाए जाते हैं:

DevQaOps अनुपात

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

2021 वर्ष के लिए योजनाएं

अगले वर्ष के लिए अपनी योजनाओं में, उत्तरदाताओं ने निम्नलिखित गतिविधियों पर ध्यान दिया:

यहां आप DevOps Live 2020 कॉन्फ्रेंस के साथ जुड़ाव देख सकते हैं। हमने कार्यक्रम की सावधानीपूर्वक समीक्षा की:

• एक उत्पाद के रूप में बुनियादी ढाँचा
• डेवऑप्स परिवर्तन
• DevOps प्रथाओं का वितरण
• देवसेकऑप्स
• केस क्लब और चर्चाएँ

लेकिन हमारी प्रस्तुति का समय सभी विषयों को कवर करने के लिए पर्याप्त नहीं है। पर्दे के पीछे छोड़ दिया:

• एक सेवा और एक उत्पाद के रूप में मंच;
• कोड, वातावरण और बादलों के रूप में बुनियादी ढाँचा;
• सतत एकीकरण और वितरण;
• वास्तुकला;
• DevSecOps पैटर्न;
• प्लेटफ़ॉर्म और क्रॉस-फ़ंक्शनल टीमें।

रिपोर्ट हमें एक विशाल, 50 पृष्ठ मिले, और आप इसे और अधिक विस्तार से देख सकते हैं।

उपसंहार

हमें उम्मीद है कि हमारा शोध और रिपोर्ट आपको विकास, परीक्षण और संचालन के लिए नए दृष्टिकोणों के साथ प्रयोग करने के लिए प्रेरित करेगा, साथ ही आपको नेविगेट करने, अध्ययन में अन्य प्रतिभागियों के साथ अपनी तुलना करने और उन क्षेत्रों की पहचान करने में मदद करेगा जहां आप अपने दृष्टिकोण में सुधार कर सकते हैं।

रूस में DevOps की स्थिति के पहले अध्ययन के परिणाम:

• प्रमुख मैट्रिक्स। हमने पाया है कि प्रमुख मेट्रिक्स (डिलीवरी समय, तैनाती आवृत्ति, पुनर्प्राप्ति समय और परिवर्तन विफलताएं) विकास, परीक्षण और संचालन प्रक्रियाओं की प्रभावशीलता का विश्लेषण करने के लिए उपयुक्त हैं।
• प्रोफ़ाइल उच्च, मध्यम, निम्न। एकत्रित आंकड़ों के आधार पर, मेट्रिक्स, प्रथाओं, प्रक्रियाओं और उपकरणों के संदर्भ में विशिष्ट विशेषताओं के साथ उच्च, मध्यम, निम्न के सांख्यिकीय रूप से विभिन्न समूहों को अलग करना संभव है। हाई प्रोफाइल के प्रतिनिधि लो की तुलना में बेहतर परिणाम दिखाते हैं। उनके अपने लक्ष्य हासिल करने और उससे आगे निकलने की संभावना अधिक होती है।
• 2021 के लिए संकेतक, महामारी और योजनाएं। इस वर्ष एक विशेष संकेतक यह है कि कंपनियों ने महामारी से कैसे मुकाबला किया। उच्च प्रतिनिधियों ने बेहतर प्रदर्शन किया, उपयोगकर्ता जुड़ाव में वृद्धि का अनुभव किया, और सफलता का मुख्य कारण कुशल विकास प्रक्रियाएं और एक मजबूत इंजीनियरिंग संस्कृति थी।
• DevOps प्रथाएं, उपकरण और उनका विकास। अगले वर्ष के लिए कंपनियों की मुख्य योजनाओं में DevOps प्रथाओं और उपकरणों का विकास, DevSecOps प्रथाओं की शुरूआत और संगठनात्मक संरचना में बदलाव शामिल हैं। और DevOps प्रथाओं का प्रभावी कार्यान्वयन और विकास पायलट परियोजनाओं, समुदायों और क्षमता केंद्रों के गठन, कंपनी के ऊपरी और निचले स्तरों पर पहल के माध्यम से किया जाता है।

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

स्रोत: www.habr.com