DevOps रूपान्तरण कसरी सुरु गर्ने

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

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

ट्रान्सक्रिप्टमा - कट अन्तर्गत उदाहरण र निर्देशनहरू सहित विस्तृत DevOps रूपान्तरण योजना रिपोर्ट Andrey Alexandrov - Express42 मा एक इन्जिनियर, जसले DevOps अंकुरणको बारेमा सल्लाह दिन्छ, यो प्रक्रियालाई गति दिन्छ किनभने उनले पहिले नै रेक नक्सा बनाइसकेकी छिन्। यदि यो तपाईंलाई लाग्छ कि तपाईंलाई रूपान्तरण आवश्यक छैन, वा तपाईंको विशिष्टताहरू यस्तो छन् कि DevOps अभ्यासहरू उपयुक्त छैनन्, प्रतिवेदनलाई सीमितताहरू फेला पार्न र हटाउन निर्देशनहरूको रूपमा प्रयोग गर्नुहोस्।

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

सेवा चयन गर्दै

हामीले एउटा योजनाको रूपरेखा बनाएका छौं, पहिलो चरणको साथ सुरू गरौं - सेवा छनौट गर्ने। पहिलो मापदण्ड जीवनकाल हो: त्यहाँ पुराना सेवाहरू छन् - विरासत, र नयाँ। तपाईं दुवै संग सुरु गर्न सक्नुहुन्छ।

यो एक युवा सेवा छनोट गर्न तार्किक छ। यो ताजा छ, यसमा काम गर्ने टोलीमा काम गर्ने प्रक्रिया अझै स्थापित भएको छैन। यसको वरिपरि प्राविधिक ऋणको पहाड छैन, तपाईले यसलाई सधैं ठीक गर्न आवश्यक छैन। हामी यसबाट जे चाहन्छौं गर्न सक्छौं।

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

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

- यो नयाँ सेवा हो! त्यहाँ सबै कुरा सरल थियो, हाम्रो मलबे संग केहि गर्न प्रयास गर्नुहोस्।

लेगेसी सेवालाई रूपान्तरणको लागि प्रयोग गर्नु अर्थपूर्ण हुन्छ जब तपाईं यो कसैसँग गर्नुहुन्छ, उदाहरणका लागि, यदि तपाईंले बाह्य सल्लाहकारलाई आमन्त्रित गर्नुभयो भने। इमानदार बनौं, परिवर्तनले सम्भव सबै कुरा हल्लाउनेछ। तपाइँ प्रयोग गर्दै हुनुहुन्छ र तपाइँ कहाँ समाप्त हुनुहुनेछ, तपाइँ कुन प्रविधिहरू प्रयोग गर्नुहुनेछ र प्रक्रियाहरूमा किन, कहाँ र कुन समस्याहरू उत्पन्न हुनेछ थाहा छैन। त्यसैले, नयाँ परिवर्तन गर्न सजिलो छ।

यदि तपाइँ आफैले सबै कुरा गर्नुहुन्छ, र कम्पनीसँग गम्भीर क्षमता छैन भने, हामी नयाँ सेवा लिन्छौं। यदि तपाइँ एक बाह्य सल्लाहकारलाई चिन्नुहुन्छ र कोष छ भने, पुरानो एक छान्नुहोस्।

त्यहाँ सेवाहरू छन् जुन प्रयोगकर्ताहरूको लागि एक इन्टरफेस हो, उदाहरणका लागि, एक साधारण वेबसाइट वा मोबाइल अनुप्रयोग। तर बिलिङको भावनामा गम्भीर चीजहरू छन्। यदि बिलिङमा केहि गलत भयो भने, यो पत्ता लगाउन गाह्रो हुनेछ। यहाँ हामीसँग पनि विकल्प छ।

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

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

थप हेरौं सेवा टोली। हामीले निरन्तर काम गर्नुपर्छ र यो सेवा प्रदान गर्नेहरूसँग धेरै नजिकको अन्तरक्रिया गर्नुपर्छ।

टोलीका मानिसहरू दुई वर्गमा विभाजित छन्: रूढिवादीहरू - पुरानो संसारमा बस्नुहोस्, वा केवल DevOps को बारे मा केहि थाहा छैन, र आविष्कारकहरू, जसले सबै फैशनेबल अभ्यासहरू तान्दछ। पछिल्लो सधैं विषय बुझ्दैनन्, तर कम से कम तिनीहरू यसको लागि तयार छन्।

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

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

