DevOps परिवर्तन कैसे शुरू करें

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

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


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

यदि आप DevOps परिवर्तन के मुद्दे के बारे में चिंतित हैं, तो आपके पास एक बड़ी कंपनी है, और आपको धीरे-धीरे इस प्रक्रिया को पूरी संरचना में स्केल करना होगा। जब तक टीम को बदलने या किसी तरह के प्रतिबंध को हटाने की आवश्यकता होती है, तब तक नीचे दिए गए एल्गोरिदम को दोहराया जा सकता है।

सेवा चयन

हमने एक योजना की रूपरेखा तैयार की है, पहले चरण से शुरू करें - एक सेवा का चयन करना। पहला मानदंड जीवनकाल है : पुरानी सेवाएं हैं - विरासत और नए। आप उन और दूसरों के साथ शुरू कर सकते हैं।

युवा सेवा का चयन करना तर्कसंगत है । यह ताजा है, इसके साथ काम करने वाली टीम में काम करने की कोई अच्छी तरह से स्थापित प्रक्रिया नहीं है। उसके चारों ओर तकनीकी ऋण का पहाड़ नहीं है, हर समय उसे सुधारने की आवश्यकता नहीं है। हम उसके साथ जो चाहें कर सकते हैं।

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

पुरानी सेवा के साथ काम करने से आपकी कंपनी में एक शक्तिशाली मिसाल पैदा होती है - आप कुछ बदल सकते हैं। यदि आप एक नई सेवा बदलते हैं, तो यह प्रति घंटे 100 बार तक लुढ़कता है, और सब कुछ ठीक है, तो आपकी कंपनी के लोग कह सकते हैं:

- यह एक नई सेवा है! वहां सब कुछ सरल था, हमारी तली हुई चीजों के साथ कुछ करने की कोशिश करें।

जब आप किसी के साथ ऐसा करते हैं, तो एक परिवर्तन में एक लिगेसी सेवा लेने का कोई मतलब नहीं है, उदाहरण के लिए, यदि आपने किसी बाहरी सलाहकार को आमंत्रित किया है। चलो ईमानदार रहें, परिवर्तन हर उस चीज को डगमगाएगा जो संभव है । आप प्रयोग कर रहे हैं और यह नहीं जानते कि आप कहां आएंगे, किन तकनीकों और क्यों का उपयोग करेंगे, प्रक्रियाओं में कहां और क्या नुकसान होंगे। इसलिए, एक नया बदलाव आसान है।

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

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

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

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

अगला, सेवा कमांड पर विचार करें । उन लोगों के साथ जो इस सेवा में लगे हुए हैं, हमें लगातार काम करना होगा और बहुत निकट संपर्क में होना चाहिए।

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

एक ओर, रूढ़िवादी अनुभवी लोग हैं: वे लंबे समय से कंपनी के साथ हैं, वे इसे पूरी तरह से समझते हैं, लेकिन वे सिर्फ प्रथाओं के बारे में नहीं जानते हैं। दूसरी ओर, ऐसे इनोवेटर हैं जिन्होंने कुछ सुना है, लेकिन सबसे अधिक संभावना है कि वे कंपनी के लिए इतने लंबे समय से काम कर रहे हैं। उनमें से किसके साथ काम करना बेहतर है?

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

एक इनोवेटर टीम का चयन करना तर्कसंगत है, क्योंकि रूढ़िवादी एक सुअर डाल सकते हैं।

व्यवहार में, अक्सर ऐसा होता है कि रूढ़िवादी लोगों के पास महत्वपूर्ण अनुभव होता है, लेकिन इस पर कोई समझ नहीं होती है कि कैसे जीना है। वे बस डरते हैं कि सेवा के परिवर्तन और परिवर्तन के बाद, उन्हें अनावश्यक के रूप में खारिज कर दिया जाएगा। कभी-कभी, बस क्या हो रहा है की समझ की कमी के कारण, वे काम को तोड़फोड़ करते हैं।

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

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

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

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

संक्षेप में देना। यदि हम अपनी कंपनी में सभी परिवर्तन स्वयं करते हैं, तो हम चुनते हैं: एक नई सेवा, अधिमानतः एक सरल इंटरफ़ेस, ताकि इसके टूटने से ज्यादा नुकसान न हो, और नवप्रवर्तनकर्ताओं की एक टीम।

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

कौन शामिल है?

हमें सामान्य रूप से सभी को खोजने की जरूरत है, जिनके पास सेवा के साथ कम से कम कुछ है: डेवलपर्स, परीक्षक, व्यवस्थापक, सुरक्षा गार्ड, प्रबंधक और संभवतः उत्पाद स्वामी। इस तथ्य के बावजूद कि उत्पाद स्वामी तकनीकी नहीं हैं, वे सेवा से संबंधित हैं: एक निर्णय लें, एक कार्य निर्धारित करें।

