डेवऑप्स और कैओस: विकेंद्रीकृत दुनिया में सॉफ्टवेयर डिलीवरी

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

हमने रिपोर्ट का एक पाठ्य संस्करण तैयार किया है।

सुप्रभात!

लगातार दूसरे वर्ष मास्को में DevOpsDays, इस मंच पर यह मेरा दूसरा मौका है, आप में से कई लोग दूसरी बार इस कमरे में हैं। इसका मतलब क्या है? इसका मतलब है कि रूस में DevOps आंदोलन बढ़ रहा है, बढ़ रहा है, और सबसे महत्वपूर्ण बात यह है कि 2018 में DevOps क्या है, इसके बारे में बात करने का समय आ गया है।

अपने हाथ उठाएँ जो सोचते हैं कि DevOps 2018 में पहले से ही एक पेशा है? ऐसे हैं. क्या कमरे में कोई DevOps इंजीनियर है जिसका कार्य विवरण "DevOps इंजीनियर" कहता है? क्या कमरे में कोई DevOps प्रबंधक हैं? ऐसी कोई बात नहीं। DevOps आर्किटेक्ट्स? भी नहीं। पर्याप्त नहीं। क्या यह सचमुच सच है कि कोई नहीं कहता कि वे एक DevOps इंजीनियर हैं?

तो आप में से अधिकांश लोग सोचते हैं कि यह एक विरोधी पैटर्न है? कि ऐसा पेशा अस्तित्व में नहीं होना चाहिए? हम जो चाहें सोच सकते हैं, लेकिन जब हम सोच रहे होते हैं, तो उद्योग पूरी तरह से DevOps तुरही की आवाज़ की ओर आगे बढ़ रहा है।

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

हम रचनात्मक लोग हैं, हम आराम से नहीं बैठते। हम कहते हैं: DevOps पर्याप्त व्यापक शब्द नहीं है; इसमें अभी भी सभी प्रकार के विभिन्न, दिलचस्प तत्वों का अभाव है। और हम अपनी गुप्त प्रयोगशालाओं में जाते हैं और दिलचस्प उत्परिवर्तन उत्पन्न करना शुरू करते हैं: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps।

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

इसलिए मैं इस दृष्टिकोण को कहता हूं - "ऑप्स, और समस्या हल हो गई।"

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

DevOps दर्द से उबर गया। और हम कष्ट सहते-सहते थक गये हैं। और यह सब होने के लिए, हम सदाबहार प्रथाओं पर भरोसा करते हैं: प्रभावी सहयोग, प्रवाह प्रथाएं, और सबसे महत्वपूर्ण, सिस्टम सोच, क्योंकि इसके बिना कोई भी DevOps काम नहीं करता है।

एक प्रणाली क्या है?

और अगर हम पहले से ही सिस्टम सोच के बारे में बात कर रहे हैं, तो आइए खुद को याद दिलाएं कि सिस्टम क्या है।

यदि आप एक क्रांतिकारी हैकर हैं, तो आपके लिए सिस्टम स्पष्ट रूप से बुरा है। यह एक ऐसा बादल है जो आपके ऊपर मंडराता रहता है और आपको वो काम करने के लिए मजबूर करता है जो आप नहीं करना चाहते।

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

यह सब एक बड़ी सामाजिक-तकनीकी प्रणाली का हिस्सा है। और केवल अगर हम समझेंगे कि यह सामाजिक-तकनीकी प्रणाली एक साथ कैसे काम करती है, तभी हम वास्तव में इस मामले में कुछ अनुकूलित कर पाएंगे।

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

व्यवहारिक दृष्टि से एक और दिलचस्प तथ्य है। सिस्टम कुछ ऐसा कर सकता है जो उसका कोई भी अलग-अलग अंग नहीं कर सकता।

