DevOps उपमाएँ लाना क्या हैं?

Question

कुछ प्रस्तुतकर्ता एक निश्चित तकनीक को स्पष्ट करने के लिए उपमाओं का उपयोग करते हैं, जैसे कि सर्विस 2.0 के रूप में पिज्जा जो कि विभिन्न ए-सर्विस (एएएस) स्टैक के बीच के अंतर को स्पष्ट करता है।

इस पिज्जा सादृश्य के लाभ यह है कि इसमें कई उपमाएँ होती हैं, यानी रनटाइम उर्फ ​​पिज्जा और घर का बना उर्फ ​​विरासत।

जब एक Googles "DevOps सादृश्य", विभिन्न चित्र दिखाए जाते हैं, लेकिन उनमें से बहुत आकर्षक नहीं है।

"लाने" की परिभाषा

1. एक प्रस्तुति में छवि दिखाएं
2. इसके बारे में 30 सेकंड बात करें
3. लिफ्ट की पिच के दौरान अधिक से अधिक लोग DevOps को समझते हैं और यह उनके द्वारा पूरी तरह से स्पष्ट है।

Comments

DevOps के कई लक्षित समूह हैं; मुझे लगता है कि छवि खोजने के लिए उस पर ध्यान केंद्रित करना आसान है। आपके दर्शक कौन हैं और एलीवेटर पिच के सफल होने की स्थिति में क्या होगा?

— पीटर मुर्सकिन

उनमें से ज्यादातर जूनियर डेवलपर्स हैं जो साइलो माइंडेड हैं, यानी केवल उत्पादन में ऐप चलाने की जिम्मेदारी का धन्यवाद किए बिना विकसित करना चाहते हैं। @PeterMuryshkin आपके अनुसार इस संदर्भ में कितने लक्ष्य समूह मौजूद हैं?

— ०३० 0

तो लक्ष्य समूहों के लिए, मैं कहूँगा कि देवो टूलचिन के प्रत्येक खंड के आसपास प्रत्येक साइलो / भूमिका के लिए? प्रबंधन, व्यापार उपयोगकर्ताओं,

— देवों

Answer 1

DevOps IT का औद्योगीकरण है

Comments

बाईं तस्वीर एक कार का प्रतिनिधित्व करती है जो हस्तनिर्मित थी?

— 030

ठीक है, यह भी कुछ मुद्दों के चारों ओर बढ़ जाएगा :)

— oryades

महान। अब मैं इसे देखता हूं। शायद आप उत्तर में कुछ अतिरिक्त विवरण जोड़ सकते हैं?

— 030

दूसरी ओर दाईं ओर की तस्वीर एक ऐसी कार का प्रतिनिधित्व करती है, जिसे आगे बढ़ने में कोई समस्या नहीं होगी, जब तक यह असेंबली लाइन पर रहती है। अन्यथा कुछ पहियों की आवश्यकता हो सकती है ...

— जिरी क्लौडा

चित्र के दाहिने भाग के बारे में, मुझे लगता है कि देवओप्स टूलचेन, सॉफ्टवेयर परीक्षण और वितरण सॉफ्टवेयर समाधानों को स्वचालित करने और वितरण पाइपलाइनों का निर्माण करने के लिए इंजीनियरिंग दृष्टिकोण है। आका औद्योगिक क्रांति 2.0 ... sigspl.org/2015/10/14/…

— पीटर मर्सकिन

Answer 2

ज्यादातर "आपदा लड़की" मेम के साथ देवों के लिए लेकिन दूसरों के जानकार: "मेरी मशीन पर काम करता है .. ऑप्स समस्या अब!" यह दर्शाता है कि जिम्मेदारी की कमी से पूरी कंपनी को खतरा हो सकता है, और केवल विशिष्ट वातावरण में काम करने वाले सॉफ़्टवेयर का मूल्य पूर्ण नहीं है।

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

Comments

क्या आप चित्र जोड़ सकते हैं?

— 030

मुझे लगता है कि मोबाइल से, ठीक से काम नहीं करेगा।

— पीटर मुर्सकिन

बहुत बढ़िया +1। क्या आप प्रत्येक चित्र में एक छोटी सी व्याख्या जोड़ सकते हैं, अर्थात ये DevOps उपमाएँ क्यों हैं?

— 030

ईमानदार होने के लिए इन छवियों को बल्कि DevOps की तुलना में DevOps के लिए प्रेरणा का वर्णन करना; इसलिए अब मुझे यकीन है कि यह आपके वास्तविक प्रश्न को "चित्रण" DevOps

— पीटर मुर्सकिन

इसके अलावा, मेरी प्रस्तुति में "व्हाई देवऑप्स" का वर्णन करने के लिए पहली तस्वीर निश्चित रूप से सहायक है।

— 030

Answer 3

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

Comments

मवेशी बनाम पालतू जानवर मुख्य रूप से एक ऑप्स चीजें हैं, इसके लिए किसी देव संगठन या मानसिकता की आवश्यकता नहीं होती है। संकेत यह केवल बुनियादी सुविधाओं के बारे में बात करता है और इस पर चलने वाले ऐप्स के बारे में कभी नहीं।

