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

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

तर यो व्यवस्थापनको लागि पर्याप्त थिएन - तिनीहरूले लगातार थप र अधिक नयाँ मेट्रिक्स आदेश दिए, धेरै चाँडै पहिले के गरेको थियो प्रयोग गर्न बन्द।

हालै, सबैले लीडटाइमको बारेमा कुरा गरिरहेका छन् - व्यापार सुविधाहरूको डेलिभरीको लागि समय। मेट्रिकले पागल नम्बर देखाएको छ - एउटा कार्य डेलिभर गर्न 200 दिन। सबैले कसरी आह र आह गरे र आकाशतिर हात उठाए!

केही समय पछि, आवाज बिस्तारै कम भयो र व्यवस्थापनले अर्को मेट्रिक सिर्जना गर्न आदेश प्राप्त गर्यो।

यो इभानलाई पूर्ण रूपमा स्पष्ट थियो कि नयाँ मेट्रिक पनि चुपचाप अँध्यारो कुनामा मर्नेछ।

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

यो मेट्रिक्सको एक विशिष्ट जाल हो: यस्तो देखिन्छ कि नयाँ मेट्रिकले अस्तित्वको सार बताउनेछ र केहि गोप्य रहस्यको व्याख्या गर्नेछ। सबैले यसका लागि धेरै आशा राख्छन्, तर कुनै न कुनै कारणले केही हुँदैन। हो, किनभने गोप्य मेट्रिक्समा फेला पार्नु हुँदैन!

इवानको लागि, यो एक पारित चरण थियो। उसले त्यो बुझ्यो मेट्रिक्स केवल एक साधारण काठ शासक हो मापनको लागि, र सबै गोप्यहरू खोजिनु पर्छ प्रभाव को वस्तु, अर्थात् यो मेट्रिक गठन भएको हो।

अनलाइन स्टोरको लागि, प्रभावको वस्तु भनेको यसको ग्राहकहरू हुनेछन् जसले पैसा ल्याउँछन्, र DevOps को लागि, यो पाइपलाइन प्रयोग गरेर वितरणहरू सिर्जना गर्ने र रोल आउट गर्ने टोलीहरू हुनेछन्।

एक दिन, हलमा आरामदायी कुर्सीमा बसेर, इभानले प्रभावको वस्तु टोलीहरू हुन् भन्ने तथ्यलाई ध्यानमा राख्दै, उनी कसरी DevOps मेट्रिक्स हेर्न चाहन्छन् भनेर ध्यानपूर्वक सोच्ने निर्णय गरे।

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

यो स्पष्ट छ कि सबैजना डेलिभरी समय कम गर्न चाहन्छ। 200 दिन, पक्कै पनि, कुनै राम्रो छैन।

तर कसरी, यो प्रश्न हो?

कम्पनीले सयौं टोलीहरू काम गर्दछ, र हजारौं वितरणहरू हरेक दिन DevOps पाइपलाइन मार्फत जान्छन्। वास्तविक डेलिभरी समय वितरणको रूपमा देखा पर्नेछ। प्रत्येक टोलीको आफ्नै समय र आफ्नै विशेषताहरू हुनेछ। यो गडबडीको बीचमा तपाइँ कसरी केहि पाउन सक्नुहुन्छ?

जवाफ स्वाभाविक रूपमा उठ्यो - हामीले समस्या टोलीहरू फेला पार्न र तिनीहरूसँग के भइरहेको छ भनेर पत्ता लगाउन आवश्यक छ र यसले किन यति लामो समय लिइरहेको छ, र "राम्रो" टोलीहरूबाट कसरी सबै कुरा छिटो गर्ने भनेर सिक्नु पर्छ। र यो गर्नको लागि, तपाईंले प्रत्येक DevOps स्ट्यान्डहरूमा टोलीहरूले बिताएको समय मापन गर्न आवश्यक छ:

"प्रणालीको उद्देश्य टोलीहरू छनौट गर्ने समयको आधारमा उनीहरूले स्ट्यान्ड पास गर्ने हो, अर्थात्। नतिजाको रूपमा, हामीले चयन गरिएको समयको साथ आदेशहरूको सूची प्राप्त गर्नुपर्छ, नम्बर होइन।

यदि हामीले स्ट्यान्डमा कुल कति समय बित्यो र स्ट्यान्डहरू बीचको डाउनटाइममा कति समय खर्च भयो भनेर पत्ता लगायौं भने, हामी टोलीहरू फेला पार्न सक्छौं, तिनीहरूलाई कल गर्न सक्छौं र कारणहरू विस्तृत रूपमा बुझ्छौं र तिनीहरूलाई हटाउन सक्छौं, "इभानले सोचे।

DevOps को लागि डेलिभरी समय कसरी गणना गर्ने

यसलाई गणना गर्न, यो DevOps प्रक्रिया र यसको सारमा जान आवश्यक थियो।

कम्पनीले सीमित संख्यामा प्रणालीहरू प्रयोग गर्दछ, र जानकारी तिनीहरूबाट मात्र प्राप्त गर्न सकिन्छ र अरू कतै छैन।

कम्पनीका सबै कार्यहरू जिरामा दर्ता भएका थिए। जब एक कार्य लिइयो, यसको लागि एक शाखा सिर्जना गरियो, र कार्यान्वयन पछि, BitBucket र पुल अनुरोधमा एक प्रतिबद्धता बनाइयो। जब एक PR (पुल अनुरोध) स्वीकार गरियो, वितरण स्वचालित रूपमा सिर्जना गरियो र नेक्सस भण्डारमा भण्डारण गरियो।

अर्को, रोलआउट, स्वचालित र म्यानुअल परीक्षणको शुद्धता जाँच गर्न जेनकिन्स प्रयोग गरेर धेरै स्ट्यान्डहरूमा वितरण रोल आउट गरियो:

इभानले कुन प्रणालीबाट स्ट्यान्डमा समय गणना गर्न कुन जानकारी लिन सकिन्छ भनेर वर्णन गरे:

• Nexus बाट - आदेश कोड समावेश भएको फोल्डरको वितरण निर्माण समय र नाम
• Jenkins बाट - सुरु समय, अवधि र प्रत्येक कामको नतिजा, स्ट्यान्ड नाम (काम प्यारामिटरहरूमा), चरणहरू (कामका चरणहरू), Nexus मा वितरणको लिङ्क।
• इभानले जिरा र बिटबकेटलाई पाइपलाइनमा समावेश नगर्ने निर्णय गरे, किनभने... तिनीहरू विकास चरणसँग बढी सम्बन्धित थिए, र स्ट्यान्डहरूमा समाप्त वितरण रोल आउट गर्न होइन।

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

वितरणहरू सिर्जना गर्न कति समय लाग्छ र ती प्रत्येकमा कति समय खर्च हुन्छ भन्ने कुरा थाह पाएर, तपाईंले सम्पूर्ण DevOps पाइपलाइन (पूर्ण चक्र) मार्फत जाने कुल लागतहरू सजिलैसँग गणना गर्न सक्नुहुन्छ।

यहाँ DevOps मेट्रिक्सहरू छन् जसको साथ इभान समाप्त भयो:

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

एकातिर, मेट्रिक्सले समयको सर्तमा DevOps पाइपलाइनलाई धेरै राम्रोसँग चित्रण गर्‍यो, अर्कोतर्फ, तिनीहरूलाई धेरै सरल मानिन्थ्यो।

राम्रोसँग गरेको कामबाट सन्तुष्ट, इभानले एउटा प्रस्तुति बनाए र व्यवस्थापनलाई प्रस्तुत गर्न गए।

उ निरुत्साहित भएर हात तल लिएर फर्कियो ।

"यो एक असफलता हो, भाई," विडम्बनापूर्ण सहकर्मी मुस्कुराए ...

लेखमा थप पढ्नुहोस् "कसरी द्रुत परिणामहरूले इवानलाई मद्दत गर्यो"।

स्रोत: www.habr.com