टोलीका लागि आविष्कारकहरू छनौट गर्नु तार्किक छ, किनभने रूढिवादीहरूले यसमा सुँगुर राख्न सक्छन्।

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

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

रूढिवादी टोलीका मानिसहरू प्रायः कार्यहरू बिर्सन्छन् वा अन्तिम मिनेटसम्म तिनीहरूलाई रोक्छन्। र यदि, जोन विलिसले मनाही गर्नुभयो भने, तपाईंले गल्ती गर्नुभयो र तिनीहरूलाई पूरा भएका कार्यहरूको संख्याको लागि KPI तोक्नुभयो, र कुनै कारणले केही अंश KPI मा समावेश गरिएको थिएन, तब तिनीहरूले केही पनि गर्दैनन्। सामान्यतया, तिनीहरू सही हुनेछन्, किनभने त्यसपछि तिनीहरूले बोनस गुमाउँछन्।

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

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

संक्षेप गरौं। यदि हामीले हाम्रो कम्पनीमा सम्पूर्ण रूपान्तरण आफैं गर्छौं भने, त्यसपछि हामी छनौट गर्छौं: एउटा नयाँ सेवा, अधिमानतः एक साधारण इन्टरफेस ताकि यसको ब्रेकडाउनबाट धेरै पीडा नहोस्, र आविष्कारकहरूको टोली।

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

को को संलग्न छन् ?

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

कम्तिमा केही निर्णयहरू गर्ने र सेवाको साथ के हुने कुरालाई प्रभाव पार्ने सबैलाई फेला पार्न, भेट्न र सञ्चार गर्न आवश्यक छ।

हामीलाई तिनीहरूलाई के चाहिन्छ? कससँग वार्ता गर्ने भनेर जान्न। रूपान्तरणको समयमा, जब सेवासँग काम गर्ने सामान्य सिद्धान्त परिवर्तन हुन्छ, यो अझै पनि हल्लिनेछ। हामीले नयाँ दृष्टिकोणहरू परीक्षण गर्दा केही समयको लागि ग्लिचहरू हुनेछन्। यसका लागि जनता तयार हुनुपर्छ र यसमा सहमत हुनुपर्छ ।

अर्को तपाईंले मान स्ट्रिम नक्सा निर्माण गर्नुपर्नेछ, र यी व्यक्तिहरू बिना तपाईंले यसलाई निर्माण गर्न सक्नुहुन्न, किनभने तिनीहरू सबै मिलेर के भइरहेको छ भन्ने पूर्ण तस्वीर थाहा छ। एक व्यक्तिलाई सेवा संग के हुन्छ सबै कुरा थाहा छैन।

तिनीहरूले टोलीको लागि मानिसहरूलाई सिफारिस गर्नेछन्। पछि हामी छलफल गर्नेछौं किन छुट्टै टोली चाहिन्छ। यसका लागि विद्यमान विभागका व्यक्तिहरू लिनुपर्छ। सेवामा संलग्न व्यक्तिहरूले हाम्रो दिशामा सोच्ने सहकर्मीहरूलाई सिफारिस गर्न सक्षम हुनेछन्, जसले हामीलाई मद्दत गर्न सक्छन् र हामीलाई आवश्यक पर्ने कुराहरूमा सक्षम छन्।

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

मान स्ट्रिम नक्सा निर्माण गर्दै

Value Stream Map एउटा रेखाचित्र वा नक्सा हो जसले ग्राहकलाई मानहरूको प्रवाह देखाउँछ। यो सबै मध्यवर्ती चरणहरू र कसरी मूल्य अन्ततः हाम्रा ग्राहकहरूलाई प्राप्त हुन्छ सहित यसको कार्यान्वयनको लागि एक विचारको साथ आउने सम्पूर्ण प्रक्रिया हो।

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

मेट्रिक्स

मान स्ट्रिम नक्सा साहित्यमा वर्णन गरिएका धेरै फरक मेट्रिकहरू छन्, तर हामीलाई सुरु गर्नका लागि केवल तीन पर्याप्त छन्।

नेतृत्व समय - ढिलाइ / पर्खनुहोस् - एक समय जब हामी केहि को लागी पर्खिरहेका छौं। उदाहरणका लागि, एक परीक्षकले परीक्षण बेन्च खाली नभएसम्म पर्खन्छ, र यस अवधिमा केही गर्न सक्दैन।

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