— टेन्सीबाई

@ तेंसिबाई आपकी पसंदीदा सादृश्यता क्या है?

— 030

यह एक प्यारा विचार है, लेकिन जैसे ही आप दृढ़ता का परिचय देते हैं, यह अपने चेहरे पर सपाट हो जाता है। आपको बेहतर उम्मीद है कि आपकी कंपनी ने DevOps kool-aid को नहीं पिया है और पेरोल सिस्टम एक पालतू जानवर है!

— गयुस

Answer 4

एक और जो मुझे पसंद है वह है इस वेबसाइट https://devrant.com/search?term=devops से

जैसा कि मैंने इसे कई बार सुना है और यह मुझे निराश करता है क्योंकि यह साइलो व्यवहार और विरोधी देवता है। मैं मूल रूप से इसे लागू करना चाहता हूं, जब आप इसे बदलते हैं तो आपको जारी करना पड़ता है या जब आप इसे तोड़ते हैं तो आप इसे ठीक करते हैं। व्यवहार में ऐसा नहीं है कि एक मानसिकता को बदलना पड़ता है।

Answer 5

एक और सादृश्य यहाँ पाया गया था https://devrant.com/search?term=devops

मुझे लगता है कि यह भी लागू है क्योंकि अभी भी डेवलपर्स हैं जो दीवार पर चीजों को फेंकना जारी रखते हैं।

मुझे यह स्वीकार करना होगा कि मैं ऐसा महसूस करता हूं और यह मुझे प्रोग्रामिंग सीखने के लिए प्रोत्साहित करता है। मैं अब जावा सीख रहा हूं और प्रमाण पत्र प्राप्त करना चाहता हूं। मैं अब जावा ओरेकल के सहयोगी के लिए अध्ययन कर रहा हूं।

Answer 6

@PeterMuryshkin के जवाबों में से एक के लिए एक टिप्पणी में एक सुझाव के आधार पर मैंने उद्योग 4.0 के बारे में अधिक पढ़ा और मुझे लगता है कि यह एक DevOps सादृश्य हो सकता है।

एक और DevOps सादृश्य उद्योग 4.0 हो सकता है:

उद्योग 4.0 विनिर्माण प्रौद्योगिकियों में स्वचालन और डेटा विनिमय की वर्तमान प्रवृत्ति का एक नाम है। इसमें साइबर-फिजिकल सिस्टम, इंटरनेट ऑफ थिंग्स, क्लाउड कंप्यूटिंग और कॉग्निटिव कंप्यूटिंग शामिल हैं। उद्योग 4.0 को आमतौर पर चौथी औद्योगिक क्रांति के रूप में जाना जाता है।

उद्योग 1.0 को पेश करने के लिए कार्यात्मक प्रक्रिया, अर्थात कैसेट का उत्पादन करने के लिए मैन्युअल रूप से इसे स्वचालित करने के लिए स्पष्ट होना चाहिए, 2.0 स्वचालित अधिक और 3.0 भी। आजकल DevOps भी अधिक से अधिक स्वचालित करने के बारे में है, लेकिन ऐसा करने के लिए प्रक्रिया स्पष्ट होनी चाहिए। जैसा कि 4.0 क्लाउड पर जाने के बारे में है, जैसे AWS, GCP, AWS, CI / CD और सेल्फ-हीलिंग सिस्टम यह एक सादृश्य भी हो सकता है।

Comments

इसके अलावा, मुझे लगता है कि वास्तविक 4.0 उद्योग बिना DevOps के काम नहीं कर रहा है।

— पीटर मुर्सकिन

Answer 7

DevOps की तुलना एक कमांडो दस्ते के साथ की जा सकती है, जिसमें कम संख्या में विशेषज्ञ होते हैं। मुझे हमेशा कमांडो 1 के पहले स्तर के बारे में दुश्मन लाइनों के पीछे सोचना पड़ता है। तीन पात्र थे:

• समुद्री
• चालक
• हरी टोपी

उनमें से प्रत्येक के पास अद्वितीय गुण हैं, अर्थात गोताखोरी, तैराकी, रोइंग (समुद्री), गोताखोर (मशीन गन, ड्राइविंग), ग्रीन बेरे (चढ़ाई, बैरल ले जाना)।

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

यदि उदाहरण के लिए गेम में कमांडो में से एक की मृत्यु हो गई, तो खेल खत्म हो गया। मिशन को पूरा करने के लिए सभी को मिलकर काम करना था। मुझे याद है कि प्रत्येक कमांडो स्तर 1 की शुरुआत में अलग-थलग पड़ गए थे और खुद दुश्मनों को बाहर निकालना था, लेकिन वे एक-दूसरे पर भी निर्भर थे।

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

जब वे एक साथ काम कर रहे थे तो एक उच्च संभावना थी कि वे जीवित रह सकते थे क्योंकि एक दुश्मन को बाहर निकालने के लिए तीन शॉट्स की आवश्यकता थी। यदि वे एक साथ गोली मारते हैं तो दुश्मन को तुरंत बाहर निकाल दिया जाता है।