जैसा कि डॉ. रसेल एकॉफ (सिस्टम थिंकिंग के संस्थापकों में से एक) ने कहा, एक विचार प्रयोग के साथ इसे साबित करना काफी आसान है। उदाहरण के लिए, कमरे में कौन कोड लिखना जानता है? बहुत सारे हाथ हैं, और यह सामान्य है, क्योंकि यह हमारे पेशे के लिए मुख्य आवश्यकताओं में से एक है। क्या आप लिखना जानते हैं, लेकिन क्या आपके हाथ आपसे अलग कोड लिख सकते हैं? ऐसे लोग हैं जो कहेंगे: "यह मेरे हाथ नहीं हैं जो कोड लिखते हैं, यह मेरा दिमाग है जो कोड लिखता है।" क्या आपका मस्तिष्क आपसे अलग कोड लिख सकता है? ख़ैर, शायद नहीं.

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

यदि कोई प्रणाली कुछ ऐसा कर सकती है जिसे उसका कोई भी अंग अलग से नहीं कर सकता है, तो इसका मतलब यह है कि उसका व्यवहार उसके अंगों के व्यवहार से निर्धारित नहीं होता है। तो फिर यह किससे निर्धारित होता है? यह इन भागों के बीच परस्पर क्रिया द्वारा निर्धारित होता है। और तदनुसार, जितने अधिक हिस्से होंगे, अंतःक्रियाएं उतनी ही जटिल होंगी, सिस्टम के व्यवहार को समझना और भविष्यवाणी करना उतना ही कठिन होगा। और यह ऐसी प्रणाली को अराजक बना देता है, क्योंकि प्रणाली के किसी भी हिस्से में कोई भी, यहां तक ​​कि सबसे महत्वहीन, अदृश्य परिवर्तन पूरी तरह से अप्रत्याशित परिणाम दे सकता है।

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

अराजकता सिद्धांत

जो लोग अराजकता का अध्ययन करते हैं वे स्वयं को अराजकतावादी कहते हैं।

दरअसल, इस रिपोर्ट का कारण यह था कि, जटिल वितरित प्रणालियों और बड़े अंतरराष्ट्रीय संगठनों के साथ काम करते हुए, कुछ बिंदु पर मुझे एहसास हुआ कि मैं ऐसा ही महसूस करता हूं। मैं एक अराजकतावादी हूं. यह मूल रूप से यह कहने का एक चतुर तरीका है: "मुझे समझ नहीं आ रहा है कि यहाँ क्या हो रहा है और मुझे नहीं पता कि इसके बारे में क्या करना है।"

मुझे लगता है कि आपमें से भी कई लोग अक्सर ऐसा ही महसूस करते हैं, इसलिए आप भी अराजकतावादी हैं। मैं आपको अराजकतावादियों के संघ में आमंत्रित करता हूं। प्रिय कैओसोलॉजिस्ट, आप और मैं जिन प्रणालियों का अध्ययन करेंगे, उन्हें "जटिल अनुकूली प्रणाली" कहा जाता है।

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

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

दो और दिलचस्प निष्कर्ष हैं।


सबसे पहले, हम समझते हैं कि एक जटिल प्रणाली को उसके भागों को सरल बनाकर सरल नहीं बनाया जा सकता है। दूसरा, किसी जटिल प्रणाली को सरल बनाने का एकमात्र तरीका उसके भागों के बीच परस्पर क्रिया को सरल बनाना है।

हम कैसे बातचीत करते हैं? आप और मैं सभी मानव समाज नामक एक विशाल सूचना प्रणाली के अंग हैं। हम एक सामान्य भाषा के माध्यम से बातचीत करते हैं, यदि वह हमारे पास है, यदि वह हमें मिल जाती है।

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

मैं कहना चाहता हूं कि जटिलता की ओर, अनुकूलनशीलता की ओर, विकेंद्रीकरण की ओर, अराजकता की ओर रुझान हर चीज में देखा जा सकता है। और उन प्रणालियों में जिन्हें आप और मैं बना रहे हैं, और उन प्रणालियों में जिनका हम एक हिस्सा हैं।

