DORA रिपोर्ट 2019: DevOps दक्षता में सुधार कैसे करें

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

टीम Mail.ru क्लाउड सॉल्यूशंस से सबसे दिलचस्प अनुवाद किया गया 2019 डेवऑप्स रिपोर्ट की त्वरित स्थिति, DevOps रिसर्च एंड असेसमेंट (DORA) विशेषज्ञों द्वारा संकलित। इस अध्ययन में दुनिया भर से 31 विशेषज्ञ शामिल थे। आइए एक नजर डालते हैं कि 000 में उद्योग में क्या बदलाव आया और व्यवसाय अपनी सॉफ्टवेयर डिलीवरी दक्षता में कैसे सुधार कर सकते हैं।

उद्योग और कंपनी का आकार DevOps की स्थिति को कैसे प्रभावित करता है

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

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

किसी कंपनी में DevOps के स्तर का आकलन कैसे करें

विशेषज्ञों ने DevOps प्रक्रियाओं की तुलना एक बेंचमार्क से की, सर्वेक्षण उत्तरदाताओं को सर्वश्रेष्ठ, अच्छे, औसत और खराब प्रदर्शन करने वालों के चार समूहों में विभाजित किया।

रिपोर्ट के लिए, हमने DevOps की प्रभावशीलता का आकलन करने के लिए चार प्रमुख मेट्रिक्स लिए: सॉफ़्टवेयर विकास में परिवर्तन पूरा करने का समय, परिनियोजन आवृत्ति, विफलता दर और पुनर्प्राप्ति समय।

DevOps के चार स्तर - आकलन करें कि आपकी कंपनी कहाँ है:

कंपनी की मुख्य सेवाओं और अनुप्रयोगों के लिए सॉफ़्टवेयर वितरण की प्रभावशीलता का आकलन करने के लिए एक मीट्रिक

सर्वश्रेष्ठ रिकॉर्ड वाली टीमें

अच्छा प्रदर्शन करने वाली टीमें

औसत टीमें

कम प्रदर्शन करने वाली टीमें

परिनियोजन आवृत्ति
कंपनी कितनी बार कोड को उत्पादन में तैनात करती है या अंतिम उपयोगकर्ताओं के लिए इसे जारी करती है।

अनुरोध पर, प्रति दिन एकाधिक तैनाती

दिन में एक बार से लेकर सप्ताह में एक बार तक

सप्ताह में एक बार से लेकर महीने में एक बार तक

महीने में एक बार/कई महीनों में

निष्पादन समय बदलें
परीक्षण से सॉफ़्टवेयर के उत्पादन में सफलतापूर्वक चलने में कितना समय लगता है?

एक दिन से भी कम

एक दिन से एक सप्ताह तक

एक सप्ताह से एक माह तक

एक महीने से लेकर छह महीने तक

सेवा पुनर्प्राप्ति समय
उपयोगकर्ताओं को प्रभावित करने वाली किसी घटना या बग के बाद किसी सेवा को बहाल करने में कितना समय लगता है।

एक घंटे से कम

दिन के दौरान

एक सप्ताह में

एक हफ्ते से लेकर एक महीने तक

विफलता दर बदलें
कितने प्रतिशत अपडेट या नई रिलीज़ के परिणामस्वरूप सेवा ख़राब होती है और सुधार की आवश्यकता होती है?

0-15%

0-15%

0-15%

46-60%

अध्ययन से निम्नलिखित प्रवृत्ति का पता चला: उच्च प्रदर्शन करने वाली टीमों की संख्या लगभग तीन गुना हो गई, जो 7 में सभी उत्तरदाताओं के 2018% से बढ़कर 20 में 2019% हो गई।

प्रदर्शन स्तर के आधार पर विकास टीमों का वितरण।

कम प्रदर्शन करने वाले समूह की टीमों की तुलना में, उच्च प्रदर्शन करने वाली DevOps टीमें:

1. 208 गुना अधिक कोड परिनियोजन निष्पादित किया गया।
2. कोड परिनियोजन पर 106 गुना कम समय खर्च किया गया।
3. हमें 7 गुना कम असफलताओं का सामना करना पड़ा।
4. विफलताओं के बाद सॉफ्टवेयर को 2,604 गुना तेजी से बहाल किया गया।

