रशिया 2020 मध्ये DevOps राज्य

एखाद्या गोष्टीची स्थिती कशी समजून घ्यावी?

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

परंतु तो दिवस आला आहे जेव्हा असा अभ्यास केला गेला आणि आज आपण परिणामांबद्दल बोलू. रशियामधील DevOps स्थितीचा कंपन्यांनी संयुक्तपणे अभ्यास केला होता "एक्सप्रेस 42"आणि"ओंटिको" Express 42 तंत्रज्ञान कंपन्यांना DevOps पद्धती आणि साधने लागू करण्यात आणि विकसित करण्यात मदत करते आणि रशियामध्ये DevOps बद्दल बोलणाऱ्यांपैकी एक होती. अभ्यासाचे लेखक, इगोर कुरोचकिन आणि व्हिटाली खाबरोव्ह, एक्स्प्रेस 42 वर विश्लेषण आणि सल्लामसलत करण्यात गुंतलेले आहेत, तसेच विविध कंपन्यांमध्ये ऑपरेशन आणि अनुभवाची तांत्रिक पार्श्वभूमी आहे. 8 वर्षांपासून, सहकाऱ्यांनी डझनभर कंपन्या आणि प्रकल्पांकडे पाहिले आहे - स्टार्टअपपासून एंटरप्रायझेसपर्यंत - वेगवेगळ्या समस्यांसह, तसेच भिन्न सांस्कृतिक आणि अभियांत्रिकी परिपक्वता.

त्यांच्या अहवालात, इगोर आणि विटाली यांनी संशोधनाच्या प्रक्रियेत कोणत्या समस्या होत्या, त्यांनी त्या कशा सोडवल्या, तसेच DevOps संशोधन तत्त्वतः कसे केले जाते आणि एक्सप्रेस 42 ने स्वतःचे संचालन करण्याचे का ठरवले हे सांगितले. त्यांचा अहवाल पाहता येईल येथे.

DevOps संशोधन

इगोर कुरोचकिनने संभाषण सुरू केले.

आम्ही नियमितपणे DevOps परिषदांमध्ये प्रेक्षकांना विचारतो, "तुम्ही या वर्षासाठी DevOps स्थिती अहवाल वाचला आहे का?" काहीजण हात वर करतात आणि आमच्या अभ्यासातून असे दिसून आले की फक्त तिसराच त्यांचा अभ्यास करतो. जर तुम्ही असे अहवाल कधीच पाहिले नसतील, तर लगेच सांगूया की ते सर्व समान आहेत. बहुतेकदा असे वाक्ये असतात: "गेल्या वर्षीच्या तुलनेत ..."

येथे आम्हाला पहिली समस्या आहे आणि त्यानंतर आणखी दोन:

1. आमच्याकडे गेल्या वर्षाचा डेटा नाही. रशियामधील DevOps चे राज्य कोणालाच स्वारस्य नाही;
2. कार्यपद्धती. गृहितकांची चाचणी कशी करावी, प्रश्न कसे तयार करावे, विश्लेषण कसे करावे, परिणामांची तुलना कशी करावी, कनेक्शन कसे शोधावे हे स्पष्ट नाही;
3. शब्दावली. सर्व अहवाल इंग्रजीत आहेत, भाषांतर आवश्यक आहे, एक सामान्य DevOps फ्रेमवर्क अद्याप शोधला गेला नाही आणि प्रत्येकजण त्यांच्या स्वत: च्या बरोबर येतो.

जगभरात DevOps राज्य विश्लेषण कसे केले गेले ते पाहू या.

ऐतिहासिक पार्श्वभूमी

2011 पासून DevOps संशोधन केले जात आहे. पपेट, कॉन्फिगरेशन मॅनेजमेंट सिस्टीमचे विकसक, ते आयोजित करणारे पहिले होते. त्या वेळी, कोडच्या स्वरूपात पायाभूत सुविधांचे वर्णन करण्यासाठी ते मुख्य साधनांपैकी एक होते. 2013 पर्यंत, हे अभ्यास फक्त बंद सर्वेक्षण होते आणि सार्वजनिक अहवाल नव्हते.

