DevOps - सब कुछ

[यह सामग्री माइकल डेखान द्वारा ट्वीट्स की एक श्रृंखला का अनुवाद है, जो लोकप्रिय Ansible ऑटोमेशन इंजन - लगभग के रचनाकारों में से एक है। ]

तो, opsmop को vespene_io के रूप में स्वीकृति और भागीदारी के कार्यक्रम के साथ एक ही समस्या है, और मुझे जारी रखने का कोई कारण भी नहीं दिखता है। मैं हठपूर्वक अपने विचार पर विश्वास करता हूं, लेकिन मुझे लगता है कि खुले स्रोत आईटी की पूरी दुनिया जल चुकी है, और मैं लोगों की दिलचस्पी लेने की कोशिश कर रहा हूं।

उन लोगों के लिए जो कहते हैं कि यह एक उत्पाद था जो बाजार में नहीं मिल रहा था, या कि मुझे थोड़ी देर इंतजार करना चाहिए - पूरे सम्मान के साथ, आप गलत हैं। मैं इस क्षेत्र के बारे में दुनिया के पांच लोगों को छोड़कर किसी से भी ज्यादा जानता हूं :-) इसके कारण दिलचस्प हैं ...

अनिवार्य रूप से (1) एक फुर्तीली चार्ट का मतलब है कि किसी के पास काम करने का समय नहीं है, (2) DevOps के अनुसार काम नहीं कर सकते। वह और वह दोनों एक क्रमिक अभिव्यक्ति के लिए समय लेते हैं, और नुकसान पहुंचाते हैं। ईमानदारी से, लगभग 12 साल पुराना है।

DevOps [-approach - लगभग ] विकास और प्रशासन के एक हाइब्रिड की तरह बन जाना चाहिए [ dev elopment / op eration s - लगभग अनुवाद], लेकिन इसके बजाय, लोग हर रोज़ उपकरण बनाते हैं, और डेवलपर्स बहुत कुछ करते हैं जो प्रशासकों के लिए उपयोग किया जाता है। और प्रशासक * और भी अधिक * सिस्टम प्रशासक बन जाते हैं, क्योंकि वे कम से कम इस अवधि के बीच में थे [12 साल की उम्र में - लगभग। अनुवाद।]

ओपन सोर्स की सफलता की कुंजी यह है कि जब उपयोगकर्ताओं और डेवलपर्स (जो योगदान कर सकते हैं) के दर्शक दृढ़ता से प्रतिच्छेद करते हैं, और इसमें शामिल और प्रेरित भी होते हैं।

हमारे मामले में, बहुत सारी चर्चाएं बताती हैं कि हर कोई व्यस्त है, किसी के पास समय नहीं है, और फिर भी ... हर कोई "छोटे कोड / कोड नहीं" जैसे समाधानों में अधिक से अधिक रुचि रखता है। यह सामान्य रूप से खुले स्रोत पर लागू नहीं होता है, लेकिन केवल आईटी प्रशासन खंड में।

लाइसेंसिंग चर्चाओं (मोंगो, रेडिस, कंफ्लुएंट) पर पीछे मुड़कर देखें - वे "बादल" गालियों के खिलाफ खुद का बचाव करने में सही थे, लेकिन यह भी कुछ और कहता है: ऐसा करने के लिए, समुदाय के साथ बातचीत करने में उन्हें एक घटते मूल्य का सामना करना पड़ा।

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

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

खुला स्रोत कार्यक्रम ईंधन बातचीत। और, मूल रूप से, यहां मेरा निदान है - बड़े पैमाने पर बर्नआउट। यह धीरे-धीरे आया, और हमने इसे नोटिस नहीं किया। फुर्तीली और DevOps - Burnout। मेरी राय में, कुछ क्षेत्रों में हम छह साल पहले की तुलना में तकनीकी रूप से बहुत गरीब हैं। क्यों?

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

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

मैं इससे लड़ने में मदद करना चाहता हूं, लेकिन अंत में, सगाई और विचार मंथन मेरा ईंधन है। अगर इसमें कोई भागीदारी नहीं है, और मैं इस भागीदारी को ठीक नहीं कर सकता, तो मुझे इससे कुछ नहीं मिलेगा। तो मैं बहुत ही कम - अधिक या कम सीमा तक निकला।

