जैसा कि इवान मेट्रिक्स DevOps ने किया था। शुरुआत

एक दिन, इवान को DevOps मैट्रिक्स पर चर्चा करने के लिए एक बैठक में बुलाया गया था।

प्रत्येक प्रतिभागी बैठक के लिए तैयार कुछ मेट्रिक्स की सूची तैयार करता है, जो कि उनकी राय में, लागू करने लायक होगी।

रिपोर्टों को सुनकर, इवान ने गणना करने की कोशिश की कि कितने मेट्रिक्स का सुझाव दिया गया था: 5.10, फिर से 10, और लगभग एक दर्जन से अधिक। यह कुछ के साथ 30 निकला।

किसी कारण से, यह विचार अचानक आया कि लोग इकट्ठा हो गए और केवल उन नामों को लिखा जो उन्हें दिलचस्प लगे। जाहिर है, किसी ने मैट्रिक्स के सार के बारे में नहीं सोचा था।

पक्ष से देखते हुए, इवान ने खुद से सवाल पूछा: क्यों? क्यों वास्तव में इन मैट्रिक्स? वे आपको क्या देंगे? यह अचानक स्पष्ट हो गया कि बैठक ने उन लोगों को एक साथ लाया जो मैट्रिक्स की प्रकृति की वास्तविक समझ से बहुत दूर थे, और यह सब कुछ हमेशा की तरह समाप्त हो जाएगा, समय की एक बड़ी राशि खो कर और काम को कचरे में फेंक दिया।

यह दुखद और अपमानजनक हो गया। यह शर्म की बात है कि कंपनी का समय और पैसा कहीं नहीं जाता है, और यह दुखद है कि एक उपयोगी व्यवसाय नहीं किया जाएगा।

इवान लंबे समय से मेट्रिक्स का अध्ययन कर रहे हैं और लंबे समय से समझा जाता है कि विषय बहुत गंभीर और जटिल है, और किसी भी मामले में इसे डिंगी खाड़ी से संपर्क करना असंभव है।

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

इवान ने DevOps मेट्रिक्स की अपनी दृष्टि तैयार करने का फैसला किया, और यह सुनिश्चित किया कि प्रत्येक मीट्रिक इसमें उचित था, एक विशिष्ट उद्देश्य था, उपयोगी और समझ में आता था।
यही उसने किया ...

आप क्या प्रबंधन करना चाहते हैं?

सबसे पहले, इवान ने MAIN GOAL के बारे में सोचने का फैसला किया, जिसके लिए मैट्रिक्स बनाये जाते हैं।
अच्छी तरह से पढ़ी जाने वाली पुस्तकें लीन एनालिटिक्स और द प्रैक्टिस ऑफ ताओ टोयोटा ने सुझाव दिया: वह संख्या चुनें जिसे आप मुख्य मीट्रिक के रूप में नियंत्रित करना चाहते हैं। इसके बाद, इस संख्या के घटकों का चयन करें जिन्हें आप मैट्रिक्स के रूप में प्रभावित कर सकते हैं।

पिछली बैठक में DevOps का लक्ष्य "सॉफ़्टवेयर गुणवत्ता" घोषित किया गया था, लेकिन गुणवत्ता की अवधारणा बहुत अस्पष्ट थी। गुणवत्ता क्या है? इसे एक संख्या में कैसे व्यक्त करें? क्या घटक इसे प्रभावित करते हैं?

दुर्भाग्य से, सॉफ्टवेयर की गुणवत्ता को एक ही संख्या में व्यक्त नहीं किया जा सकता है।

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

मैनुअल श्रम को हटाकर, उसने तब त्रुटियों की संख्या में इतनी तेजी और कमी हासिल की कि कम से कम एक मिनट में सुधार जारी करना संभव हो गया।

इस प्रकार, यह पता चला कि TARGET METRIC DevOps के रूप में खुद से ही पता चलता है

प्रसव का समय

यह ठीक से इसकी कमी या वृद्धि है जो प्रबंधकीय निर्णयों के प्रभाव को दिखाएगा।

प्रसव का समय (मार्केट टू टाइम, टीटीएम) बढ़ गया है - खराब रूप से। घटा - उत्कृष्ट।
लेकिन प्रसव का समय कार्य की मात्रा और परीक्षण की अवधि पर और कई अन्य कारकों पर निर्भर करता है! हाँ, यह सही है।

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

