DevOps और अराजकता: एक विकेंद्रीकृत दुनिया में सॉफ्टवेयर डिलीवरी

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

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



सुप्रभात

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

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

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

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



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



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

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

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

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

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

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



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



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

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

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

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

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

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

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

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

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

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



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

मुझे लगता है कि आप में से कई लोग भी खुद को इतनी बार महसूस करते हैं, इसलिए आप अराजक विज्ञानी भी हैं। मैं आपको अराजकताविदों के गिल्ड में आमंत्रित करता हूं। वे प्रणालियाँ, जिन्हें हम अराजकताविदों के प्रिय सहयोगी, अध्ययन करेंगे, "जटिल अनुकूली प्रणालियाँ" कहा जाता है।

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

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

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


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

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



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

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

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



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

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



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

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

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

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

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



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

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

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



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

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

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

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

अराजकता इंजीनियरिंग

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

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

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

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

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

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

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



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



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



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



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



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

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

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



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

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

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

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

DevOps संगठन की मूल बातें

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

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



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

zapping

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



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

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

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

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

कैओस बंदर के अलावा क्या?

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

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

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

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

यही है, DevOps दर्शन में, माइक्रोसॉफ़्ट ऐसे आशीर्वाद नहीं हैं?

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

फिर भी, किस पर अधिक जोर दिया जाता है: सहभागिता का सरलीकरण या भागों का सरलीकरण?

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

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

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

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

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

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

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

इस साल, DevOpsDays मास्को सम्मेलन 7 दिसंबर को Technopolis में आयोजित किया जाएगा। 11 नवंबर तक, हम रिपोर्ट के लिए आवेदन स्वीकार करते हैं। अगर आप बोलना चाहते हैं तो हमें ईमेल करें।

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