इसके अतिरिक्त, उच्च प्रदर्शन करने वाली DevOps टीमों के कम प्रदर्शन करने वाली टीमों की तुलना में अपने संगठनात्मक प्रदर्शन मेट्रिक्स को पूरा करने या उनसे आगे निकलने की संभावना दोगुनी है।

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

मुझे DevOps टीमों की संख्या में वृद्धि में कोई आश्चर्य की बात नहीं दिखती; यह स्वाभाविक है: DevOps दर्शन अब लोकप्रिय है, और स्टार्टअप की संख्या बढ़ रही है।

लेकिन, मेरी राय में, विशेषज्ञों ने DevOps की प्रभावशीलता का आकलन करने के लिए पूरी तरह से सही पैरामीटर नहीं चुने।

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

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

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

डेनिस रोमानेंको, Mail.ru क्लाउड सॉल्यूशंस के फ्रीलांस विशेषज्ञ

DevOps प्रक्रियाओं को कैसे सुधारें

रिपोर्ट दो क्षेत्रों को प्रस्तुत करती है जो DevOps को बेहतर बनाने में मदद करेंगे: सॉफ़्टवेयर विकास और वितरण की दक्षता बढ़ाना और कार्यकर्ता उत्पादकता में सुधार करना।

प्रत्येक क्षेत्र के अपने घटक शामिल हैं, जिनमें सुधार करके आप वांछित लक्ष्य प्राप्त कर सकते हैं।

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

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

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

डेनिस रोमानेंको, Mail.ru क्लाउड सॉल्यूशंस के फ्रीलांस विशेषज्ञ

नीचे हम DevOps टीमों की दक्षता में सुधार के कुछ घटकों पर नज़र डालेंगे।

क्लाउड प्रौद्योगिकियाँ DevOps को सफल बनाती हैं

2019 में, अधिक से अधिक संगठन क्लाउड समाधान चुन रहे हैं जो DevOps टीमों की उत्पादकता में उल्लेखनीय वृद्धि करते हैं।

DevOps टीमें किस बुनियादी ढांचे का उपयोग करती हैं?

डोरा ने पाया कि 80% उत्तरदाता स्थान पर हैं क्लाउड प्लेटफ़ॉर्म पर मुख्य एप्लिकेशन या सेवाएँ. हालाँकि, केवल 29% उत्तरदाताओं ने नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी के सभी पांच मुख्य क्लाउड विशेषताओं को लागू किया है - जो DevOps के भीतर क्लाउड के मूल्य का आकलन करने के लिए सबसे महत्वपूर्ण मानक है।

लक्षण वर्णन

उपयोगकर्ताओं का प्रतिशत

मांग पर स्व-सेवा
उपभोक्ता स्वचालित रूप से कंप्यूटिंग संसाधनों का प्रावधान कर सकते हैं
आवश्यकतानुसार, प्रदाता की भागीदारी के बिना।

57% तक
(11 से +2018%)

व्यापक नेटवर्क पहुंच
क्लाउड क्षमताएं विभिन्न प्लेटफार्मों के माध्यम से उपलब्ध हैं,
जैसे मोबाइल फोन, टैबलेट, लैपटॉप और वर्कस्टेशन।

60% तक
(14 से +2018%)

संसाधन संग्रह
प्रदाता के संसाधनों को एक बहु-किरायेदार मॉडल में संयोजित किया जाता है, जहां भौतिक और आभासी संसाधनों को मांग पर गतिशील रूप से सौंपा जाता है।

58% तक
(15 से +2018%)

मापनीयता और लोच
मांग के अनुसार संसाधनों का पैमाना क्षैतिज या लंबवत होता है, वे व्यावहारिक रूप से असीमित होते हैं और किसी भी समय किसी भी मात्रा में जारी किए जा सकते हैं।

58% तक
(135 से +2018)

पारदर्शिता
क्लाउड सिस्टम सेवा के प्रकार के आधार पर संसाधन उपयोग की स्वचालित रूप से निगरानी, ​​अनुकूलन और रिपोर्ट करते हैं: डेटा भंडारण और प्रसंस्करण, ट्रैफ़िक की मात्रा,
सक्रिय उपयोगकर्ता खाते.

62% तक
(14 से +2018%)

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