और निराधार न होने के लिए, आइए देखें कि हम जो सिस्टम बनाते हैं वे कैसे बदल रहे हैं।

आप इस शब्द की प्रतीक्षा कर रहे थे, मैं समझता हूं। हम एक DevOps सम्मेलन में हैं, आज यह शब्द लगभग एक लाख बार सुना जाएगा और फिर हम रात में इसके बारे में सपना देखेंगे।

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

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

जटिलता कहां है? बेशक, कठिनाई बातचीत में है। कोई व्यक्ति अपने आप कितना कार्य कर सकता है? यह अन्य कार्यों के साथ कैसे इंटरैक्ट करता है? संदेश कतारें, डेटाबेस, बैलेंसर। विफलता होने पर किसी घटना को दोबारा कैसे बनाया जाए? बहुत सारे प्रश्न और कुछ उत्तर।

माइक्रोसर्विसेज और सर्वरलेस को हम गीक हिपस्टर्स क्लाउड नेटिव कहते हैं। यह सब बादल के बारे में है. लेकिन बादल भी स्वाभाविक रूप से अपनी मापनीयता में सीमित है। हम इसे एक वितरित प्रणाली के रूप में सोचने के आदी हैं। वास्तव में, क्लाउड प्रदाताओं के सर्वर कहाँ रहते हैं? डेटा सेंटरों में. यानी, हमारे यहां एक तरह का केंद्रीकृत, बहुत सीमित, वितरित मॉडल है।

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

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

कोहरे की गणना. मुद्दा यह है कि बादल पानी, भाप, बर्फ और पत्थरों के केंद्रीकृत समूह हैं। और कोहरा पानी की बूंदें हैं जो हमारे चारों ओर वायुमंडल में बिखरी हुई हैं।

कोहरे के प्रतिमान में, अधिकांश कार्य इन बूंदों द्वारा पूरी तरह से स्वायत्त रूप से या अन्य बूंदों के सहयोग से किया जाता है। और वे बादल की ओर तभी मुड़ते हैं जब उन पर वास्तव में दबाव डाला जाता है।

यानी, फिर से विकेंद्रीकरण, स्वायत्तता, और निश्चित रूप से, आप में से कई लोग पहले से ही समझते हैं कि यह सब कहाँ जा रहा है, क्योंकि आप ब्लॉकचेन का उल्लेख किए बिना विकेंद्रीकरण के बारे में बात नहीं कर सकते।

ऐसे लोग हैं जो मानते हैं, ये वे हैं जिन्होंने क्रिप्टोकरेंसी में निवेश किया है। उदाहरण के लिए, ऐसे लोग भी हैं जो विश्वास करते हैं लेकिन डरते हैं, मेरी तरह। और ऐसे लोग भी हैं जो विश्वास नहीं करते। यहां आप अलग तरह से इलाज कर सकते हैं. तकनीक है, कोई नया अज्ञात मामला है, समस्याएँ हैं। किसी भी नई तकनीक की तरह, यह उत्तर देने से अधिक प्रश्न उठाती है।

ब्लॉकचेन के आसपास का प्रचार समझ में आता है। सोने की दौड़ को एक तरफ रख दें, प्रौद्योगिकी अपने आप में एक उज्जवल भविष्य के लिए उल्लेखनीय वादे रखती है: अधिक स्वतंत्रता, अधिक स्वायत्तता, वितरित वैश्विक विश्वास। क्या नहीं चाहिए?

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

वैसे, कौन जानता है कि स्क्रीन पर किस तरह का लोगो है? यह हाइपरलेजर है. यह एक परियोजना है जिसे लिनक्स फाउंडेशन के तत्वावधान में विकसित किया जा रहा है और इसमें ब्लॉकचेन प्रौद्योगिकियों का एक सेट शामिल है। यह वास्तव में हमारे ओपन सोर्स समुदाय की ताकत है।

