हम DevOps के बारे में समझने योग्य भाषा में बात करते हैं

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

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

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

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

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

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

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

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

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

"DevOps डेवलपर्स को एप्लिकेशन रखने, उन्हें चलाने और शुरू से अंत तक डिलीवरी प्रबंधित करने का अधिकार देता है।"

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

3. DevOps एप्लिकेशन बनाने और वितरित करने में सहयोग के बारे में है।

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps को कैसे स्केल करें: विशेषज्ञों से 10 युक्तियाँ

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

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

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

यह देखना आसान है कि इसका परिणाम "हम" और "वे" के बीच विभाजन की संस्कृति है।

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

“और यह सांस्कृतिक समस्या सिर्फ एक कारण है कि DevOps को स्केल करना मुश्किल है। स्केलियर के संस्थापक और अध्यक्ष स्टीव न्यूमैन ने कहा, डेवऑप्स टीमों को बढ़ती तकनीकी चुनौतियों का सामना करना पड़ रहा है जो तेजी से बढ़ती आईटी-फर्स्ट कंपनियों की खासियत हैं।

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

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

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

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

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

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

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

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

3. दोष को जिम्मेदारी से बाहर निकालें।

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

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

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

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

5. उपकरणों का लोकतंत्रीकरण करें

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

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

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

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

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

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

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

8. पुराने निशानों की तलाश करें

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

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

9. DevOps विकल्पों का प्रजनन न करें

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

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

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

बोनस

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

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

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

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

स्रोत: www.habr.com