DevOps और स्वचालन के बीच अंतर क्या है?

Question

मैं देख रहा हूं कि जब भी कोई DevOps करता है, तो वह ज्यादातर चीजों को स्वचालित करने के बारे में होता है जैसे कि तैनाती आदि।

लेकिन ऑटोमेशन कहां समाप्त होता है और देवओप्स शुरू होता है?

Comments

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

— रिचर्ड स्लेटर

शायद बेहतर सवाल यह होगा कि DevOps कहां समाप्त होता है और स्वचालन शुरू होता है? DevOps के साथ किया गया सब कुछ स्वचालन के बारे में नहीं है; इसका एक बड़ा हिस्सा, हां, लेकिन सभी नहीं ... एक कह सकता है कि DevOps सब कुछ है, लेकिन स्वचालन - यह एक विशेष तकनीकी क्षेत्र के सामान्य प्रकाशन मानकों (कहते हैं GitHub) के sysadmin कलन, आम है। क्या उस विशेष क्षेत्र में ऑटोमेशन शुरू होना अपने आप में एक अच्छा सवाल है, मुझे लगता है ...

— JohnDoea

Answer 1

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

यहां बताया गया है कि कैसे DevOps और स्वचालन संबंधित हैं। DevOps सिर्फ स्वचालन नहीं है, इसमें और भी बहुत कुछ है। इसके विपरीत, स्वचालन का उपयोग विशेष रूप से "DevOps people" द्वारा नहीं किया जाता है। DevOps के आने से पहले IT में काफी स्वचालन हो रहा था।

कृपया सभी आरेखों का प्रतिनिधित्व करने के लिए उपरोक्त आरेख पर विचार न करें जो DevOps है, या यह सब स्वचालन है। यह पाठक की तस्वीर की मदद करना है कि दो अवधारणाएं कैसे संबंधित हैं।

Comments

वास्तव में मैंने इस विषय पर क्या कहा था :)

— तेंसिबाई

DevOps में "टिकट वर्कफ़्लो" क्यों नहीं है?

— नैकिलोन

Answer 2

स्वचालन DevOps का एक प्रमुख गुण है, लेकिन यह पूरी कहानी नहीं है। सवाल तरह का है "टाइम-बॉक्सिंग और स्क्रैम के बीच अंतर क्या है?"।

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

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

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

एक बार जब हमारे पास उस स्वचालन की जगह होती है, तो फीडबैक लूप्स में किक करता है। हम चक्र समय जैसी चीजों को मापना शुरू करते हैं ताकि हम उन चीजों का पता लगा सकें जो हमने पिछले अनुमानों के साथ अनुमान लगाने की कोशिश की थीं। आर्किटेक्चर के बारे में चीजें जो स्वचालन / निरंतर वितरण को कठिन बनाती हैं, उन्हें वैकल्पिक वास्तुशिल्प पैटर्न के साथ प्रतिस्थापित किया जाता है जो स्वचालन / निरंतर वितरण को आसान बनाते हैं (इसके कई उदाहरणों को 'इवोल्यूशनरी डेटाबेस' पुस्तक में प्रलेखित किया गया है। 'Green / Blue Deployments' एक और है )।

सूचना मैं जेनकिंस, चेक, कठपुतली, Ansible, Vagrant, AWS, या इसका समर्थन करने वाले किसी भी अन्य टूलिंग के बारे में बात किए बिना यह विवरण प्रदान करने में सक्षम था। इसका मतलब है कि हम 'कार्यप्रणाली' जैसे बड़े स्तर के buzzwords से हैं। अंत में, उपकरणों के किसी भी सेट को प्रतिस्थापित किया जा सकता है ... जो हम छोड़ रहे हैं वह स्वचालन द्वारा सक्षम मुख्य प्रबंधन सिद्धांत और पाइपलाइन पर ध्यान केंद्रित करना है।

Comments

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

— तेंसिबाई

