DevOps मेट्रिक्स - गणना के लिए डेटा कहां से प्राप्त करें

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

लेकिन यह प्रबंधन के लिए पर्याप्त नहीं था - उन्होंने लगातार अधिक से अधिक नए मेट्रिक्स का आदेश दिया, जो पहले किया गया था उसका उपयोग करना बहुत जल्दी बंद कर दिया।

हाल ही में, हर कोई लीडटाइम के बारे में बात कर रहा है - व्यावसायिक सुविधाओं की डिलीवरी का समय। मीट्रिक ने एक अजीब संख्या दिखाई - एक कार्य पूरा करने के लिए 200 दिन। कैसे सभी ने आह और आह की और अपने हाथ आसमान की ओर उठाये!

कुछ समय बाद, शोर धीरे-धीरे कम हो गया और प्रबंधन को एक और मीट्रिक बनाने का आदेश मिला।

इवान के लिए यह पूरी तरह से स्पष्ट था कि नई मीट्रिक चुपचाप एक अंधेरे कोने में मर जाएगी।

दरअसल, इवान ने सोचा, संख्या जानने से किसी को कुछ भी पता नहीं चलता। 200 दिन या 2 दिन - कोई अंतर नहीं है, क्योंकि संख्या से कारण निर्धारित करना और यह समझना असंभव है कि यह अच्छा है या बुरा।

यह मेट्रिक्स का एक विशिष्ट जाल है: ऐसा लगता है कि एक नया मेट्रिक्स अस्तित्व का सार बताएगा और कुछ गुप्त रहस्य बताएगा। हर किसी को इसकी बहुत उम्मीद होती है, लेकिन किसी कारणवश ऐसा कुछ नहीं हो पाता। हाँ, क्योंकि रहस्य मेट्रिक्स में नहीं मिलना चाहिए!

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

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

एक दिन, हॉल में एक आरामदायक कुर्सी पर बैठकर, इवान ने ध्यान से सोचने का फैसला किया कि वह DevOps मेट्रिक्स को कैसे देखना चाहता है, इस तथ्य को ध्यान में रखते हुए कि प्रभाव की वस्तु टीमें हैं।

DevOps मेट्रिक्स का उद्देश्य

साफ है कि हर कोई डिलीवरी का समय कम करना चाहता है. निस्संदेह, 200 दिन अच्छे नहीं हैं।

लेकिन सवाल यह है कि कैसे?

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

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

“सिस्टम का उद्देश्य स्टैंड से गुजरने के समय के आधार पर टीमों का चयन करना होगा, यानी। परिणामस्वरूप, हमें चयनित समय के साथ आदेशों की एक सूची मिलनी चाहिए, न कि कोई संख्या।

अगर हमें पता चले कि स्टैंड पर कुल कितना समय बिताया गया और स्टैंड के बीच डाउनटाइम पर कितना समय बिताया गया, तो हम टीमों को ढूंढ सकते हैं, उन्हें बुला सकते हैं और कारणों को अधिक विस्तार से समझ सकते हैं और उन्हें खत्म कर सकते हैं, ”इवान ने सोचा।

DevOps के लिए डिलीवरी समय की गणना कैसे करें

इसकी गणना करने के लिए, DevOps प्रक्रिया और उसके सार में गहराई से जाना आवश्यक था।

कंपनी सीमित संख्या में सिस्टम का उपयोग करती है, और जानकारी केवल उनसे ही प्राप्त की जा सकती है और कहीं से नहीं।

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

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

इवान ने बताया कि स्टैंड पर समय की गणना करने के लिए किन प्रणालियों से कौन सी जानकारी ली जा सकती है:

• नेक्सस से - वितरण निर्माण समय और उस फ़ोल्डर का नाम जिसमें कमांड कोड था
• जेनकींस से - प्रत्येक कार्य का प्रारंभ समय, अवधि और परिणाम, स्टैंड का नाम (कार्य मापदंडों में), चरण (कार्य चरण), नेक्सस में वितरण का लिंक।
• इवान ने जीरा और बिटबकेट को पाइपलाइन में शामिल नहीं करने का निर्णय लिया, क्योंकि... वे विकास चरण से अधिक संबंधित थे, न कि स्टैंड पर तैयार वितरण को शुरू करने से।

उपलब्ध जानकारी के आधार पर, निम्नलिखित चित्र तैयार किया गया:

यह जानकर कि वितरण बनाने में कितना समय लगता है और उनमें से प्रत्येक पर कितना समय खर्च होता है, आप आसानी से संपूर्ण DevOps पाइपलाइन (पूर्ण चक्र) से गुजरने की कुल लागत की गणना कर सकते हैं।

इवान द्वारा समाप्त किए गए DevOps मेट्रिक्स यहां दिए गए हैं:

• बनाए गए वितरणों की संख्या
• वितरण का हिस्सा जो स्टैंड पर "आया" और स्टैंड को "पारित" किया
• स्टैंड पर बिताया गया समय (स्टैंड साइकिल)
• पूर्ण चक्र (सभी स्टैंडों के लिए कुल समय)
• कार्य अवधि
• स्टैंड के बीच डाउनटाइम
• जॉब लॉन्च के बीच डाउनटाइम एक ही स्टैंड पर है

एक ओर, मेट्रिक्स ने समय के संदर्भ में DevOps पाइपलाइन को बहुत अच्छी तरह से चित्रित किया, दूसरी ओर, उन्हें बहुत सरल माना गया।

अच्छी तरह से किए गए काम से संतुष्ट होकर, इवान ने एक प्रेजेंटेशन बनाया और इसे प्रबंधन के सामने पेश करने गया।

वह उदास और हाथ नीचे किये हुए वापस आया।

"यह एक असफलता है, भाई," व्यंग्यात्मक सहकर्मी मुस्कुराया...

लेख में और पढ़ें “कैसे त्वरित परिणामों ने इवान की मदद की'.

स्रोत: www.habr.com