%C/A स्वीकृत कामको प्रतिशत हो। हामीसँग एउटा चरण - विकास, दोस्रो चरण - परीक्षण। विकासकर्ताहरूबाट कति सुविधाहरू परीक्षकहरूले स्वीकार गरे यो प्रतिशत हो।

यो लगभग हाम्रो नक्सा जस्तो देखिन्छ।

संगठनको संरचना, विभागहरूको संख्या र तपाईंले के गर्नुहुन्छ भन्ने आधारमा यो फरक देखिन सक्छ। तर सामान्यतया नक्सामा दुई चरणहरू हुनेछन्: विचार и analytics। यस चरणमा, डेटा अपेक्षित छ, उदाहरणका लागि, नेतृत्व समय २ हप्ता र मूल्य थपिएको समय २ दिन।

हामी मेट्रिक्सको साथ बिल्कुल सबै चरणहरू कभर गर्छौं।

ब्याकलग -विश्लेषकहरु आएपछि कति समस्याहरु आए ।

विकास - विकासकर्ताहरू कार्यहरू, स्ट्यान्डहरू वा उपकरणहरूमा स्पष्टीकरणको लागि कति हप्ता पर्खिरहेका छन् - यसले फरक पार्दैन, तर तिनीहरू केहिको लागि पर्खिरहेका छन्। उदाहरण को लागी, यो सुविधा लागू गर्न 4 दिन लाग्छ। यो जहाँ % C/A मेट्रिक आउँछ। विकासकर्ताहरूले ब्याकलगबाट मात्र 80% कार्यहरू लिए। बाँकी २०%सँग पर्याप्त प्राविधिक स्पेसिफिकेशन नभएको उनीहरुको विश्वास छ र परिमार्जनका लागि पठाइएको छ ।

परीक्षण गर्दै। LT रेखाचित्र 4 दिनमा सेट गरिएको छ। उदाहरणका लागि, परीक्षकहरू परीक्षण बेन्च नि:शुल्क हुनको लागि पर्खिरहेका थिए, VA तिनीहरूले वास्तवमा 2 दिनको लागि केहि परीक्षण गरिरहेका थिए, र %C/A = 40%। — विकासकर्ताहरूद्वारा पठाइएका कोड वा सुविधाहरूको 40% मात्र परीक्षकहरूले पर्याप्त मानेका थिए। उनीहरूलाई कुनै न कुनै कारणले अरू सबै मन परेन।

म यी मापनहरू कसरी पूरा गर्ने भनेर विस्तृत रूपमा बस्ने छैन; लेखको अन्त्यमा म साहित्य सिफारिस गर्नेछु जसबाट तपाईंले तिनीहरूको बारेमा जान्न सक्नुहुन्छ।

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

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

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

अस्थायी टोली

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

जब एक DevOps टोली धेरै वर्षसम्म लगातार अवस्थित हुन्छ, यो ठूलो गल्ती हो, किनभने DevOps विभागहरू बीचको सञ्चार, गति र दक्षताको बारेमा हो।

यदि एक टोली विभागहरू बीच मात्र अलग केहि गर्न को लागी अवस्थित छ, र लामो समय को लागी अवस्थित छ, तब यो एक अनावश्यक बाधा सिर्जना गर्दछ। अब, समस्या समाधान गर्न तुरुन्त प्रशासकमा जानुको सट्टा, प्रोग्रामरले पहिले DevOps विभागलाई सम्पर्क गर्नुपर्छ, र उसले अगाडि बढ्नेछ।

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

किन चाहियो अस्थायी टोली ?

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

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

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

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

काममा समय बर्बाद नगर्नुहोस्। यो फेरि उत्पादन को बारे मा छ। टोलीलाई अन्य उपकरण र सामानहरू प्रयास गर्न धेरै समय लाग्छ। मानिसहरूलाई उपकरणहरू मास्टर गर्न, तिनीहरूलाई लागू गर्न र तिनीहरूलाई सामान्य रूपमा प्रयोग गर्न कम्तिमा छ महिना लाग्नेछ। यदि तिनीहरू पनि उत्पादनमा ध्यान केन्द्रित गर्छन् भने, छ महिना ब्रह्माण्डीय रूपमा फैलिनेछ। यदि मानिसहरू उत्पादनमा काम गर्छन् भने, तिनीहरू फेरि पुरानो प्रक्रियाहरूसँग काम गर्छन् - हामीलाई त्यो आवश्यक छैन।