हर कोई जो कम से कम कुछ निर्णय लेता है और प्रभावित करता है कि सेवा के साथ क्या हो रहा है, मिलना और मिलना चाहिए।

वे हमारे लिए क्या हैं? यह जानने के लिए कि किसके साथ बातचीत करनी है । परिवर्तन के दौरान, जब सेवा के साथ काम करने का सामान्य सिद्धांत बदल जाता है, तो यह वैसे भी हिल जाएगा। नए दृष्टिकोणों का परीक्षण करते समय थोड़ी देर के लिए ग्लिच होंगे। लोगों को इसके लिए तैयार रहना चाहिए और इससे सहमत होना चाहिए।

फिर आपको एक वैल्यू स्ट्रीम मैप तैयार करना होगा और इन लोगों के बिना आप इसे नहीं बना सकते, क्योंकि केवल वे सभी एक साथ पूरी तस्वीर जानते हैं कि क्या हो रहा है। एक व्यक्ति सेवा के साथ होने वाली हर चीज को कभी नहीं जानता है।

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

फिर हम इन सभी लोगों को अलग-अलग विभागों से एक कमरे में इकट्ठा करते हैं और वैल्यू स्ट्रीम मैप बनाने लगते हैं।

एक मूल्य स्ट्रीम मानचित्र का निर्माण

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

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

मैट्रिक्स

वैल्यू स्ट्रीम मैप साहित्य में वर्णित कई अलग-अलग मीट्रिक हैं, लेकिन शुरुआत के लिए, हमें केवल तीन की आवश्यकता है।

लीड समय - देरी / प्रतीक्षा - वह समय जब हम किसी चीज की प्रतीक्षा करते हैं। उदाहरण के लिए, परीक्षक तब तक प्रतीक्षा करता है जब तक परीक्षण स्टैंड को मुक्त नहीं किया जाता है और इस समय कुछ भी नहीं कर सकता है।

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

% C / A - स्वीकृत कार्य का प्रतिशत। हमारे पास एक चरण है - विकास, दूसरा चरण - परीक्षण। डेवलपर्स से कितने फ़ीचर टेस्टर लिए गए, और यह प्रतिशत है।

यह हमारे नक्शे जैसा दिखता है।



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

मेट्रिक्स बिल्कुल सभी चरणों को कवर करते हैं।

बैकलॉग - विश्लेषकों ने उनके साथ आने के बाद कितने कार्य किए।

विकास - कार्य, स्टैंड या उपकरण पर स्पष्टीकरण के लिए डेवलपर्स कितने हफ्तों से इंतजार कर रहे हैं - यह कोई फर्क नहीं पड़ता, लेकिन वे किसी चीज का इंतजार कर रहे हैं। उदाहरण के लिए, वे 4 दिनों के लिए एक सुविधा लागू करते हैं। % C / A मीट्रिक यहाँ दिखाई देता है। डेवलपर्स ने बैकलॉग से केवल 80% कार्य लिया। उनका मानना ​​है कि शेष 20% में स्पष्ट टीके नहीं हैं, और उन्हें संशोधन के लिए भेजा है।

परीक्षण । LT स्कीम पर, 4 दिन निर्धारित हैं। उदाहरण के लिए, परीक्षकों को परीक्षण बेंच जारी होने की प्रतीक्षा थी, वीए 2 दिनों के लिए वे वास्तव में कुछ परीक्षण कर रहे हैं, और% C / A / 40%। - केवल 40% कोड या विशेषताएं जो भेजे गए डेवलपर्स को परीक्षकों द्वारा पर्याप्त माना जाता था। वे किसी कारण से बाकी को पसंद नहीं करते थे।

मैं इन मापों को पूरा करने के तरीके पर ध्यान नहीं दूंगा, लेख के अंत में मैं साहित्य की सिफारिश करूंगा जिसमें से आप उनके बारे में जान सकते हैं।

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

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

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

अस्थायी टीम

कई कंपनियां जिन्होंने देवओप्स को पेश करने का फैसला किया है, वे न केवल अस्थायी, बल्कि कई वर्षों से एक टीम बना सकते हैं। यदि आप DevOps में जाते हैं, तो माफी माँगने वाली सेवा, जो DevOps में एक संगठनात्मक संरचना बनाने के लिए विभिन्न पैटर्न का वर्णन करती है, तो आप समझेंगे कि यह एक एंटीपैटर्न है।

जब DevOps टीम कई वर्षों से लगातार अस्तित्व में है, तो यह एक बड़ी गलती है, क्योंकि DevOps विभागों के बीच संचार, गति और दक्षता के बारे में है।

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

