DevOps मेट्रिक्स - गणनेसाठी डेटा कुठे मिळवायचा

खरे सांगायचे तर, इव्हान अनेकदा मॉनिटरिंग विभागातील त्याच्या सहकाऱ्यांच्या व्यर्थ प्रयत्नांवर हसले. त्यांनी कंपनीच्या व्यवस्थापनाने त्यांना प्राप्त करण्याचे आदेश दिलेले मेट्रिक्स अंमलात आणण्यासाठी खूप प्रयत्न केले. ते इतके व्यस्त होते की त्यांना इतर कोणीही काही करावेसे वाटले नाही.

परंतु व्यवस्थापनासाठी ते पुरेसे नव्हते - त्यांनी सतत अधिकाधिक नवीन मेट्रिक्स ऑर्डर केल्या, जे पूर्वी केले होते ते वापरणे फार लवकर बंद केले.

अलीकडे, प्रत्येकजण लीडटाइमबद्दल बोलत आहे - व्यवसाय वैशिष्ट्यांच्या वितरणाची वेळ. मेट्रिकने एक वेडा क्रमांक दर्शविला - एक कार्य वितरीत करण्यासाठी 200 दिवस. सर्वांनी कसे आहाहाकार केला आणि आकाशाकडे हात वर केले!

काही काळानंतर, आवाज हळूहळू कमी झाला आणि व्यवस्थापनाला आणखी एक मेट्रिक तयार करण्याचा आदेश मिळाला.

इव्हानला हे पूर्णपणे स्पष्ट होते की नवीन मेट्रिक अगदी शांतपणे एका गडद कोपर्यात मरेल.

खरंच, इव्हानने विचार केला, संख्या जाणून घेतल्याने कोणालाही काहीही कळत नाही. 200 दिवस किंवा 2 दिवस - यात काही फरक नाही, कारण संख्येद्वारे कारण निश्चित करणे आणि ते चांगले की वाईट हे समजणे अशक्य आहे.

हा मेट्रिक्सचा एक सामान्य सापळा आहे: असे दिसते की एक नवीन मेट्रिक अस्तित्वाचे सार सांगेल आणि काही गुप्त रहस्य स्पष्ट करेल. प्रत्येकजण यासाठी खूप आशा करतो, परंतु काही कारणास्तव काहीही होत नाही. होय, कारण मेट्रिक्समध्ये रहस्य शोधले जाऊ नये!

इव्हानसाठी, हा एक उत्तीर्ण झालेला टप्पा होता. त्याला ते समजले मेट्रिक्स फक्त एक सामान्य लाकडी शासक आहेत मोजमापासाठी, आणि सर्व रहस्ये शोधली पाहिजेत प्रभावाची वस्तू, म्हणजे हे मेट्रिक तयार झाले आहे.

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

एके दिवशी, हॉलमध्ये आरामदायी खुर्चीवर बसून, इव्हानने देवऑप्सचे मेट्रिक्स कसे पहायचे आहेत याचा काळजीपूर्वक विचार करण्याचे ठरवले, प्रभावाचा उद्देश संघ आहे हे लक्षात घेऊन.

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

हे स्पष्ट आहे की प्रत्येकजण वितरण वेळ कमी करू इच्छित आहे. 200 दिवस नक्कीच चांगले नाहीत.

पण कसा, हा प्रश्न आहे.

कंपनी शेकडो संघांना नियुक्त करते आणि हजारो वितरणे दररोज DevOps पाइपलाइनमधून जातात. वास्तविक वितरण वेळ वितरण म्हणून दिसून येईल. प्रत्येक संघाचा स्वतःचा वेळ आणि स्वतःची वैशिष्ट्ये असतील. या गोंधळात तुम्हाला काहीही कसे सापडेल?

उत्तर नैसर्गिकरित्या उद्भवले - आम्हाला समस्या संघ शोधणे आणि त्यांच्याबरोबर काय चालले आहे हे शोधून काढणे आवश्यक आहे आणि यास इतका वेळ का लागतो आहे, आणि "चांगल्या" संघांकडून सर्वकाही कसे लवकर करायचे ते शिकणे आवश्यक आहे. आणि हे करण्यासाठी, तुम्हाला प्रत्येक DevOps स्टँडवर संघांनी घालवलेला वेळ मोजावा लागेल:

“प्रणालीचा उद्देश संघ निवडणे हा आहे की ते स्टँड पार करतात त्या वेळेवर आधारित, म्हणजे. परिणामी, आम्हाला निवडलेल्या वेळेसह आदेशांची सूची मिळावी, संख्या नाही.

स्टँडवर एकूण किती वेळ घालवला गेला आणि स्टँडमधील डाउनटाइममध्ये किती वेळ गेला हे आम्हाला आढळल्यास, आम्ही संघ शोधू, त्यांना कॉल करू आणि कारणे अधिक तपशीलवार समजून घेऊ आणि त्यांना दूर करू, ”इव्हानने विचार केला .

DevOps साठी वितरण वेळेची गणना कशी करावी

त्याची गणना करण्यासाठी, DevOps प्रक्रिया आणि त्याचे सार जाणून घेणे आवश्यक होते.

कंपनी मर्यादित संख्येने सिस्टीम वापरते आणि माहिती फक्त त्यांच्याकडूनच मिळवली जाऊ शकते आणि इतर कोठेही नाही.

कंपनीतील सर्व कामे जिरामध्ये नोंदणीकृत होती. जेव्हा एखादे कार्य हाती घेतले जाते, तेव्हा त्यासाठी एक शाखा तयार केली गेली आणि अंमलबजावणीनंतर, बिटबकेट आणि पुल विनंतीसाठी एक कमिट केले गेले. जेव्हा PR (पुल रिक्वेस्ट) स्वीकारले जाते, तेव्हा वितरण आपोआप तयार होते आणि Nexus रिपॉजिटरीमध्ये संग्रहित होते.

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

इव्हानने स्टँडवरील वेळेची गणना करण्यासाठी कोणत्या सिस्टममधून कोणती माहिती घेतली जाऊ शकते याचे वर्णन केले:

• Nexus कडून - वितरण निर्मिती वेळ आणि कमांड कोड असलेल्या फोल्डरचे नाव
• जेनकिन्स कडून - प्रत्येक कामाचा प्रारंभ वेळ, कालावधी आणि परिणाम, स्टँडचे नाव (नोकरीच्या पॅरामीटर्समध्ये), टप्पे (नोकरीचे टप्पे), नेक्ससमधील वितरणाची लिंक.
• इव्हानने पाइपलाइनमध्ये जिरा आणि बिटबकेटचा समावेश न करण्याचा निर्णय घेतला, कारण... ते विकासाच्या टप्प्याशी अधिक संबंधित होते, आणि स्टँडवर तयार झालेले वितरण रोल आउट करण्याशी नाही.

उपलब्ध माहितीच्या आधारे, खालील आकृती काढण्यात आली:

वितरण तयार करण्यासाठी किती वेळ लागतो आणि त्या प्रत्येकावर किती वेळ खर्च होतो हे जाणून घेतल्यास, तुम्ही संपूर्ण DevOps पाइपलाइन (पूर्ण सायकल) मधून जाण्याच्या एकूण खर्चाची सहज गणना करू शकता.

इव्हानने संपलेल्या DevOps मेट्रिक्स येथे आहेत:

• तयार केलेल्या वितरणांची संख्या
• स्टँडवर “आले” आणि स्टँड “पास” झालेल्या वितरणाचा हिस्सा
• स्टँडवर घालवलेला वेळ (स्टँड सायकल)
• पूर्ण सायकल (सर्व स्टँडसाठी एकूण वेळ)
• नोकरीचा कालावधी
• स्टँड दरम्यान डाउनटाइम
• त्याच स्टँडवर जॉब लॉन्च दरम्यान डाउनटाइम

एकीकडे, मेट्रिक्सने DevOps पाइपलाइनचे वेळेच्या दृष्टीने अतिशय चांगले वर्णन केले आहे, तर दुसरीकडे, ते अतिशय सोपे मानले गेले.

चांगल्या प्रकारे केलेल्या कामाबद्दल समाधानी, इव्हानने एक सादरीकरण केले आणि ते व्यवस्थापनाला सादर करण्यासाठी गेला.

तो खिन्न होऊन हात खाली करून परत आला.

"हा एक फियास्को आहे, भाऊ," उपरोधिक सहकारी हसला...

लेखात अधिक वाचा “जलद परिणामांनी इव्हानला किती मदत केली».

स्त्रोत: www.habr.com