त्यसकारण, हामी विभिन्न विभागका मानिसहरूलाई छुट्टै टोलीमा नियुक्त गर्छौं जसले सेवालाई रूपान्तरण गर्नेछ। नतिजाको रूपमा, सेवाले काम गर्दछ, विकास गर्न जारी राख्छ, र एकै समयमा हामी यसमा केही प्रयोगहरू सञ्चालन गर्दछौं।

अस्थायी टोली केवल DevOps रूपान्तरणमा समर्पित छ - हामीले फेला पारेको सीमितता हटाउँदै, र अरू केही छैन।

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

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

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

- हो, यो राम्रो साथी हामी सबैलाई थाहा छ र माया त्यहाँ फिट हुन्छ - स्पष्ट रूपमा त्यहाँ DevOps मा हेर्न लायक केहि छ!

लक्ष्य सेट गर्दै

हामीले मानिसहरूलाई भेला गर्यौं, सेवा रोज्यौं, प्रतिबन्धहरू हेर्‍यौं, र कुन मानिसहरूलाई हामीले प्रभाव पार्छौं भनेर निर्धारण गर्यौं। अब तपाईंले लक्ष्य सेट गर्न आवश्यक छ र यो सीधा हुनुपर्छ SMART द्वारा - हामी सबै माया गर्छौं।

विशिष्ट - विशिष्ट.

मापनयोग्य - मापनयोग्य। यो एक धेरै महत्त्वपूर्ण SMART बिन्दु हो। यदि तपाइँ केहि मापन गर्न सक्नुहुन्न भने, तपाइँ यसलाई परिवर्तन गर्न सक्नुहुन्न र बुझ्न सक्नुहुन्न कि तपाइँ के र कसरी राम्रो वा खराब गर्नुभयो।

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

प्रासंगिक - प्रासंगिक। हामी केवल ती प्रतिबन्धहरू हटाउँछौं जुन वास्तवमा हाम्रो वर्तमान लक्ष्यहरू पूरा गर्दछ।

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

हामी मान स्ट्रिम नक्सा प्रयोग गरेर लक्ष्य लिन्छौं - हामी सबै मानिसहरूलाई फेरि सङ्कलन गर्छौं र तिनीहरूलाई आकर्षित गर्छौं। तर अब मात्र, अघिल्लो मान स्ट्रिम नक्सामा आधारित, हामी के प्राप्त गर्न चाहन्छौं।

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

यसको आधारमा, हामीले कार्य सेट गर्छौं: हामी समाप्त भएको रिलीज र युद्धमा जाने बीचको प्रतीक्षा अधिकतम एक घण्टाको हुन चाहन्छौं।

कार्यहरूको उदाहरणहरू।

• परीक्षणको नेतृत्व समय 4 दिनबाट 1 घण्टामा घटाउनुहोस्।
• परीक्षणको लागि मूल्य थपिएको समयलाई २ दिनबाट ३ घण्टामा घटाउनुहोस्।
• डिप्लोयमेन्टको लीड टाइमलाई ५ घण्टाबाट १० मिनेटमा घटाउनुहोस्।
• C/A लाई 50% बाट 95% मा बढाउनुहोस्, अर्थात्, परीक्षकहरूले स्वीकार गर्ने सुविधाहरूको संख्या बढाउनुहोस्, अर्को शब्दमा, विकासकर्ताहरूको कामको गुणस्तर सुधार गर्नुहोस्।

कार्यहरूको उदाहरणहरू हाम्रो टाउकोबाट लिइँदैन - तिनीहरू हामीले मान स्ट्रिम नक्सा विकास गर्दा गरेका मापनहरूमा आधारित हुन्छन्।

हामीले हाम्रो टोलीको लागि समान कार्य र समय सीमा सेट गर्यौं। तपाईको कम्पनीले कति राम्रो गरिरहेको छ भन्ने आधारमा, तपाईले फरक समयसीमा सेट गर्नुहुन्छ। औसतमा, यो सामान्यतया छ महिना लाग्छ सीमितता हटाउन, यदि मानिसहरूले यो पहिलो पटक गर्दैछन् र अझै थाहा छैन कुन प्रविधिहरू र कसरी विशेष रूपमा तिनीहरूले समस्या समाधान गर्नेछन्।

छोटो योजना

