हम एक संक्षिप्त भाषा में DevOps के बारे में बात करते हैं

क्या DevOps के बारे में बात करते समय यह बात पाना मुश्किल है? हम आपके लिए ज्वलंत उपमाएँ, परकशन फॉर्मूलेशन और विशेषज्ञ की सलाह के लिए इकट्ठा हुए हैं जो गैर-विशेषज्ञों को भी बात करने में मदद करेंगे। अंत में, बोनस Red Hat का अपना DevOps है।



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

इसलिए, DevOps के बारे में आप अक्सर सवाल सुन सकते हैं जैसे, क्या यह चुस्त है? या यह किसी प्रकार की विशेष पद्धति है? या यह "सहयोग" शब्द के लिए सिर्फ एक और पर्याय है?

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

DevOps क्या है: 6 परिभाषाएँ और उपमाएँ

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

1. DevOps एक सांस्कृतिक आंदोलन है

“DevOps एक सांस्कृतिक आंदोलन है, जिसमें दोनों पक्ष (सॉफ्टवेयर डेवलपर्स और आईटी सिस्टम ऑपरेशन विशेषज्ञ) मानते हैं कि सॉफ्टवेयर तब तक वास्तविक लाभ नहीं लाता है जब तक कि कोई इसका उपयोग शुरू नहीं करता है: ग्राहक, ग्राहक, कर्मचारी, इस बिंदु पर नहीं, देवओप्स इंस्टीट्यूट के वरिष्ठ विश्लेषक एवलीन ओहरेलिच का कहना है। "इसलिए, ये दोनों पार्टियां मिलकर तेज और उच्च गुणवत्ता वाली सॉफ्टवेयर डिलीवरी प्रदान करती हैं।"

2. DevOps वह है जो डेवलपर्स को सशक्त बनाता है

"DevOps डेवलपर्स को अनुप्रयोगों के स्वामित्व, उनके लॉन्च और वितरण प्रबंधन को शुरू से अंत तक सशक्त बनाता है"

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

3. DevOps अनुप्रयोगों के निर्माण और वितरण में एक सहयोग है

बीएमसी में डिजिटल बिजनेस ऑटोमेशन के अध्यक्ष और प्रमुख गुर स्टफ ने कहा, "सीधे शब्दों में कहें तो देव ऑप्शंस सॉफ्टवेयर के उत्पादन और वितरण के लिए एक ऐसा तरीका है जब हर कोई एक साथ काम करता है।"

4. DevOps एक पाइपलाइन है

"कन्वेयर असेंबली केवल तभी संभव है जब सभी भाग एक साथ फिट हों।"

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

व्यवसाय तर्क या उपयोगकर्ता इंटरफ़ेस बनाने वाले एक डेवलपर को एक डेटाबेस के बारे में सोचना चाहिए जो ग्राहकों के बारे में जानकारी संग्रहीत करता है, उपयोगकर्ता डेटा की सुरक्षा के लिए सुरक्षा उपायों के बारे में जानकारी देता है, और जब यह सेवा एक बड़े, संभवतः यहां तक ​​कि मल्टी-मिलियन की सेवा शुरू करती है, तो यह कैसे काम करेगा उपयोगकर्ता दर्शक। "

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

5. DevOps लोगों, प्रक्रियाओं और स्वचालन का सही संयोजन है

DevOps Institute के कार्यकारी निदेशक, Jayne Groll ने DevOps को समझाने के लिए एक महान सादृश्य की पेशकश की। उनके अनुसार, “DevOps एक पाक व्यंजन की तरह है जिसमें सामग्री की तीन मुख्य श्रेणियाँ हैं: लोग, प्रक्रियाएँ और स्वचालन। इनमें से अधिकांश सामग्री अन्य क्षेत्रों और स्रोतों से ली जा सकती है: लीन, एजाइल, एसआरई, सीआई / सीडी, आईटीआईएल, नेतृत्व, संस्कृति, उपकरण। DevOps का रहस्य, साथ ही साथ कोई भी अच्छा नुस्खा है, कैसे सही अनुपात का चयन करें और अनुप्रयोगों को बनाते और जारी करते समय काम की गति और प्रभावशीलता बढ़ाने के लिए इन सामग्रियों को मिलाएं। ”

