DevOps के लिए ROI को मापने के लिए कुछ तरीके क्या हैं?


24

DevOps जटिल है, और इसमें संस्कृति और प्रक्रिया जैसे कई गैर-निर्धारक पहलू शामिल हैं।
सफलता के लिए DevOps पहलों को मापने के कुछ तरीके क्या हैं?
आप एक व्यवसाय को कैसे साबित करते हैं कि उन्होंने जो निवेश किया है, वह वास्तविक डॉलर लौटा रहा है (या बचत कर रहा है)?


हे डेव, मुझे आश्चर्य है कि "माप" से आपका क्या मतलब है, आपके प्रश्न में आपके द्वारा उपयोग किए गए टैग में से एक के अनुसार। IMO (तब और अधिक नहीं), केवल (मौजूदा) "मैट्रिक्स" टैग का उपयोग करना अधिक उपयुक्त होगा। नहीं? यदि आप सहमत नहीं हैं (जो कि ठीक है ...), तो क्या आप समझेंगे (संक्षेप में) यह समझाते हुए कि आप उन 2 टैगों के बीच अंतर क्या है (या होना चाहिए)?
Pierre.Vriens

@ पियरे। मुझे लगता है कि माप डेटा इकट्ठा करने का कार्य है, जबकि एक मीट्रिक वह चीज है जिसे आप मापते हैं। मैंने "माप" टैग हटा दिया क्योंकि यह शायद बेमानी है।
डेव स्वर्सकी

जवाबों:


16

बड़ा अच्छा सवाल! हम में से अधिकांश देवओप्स प्रथाओं में निवेश करना जानते हैं, जो असंख्य कारणों से एक बहुत ही सार्थक खोज है; हालांकि, अक्सर हम नीचे की रेखा के प्रभाव पर DevOps को सही नहीं ठहराते, हालाँकि।

नोट : यह एक राय वाला सवाल है, और मेरा जवाब भी इसी तरह का है।

Tensibai ने समझदारी से सुझाव दिया कि हम सही मेट्रिक्स पाते हैं, और उन्होंने उदाहरण के तौर पर समय-समय पर बाज़ार का इस्तेमाल किया। यह एक बड़ी तस्वीर है।

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

यहाँ कुछ राजकोषीय जीतें हैं:

  • क्लाउड में ऑटो-स्केलिंग का लाभ उठाकर सर्वर की लागत की गणना करें
  • आय पैदा करने वाली साइटों के लिए, डाउनटाइम की लागत-प्रति-मिनट को एक्सट्रापोल करें, फिर MTTI और MTTR में सुधार दिखाएं
  • फिर से आय पैदा करने वाली साइटों के लिए, पिछली घटनाओं के आधार पर अत्यधिक उपलब्ध वास्तुकला का लाभ उठाते हुए लागत-प्रति-मिनट का अनुमान लगाएं
  • यदि आपने अपनी बिल्ड और पाइपलाइन में सुधार किया है, तो दिखाएं कि आपने पहले से ट्रैक किए गए दोषों के कारण उत्पादन में प्रतिगमन और त्रुटियों को कम किया है
  • यदि आपने डेवलपर परीक्षण वातावरण, या यहां तक ​​कि डेवलपर लैपटॉप पर उपकरण और कॉन्फ़िगरेशन में सुधार किया है, तो यह देखने के लिए प्रतिबद्ध इतिहास देखें कि क्या नए इंजीनियर शामिल होने के तुरंत बाद अपना पहला योगदान दे रहे हैं
  • क्लाउड और ऑन- प्रिम के बीच पूर्ण लागत की तुलना करना, जैसे कि गितलाब ने हाल ही में किया था , अपने बुनियादी ढांचे के खर्च (उर्फ बचत!) को सही ठहराने के लिए।

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


2
मैं इसके पीछे 1000% हूं। मुझे लगता है कि हम मॉनिटरिंग में एक बड़ी पारी की कगार पर हैं: मुझे अब इस बात की कोई परवाह नहीं है कि किसी भी उदाहरण पर CPU या RAM का कितना उपयोग होता है, मुझे इस बात की परवाह है कि मैं इंस्टेंस के ऑटो-स्केलिंग समूह के लिए कितना भुगतान कर रहा हूं अधिक समय तक। मुझे परवाह नहीं है कि एक अनुरोध कितने अनुरोधों को संभाल सकता है, मुझे इस बात की परवाह है कि अनुरोध को पूरा करने में कितना खर्च होता है। सोच में यह बदलाव वास्तव में आरओआई सहित DevOps के लिए बेहतर मैट्रिक्स ड्राइव करने में मदद कर सकता है।
एड्रियन

12

एक DevOps पाइपलाइन के लिए मुख्य मीट्रिक साइकिल समय (जिसे लीड समय भी कहा जाता है ) है। यह वह समय है जब यह परिवर्तन (या एक परिवर्तन अनुरोध), विचार की शुरुआत के लिए सभी तरह से ट्रैक करता है)। इस अवधारणा का सबसे अच्छा उदाहरण मुझे पता है कि "द गोल" पुस्तक से है, जो इसके निर्माण के संदर्भ में बात करती है।

तैनाती आवृत्ति भी उपयोगी है। हम चाहते हैं कि डिवोस्पेस पाइपलाइन में तैनाती लगातार हो। कोई जादुई नहीं है "1 दिन अच्छा है, 2 दिन खराब है" माप; यह सार्थक होने के लिए आपकी परियोजना पर एक ऐतिहासिक संदर्भ की आवश्यकता होगी।

तैनाती का आकार : हालांकि आपके डेवलपर्स काम को मापते हैं - उपयोगकर्ता की कहानियां, कहानी के बिंदु, क्वाटलोस, जो भी हो। फिर से, आप समय के साथ रुझान देखना चाहते हैं, पूर्ण मूल्य नहीं।

