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

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

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

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

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

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

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

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

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

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

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

लक्ष्य देवता मेट्रिक्स

यह स्पष्ट है कि हर कोई प्रसव के समय को कम करना चाहता है। 200 दिन, ज़ाहिर है, कुछ भी नहीं के लिए अच्छा है।

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

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

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



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

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

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

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

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

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



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



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

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

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



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

यहाँ इवान से DevOps मेट्रिक्स हैं:

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

एक तरफ, मेट्रिक्स ने समय के संदर्भ में अच्छी तरह से DevOps पाइपलाइन की विशेषता बताई, दूसरी ओर, उन्हें बहुत सरल माना जाता था।

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

वह डूबते हुए और हाथों से नीचे लौट आया।

"यह एक उधम मचाता है, भाई," विडंबना है कि सहकर्मी मुस्कुराया।

लेख पढ़ना जारी रखें " इवान ने त्वरित परिणाम कैसे दिए ।"