क्लाउड प्रदाताओं के लिए, विभिन्न प्रकार की सेवाओं का प्रावधान एक सार्वभौमिक मानक बनता जा रहा है: वर्चुअल मशीन नेटवर्किंग, पहचान और एक्सेस प्रबंधन (IAM), स्टोरेज और डेटाबेस, मशीन लर्निंग, इंटरनेट ऑफ थिंग्स (IoT), कंटेनर समाधान, सुरक्षा समाधान और अन्य। .

क्लाउड प्रदाताओं के ग्राहक केवल उनके द्वारा उपयोग किए जाने वाले संसाधनों के लिए भुगतान करते हैं, जो लागत पारदर्शिता प्रदान करता है, पारंपरिक डेटा केंद्रों के विपरीत जहां विकास लागत पर जानकारी प्राप्त करना मुश्किल या असंभव है। ऊपर सूचीबद्ध क्लाउड विशेषताओं को पूरा करने वाली कंपनियों के उत्तरदाताओं द्वारा सॉफ़्टवेयर चलाने की लागत का सटीक अनुमान लगाने की संभावना 2,6 गुना अधिक है, यह समझने की संभावना 2 गुना अधिक है कि किन अनुप्रयोगों को अधिक संसाधनों की आवश्यकता है, और उनके आईटी बजट के भीतर रहने की संभावना 1,65 गुना अधिक है।

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

डेनिस रोमानेंको, Mail.ru क्लाउड सॉल्यूशंस के फ्रीलांस विशेषज्ञ

DevOps तकनीकी अभ्यास

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

ऐसा कहा जा रहा है कि, ऐसे सामान्य क्षेत्र हैं जो DevOps प्रदर्शन को बेहतर बनाने में मदद कर सकते हैं: कुछ को टीम स्तर पर विकसित किया जाता है, अन्य को संगठनात्मक स्तर पर प्रयासों की आवश्यकता होती है।

2019 में DevOps टीमों के लिए विकास के किन क्षेत्रों पर प्रकाश डाला गया है:

संगठनात्मक स्तर पर

• शिथिल युग्मित वास्तुकला
• परिवर्तनों का कार्यान्वयन
• कोड समर्थन

टीम स्तर पर

• लगातार एकीकरण
• परीक्षण स्वचालन
• तैनाती स्वचालन
• निगरानी
• विकास पाइपलाइन

टीम और संगठन स्तर पर

• क्लाउड सेवाओं का उपयोग
• आपदा पुनर्प्राप्ति परीक्षण

अध्ययन ने DevOps प्रदर्शन पर शिथिल युग्मित आर्किटेक्चर के सकारात्मक प्रभाव की पुष्टि की।

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

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

डेनिस रोमानेंको, Mail.ru क्लाउड सॉल्यूशंस के फ्रीलांस विशेषज्ञ

सफल DevOps टीमें हर चीज़ को स्वचालित करती हैं

सतत एकीकरण और वितरण (सीआई/सीडी) आपको कम लागत और जोखिम के साथ सेवाओं और अनुप्रयोगों को उत्पादन में जारी करने की अनुमति देता है, साथ ही संगठन के लक्ष्यों के अनुसार रिलीज का समर्थन भी करता है।

सफल सीआई/सीडी का मतलब यह भी है कि टीमें मांग के अनुसार उत्पादन में बदलाव कर सकती हैं, तैनाती की गुणवत्ता पर तत्काल प्रतिक्रिया दे सकती हैं, और अगले तैनाती चक्र को बेहतर बनाने के लिए उस पर तुरंत कार्रवाई कर सकती हैं।

रिपोर्ट से पता चलता है कि सफल DevOps टीमें सहायक प्रक्रियाओं, प्रथाओं और उपकरणों की एक विस्तृत श्रृंखला में निवेश करती हैं:

• 92% स्वचालित असेंबली टूल का उपयोग करते हैं;
• 87% स्वचालित इकाई परीक्षणों का उपयोग करते हैं;
• 57% ने स्वचालन को स्वीकृति परीक्षण तक बढ़ाया;
• 72% परीक्षण वातावरण में तैनाती को स्वचालित करते हैं, 69% उत्पादन में तैनाती के लिए भी ऐसा ही करते हैं;
• 69% ने चैटबॉट्स को परिनियोजन प्रक्रिया में एकीकृत किया;
• 57% निगरानी उपकरणों के साथ एकीकृत हैं।

सही उपकरण और तकनीक चुनना महत्वपूर्ण है