2013 मध्ये, IT क्रांती दिसू लागली, जी DevOps वरील सर्व प्रमुख पुस्तकांची प्रकाशक होती. पपेट सोबत, त्यांनी पहिले स्टेट ऑफ DevOps प्रकाशन तयार केले, जिथे प्रथमच 4 की मेट्रिक्स दिसल्या. पुढच्या वर्षी, ThoughtWorks, उद्योग पद्धती आणि साधनांवरील नियमित तंत्रज्ञान रडारसाठी ओळखली जाणारी एक सल्लागार कंपनी सहभागी झाली. आणि 2015 मध्ये, पद्धतीसह एक विभाग जोडला गेला आणि ते विश्लेषण कसे करतात हे स्पष्ट झाले.

2016 मध्ये, अभ्यासाच्या लेखकांनी, त्यांची स्वतःची कंपनी DORA (DevOps Research and Assessment) तयार करून, वार्षिक अहवाल प्रकाशित केला. पुढच्या वर्षी, डोरा आणि पपेट यांनी त्यांचा शेवटचा संयुक्त अहवाल प्रसिद्ध केला.

आणि मग काहीतरी मनोरंजक सुरू झाले:

2018 मध्ये, कंपन्या विभाजित झाल्या आणि दोन स्वतंत्र अहवाल प्रसिद्ध झाले: एक पपेटकडून, दुसरा Google सोबत DORA कडून. DORA ने मुख्य मेट्रिक्स, कार्यप्रदर्शन प्रोफाइल आणि मुख्य मेट्रिक्स आणि कंपनी-व्यापी कामगिरीवर परिणाम करणाऱ्या अभियांत्रिकी पद्धतींसह आपल्या कार्यपद्धतीचा लाभ घेणे सुरू ठेवले आहे. आणि पपेटने प्रक्रियेच्या वर्णनासह आणि DevOps च्या उत्क्रांतीसह स्वतःचा दृष्टीकोन ऑफर केला. परंतु कथा मूळ धरू शकली नाही, 2019 मध्ये पपेटने ही पद्धत सोडून दिली आणि अहवालांची एक नवीन आवृत्ती जारी केली, ज्यात मुख्य पद्धती सूचीबद्ध केल्या आहेत आणि त्यांचा त्यांच्या दृष्टिकोनातून DevOps वर कसा परिणाम होतो. मग आणखी एक घटना घडली: Google ने DORA विकत घेतले आणि त्यांनी एकत्रितपणे दुसरा अहवाल जारी केला. तुम्ही त्याला पाहिले असेल.

या वर्षी, गोष्टी गुंतागुंतीच्या झाल्या. पपेटने स्वत:चे सर्वेक्षण सुरू केल्याची माहिती आहे. त्यांनी हे आमच्यापेक्षा एक आठवडा आधी केले होते आणि ते आधीच संपले आहे. आम्ही त्यात भाग घेतला आणि त्यांना कोणत्या विषयात रस आहे ते पाहिले. आता पपेट त्याचे विश्लेषण करत आहे आणि अहवाल प्रकाशित करण्याची तयारी करत आहे.

परंतु अद्याप DORA आणि Google कडून कोणतीही घोषणा नाही. मे मध्ये, जेव्हा सर्वेक्षण सामान्यतः सुरू झाले तेव्हा माहिती आली की DORA च्या संस्थापकांपैकी एक निकोल फोर्सग्रेन दुसर्‍या कंपनीत गेले होते. म्हणून, आम्ही असे गृहीत धरले की यावर्षी 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 लोकांच्या टीममध्ये काम करतात. स्वतंत्रपणे, आम्ही मुख्य क्रियाकलापांबद्दल विचारले, आणि बहुतेक ऑपरेशनशी संबंधित आहेत आणि सुमारे 40% विकासामध्ये गुंतलेले आहेत:

म्हणून आम्ही विविध उद्योग, कंपन्या, संघ यांच्या प्रतिनिधींची तुलना आणि विश्लेषणासाठी माहिती गोळा केली. माझे सहकारी विटाली खाबरोव विश्लेषणाबद्दल सांगतील.

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

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* (विकासात)
• स्वतःचा विकास (आपण स्वतःचे अंतर्गत कॅल्क्युलेटर तयार करू शकता).

ते कशासाठी आवश्यक आहेत? समजून घेणे:

• आमच्या संस्थेतील संघ आमच्या मानकांनुसार आहे का?
• नसल्यास, आमच्या कंपनीकडे असलेल्या कौशल्याच्या चौकटीत आम्ही यास मदत करू शकतो का?
• तसे असल्यास, आपण आणखी चांगले करू शकतो का?

तुम्ही त्यांचा वापर कंपनीमधील आकडेवारी गोळा करण्यासाठी देखील करू शकता:

• आमच्याकडे कोणते संघ आहेत?
• कार्यसंघांना प्रोफाइलमध्ये विभाजित करा;
• पहा: अरे, या आदेश कमी कामगिरी करत आहेत (ते थोडेसे बाहेर काढत नाहीत), परंतु या छान आहेत: ते दररोज तैनात करतात, त्रुटींशिवाय, त्यांच्याकडे एक तासापेक्षा कमी वेळ आहे.

आणि मग आपण शोधू शकता की आमच्या कंपनीमध्ये त्या संघांसाठी आवश्यक कौशल्य आणि साधने आहेत जी अद्याप समतुल्य नाहीत.

किंवा, जर तुम्हाला समजले की तुम्हाला कंपनीमध्ये खूप चांगले वाटते, तुम्ही अनेकांपेक्षा चांगले आहात, तर तुम्ही थोडे विस्तीर्ण दिसू शकता. हे फक्त रशियन उद्योग आहे: स्वतःला गती देण्यासाठी आम्ही रशियन उद्योगात आवश्यक कौशल्य मिळवू शकतो का? एक्सप्रेस 42 कॅल्क्युलेटर येथे मदत करेल (ते विकासाधीन आहे). आपण रशियन बाजार मागे टाकले असल्यास, नंतर पहा DORA कॅल्क्युलेटर आणि जागतिक बाजारपेठेत.

दंड. आणि जर तुम्ही DORA कॅल्क्युलेटरवर एलिट गटात असाल तर तुम्ही काय करावे? येथे कोणताही चांगला उपाय नाही. तुम्ही उद्योगात बहुधा आघाडीवर आहात आणि अंतर्गत R&D आणि अधिक संसाधने खर्च करून पुढील प्रवेग आणि विश्वासार्हता शक्य आहे.

चला सर्वात गोड - तुलनाकडे जाऊया.

तुलना

आम्हाला सुरुवातीला रशियन उद्योगाची पाश्चात्य उद्योगाशी तुलना करायची होती. जर आपण थेट तुलना केली तर आपण पाहतो की आपल्याकडे कमी प्रोफाइल आहेत आणि ते एकमेकांशी थोडे अधिक मिसळलेले आहेत, सीमा थोड्या अधिक अस्पष्ट आहेत:

आमचे एलिट कलाकार उच्च कलाकारांमध्ये लपलेले आहेत, परंतु ते तेथे आहेत - हे उच्चभ्रू, युनिकॉर्न आहेत ज्यांनी लक्षणीय उंची गाठली आहे. रशियामध्ये, एलिट प्रोफाइल आणि हाय प्रोफाइलमधील फरक अद्याप पुरेसा लक्षणीय नाही. आम्हाला वाटते की भविष्यात अभियांत्रिकी संस्कृतीत वाढ, अभियांत्रिकी पद्धतींच्या अंमलबजावणीची गुणवत्ता आणि कंपन्यांमधील कौशल्य यामुळे हे वेगळे होईल.

जर आपण रशियन उद्योगात थेट तुलना केली तर आपण पाहू शकतो की हाय प्रोफाईल संघ सर्व बाबतीत चांगले आहेत. आम्ही आमच्या गृहीतकाची पुष्टी केली की या मेट्रिक्स आणि संस्थात्मक कार्यप्रदर्शन यांच्यात एक संबंध आहे: उच्च प्रोफाइल कार्यसंघ केवळ उद्दिष्टेच साध्य करत नाहीत तर ते ओलांडतात.
चला हाय प्रोफाईल टीम बनू आणि तिथेच थांबू नका:

परंतु हे वर्ष विशेष आहे आणि आम्ही साथीच्या आजारात कंपन्या कसे काम करत आहेत हे तपासण्याचे ठरविले: उच्च प्रोफाइल कार्यसंघ उद्योगाच्या सरासरीपेक्षा बरेच चांगले काम करत आहेत आणि चांगले वाटत आहेत:

• नवीन उत्पादने सोडण्याची शक्यता 1,5-2 पट जास्त,
• अॅप्लिकेशन इन्फ्रास्ट्रक्चरची विश्वासार्हता आणि/किंवा कार्यप्रदर्शन सुधारण्याची 2 पट अधिक शक्यता.

म्हणजेच, ज्या क्षमतांनी त्यांना आधीच जलद विकसित करण्यात, नवीन उत्पादने लाँच करण्यात, विद्यमान उत्पादनांमध्ये सुधारणा करण्यात, नवीन बाजारपेठा आणि नवीन वापरकर्त्यांना जिंकण्यात मदत केली होती:

आमच्या संघांना आणखी कशाने मदत केली?

अभियांत्रिकी पद्धती

आम्ही चाचणी केलेल्या प्रत्येक सरावाच्या महत्त्वपूर्ण निष्कर्षांबद्दल मी तुम्हाला सांगेन. कदाचित संघांना आणखी काहीतरी मदत केली असेल, परंतु आम्ही DevOps बद्दल बोलत आहोत. आणि DevOps मध्ये, आम्हाला वेगवेगळ्या प्रोफाइलच्या संघांमध्ये फरक दिसतो.

सेवा म्हणून प्लॅटफॉर्म

आम्हाला प्लॅटफॉर्म वय आणि कार्यसंघ प्रोफाइलमध्ये महत्त्वपूर्ण संबंध आढळला नाही: निम्न-संघ आणि उच्च-संघ दोन्हीसाठी प्लॅटफॉर्म्स एकाच वेळी दिसू लागले. परंतु नंतरच्यासाठी, प्लॅटफॉर्म प्रोग्राम कोडद्वारे नियंत्रणासाठी सरासरी, अधिक सेवा आणि अधिक प्रोग्रामिंग इंटरफेस प्रदान करते. आणि प्लॅटफॉर्म संघ त्यांच्या विकसकांना आणि संघांना प्लॅटफॉर्म वापरण्यात, त्यांच्या समस्या आणि प्लॅटफॉर्मशी संबंधित घटनांचे निराकरण करण्यात आणि इतर संघांना शिक्षित करण्यात मदत करण्याची अधिक शक्यता असते.

कोड म्हणून पायाभूत सुविधा

येथे सर्व काही अगदी मानक आहे. इन्फ्रास्ट्रक्चर कोडचे काम स्वयंचलित करणे आणि इन्फ्रास्ट्रक्चर रिपॉजिटरीमध्ये किती माहिती साठवली जाते यामधील संबंध आम्हाला आढळला आहे. हाय प्रोफाईल कमांड रिपॉजिटरीजमध्ये अधिक माहिती साठवतात: हे इन्फ्रास्ट्रक्चर कॉन्फिगरेशन, CI/CD पाइपलाइन, पर्यावरण सेटिंग्ज आणि बिल्ड पॅरामीटर्स आहे. ते ही माहिती अधिक वेळा संग्रहित करतात, पायाभूत सुविधा कोडसह चांगले कार्य करतात आणि पायाभूत सुविधा कोडसह कार्य करण्यासाठी अधिक प्रक्रिया आणि कार्ये स्वयंचलित करतात.

विशेष म्हणजे पायाभूत सुविधांच्या चाचण्यांमध्ये आम्हाला फारसा फरक दिसला नाही. मी याचे श्रेय देतो की हाय प्रोफाईल संघांमध्ये सर्वसाधारणपणे अधिक चाचणी ऑटोमेशन असते. कदाचित ते इन्फ्रास्ट्रक्चर चाचण्यांद्वारे वेगळे विचलित होऊ नयेत, तर त्या चाचण्या ज्याद्वारे ते अनुप्रयोग तपासतात आणि त्यांच्यामुळे ते काय आणि कोठे मोडले आहेत हे त्यांना आधीच दिसत आहे.

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

सर्वात कंटाळवाणा विभाग, कारण आम्ही पुष्टी केली आहे की तुमच्याकडे जितके अधिक ऑटोमेशन असेल, तुम्ही कोडसह जितके चांगले कार्य कराल तितके चांगले परिणाम मिळण्याची शक्यता जास्त आहे.

आर्किटेक्चर