कैओस इंजीनियरिंग

इसलिए, हम जो प्रणाली विकसित कर रहे हैं वह अधिक से अधिक जटिल, अधिक से अधिक अराजक और अधिक से अधिक अनुकूली होती जा रही है। नेटफ्लिक्स माइक्रोसर्विस सिस्टम के अग्रणी हैं। वे इसे समझने वाले पहले लोगों में से थे, उन्होंने उपकरणों का एक सेट विकसित किया जिसे उन्होंने सिमियन आर्मी कहा, जिनमें से सबसे प्रसिद्ध था अराजकता बंदर. उन्होंने परिभाषित किया कि क्या कहा जाने लगा "अराजकता इंजीनियरिंग के सिद्धांत".

वैसे, रिपोर्ट पर काम करने की प्रक्रिया में, हमने इस पाठ का रूसी में अनुवाद भी किया है, इसलिए आगे बढ़ें जोड़ना, पढ़ें, टिप्पणी करें, डांटें।

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

हमें स्वयं इन त्रुटियों को अपनी उत्पादन प्रणालियों में शामिल करने का प्रयास करना चाहिए ताकि हम अपनी प्रणालियों को इसी अनुकूलन क्षमता, स्वयं-संगठन की इसी क्षमता, अस्तित्व के लिए परख सकें।

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

वितरित सिस्टम एकीकरण प्रोटोकॉल

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

मैं किस बारे में बात कर रहा हूँ? सबसे पहले, परियोजना ओपनट्रेसिंग. कुछ लोग एक सामान्य वितरित ट्रैकिंग प्रोटोकॉल बनाने का प्रयास करते हैं, जो जटिल वितरित सिस्टम को डीबग करने के लिए एक बिल्कुल अपरिहार्य उपकरण है।

आगे की - ओपन पॉलिसी एजेंट. हम कहते हैं कि हम भविष्यवाणी नहीं कर सकते कि सिस्टम का क्या होगा, यानी हमें इसकी अवलोकन क्षमता, अवलोकन क्षमता को बढ़ाने की जरूरत है। ओपनट्रेसिंग उपकरणों के एक परिवार से संबंधित है जो हमारे सिस्टम को अवलोकन प्रदान करता है। लेकिन हमें यह निर्धारित करने के लिए अवलोकन की आवश्यकता है कि क्या सिस्टम हमारी अपेक्षा के अनुरूप व्यवहार करता है या नहीं। हम अपेक्षित व्यवहार को कैसे परिभाषित करते हैं? किसी प्रकार की नीति, कुछ नियमों के समूह को परिभाषित करके। ओपन पॉलिसी एजेंट प्रोजेक्ट पहुंच से लेकर संसाधन आवंटन तक के स्पेक्ट्रम में नियमों के इस सेट को परिभाषित करने के लिए काम कर रहा है।

जैसा कि हमने कहा, हमारे सिस्टम तेजी से इवेंट-संचालित हो रहे हैं। सर्वरलेस इवेंट-संचालित सिस्टम का एक बेहतरीन उदाहरण है। सिस्टम के बीच घटनाओं को स्थानांतरित करने और उन्हें ट्रैक करने के लिए, हमें कुछ सामान्य भाषा, कुछ सामान्य प्रोटोकॉल की आवश्यकता है कि हम घटनाओं के बारे में कैसे बात करते हैं, हम उन्हें एक-दूसरे तक कैसे पहुंचाते हैं। इसे ही प्रोजेक्ट कहा जाता है बादलघटनाएँ.