जटिल प्रणालियों का निर्माण करते समय और व्यवसाय-महत्वपूर्ण बुनियादी ढांचे का प्रबंधन करते समय, प्रौद्योगिकियों का चयन करना महत्वपूर्ण है:

• जिन्हें पहले कनेक्शन और निरंतर उपयोग दोनों के लिए उपयोग करना आसान है;
• जो आपको अपने लक्ष्य हासिल करने में मदद करता है।

रिपोर्ट में सीआई/सीडी और टेस्ट ऑटोमेशन टूल के माध्यम से सॉफ़्टवेयर तैनात करते समय उपयोग किए जाने वाले टूल की जांच की गई - ये वे प्रौद्योगिकियां हैं जो DevOps का आधार हैं।

DevOps टीमें किन तकनीकों का उपयोग करती हैं:

प्रौद्योगिकी

कम प्रदर्शन करने वाली टीमें

औसत टीमें

अच्छा प्रदर्शन करने वाली टीमें

उच्च प्रदर्शन करने वाली टीमें

मालिकाना, खुला स्रोत और वाणिज्यिक पैकेज्ड उत्पादों का संयोजन

30% तक

34% तक

32% तक

33% तक

मुख्य रूप से खुला स्रोत और अत्यधिक अनुकूलित पैकेज्ड समाधान

17% तक

8%

7%

10% तक

अधिकतर खुले स्रोत और थोड़े अनुकूलन के साथ पैकेज्ड समाधान

14% तक

21% तक

18% तक

20% तक

मुख्य रूप से बॉक्सिंग वाणिज्यिक समाधान

8%

12% तक

8%

4%

कंपनी के लिए आंतरिक विकास और मालिकाना समाधान

20% तक

6%

5%

6%

मजबूत अनुकूलन के साथ मुख्य रूप से खुला स्रोत

6%

7%

5%

12% तक

थोड़े से अनुकूलन के साथ मुख्य रूप से खुला स्रोत

5%

12% तक

24% तक

15% तक

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

मेरी राय में, यह तालिका यह एहसास दिलाती है कि एक सफल DevOps टीम बनने के लिए, आपको तकनीकी समस्या का नहीं, बल्कि फैशन का पालन करने की आवश्यकता है।

एक सक्षम विशेषज्ञ कार्य के लिए उपकरण चुनता है, न कि इसके विपरीत। किसी भी समस्या को हल करने के लिए हमेशा कई उपकरण और दृष्टिकोण होते हैं। एक विशिष्ट उपकरण निम्न द्वारा निर्धारित किया जाता है: कार्य की विशिष्टताएँ; कर्मचारी इस उपकरण से कितना परिचित है (यदि उपकरण नया है तो प्रवेश सीमा कितनी अधिक है); वित्तीय घटक, यदि मौजूद हो।

डेनिस रोमानेंको, Mail.ru क्लाउड सॉल्यूशंस के फ्रीलांस विशेषज्ञ

आपदा बहाली

प्रत्येक संगठन जिसका संचालन सॉफ्टवेयर के संचालन पर निर्भर करता है, के पास होना चाहिए आपदा पुनर्प्राप्ति योजना. रिपोर्ट से पता चलता है कि विभिन्न कंपनियां किस प्रकार के आपदा लचीलापन परीक्षण का उपयोग करती हैं।

आपदा निवारण के लिए कंपनियाँ किस प्रकार के परीक्षण का उपयोग करती हैं?

परीक्षण का प्रकार

कम प्रदर्शन करने वाली टीमें

औसत टीमें

अच्छा प्रदर्शन करने वाली टीमें

उच्च प्रदर्शन करने वाली टीमें

औसत

ऐसे परीक्षण जो वास्तविक प्रणालियों को प्रभावित नहीं करते

35% तक

26% तक

27% तक

30% तक

28% तक

इन्फ्रास्ट्रक्चर फेलओवर (डेटा सेंटर सहित)

27% तक

43% तक

34% तक

38% तक

38% तक

अनुप्रयोग विफलता परीक्षण

25% तक

46% तक

41% तक

49% तक

43% तक

परीक्षण प्रणालियों में व्यवधान से जुड़ी घटनाओं का अनुकरण

18% तक

22% तक

23% तक

29% तक

23% तक

कार्य प्रणालियों में व्यवधान से जुड़ी घटनाओं का अनुकरण

18% तक

11% तक

12% तक

13% तक

12% तक