मायक्रोसर्व्हिसेस कार्यक्षमतेवर कसा परिणाम करतात हे आम्हाला पहायचे होते. खरेतर, ते तसे करत नाहीत, कारण मायक्रोसर्व्हिसेसचा वापर कार्यक्षमता निर्देशकांच्या वाढीशी संबंधित नाही. हाय प्रोफाईल कमांड आणि लो प्रोफाईल कमांड या दोन्हीसाठी मायक्रो सर्व्हिसेसचा वापर केला जातो.

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

आम्हाला हे सर्व कसे कळले?

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

आम्‍ही प्रत्‍येक प्रोफाईलमध्‍ये संघांमध्‍ये अभियांत्रिकी सरावांचे वितरण पाहिले आणि असे आढळले की, हाय प्रोफाईल संघ, सरासरी, अभियांत्रिकी पद्धती वापरण्‍याची अधिक शक्यता असते. आपण या सर्वांबद्दल आमच्यामध्ये अधिक वाचू शकता अहवाल.

बदलासाठी, चला जटिल आकडेवारीवरून साध्या आकडेवारीकडे जाऊ या.

आम्ही आणखी काय शोधले आहे?

साधने

आम्‍ही पाहतो की बहुतांश कमांडस् लिनक्स कुटुंबातील OS वापरतात. परंतु विंडोज अजूनही ट्रेंडमध्ये आहे - आमच्या प्रतिसादकर्त्यांपैकी किमान एक चतुर्थांश लोकांनी त्याच्या एक किंवा दुसर्या आवृत्त्यांचा वापर केला आहे. मार्केटला ही गरज असल्याचे दिसते. म्हणून, आपण या क्षमता विकसित करू शकता आणि परिषदांमध्ये सादरीकरण करू शकता.

ऑर्केस्ट्रेटर्समध्ये, हे कोणासाठीही गुप्त नाही, कुबर्नेट्स आघाडीवर आहेत (52%). पुढचा इन लाइन ऑर्केस्ट्रेटर आहे डॉकर स्वॉर्म (सुमारे 12%). जेनकिन्स आणि गिटलॅब या सर्वात लोकप्रिय सीआय सिस्टम आहेत. सर्वात लोकप्रिय कॉन्फिगरेशन व्यवस्थापन प्रणाली उत्तरदायी आहे, त्यानंतर आमचे प्रिय शेल आहे.

Amazon सध्या आघाडीचे क्लाउड होस्टिंग प्रदाता आहे. रशियन ढगांचा वाटा हळूहळू वाढत आहे. पुढील वर्षी हे पाहणे मनोरंजक असेल की रशियन क्लाउड प्रदात्यांना कसे वाटेल, त्यांचा बाजारातील हिस्सा वाढेल का. ते आहेत, ते वापरले जाऊ शकतात आणि ते चांगले आहे:

मी मजला इगोरकडे देतो, जो आणखी काही आकडेवारी देईल.

पद्धतींचा प्रसार

इगोर कुरोचकिन: स्वतंत्रपणे, आम्ही प्रतिसादकर्त्यांना कंपनीमध्ये अभियांत्रिकी पद्धती कशा वितरित केल्या जातात हे सूचित करण्यास सांगितले. बर्‍याच कंपन्यांमध्ये, एक मिश्रित दृष्टीकोन आहे, ज्यामध्ये भिन्न नमुन्यांचा समावेश आहे आणि पायलट प्रकल्प खूप लोकप्रिय आहेत. आम्ही प्रोफाइलमध्ये थोडा फरक देखील पाहिला. उच्च प्रोफाइलचे प्रतिनिधी अधिक वेळा "खालीलकडून पुढाकार" पॅटर्न वापरतात, जेव्हा तज्ञांचे छोटे संघ कार्य प्रक्रिया, साधने बदलतात आणि इतर कार्यसंघांसह यशस्वी पद्धती सामायिक करतात. माध्यमात, हा एक टॉप-डाउन उपक्रम आहे जो समुदाय आणि उत्कृष्टता केंद्रांच्या निर्मितीद्वारे संपूर्ण कंपनीला प्रभावित करतो:

चपळ आणि DevOps