त्यसोभए, हाम्रो टोली बन्यो, यसको लक्ष्य छ, मानिसहरू काम गर्न थाल्छन्। एउटा महत्त्वपूर्ण बिन्दु कामको छोटो योजना हो: स्प्रिन्ट एक देखि दुई हप्तार अधिक छैन, मापनयोग्य सुधारहरू हरेक हप्ता र पाठ्यक्रम सुधार.

उदाहरणका लागि, हामी अक्सर दृष्टिकोण प्रयोग गर्दछौं चलिरहेकोजब सम्पूर्ण टोली प्रत्येक हप्ताको सुरुमा भेला हुन्छ, तिनीहरूले सबैले के गर्ने भन्ने फाइलमा लेख्छन्। एक हप्ता पछि, हामी के गरिएको छ र के छैन, यदि छैन भने, त्यसो भए किन, र हामी अर्को के गर्ने बारे सोच्दछौं।

स्प्रिन्टहरूले तपाईंलाई समयमै पाठ्यक्रम सुधार गर्न अनुमति दिन्छ।

एक वा दुई हप्ताको लागि तपाईंले केहि प्रयास गर्नुभयो: प्रविधिहरू, दृष्टिकोणहरू, काम गर्ने तरिकाहरू, त्यसपछि तपाईं फेरि मापन गर्नुहोस् र हेर्नुहोस् - यो दृष्टिकोण संग यो राम्रो वा खराब भयो? यदि यो खराब छ भने, यसको मतलब हामी गलत दिशामा जाँदैछौं, हामीले पाठ्यक्रम सच्याउन आवश्यक छ: फरक कार्य सेट गर्नुहोस्, फरक प्रविधि लिनुहोस्, वा अरू केहि गर्नुहोस्। 1-2 हप्ताको छोटो स्प्रिन्टहरूले तपाईंलाई चाल चलाउन र समयमा खराब निर्णयहरूबाट बच्न अनुमति दिन्छ।

सेयर गर्दै सफलता

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

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

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

तपाईंले के गर्नुभयो भन्ने बारेमा कुरा गर्नु महत्त्वपूर्ण छ। यस तरिकाले तपाईंले आफ्नो शिविरमा सामेल हुन र तिनीहरूलाई आविष्कारकहरूमा रूपान्तरण गर्न पुरानो तरिकाले सबै गर्न चाहने रूढीवादीहरूलाई विश्वस्त पार्नुहुनेछ।

कुल

सेवा छनोट गर्दै, सुरूवात बिन्दुको रूपमा - हामी कम्पनीमा परिवर्तन सुरु गर्ने ठाउँ। हामी सबैलाई पहिचान गर्छौं जो सेवासँग सम्बन्धित छ र तिनीहरूसँग एक मान स्ट्रीम नक्शा निर्माण, हामी कहाँ र के सीमाहरू छन् मापन र हेर्छौं।

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

प्रक्रिया दोहोर्याउनुहोस्, जबसम्म हामीले हाम्रा सबै सेवाहरूलाई आवश्यक फारममा रूपान्तरण गर्दैनौं र सबै प्रतिबन्धहरू हटाउँदैनौं।

बोनस। उपयोगी सामाग्री

तिनीहरूका लागि जसले आफ्नै रूपमा DevOps गर्ने निर्णय गरे।

फीनिक्स परियोजना

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

"तपाईंसँग सबै कुरा ठीक गर्न केही वर्षहरू छन् ताकि हामी अन्ततः हाम्रा ग्राहकहरूलाई छिटो र प्रभावकारी रूपमा हाम्रो उत्पादनहरू डेलिभर गर्न सक्छौं।"

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

DevOps गाइड

पुस्तक थप जटिल छ। यो धेरै वर्ष पहिले अंग्रेजीमा "The DevOps Handbook How to create world-class agility, reliability, and security in Technologies" शीर्षकमा प्रकाशित भएको थियो तर अब यो रुसी भाषामा उपलब्ध छ। यो साच्चिकै हो ह्यान्डबुक - व्यावहारिक गाइड: मापन कसरी गर्ने, मान स्ट्रिम नक्सा के हो र यो किन आवश्यक छ, कहाँ जाने, कुन क्रममा। पुस्तक केवल तिनीहरूका लागि हो जसले सबै कुरा आफैं गर्न चाहन्छ। सबैभन्दा महत्त्वपूर्ण कुरा, यसले अन्य कम्पनीहरूको अनुभवहरूको उदाहरणहरू समावेश गर्दछ।

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

गतिवर्धन

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

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

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

स्रोत: www.habr.com