मुझे अभी भी सॉफ्टवेयर लिखना बहुत पसंद है, लेकिन मैं उन परियोजनाओं को बनाने की कोशिश करने जा रहा हूं जो मेरे लिए व्यक्तिगत रूप से दिलचस्प हैं, और नेतृत्व की मदद करने के लिए काफी ध्यान देने योग्य हैं। इसका मतलब है कि एक म्यूजिक सीक्वेंसर के लिए मेरा प्रोजेक्ट जैसे सामान। क्योंकि मेरा मानना ​​है कि लोग एक शौक के बारे में बहुत कुछ नहीं देते ...

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

हम सामान्य रूप से और सामान्य रूप से आईटी के लिए खुला स्रोत कैसे तय कर सकते हैं? एक नजर डालिए कि DevOps कौन होना चाहिए ... उसे सिर्फ एक डेवलपर के रूप में होना चाहिए, जितना कि एक प्रशासक के रूप में। उस फुर्तीले से लड़ें जो आपके शेड्यूल को बिगाड़ती है। नई चीजों को आजमाएं, सोचें, विकल्पों का अध्ययन करें और किसी और के होने की कोशिश न करें।

ब्लॉक ट्विटर "डेवलपर अधिवक्ता।" हम प्रतिनिधित्व के बारे में बात करना पसंद करते हैं, लेकिन इस बारे में सोचें कि तकनीक का क्या मतलब हो सकता है "स्थानीय खरीदें।" छोटी परियोजनाओं और ISV का समर्थन [स्वतंत्र सॉफ्टवेयर विक्रेताओं - लगभग। ]। सहभागिता करते हैं। हम में से अधिकांश किसी और चीज़ से अधिक बातचीत करते हैं।

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

हम बेहतरीन तरीके से बहुत कम चीजें करते हैं, मूल रूप से हर कोई इसे करता है। अधिकांश सॉफ्टवेयर जो हर कोई उपयोग करना चाहता है बकवास है। खैर, क्या पकड़ है, ठीक है, वास्तव में? औसत दर्जे का त्याग करें और जैसा आप फिट देखते हैं वैसा ही करें।

डिप्रेशन / बर्नआउट के बारे में उस बात के बारे में - अपने कौशल का ख्याल रखें। प्रदर्शन का आनंद लें। बुलेटप्रूफ आइटम बनाएं। लिखित स्क्रिप्ट साझा करें। ब्लॉग रखें। कुछ भी। साझा करें और भी अधिक साझा करें। शायद, थोड़ा-थोड़ा करके, हम इसे बदल सकते हैं।

लेकिन अगली बार, जब बातचीत "फुर्तीली" या "devops" की तरह एक बदलाव की ओर आती है, तो किसी ऐसे व्यक्ति द्वारा शुरू की गई, जिसने न तो कुछ लिखा है और न ही कुछ महत्वपूर्ण बनाया है, विनम्र हो, लेकिन इस तथ्य से मूर्ख मत बनो कि वे आपको हंसाने की कोशिश कर रहे हैं।

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

हमने ऐसे आंदोलन किए जो हमारे साथ ऐसा करते थे, और हम अब भी करते हैं। Ossification की स्वीकृति [व्यवसायी - लगभग। अनुवाद ] और सॉफ्टवेयर की गुणवत्ता पर थूकना जो हम सभी का समर्थन करते हैं, बस रोकना है। आईटी इंजीनियरिंग है, इसलिए उनके अनुसार व्यवहार करें।

यदि यह मेरे लिए मुश्किल है , तो कल्पना करें कि यह बिना किसी प्लेटफॉर्म के लिए कैसा है। मेरे लिए, ओएसएस बहुत सारे लोगों को जानने का एक शानदार तरीका था, और बहुत सारी खुशी, और ... अगर मैं आज ऐसा नहीं कर सकता - ओह ...

2006 में रेडहैट पर हमने जो ओएसएस आंदोलन का आनंद लिया, उसके बारे में सभी प्रकार की शांत मदद कुछ ऐसा है जिसे मैं आज विश्वास नहीं करता। आंदोलन गलत नहीं था, बस कुछ संस्कृति में चला गया, और उसे मार डाला।

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

बेशक, वे सबसे अधिक संभावना कुछ और कहेंगे, लेकिन मुझे आश्चर्य है कि वे क्या सोचते हैं। और मुझे लगता है कि वे सभी सोचते हैं कि फ्रीमियम एक अच्छा डाउनलोड मॉडल है, लेकिन वास्तविक कोड और सहयोग का मतलब कुछ और नहीं है, क्योंकि लोग इसमें शामिल नहीं हैं।

(हर कोई जो इसके लिए "प्लस" डालता है, हम्म ... धन्यवाद?)