परिवर्तनों की निरंतर धारा जो हमारे सिस्टम को प्रभावित करती है, उन्हें लगातार अस्थिर करती है, सॉफ्टवेयर कलाकृतियों की एक सतत धारा है। परिवर्तनों के इस निरंतर प्रवाह को बनाए रखने के लिए, हमें किसी प्रकार के सामान्य प्रोटोकॉल की आवश्यकता है जिसके माध्यम से हम बात कर सकें कि सॉफ़्टवेयर आर्टिफैक्ट क्या है, इसका परीक्षण कैसे किया जाता है, यह किस सत्यापन से गुजरा है। इसे ही प्रोजेक्ट कहा जाता है Grafeas. अर्थात्, सॉफ़्टवेयर कलाकृतियों के लिए एक सामान्य मेटाडेटा प्रोटोकॉल।

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

ये सभी परियोजनाएँ युवा हैं, इन सभी को हमारे प्यार, हमारे सत्यापन की आवश्यकता है। यह सब खुला स्रोत है, हमारा परीक्षण, हमारा कार्यान्वयन। वे हमें दिखाते हैं कि प्रौद्योगिकी किस ओर जा रही है।

लेकिन DevOps कभी भी मुख्य रूप से प्रौद्योगिकी के बारे में नहीं रहा है, यह हमेशा लोगों के बीच सहयोग के बारे में रहा है। और, तदनुसार, यदि हम चाहते हैं कि जो प्रणालियाँ हम विकसित कर रहे हैं वे बदलें, तो हमें स्वयं बदलना होगा। वास्तव में, हम वैसे भी बदल रहे हैं; हमारे पास ज्यादा विकल्प नहीं हैं।

वहाँ एक अद्भुत है книга ब्रिटिश लेखिका राचेल बॉट्समैन, जिसमें वह पूरे मानव इतिहास में विश्वास के विकास के बारे में लिखती हैं। वह कहती हैं कि शुरू में, आदिम समाजों में, भरोसा स्थानीय था, यानी हम केवल उन्हीं पर भरोसा करते थे जिन्हें हम व्यक्तिगत रूप से जानते थे।

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

और यह वही है जो हम अपनी आधुनिक दुनिया में देखते हैं: विश्वास अधिक से अधिक वितरित और विकेंद्रीकृत होता जा रहा है, और यह सूचना प्रवाह की स्वतंत्रता, सूचना की उपलब्धता पर आधारित है।

यदि आप इसके बारे में सोचते हैं, तो यह वही पहुंच है, जो इस भरोसे को संभव बनाती है, जिसे आप और मैं लागू कर रहे हैं। इसका मतलब यह है कि जिस तरह से हम सहयोग करते हैं और जिस तरह से हम इसे करते हैं, दोनों में बदलाव होना चाहिए, क्योंकि पुराने केंद्रीकृत, पदानुक्रमित आईटी संगठन अब काम नहीं कर रहे हैं। वे ख़त्म होने लगते हैं.

DevOps संगठन की बुनियादी बातें

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

निस्संदेह, सांस्कृतिक परिवर्तन के बिना इनमें से कुछ भी संभव नहीं है। हमारे पास परिवर्तनकारी नेतृत्व, व्यक्तिगत जिम्मेदारी, आंतरिक प्रेरणा होनी चाहिए।

यह DevOps संगठनों का आधार है: सूचना पारदर्शिता, अतुल्यकालिक संचार, परिवर्तनकारी नेतृत्व, विकेंद्रीकरण।

zapping

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

बर्नआउट तब होता है जब हम किसी ऐसी चीज़ को नियंत्रित करने का प्रयास करते हैं जो स्वाभाविक रूप से अनियंत्रित होती है। जब हम थक जाते हैं, तो हर चीज़ अपना अर्थ खो देती है क्योंकि हम कुछ नया करने की इच्छा खो देते हैं, हम रक्षात्मक हो जाते हैं और जो हमारे पास है उसका बचाव करना शुरू कर देते हैं।

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