इसलिए, शुरू करने के लिए, आपको एक अस्थायी टीम बनाने की आवश्यकता है । यह छह महीने की निलंबित अवधि के लिए मौजूद रहेगा, अधिकतम एक वर्ष, कार्य के आधार पर, केवल एक सीमा को समाप्त करने के लिए जिसे हमने चुना है। फिर वह मर जाएगी। यदि हम अगला बिंदु चुनते हैं जहां यह बहुत दर्द देता है और यह समझता है कि हमें इसके लिए एक अलग टीम की भी आवश्यकता है, तो हम इसे फिर से बनाएंगे। लेकिन ऐसी टीमों को "स्थायी आधार" पर मौजूद नहीं होना चाहिए - फिर वे केवल संचार को बाधित करते हैं और सामान्य रूप से अलग कार्य करते हैं, केवल कुछ करने के लिए। ये कार्य देवओप्स या परिवर्तन से संबंधित नहीं हो सकते हैं। हम मौजूदा विभागों को यह कार्य क्यों नहीं देते?

आपको एक अस्थायी टीम की आवश्यकता क्यों है

वर्तमान प्रक्रियाओं के साथ संघर्ष । DevOps का परिवर्तन केवल हमारे द्वारा उपयोग की जाने वाली तकनीकों और उपकरणों का परिवर्तन नहीं है, बल्कि कार्य, सोच और मूल्यों की प्रक्रिया में परिवर्तन है। यदि टीम जिस तरह से उसका उपयोग करती है, वह काम करता है, तो वह अन्य तरीकों की कोशिश करने में सक्षम नहीं होगा।

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

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

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

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

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

अस्थायी टीम केवल DevOps परिवर्तन में शामिल है - जो प्रतिबंध हमें मिला, और इससे अधिक कुछ नहीं।

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

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

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

- हाँ, यह अच्छा दोस्त है कि हम सभी जानते हैं और प्यार करते हैं, वहाँ फिट - जाहिर है, DevOps में कुछ देखने लायक है!

हमने एक लक्ष्य निर्धारित किया

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

विशिष्ट - विशिष्ट ।

मापने योग्य - औसत दर्जे का । यह स्मार्ट का एक बहुत महत्वपूर्ण बिंदु है। यदि आप कुछ नहीं माप सकते हैं, तो आप इसे बदल नहीं सकते हैं और समझ सकते हैं कि आपने क्या और कैसे बेहतर या बुरा किया है।

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

प्रासंगिक - प्रासंगिक। हम केवल उस सीमा को समाप्त करते हैं जो वास्तव में हमारे वर्तमान लक्ष्यों का पीछा करती है।

समय सीमित - समय सीमित । यदि कोई समय सीमा नहीं है, तो टीम कुछ भी करेगी: 3 के बजाय 15 तकनीकों का प्रयास करें, बहुत बड़ी रिपोर्ट लिखें, बेकार अनुसंधान करें, जब लक्ष्य पहले से ही प्राप्त हो जाए तो इसके क्रियान्वयन को एक चमक के लिए चाटें।

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



हम एक सीमा को पूरा करते हैं जिसे हम अभी खत्म कर देंगे - यह वही है जो टीम करेगी। एक उदाहरण के रूप में, मैंने उत्पादन में अपनी तैनाती के लिए एक समाप्त रिलीज से अपेक्षा की - यह सबसे आम सीमा है जो लोग सलाहकारों की ओर मुड़ते हैं।

इसके आधार पर, हम कार्य निर्धारित करते हैं: हम चाहते हैं कि एक तैयार रिलीज के बीच का इंतजार और अधिकतम एक घंटे के लिए कार्रवाई में जाए।

कार्यों के उदाहरण।

• लीड समय परीक्षण को 4 दिन से 1 घंटे तक कम करें।
• 2 दिनों से 3 घंटे तक परीक्षण के लिए मूल्य वर्धित समय को कम करें।
• 5 घंटे से 10 मिनट तक लीड समय परिनियोजन को कम करें।
• सी / ए को 50% से बढ़ाकर 95% करें, अर्थात, उन विशेषताओं को बढ़ाएं जो परीक्षक स्वीकार करते हैं, दूसरे शब्दों में, डेवलपर्स की गुणवत्ता में सुधार करते हैं।

कार्यों के उदाहरण सिर से नहीं लिए गए हैं - वे उन मापों पर आधारित हैं जो हमने वैल्यू स्ट्रीम मैप को विकसित करते समय किए थे।

हम अपनी टीम के लिए एक समान कार्य और एक समय सीमा निर्धारित करते हैं। , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

क्यों? , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

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