@ तेंसिबाई मुझे कुछ हद तक असहमत होना पड़ता है- आप एक ऐसी प्रक्रिया को स्वचालित नहीं करते हैं जो अक्सर निष्पादित नहीं होती है। एजाइल के बिना DevOps एक बहु-मिलियन डॉलर की सुपरकार की इमारत को स्वचालित करने जैसा है।

— डेव स्वर्सकी

यह उत्तर अविश्वसनीय रूप से क्रियात्मक है और मतभेदों को दूर करना कठिन है, या विपक्ष / विपक्ष जो ओपी क्यू से संबंधित है।

— एवगेनी

@ क्या आप इस बिंदु को याद कर रहे हैं, मुझे स्पष्ट नहीं होना चाहिए, मेरा क्या मतलब है कि देवोप्स संस्कृति साइलो टीमों को तोड़ने के बारे में है, स्वचालन या छोटा चक्र सामान्य रूप से भी असंबंधित है, मैंने आपके उत्तर में इस महत्वपूर्ण बिंदु को नहीं देखा है

— तनसीबाई

Answer 3

DevOps वास्तव में एक सांस्कृतिक बदलाव है - यह संचालन और विकास के बीच पारंपरिक बाधाओं को तोड़ने के बारे में है (और वास्तव में QA और बाकी व्यवसाय के साथ भी!)। विचार यह है कि विभागीय 'साइलो' होने के बजाय आप अन्य टीमों के साथ काम कर सकते हैं ताकि चीजें जल्दी और अधिक कुशलता से हो सकें।

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

Answer 4

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

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

Answer 5

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

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

Answer 6

देवों के आंदोलन में चार प्रमुख क्षेत्र शामिल हैं जिन्हें CAMS कहा जाता है :

1. संस्कृति
2. स्वचालन
3. माप
4. शेयरिंग

यहाँ 2010 से मूल परिभाषित पोस्ट है।

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

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

Answer 7

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

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

स्वचालन सफलता को दोहराने के बारे में है। अगर मैं चरण A, b और c और प्रक्रिया X हमेशा काम करता हूं, तो चरण a, b और c स्वचालन के लिए अच्छे उम्मीदवार हैं। फिर मैं उस समय का उपयोग कर सकता हूं जो उन चीजों को करने के लिए मैन्युअल प्रक्रिया के रूप में उपयोग किया जाता है जो मुझे अधिक पैसा बनाते हैं। स्वचालन सरल होने पर सफल होता है। नई रिलीज़ की तैनाती, एकीकरण परीक्षण चलाने, बोल्ट पर एक नट को टॉर्चर करना, डेटा का बैकअप लेना, क्रेडिट बनाम डेबिट आदि, स्वचालन के लिए सभी महान उम्मीदवार हैं क्योंकि चरणों को एक व्यक्ति या रोबोट द्वारा दोहराया जाता है।

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

Comments

लेकिन इसके विपरीत, सहयोग हमेशा सही था? देव और ऑप्स के बीच संचार, क्या यह कुछ नया है? क्या नया लाना है?

— गुलाबीपार्क

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

— कोई वापसी नहीं

स्वचालन और DevOps "असंबंधित" हैं? सम्मानपूर्वक, मैं इससे अधिक असहमत नहीं हो सकता। निरंतर एकीकरण, सतत तैनाती, स्वचालित परीक्षण, और अधिक DevOps के प्रौद्योगिकी घटक के लिए अभिन्न अंग हैं। स्वचालन के बिना, DevOps केवल संस्कृति है। संस्कृति महत्वपूर्ण है, सुनिश्चित करें, लेकिन यह तीन-पैर वाले DevOps मल (संस्कृति, प्रक्रिया, प्रौद्योगिकी) का केवल एक पैर है

— डेव स्वार्स्की

@NoRefundsNoReturns देवता संचालक हैं। इस अर्थ में कि किसी दल की आवश्यकता नहीं है?

— गुलाबीपार्क

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

— कोई वापसी नहीं वापसी