मेरी राय में, केवल अराजकता की रचनात्मक शक्ति को स्वीकार करना, केवल उसके सिद्धांतों के अनुसार सहयोग का निर्माण करना ही हमें हमारे पेशे में जो अच्छा है उसे खोने से बचाने में मदद करेगा।

मैं आपसे यही कामना करता हूं: आप अपनी नौकरी से प्यार करें, हम जो करते हैं उससे प्यार करें। यह दुनिया सूचनाओं से पोषित होती है, हमें इसे पोषित करने का सम्मान प्राप्त है। तो आइए अराजकता का अध्ययन करें, आइए अराजकतावादी बनें, आइए मूल्य लाएं, कुछ नया बनाएं, ठीक है, समस्याएं, जैसा कि हम पहले ही पता लगा चुके हैं, अपरिहार्य हैं, और जब वे प्रकट होती हैं, तो हम बस कहेंगे "ऑप्स!" और समस्या हल हो गई है।

अराजकता बंदर के अलावा और क्या?

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

यह समझने की कोशिश करें कि आपके सिस्टम कैसे ख़राब होते हैं और उन्हें तोड़ना शुरू करें और देखें कि वे कैसे टिके रहते हैं। यह सबसे पहले आता है. और आप उपकरण ढूंढ सकते हैं. हर तरह के प्रोजेक्ट हैं.

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

यह सही है, सामान्य तौर पर माइक्रोसर्विसेज एक बहुत ही विवादास्पद विषय है। वास्तव में, भागों को सरल बनाने से लचीलापन बढ़ता है। माइक्रोसर्विसेज क्या प्रदान करते हैं? वे हमें लचीलापन और गति देते हैं, लेकिन निश्चित रूप से वे हमें सरलता नहीं देते। वे कठिनाई बढ़ा देते हैं.

तो, DevOps दर्शन में, माइक्रोसर्विसेज इतनी अच्छी चीज़ नहीं हैं?

किसी भी अच्छे का एक विपरीत पक्ष भी होता है। लाभ यह है कि इससे लचीलापन बढ़ता है, जिससे हम तेजी से बदलाव कर पाते हैं, लेकिन इससे जटिलता और इसलिए पूरे सिस्टम की नाजुकता बढ़ जाती है।

फिर भी, अधिक जोर किस पर है: बातचीत को सरल बनाने पर या भागों को सरल बनाने पर?

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

क्या यह सच है कि आपने जो कुछ कहा वह प्रतिस्पर्धा रहित दुनिया में रहता है, और वहां अराजकता इतनी दयालु है, और इस अराजकता के भीतर कोई विरोधाभास नहीं है, कोई भी किसी को खाना या मारना नहीं चाहता है? प्रतिस्पर्धा और DevOps का प्रदर्शन कैसा होना चाहिए?

खैर, यह इस पर निर्भर करता है कि हम किस तरह की प्रतिस्पर्धा की बात कर रहे हैं। क्या यह कार्यस्थल में प्रतिस्पर्धा या कंपनियों के बीच प्रतिस्पर्धा के बारे में है?

सेवाओं की प्रतिस्पर्धा के बारे में जो मौजूद हैं क्योंकि सेवाएँ कई कंपनियाँ नहीं हैं। हम एक नए प्रकार का सूचना वातावरण बना रहे हैं, और कोई भी वातावरण प्रतिस्पर्धा के बिना नहीं रह सकता। हर जगह प्रतिस्पर्धा है.

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

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

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

इस वर्ष का सम्मेलन डेवऑप्सडेज़ मॉस्को 7 दिसंबर को टेक्नोपोलिस में होगा। हम 11 नवंबर तक रिपोर्ट के लिए आवेदन स्वीकार कर रहे हैं। लिखना यदि आप बात करना चाहें तो हमसे।

प्रतिभागियों के लिए पंजीकरण खुला है, टिकटों की कीमत 7000 रूबल है। हमसे जुड़ें!

स्रोत: www.habr.com