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

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

सप्ताहांत में भी, उन्होंने मेट्रिक्स के बारे में सोचा: “तो क्या, मैं समय क्या मापता हूं? यह मुझे क्या देगा? ”

वास्तव में, समय का ज्ञान क्या देगा? मान लीजिए डिलीवरी में 5 दिन लगते हैं। तो आगे क्या है? यह अच्छा है या बुरा? यहां तक ​​कि अगर यह खराब है, तो आपको किसी तरह इस समय को कम करने की आवश्यकता है। लेकिन कैसे?
इन विचारों ने उसे आराम नहीं दिया, लेकिन कोई समाधान नहीं आया।

इवान समझ गया कि वह बहुत सार से संपर्क कर चुका है। मेट्रिक्स के अनगिनत ग्राफ़ जो उसने पहले देखे थे, उन्हें बहुत पहले आश्वस्त कर दिया था कि मानक दृष्टिकोण काम नहीं करेगा, और यदि आप बस एक ग्राफ ( यहां तक ​​कि एक कोहर्ट ) बनाते हैं, तो इसमें कोई मतलब नहीं होगा।

कैसे हो? ...

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

अपने प्रिय लेखक हैरी हैरिसन के "स्टेनलेस स्टील चूहे" ने हमेशा कहा: विचार मस्तिष्क के तल तक पहुंचना चाहिए और वहां लेट जाना चाहिए, इसलिए इवान ने परिणाम के बिना कई दिनों तक एक और काम करने का फैसला किया ...

कुछ दिनों के बाद, ऑनलाइन स्टोर के बारे में एक लेख पढ़ते हुए, इवान को अचानक एहसास हुआ कि ऑनलाइन स्टोर द्वारा प्राप्त की जाने वाली राशि इस बात पर निर्भर करती है कि साइट आगंतुक कैसे व्यवहार करता है। वे, आगंतुक / ग्राहक, दुकान को अपना पैसा देते हैं और उनके स्रोत हैं। स्टोर द्वारा प्राप्त नकदी की कुल राशि ग्राहक के व्यवहार में परिवर्तन से प्रभावित होती है, न कि कुछ और।

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

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

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

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

बिना किसी हिचकिचाहट के, इवान ने फोन उठाया और एक व्यक्ति की संख्या डायल की जो अच्छी तरह से DevOps के इंटर्ल्स में पारंगत था:

- डेनिस, मुझे बताओ, कृपया, क्या किसी तरह यह समझना संभव है कि टीम इस या उस स्टैंड से गुजरी?
- बिल्कुल। हमारे जेनकिन्स ने ध्वज को गिरा दिया यदि असेंबली ने सफलतापूर्वक स्टैंड पर परीक्षण समाप्त कर दिया (पास कर दिया)।
- सुपर। झंडा क्या है?
- यह "stand_OK" या "stand_FAIL" प्रकार की एक नियमित पाठ फ़ाइल है, जो कहती है कि असेंबली पास हो गई या स्टैंड पारित नहीं हुआ। बेनाम: ठीक है, तुम इसे, हुह?
- सिद्धांत में, हाँ। क्या यह रिपॉजिटरी में उसी फ़ोल्डर में लिखा गया है, जहां विधानसभा है?
- हाँ
- और अगर विधानसभा ने पारित नहीं किया तो क्या होगा? क्या आपको एक नई विधानसभा करने की आवश्यकता होगी?
- हाँ
- ठीक है, धन्यवाद। और एक और सवाल: क्या मैं सही ढंग से समझता हूं कि मैं ध्वज निर्माण की तारीख को स्टैंड के पारित होने की तारीख के रूप में उपयोग कर सकता हूं?
- बिल्कुल!
- सुपर!

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

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

कल के लिए, उन्होंने खुद को सिस्टम के आर्किटेक्चर को तैयार करने का काम दिया।

जारी रखने के लिए ...