6. DevOps - यह तब होता है जब प्रोग्रामर फॉर्मूला 1 टीम के रूप में काम करते हैं

"दौड़ शुरू से अंत तक नहीं, बल्कि खत्म से शुरू होने की योजना है।"

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

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

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

कैसे करें देवओप्स: 10 एक्सपर्ट टिप्स

बस DevOps और बड़े पैमाने पर DevOps दो पूरी तरह से अलग चीजें हैं। हम आपको बताएंगे कि पहले से दूसरे तक बाधाओं को कैसे दूर किया जाए।

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

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

यह देखना आसान है कि परिणामस्वरूप, "हम" और "वे" में अलगाव की संस्कृति बनती है।

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

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

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

ऊपर वर्णित इन कठिनाइयों को कैसे दूर करें और एक बड़े संगठन में DevOps के बड़े पैमाने पर उपयोग के लिए आगे बढ़ें? विशेषज्ञ आपसे धैर्य रखने का आग्रह करते हैं, भले ही आपका अंतिम लक्ष्य सॉफ्टवेयर विकास चक्र और व्यावसायिक प्रक्रियाओं को गति देना हो।

1. याद रखें कि सांस्कृतिक परिवर्तन में समय लगता है

Devneps Institute के कार्यकारी निदेशक Jayne Groll: “मेरी राय में, DevOps का विस्तार क्रमिक विकास के रूप में क्रमिक और पुनरावृत्त होना चाहिए (और संस्कृति को समान रूप से प्रभावित करता है)। फुर्तीली और DevOps छोटी टीमों पर ध्यान केंद्रित करते हैं। लेकिन इस तरह की टीमों की संख्या और एकीकरण बढ़ता है, हम अधिक से अधिक लोगों को काम के नए तरीकों को लागू करते हैं, और परिणामस्वरूप, बड़े पैमाने पर सांस्कृतिक परिवर्तन उत्पन्न होता है। "

2. पर्याप्त समय की योजना बनाना और एक मंच चुनना

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

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

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

3. दोषी स्वाद से छुटकारा पाएं

गॉर्डन हैफ, रेडहैट इंजीलवादी: "एक प्रणाली और वातावरण बनाना जो प्रयोग की अनुमति देता है और प्रोत्साहित करता है, हमें चुस्त सॉफ्टवेयर विकास में तथाकथित सफल विफलताओं का एहसास करने की अनुमति देता है। इसका मतलब यह नहीं है कि विफलताओं के लिए कोई और जिम्मेदार नहीं है। वास्तव में, एक जिम्मेदार व्यक्ति को स्थापित करना और भी आसान हो जाता है, क्योंकि "जिम्मेदार होने" का मतलब अब "दुर्घटना का अपराधी बनना" नहीं है। यही है, जिम्मेदारी का सार गुणात्मक रूप से बदल रहा है। इस मामले में, चार कारक अत्यंत महत्वपूर्ण हो जाते हैं: विफलता, दृष्टिकोण, उत्पादन प्रक्रियाओं और प्रोत्साहनों का परिमाण। " (इन कारकों पर अधिक जानकारी के लिए, गॉर्डन हफ के DevOps पाठ देखें: स्वस्थ प्रयोगों के 4 पहलू।)

4. आगे का रास्ता साफ करें

बेन ग्रिनल, मैनेजिंग डायरेक्टर और डिजिटल टेक्नोलॉजी के हेड, नॉर्थ हाईलैंड कंसल्टिंग: “स्केल अप करने के लिए, मैं सुझाव देता हूं कि अग्रणी प्रोजेक्ट्स के साथ, हमने क्लीयरिंग पाथ प्रोग्राम लॉन्च किया है। इस कार्यक्रम का लक्ष्य DevOps के अग्रदूतों के साथ बने रहने वाले कचरे को साफ करना है, जैसे कि नियम जो प्रासंगिकता और अन्य समान चीजों को खो चुके हैं, ताकि आगे का रास्ता स्पष्ट रहे। "

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