यह महत्वपूर्ण है कि पहले एक सिद्धांत, एक अवधारणा विकसित की जाए, इवान ने सोचा, और इसे अन्य अप्रकाशित क्षेत्रों तक विस्तारित करने के लिए, क्योंकि कोडिंग, असेंबली और अन्य सभी विकास कदम भी सीडीएल चरण की तरह ही प्रसव के समय को प्रभावित करते हैं। चलो एक में करते हैं - हम इसे दूसरे में करेंगे।

इवान के काम करने वाली बड़ी कंपनी में, मेट्रिक्स महत्वपूर्ण थे। हजारों डेवलपर्स ने कोड को देखा और सैकड़ों विधानसभाओं को दैनिक रूप से बनाया गया था, लेकिन कोई भी, कंपनी में किसी को भी नहीं पता था कि वास्तव में देवऑप्स पर टीमें कितना समय बिताती हैं।

सभी पक्षों से शिकायतें दर्ज की जाती हैं: DevOps बकवास, यह काम नहीं करता है, यह बहुत धीमा हो गया, इसका कोई मतलब नहीं है। लेकिन किसी के पास असली संख्या नहीं थी, और टीमों के बयानों को साबित करना या उनका खंडन करना असंभव था।

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

यह नहीं हो सकता है, इवान ने सोचा, अगर मैंने एक बार DevOps लॉन्च किया था और इसने तुरंत प्रभाव दिया, तो यह यहाँ क्यों नहीं है?

मैट्रिक्स की एक प्रणाली का निर्माण इवान के लिए सम्मान का विषय बन गया।

जिसे आप नियंत्रित कर सकते हैं उसे नियंत्रित करें

प्रसव के समय का प्रबंधन कैसे करें? क्या यह संभव है? - इवान से पूछा।
यदि हम डिलीवरी के समय को एक संख्या मानते हैं, तो यह स्पष्ट हो जाता है कि देवओप्स प्रक्रिया में ऐसे स्थान हैं जो इस संख्या को महत्वपूर्ण रूप से प्रभावित करते हैं।

इवान की कंपनी का एक मानक था: प्रोम में जाने से पहले प्रत्येक विधानसभा को तीन परीक्षण पीठों को पारित करना था, जिस पर सॉफ्टवेयर के विभिन्न पहलुओं का परीक्षण किया गया था।

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

प्रसव के समय = स्टैंड पर समय 1 + स्टैंड पर समय 2 + स्टैंड 3 पर समय

प्रत्येक स्टैंड पर टीमों द्वारा बिताए गए समय को प्रभावित करते हुए, अंतिम वितरण समय को प्रभावित करना संभव होगा।

दो सरल प्रश्न बने रहे:

1. स्टैंड पर टीमों की लागतों की भौतिक गणना कैसे करें
2. स्टैंड्स के बीच डाउनटाइम्स के साथ क्या करना है (डाउनटाइम्स डिलीवरी टाइम के घटक भी हैं)?

इवान के पास जेनकिंस और नेक्सस (सीडीएल में प्रयुक्त सॉफ्टवेयर) के जंगल में डुबकी लगाने के अलावा कोई विकल्प नहीं था।

जेनकिंस और नेक्सस मदद करते हैं

स्टैंड पर "रोल" विधानसभा जेनकींस का उपयोग करके किया गया था। वास्तव में, जेनकिंस एक नियमित शेड्यूलर है, जैसे क्रॉस्टैब, लेकिन उन्नत सुविधाओं के साथ।

जेनकिंस जानता है कि आरएसएस के रूप में सभी चल रही नौकरियों (स्टैंड पर असेंबली को रोल करने के लिए कार्य) के लॉग को कैसे प्रदर्शित किया जाए, और एक विशिष्ट विधानसभा के लिए एक शुरुआत, अंत समय और एक लिंक है।

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

और यदि सभी स्टैंडों के डेटा को एक डेटाबेस में डंप किया गया था, तो स्टैंड के बीच डाउनटाइम की गणना करना संभव था। यह बहुत अच्छा था!

नेक्सस (नेटवर्क फाइल स्टोरेज) से इवान असेंबली की निर्माण तिथि और इसी तरह की अन्य तारीखों को प्राप्त करने जा रहा था इसकी उपस्थिति और संदर्भ बिंदु का क्षण निर्धारित करें।

सब कुछ जगह-जगह गिर गया। लगभग।

- और यह कैसे प्रबंधित करने के लिए, सोचा इवान?

जारी रखा जाए। प्रभाव की वस्तु