मैं लगभग पांच वर्षों से विभिन्न ग्राहकों के साथ एक परामर्शदाता के रूप में DevOps पर अभ्यास और सलाह दे रहा हूं, अपनी वर्तमान स्थिति से पहले, मैंने सॉफ्टवेयर विकास, वेब संचालन और सिस्टम प्रशासन में भूमिकाएं निभाईं। मेरे व्यक्तिगत अनुभव में DevOps कई स्वादों में आता है।
संगठन के पैटर्न
देवता प्रतिपदा:
NoOps और NoDevs - सख्ती से DevOps सबसे सख्त अर्थों में नहीं हैं, हालांकि, ये टीमें विकास और संचालन के बीच विभाजन रेखा के बिना सॉफ़्टवेयर का निर्माण और संचालन करती हैं। इन टीमों के साथ चुनौतियां परिपक्वता के लिए नीचे आती हैं, विकास दल विशेषज्ञ सॉफ्टवेयर डेवलपर्स हो सकते हैं लेकिन नौसिखिए ऑपरेटर और वीजा वर्सा।
DevOps Bridge - यह वह जगह है जहाँ एक या अधिक टीमों को विकास टीमों से काम लेने और इसे संचालित करने के लिए " उत्पादन " करने की जिम्मेदारी दी जाती है । यह चुनौती अब कम हो गई है, दो हाथ हैं, यानी विकास → DevOps और DevOps → संचालन।
DevOps टीम - यह, यकीनन काम कर सकता है यदि टीम के पास ऐसे उपकरण बनाने की जिम्मेदारी है जो DevOps सक्षम ऑपरेटिंग मॉडल का समर्थन करते हैं, हालांकि, इसे संभवतः "टूल टीम" या "प्लेटफ़ॉर्म टीम" कहा जाना चाहिए।
DevOps पैटर्न:
एंबेडेड DevOps - जिसे आमतौर पर प्लेटफ़ॉर्म इंजीनियरिंग के रूप में जाना जाता है, जिसमें टीम के भीतर कोई है जो जवाबदेह है, लेकिन समाधान के प्रावधान और तैनाती के लिए स्वचालन, उपकरण और बुनियादी ढांचे को वितरित करने के लिए ज़िम्मेदार नहीं है , कभी-कभी सॉफ़्टवेयर का संचालन करना भी शामिल है - मेरे दिमाग में , यह बाद वाला है जो वास्तव में DevOps का प्रतिनिधि है।
संस्थागत DevOps - जहां एक प्रोजेक्ट टीम संयुक्त रूप से एक सॉफ्टवेयर पैकेज बिल्डिंग साझा स्वामित्व और सकारात्मक प्रतिक्रिया छोरों के विकास और संचालन दोनों के लिए जिम्मेदार है।
आचरण
DevOps का वास्तविक अभ्यास कई अन्य प्रथाओं के शीर्ष पर है, अर्थात्:
उपरोक्त प्रथाओं में से प्रत्येक दूसरे पर बनाता है, यह एक अभ्यास का पालन नहीं करना संभव है , हालांकि, इसका मतलब है कि एक महत्वपूर्ण प्रतिक्रिया चक्र गायब है जो एक "चूक गए अवसर" का संकेत हो सकता है। अन्य प्रथाओं और DevOps में से किसी का पालन करने के बीच महत्वपूर्ण अंतर उत्पादन में सॉफ्टवेयर का संचालन है ।
तीन तरीके
में फीनिक्स परियोजना जीन किम और उनके सह लेखकों का वर्णन करता है DevOps के तीन तरीके :
प्रणाली की विचारधारा
पहला रास्ता पूरी प्रणाली के प्रदर्शन पर जोर देता है, काम या विभाग के एक विशिष्ट साइलो के प्रदर्शन के विपरीत - यह उतना ही बड़ा हो सकता है जितना एक विभाजन (जैसे, विकास या आईटी संचालन) या एक छोटे से व्यक्तिगत योगदानकर्ता के रूप में (जैसे , एक डेवलपर, सिस्टम प्रशासक)।
मेरे अनुभव में डेवलपर्स को ऑपरेशनल कंसर्न और गैर-कार्यात्मक आवश्यकताओं पर विचार करना शुरू करना इस लक्ष्य को प्राप्त करता है। यह DevOps के संस्कृति पहलुओं का बहुत हिस्सा है ।
फीडबैक लूप्स का प्रवर्धन
दूसरा तरीका वामपंथियों के दायें हाथ के छोरों को बनाने के बारे में है। लगभग किसी भी प्रक्रिया सुधार पहल का लक्ष्य फीडबैक को छोटा और बढ़ाना है ताकि आवश्यक सुधार लगातार किए जा सकें।
मैं आम तौर पर कंटीन्यूअस इंटीग्रेशन / डिलिवरी / परिनियोजन और साझा निगरानी और अलर्टिंग के माध्यम से इसे प्राप्त करता हूं, इस प्रकार यह DevOps के टूल कंपोनेंट के साथ बहुत फिट बैठता है ।
सतत प्रयोग और सीखने की संस्कृति
थर्ड वे एक संस्कृति बनाने के बारे में है जो दो चीजों को बढ़ावा देती है: लगातार प्रयोग, जोखिम लेना और विफलता से सीखना; और यह समझना कि पुनरावृत्ति और अभ्यास महारत हासिल करने की शर्त है।
यह कल्चर स्पेस में बहुत फिट बैठता है, हालांकि यह टूल्स पर निर्भर करता है और संस्कृति को विकसित करने के लिए प्रक्रिया करता है।