5. औजारों को अधिक लोकतांत्रिक बनाएं

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

6. टीम के काम के लिए आदर्श स्थितियां बनाएं

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

7. कॉनवे कानून और कानबन बोर्डों को मत भूलना

लोगान Daigle, CollabNetVersionOne DevOps सॉफ़्टवेयर डिलीवरी और रणनीति निदेशक: “कॉनवे के नियम के परिणामों को समझना महत्वपूर्ण है। मेरे नि: शुल्क विरोधाभास में, यह कानून बताता है कि हम जो उत्पाद बनाते हैं और जिन प्रक्रियाओं का हम उपयोग करते हैं, जिनमें DevOps भी शामिल हैं, हमारे संगठन के समान ही हैं। ”

“यदि संगठन अत्यधिक खंडित है, और जब सॉफ़्टवेयर की योजना बनाते, बनाते और जारी करते हैं, तो प्रबंधन कई बार हाथों से गुजरता है, स्केलिंग का प्रभाव शून्य या अल्पकालिक होगा। यदि संगठन उन उत्पादों के आसपास क्रॉस-फ़ंक्शनल टीमों का निर्माण करता है जो बाजार उन्मुखीकरण के साथ वित्त पोषित हैं, तो सफलता की संभावना नाटकीय रूप से बढ़ जाती है। ”

“स्केलिंग का एक अन्य महत्वपूर्ण पहलू है किनबन बोर्डों पर सभी कार्य प्रगति पर प्रदर्शित होना (डब्ल्यूआईपी, वर्किनप्रोग्रेस)। जब कोई संगठन ऐसी जगह पर दिखाई देता है जहाँ लोग ऐसी चीजों को देख सकते हैं, तो यह सहयोग को बहुत उत्तेजित करता है, जिसका स्केलिंग पर सकारात्मक प्रभाव पड़ता है। ”

8. पुराने निशान देखें

मैनुअल पाइस, देवऑप्स सलाहकार और टीम टोपोलॉजी के सह-लेखक: “देवी ऑप्स से परे देवओप्स प्रथाओं को लेना और उन्हें अन्य कार्यों में लागू करने की कोशिश करना शायद ही इष्टतम दृष्टिकोण कहा जा सकता है। यह निस्संदेह एक निश्चित प्रभाव देगा (उदाहरण के लिए, मैनुअल नियंत्रण के स्वचालन के कारण), लेकिन बहुत कुछ हासिल किया जा सकता है यदि हम वितरण प्रक्रियाओं और प्रतिक्रिया की समझ के साथ शुरू करते हैं।

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

9. DevOps विकल्प न रखें

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

10. व्यवसाय के लिए DevOps के मूल्य का प्रचार करें

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

बोनस

13 सितंबर को, हमारे अपने DevOps Red Hat फोरम रूस में पहुंचेंगे - हाँ, Red Hat, एक सॉफ़्टवेयर निर्माता के रूप में, अपनी स्वयं की DevOps टीमें और प्रथाएँ हैं।

हमारे इंजीनियर मार्क बिगर, जो पूरे संगठन में अन्य समूहों के लिए आंतरिक स्वचालन सेवाओं का विकास कर रहे हैं, शुद्ध रूसी में अपनी कहानी कहते हैं - कैसे Red Hat DevOps टीम ने Open वर्चुअलाइजेशन प्लेटफॉर्म पर एक पूर्ण कंटेनर प्रारूप में Ansible द्वारा Hat वर्चुअलाइजेशन प्रबंधित परिवेशों से अनुप्रयोगों को माइग्रेट किया।

लेकिन यह सब नहीं है:

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