कसरी इभानले DevOps मेट्रिक्स गरे। प्रभावको वस्तु

एक हप्ता बितिसकेको छ जब इभानले पहिलो पटक DevOps मेट्रिक्स बारे सोच्यो र तिनीहरूको मद्दतले उत्पादन वितरण समय व्यवस्थापन गर्न आवश्यक छ भनेर महसुस गरे। (समय-टु-बजार)।

सप्ताहन्तमा पनि, उसले मेट्रिक्सको बारेमा सोच्यो: "त्यसो भए के मैले समय नाप्छु? यसले मलाई के दिनेछ?

साँच्चै, समयको ज्ञानले के दिन्छ? मानौं डेलिभरी 5 दिन लाग्छ। त्यसोभए, अर्को के छ? यो राम्रो कि नराम्रो? यदि यो नराम्रो छ भने पनि, तपाईले यो समयलाई कुनै न कुनै रूपमा घटाउनु पर्छ। तर कसरी?
यी विचारहरूले उनलाई सतायो, तर कुनै समाधान भएन।

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

कसरी हुन?…

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

उनको मनपर्ने लेखक ह्यारी ह्यारिसनको "स्टेनलेस स्टिल मुसा" सधैं भन्थे: एक विचार मस्तिष्कको फेदमा पुग्नुपर्छ र त्यहाँ लुकेको हुनुपर्दछ, त्यसैले धेरै दिनसम्म कष्ट भोगेपछि, इभानले अर्को काम लिने निर्णय गरे ...

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

यो बाहिर आयो कि मापन मान परिवर्तन गर्न को लागी यो मान को गठन गर्नेहरुलाई प्रभाव पार्न आवश्यक थियो, अर्थात्। अनलाइन स्टोरको पैसाको मात्रा परिवर्तन गर्न, यो स्टोरका ग्राहकहरूको व्यवहारलाई प्रभाव पार्न आवश्यक थियो, र DevOps मा डेलिभरी समय परिवर्तन गर्न, यो समय "सिर्जना" गर्ने टोलीहरूलाई प्रभाव पार्न आवश्यक थियो, अर्थात्। तिनीहरूको काममा DevOps प्रयोग गर्नुहोस्।

इभानले महसुस गरे कि DevOps मेट्रिकहरू ग्राफहरू द्वारा प्रतिनिधित्व गर्नु हुँदैन। तिनीहरूले आफ्नो प्रतिनिधित्व गर्नुपर्छ खोज उपकरण "उत्कृष्ट" टोलीहरू जसले अन्तिम डेलिभरी समयलाई आकार दिन्छ।

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

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

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

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

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

"सबैभन्दा धेरै समय कहाँ बित्यो भन्ने बुझेर, हामी टोलीहरूलाई चिनाउनेछौं, तिनीहरूमा जान्छौं र समस्याको खोजी गर्नेछौं।" इवान मुस्कुरायो।

भोलिको लागि, उहाँले कोरिएको प्रणालीको वास्तुकला स्केच गर्ने कार्य आफैलाई सेट गर्नुभयो।

फेरि जारी राखौंला…

स्रोत: www.habr.com