DevOps और अन्य बुरे विचारों पर लोगों को किराए पर लें

एक बार उन्होंने दो दोस्तों के बीच बातचीत देखी और सुना:
“क्या आपके पास पहले से ही DevOps है? यह सिर्फ इतना है कि MegaTeleKo में सब कुछ पूरे जोरों पर है! हमने हाल ही में 35 लोगों की एक DevOps टीम की भर्ती की है! "

तो क्यों एक DevOps टीम को भर्ती करना एक बुरा विचार है?

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

• बुनियादी ढांचे में बदलाव का स्वचालन
• JIRA सेटअप
• MySQL प्रशासन
• बड़े पैमाने पर लिनक्स परियोजनाओं के लिए समर्थन
• कठपुतली से जुड़ी हर चीज को मैनेज करना
• रूबी, अजगर या बैश में स्क्रिप्ट लिखना
• यहां और वहां "बैसाखी" के साथ परिचालन प्रॉपिंग

सूची को वास्तविक नौकरियों के टुकड़ों से बनाया गया है, थोड़ा संशोधित किया गया है ताकि किसी विशिष्ट पर संकेत न दिया जा सके।

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

तो क्या वास्तव में DevOps को विकसित करने की आवश्यकता है?

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

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

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

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