Agile आणि DevOps यांच्यातील कनेक्शनचा प्रश्न उद्योगात अनेकदा चर्चिला जातो. 2019/2020 च्या स्टेट ऑफ चपळ अहवालात देखील हा मुद्दा उपस्थित केला गेला आहे, म्हणून आम्ही कंपन्यांमध्ये Agile आणि DevOps क्रियाकलाप कसे जोडलेले आहेत याची तुलना करण्याचे ठरवले आहे. आम्हाला आढळले की चपळ नसलेली DevOps दुर्मिळ आहे. निम्म्या प्रतिसादकर्त्यांसाठी, चपळाचा प्रसार खूप आधी सुरू झाला आणि सुमारे 20% लोकांनी एकाच वेळी सुरू झाल्याचे निरीक्षण केले, आणि निम्न प्रोफाइलचे एक लक्षण म्हणजे चपळ आणि DevOps पद्धतींची अनुपस्थिती आहे:

कमांड टोपोलॉजीज

गेल्या वर्षाच्या शेवटी, पुस्तकटीम टोपोलॉजीज", जे कमांड टोपोलॉजीजचे वर्णन करण्यासाठी एक फ्रेमवर्क प्रस्तावित करते. ते रशियन कंपन्यांना लागू आहे की नाही हे आमच्यासाठी मनोरंजक झाले. आणि आम्ही प्रश्न विचारला: "तुम्हाला कोणते नमुने सापडले?".

निम्म्या उत्तरदात्यांमध्ये पायाभूत सुविधा कार्यसंघ, तसेच विकास, चाचणी आणि ऑपरेशनसाठी स्वतंत्र संघांचे निरीक्षण केले जाते. विभक्त DevOps संघांनी 45% नोंदवले, ज्यामध्ये उच्च प्रतिनिधी अधिक सामान्य आहेत. पुढे क्रॉस-फंक्शनल टीम्स येतात, जे उच्च वर देखील अधिक सामान्य आहेत. वेगळ्या SRE कमांड्स उच्च, मध्यम प्रोफाइलमध्ये दिसतात आणि क्वचितच निम्न प्रोफाइलमध्ये दिसतात:

DevQaOps प्रमाण

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

2021 साठी योजना

पुढील वर्षाच्या योजनांमध्ये, प्रतिसादकर्त्यांनी खालील क्रियाकलापांची नोंद केली:

येथे तुम्ही DevOps Live 2020 परिषदेचे छेदनबिंदू पाहू शकता. आम्ही कार्यक्रमाचे काळजीपूर्वक पुनरावलोकन केले:

• उत्पादन म्हणून पायाभूत सुविधा
• DevOps परिवर्तन
• DevOps पद्धतींचे वितरण
• DevSecOps
• केस क्लब आणि चर्चा

परंतु आमच्या सादरीकरणाचा वेळ सर्व विषयांचा समावेश करण्यासाठी पुरेसा नाही. पडद्यामागे बाकी:

• एक सेवा आणि उत्पादन म्हणून प्लॅटफॉर्म;
• कोड, वातावरण आणि ढग म्हणून पायाभूत सुविधा;
• सतत एकत्रीकरण आणि वितरण;
• आर्किटेक्चर;
• DevSecOps नमुने;
• प्लॅटफॉर्म आणि क्रॉस-फंक्शनल संघ.

अहवाल द्या आम्हाला एक विपुल, 50 पृष्ठे मिळाली आणि तुम्ही ते अधिक तपशीलाने पाहू शकता.

गोळा करीत आहे

आम्हाला आशा आहे की आमचे संशोधन आणि अहवाल तुम्हाला विकास, चाचणी आणि ऑपरेशन्ससाठी नवीन पध्दतींचा प्रयोग करण्यास प्रेरणा देईल, तसेच तुम्हाला नेव्हिगेट करण्यात, अभ्यासातील इतर सहभागींशी तुमची तुलना करण्यात आणि तुम्ही तुमची स्वतःची दृष्टीकोन सुधारू शकता अशी क्षेत्रे ओळखण्यास मदत करतील.

रशियामधील DevOps राज्याच्या पहिल्या अभ्यासाचे परिणाम:

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

आम्हाला तुमचा अभिप्राय, कथा, अभिप्राय ऐकायला आवडेल. आम्ही अभ्यासात सहभागी झालेल्या प्रत्येकाचे आभार मानतो आणि पुढच्या वर्षी तुमच्या सहभागाची अपेक्षा करतो.

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