DevOps एक संस्कृति है, भूमिका नहीं!

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

  • स्वचालित कॉन्फ़िगरेशन प्रबंधन, परीक्षण और अनुप्रयोग परिनियोजन;
  • सहयोग और रोलबैक को सक्षम करने के लिए एप्लिकेशन और इन्फ्रास्ट्रक्चर कोड का संस्करण नियंत्रण;
  • CI (निरंतर एकीकरण) कोड को स्वचालित बनाता है और अधिक लगातार, कम जोखिम वाले रिलीज के माध्यम से तेजी से प्रतिक्रिया और पुनरावृत्ति को सक्षम करता है।

DevOps इस बात का एक सांस्कृतिक परिप्रेक्ष्य है कि कैसे सभी को सही तरीके से काम करने में लगे रहना चाहिए। एक सॉफ्टवेयर परिभाषित दुनिया में सवालों का ढेर दिखाई देता है।

हम उत्पादन में कैसे जल्दी और उत्पादन में एक बार कुछ प्राप्त करते हैं? हमें कैसे पता चलेगा कि हम सबसे अच्छे समाधान के साथ आए हैं? हम कितनी जल्दी सुधार और अपडेट लागू कर सकते हैं?

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

हाल ही में कहा गया है कि माइक दिलवर्थ, फुर्तीली और DevOps परिवर्तन नेतृत्व:

DevOps एक संस्कृति है, भूमिका नहीं! पूरी कंपनी को काम करने के लिए DevOps करने की जरूरत है।

केवल विकास और संचालन विभाग ही नहीं, बल्कि वरिष्ठ नेतृत्व से भी समर्थन की जरूरत है, लेकिन अंतिम उत्पाद में हिस्सेदारी के साथ सभी की भागीदारी।

मैं पपेट द्वारा एक श्वेत पत्र पढ़ता था कि हम उच्च प्रदर्शन करने वाली आईटी टीम कैसे बना सकते हैं। और धारा ए में आपके साथ साझा करने के लिए दिलचस्प सिद्धांतों और प्रथाओं का एक समूह था।

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

व्यावसायिक मामले का निर्माण करें

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

आप देवओप्स के लिए एक स्पष्ट, ठोस मामला कैसे बनाते हैं जो डर को कम करता है और संशयवादियों को चैंपियन में परिवर्तित करता है?

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

लोग वे नहीं खरीद रहे हैं जो वे नेता कर रहे हैं लेकिन वे ऐसा क्यों कर रहे हैं।

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

DevOps के साथ बोर्ड पर देवता का होना

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

  1. एक देव के लैपटॉप से ​​उत्पादन के लिए कोड कितनी जल्दी स्थानांतरित हो सकता है?
  2. यह आपके पूर्व लीड समय के खिलाफ कैसे ढेर हो जाता है? (क्या आपने निर्माण प्रक्रिया को अधिक स्वचालित किया था? क्या आपने तैनाती के लिए आवश्यक टिकटों की संख्या में कटौती की थी? "
  3. अब आप कितनी बार बनाम तब तैनात कर रहे हैं?
  4. क्या तैनाती आसान और तेज हो गई है?

DevOps के साथ बोर्ड पर ऑप्स प्राप्त करना

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

  • अपटाइम / डाउनटाइम: क्या आप अपनी सेवा-स्तर की आवश्यकताओं को पूरा करने में बेहतर हैं? डाउनटाइम कम हो गया है?
  • असफलता दर बदलें: क्या असफलताएँ कम हुई हैं?
  • पुनर्प्राप्त करने का औसत समय: क्या आपने असफलता होने पर अपने अंतिम ज्ञात अच्छे राज्य में वापस आने में लगने वाले समय को सिकोड़ लिया है?

छोटी शुरुआत करें और शुरुआती सफलताओं से बढ़ें।

तो आप इन DevOps प्रभावों को कैसे मापना शुरू करते हैं और अपने व्यापार के मामले को बढ़ाते हैं? विशिष्ट कार्यों और परियोजनाओं के साथ छोटी शुरुआत करें। यह दृष्टिकोण टेरी पॉट्स (रेथियॉन में इंजीनियरिंग साथी और सॉफ्टवेयर तकनीकी निदेशक) के लिए अत्यधिक प्रभावी साबित हुआ।

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

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

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