स्वचालन और ऐसी प्रणालियाँ बनाना जो बाधित करती हैं
नियमित, निरंतर आधार पर उत्पादन प्रणालियाँ

9%

8%

7%

9%

8%

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

DevOps टीमों को जानकारी तक पहुंच प्रदान करना महत्वपूर्ण है

समस्याओं को हल करने के लिए आसानी से जानकारी ढूंढने से DevOps टीमों को उत्पादक बनाए रखने में मदद मिल सकती है। यह आज के प्रौद्योगिकी परिवेश में विशेष रूप से सच है, जिसमें जटिल प्रणालियाँ शामिल हैं।

ऐसी जानकारी के स्रोतों को दो समूहों में विभाजित किया जा सकता है:

1. आंतरिक स्रोत: कोड, कॉर्पोरेट ज्ञान आधार, रिपॉजिटरी और बहुत कुछ बनाने और बनाए रखने पर कंपनी दस्तावेज़ीकरण। आंतरिक ज्ञान स्रोतों का उपयोग करने वाली DevOps टीमें 1,73 गुना अधिक उत्पादक थीं।
2. बाहरी स्रोत: खोज इंजन और स्टैक पूर्णता। आउटसोर्स की गई DevOps टीमें 1,67 गुना अधिक उत्पादक थीं। बाहरी प्रौद्योगिकियाँ सीखने और विकास के लिए एक बड़ा लाभ प्रदान करती हैं, विशेष रूप से सार्वजनिक क्लाउड और ओपन सोर्स टूल का उपयोग।

कंपनियों के लिए तकनीकी कर्ज कम करना जरूरी है

तकनीकी ऋण में ज्ञात लेकिन ठीक न किए गए बग वाले कोड या सिस्टम शामिल हैं; अपर्याप्त परीक्षण कवरेज; निम्न गुणवत्ता कोड या डिज़ाइन; कलाकृतियाँ जिनका उपयोग नहीं किया गया है लेकिन हटाया नहीं गया है; कार्यान्वयन जिनका टीम प्रभावी ढंग से समर्थन नहीं कर सकती; पुरानी प्रौद्योगिकियाँ; अधूरा या पुराना दस्तावेज़।

विशेषज्ञों ने पाया है कि तकनीकी ऋण DevOps प्रदर्शन पर नकारात्मक प्रभाव डालता है। उच्च तकनीकी ऋण वाली टीमें 1,6 गुना कम उत्पादक थीं। उच्च प्रदर्शन वाली टीमों पर कम तकनीकी ऋण होने की संभावना 1,4 गुना अधिक थी।

DevOps अध्ययन की स्थिति से मुख्य निष्कर्ष

1. उच्च प्रदर्शन वाली DevOps टीमों का प्रतिशत लगभग तीन गुना होकर 20% हो गया है। इसका मतलब यह है कि व्यवसाय सॉफ्टवेयर विकास और वितरण में सुधार के लिए प्रथाओं के वादे को समझते हैं, और कंपनियां अपने आईटी विभागों में अधिक सक्रिय रूप से DevOps को लागू कर रही हैं।
2. अनुप्रयोगों और सेवाओं की तीव्र डिलीवरी प्रौद्योगिकी और संगठनात्मक परिवर्तन के मूल में है। रिलीज़ की गति और निरंतरता से मुनाफ़ा और ग्राहक संतुष्टि बढ़ती है।
3. DevOps टीमों के लिए उत्कृष्टता हासिल करने में क्लाउड प्रौद्योगिकियाँ महत्वपूर्ण बनी हुई हैं। क्लाउड का उपयोग आपको आवश्यक गति पर सॉफ़्टवेयर डिलीवरी व्यवस्थित करने की अनुमति देता है, बुनियादी ढांचे की उपलब्धता, स्केलेबिलिटी और प्रदर्शन सुनिश्चित करता है।
4. टीम के सदस्यों की उत्पादकता पर ध्यान देकर, आरामदायक मनोवैज्ञानिक माहौल प्रदान करके और सुविधाजनक उपकरणों का उपयोग करके DevOps टीमों की प्रभावशीलता में सुधार किया जा सकता है।
5. सही दृष्टिकोण के साथ रिलीज़ जारी करने की गति बढ़ाने से कंपनी की सेवाओं और अनुप्रयोगों की स्थिरता प्रभावित नहीं होती है।

स्रोत: www.habr.com