आवृत्ति और आकार के बीच एक कहानी है। क्या हमारी रिलीज़ अधिक अनियंत्रित और बड़ी होती जा रही है? क्यूं कर? क्या वे छोटे और अधिक लगातार होते जा रहे हैं? फिर, क्यों?

यह बताते हुए कि क्या फ्रीक्वेंसी / साइज का चलन अच्छा है, हमें असफल डिप्लॉयस के प्रतिशत की भी आवश्यकता होगी । उन तीन मैट्रिक्स में 'क्यों' को उजागर करना आपको परियोजना के स्वास्थ्य के बारे में बहुत कुछ बताएगा।

मेरा व्यक्तिगत पसंदीदा, हालांकि यह एक वैनिटी मीट्रिक है, टाइम फॉर ए ट्रिवियल डिप्लॉय । यदि आपको पूरी साइट को फिर से तैयार करने के लिए सबसे छोटी संभव चीज मिली ... शायद सीईओ के नाम में एक टाइपो ... कितनी जल्दी आप एक तैनात साइट पर पैनिक फोन कॉल से जा सकते हैं? मैं 'घमंड' कहता हूं क्योंकि यह वास्तव में उस भविष्यवाणी से परे नहीं है जो अन्य मेट्रिक्स के ऊपर चर्चा करती है, लेकिन मुझे अच्छा लगता है जब मुझे मूल्य पसंद होता है।

यदि हम मॉनिटरिंग में आते हैं, तो अलग-अलग चीजों का एक गुच्छा होता है, जिन्हें हम ट्रैक कर सकते हैं ... ' Uptime ' जैसी सभी चीजों से , वास्तव में निम्न स्तर की चीजों की तरह, जो अनुरोध-प्रतिक्रिया चक्र पर कस्टम HTML को पुनर्जीवित करने में बिताए गए समय की तरह होती हैं ... लेकिन वे एक DevOps संस्कृति की स्थापना के लिए विशिष्ट नहीं हैं।

ये सीधे डॉलर से नहीं जुड़ते हैं ... ऐसा करने से मुझे अपने ऑर्गन के बारे में अधिक जानकारी की आवश्यकता होगी जैसे कि मैं इस तरह फोरम में पेश कर सकता हूं; लेकिन वे उस प्रश्न का उत्तर देने के लिए BEGIN की कुंजी हैं। एक बार जब आप जानते हैं कि आप एक गैर-घटना के रूप में उत्पादन में नियमित रूप से काम जारी करने में सक्षम हैं, तो आप यह देखना शुरू कर सकते हैं कि आप पहले कितना प्रयास कर रहे थे। जैसा कि पुस्तक "द गोल" सिखाती है (विनिर्माण पाइपलाइनों के बारे में - यह प्रासंगिक है), स्थानीय स्तर पर अनुकूलन ऐसा लग सकता है कि आप पैसे बचा रहे हैं, लेकिन आखिरकार, यह सिर्फ मूल्य बनाता है जो इन्वेंट्री (अनपेक्षित सुविधाओं) में बंधा हुआ है।

इस सलाह से परे, आपको पिछले कुछ वर्षों के लिए स्टेट ऑफ़ देवओप्स रिपोर्ट पर एक नज़र डालनी चाहिए । यह वास्तविक विश्व परियोजनाओं के बारे में माप से भरा है जिन्हें आप अनुकरण कर सकते हैं।


8

स्पष्ट कप्तान: बाजार के लिए समय कम करने और रिलीज पर दोष।

इस एक लाइनर का विस्तार करने के लिए, सामान्य रूप से बिना किसी संदर्भ के संगठन में बदलाव किया जा रहा है।

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

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

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

सामान्य गड़बड़ी किसी भी मेट्रिक्स को परिभाषित करने से पहले परिवर्तन को संलग्न करना है और इस तरह एक भावना पर आरओआई का मूल्यांकन करना है न कि तथ्यात्मक डेटा पर।

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


1

खेल के लिए देर से यहाँ लेकिन सोचा था कि मैं झंकार में हूँ।

आप प्रबंधन नहीं कर सकते हैं कि आप क्या मापते हैं, इसलिए शुरुआत के लिए, यहां प्रमुख मेट्रिक्स डेप्स टीमों को घटना प्रतिक्रिया के लिए ट्रैक करना चाहिए:

  • %% : कुल समय उपलब्ध% = [कुल समय - डाउनटाइम] / [कुल समय]
  • MTTR : मतलब समय के लिए संकल्प = [डाउनटाइम] / [# घटनाएं]
  • MTTA : मतलब स्वीकार करने का समय = [स्वीकार करने के लिए कुल समय] / [घटनाओं का #]
  • MTBF : विफलताओं के बीच का समय = [कुल समय - डाउनटाइम] / [घटनाओं का #]

ये मीट्रिक आपको अपने संचालन की उच्च स्तरीय स्वास्थ्य जांच देते हैं, और आपको यह पहचानने में मदद करते हैं कि आपको आगे कहाँ खुदाई करने की आवश्यकता है।

पर एक नजर डालें व्हाइटबोर्ड एनीमेशन यहाँ विषय पर एक अधिक गहराई से देखने के लिए।

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


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

धन्यवाद @ पायल यह एक अच्छी बात है - ये वास्तव में विश्वसनीयता पर केंद्रित मैट्रिक्स हैं, जो कि DevOps का एक महत्वपूर्ण हिस्सा है, लेकिन निश्चित रूप से पूरी बात नहीं है। उम्मीद है कि विश्वसनीयता के शीर्ष पर रहना एक अच्छा शुरुआती बिंदु है, लेकिन वहाँ रुकना मत!
युआन चेंग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.