DevOps र Chaos: विकेन्द्रीकृत संसारमा सफ्टवेयर डेलिभरी

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

हामीले प्रतिवेदनको पाठ संस्करण तयार गरेका छौं।

शुभ बिहान

लगातार दोस्रो वर्ष मस्कोमा DevOpsDays, यो मञ्चमा यो मेरो दोस्रो पटक हो, तपाईंहरू मध्ये धेरै दोस्रो पटक यस कोठामा हुनुहुन्छ। यसको मतलब के हो? यसको मतलब यो हो कि रूसमा DevOps आन्दोलन बढ्दै छ, गुणा हुँदैछ, र सबैभन्दा महत्त्वपूर्ण कुरा, यसको मतलब यो हो कि DevOps 2018 मा के हो भनेर कुरा गर्ने समय आएको छ।

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

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

DevDevOps भन्ने नयाँ विषयको बारेमा कसले सुनेको छ? यो एक नयाँ प्रविधि हो जसले विकासकर्ताहरू र डेभपहरू बीच प्रभावकारी सहयोगको लागि अनुमति दिन्छ। र त्यति नयाँ होइन। ट्विटरको आधारमा, तिनीहरूले 4 वर्ष पहिले नै यसको बारेमा कुरा गर्न थाले। र अहिले सम्म, यसमा चासो बढ्दै र बढ्दै छ, त्यो हो, त्यहाँ समस्या छ। समस्या समाधान गर्न आवश्यक छ।

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

तर्क फलामको छ, हैन? हाम्रो वितरण प्रणाली कार्यात्मक छैन, हाम्रा प्रणालीहरू अस्थिर छन् र हाम्रा प्रयोगकर्ताहरू असन्तुष्ट छन्, हामीसँग समयमै सफ्टवेयर रोल आउट गर्ने समय छैन, हामी बजेटमा फिट हुँदैनौं। हामी यो सबै कसरी समाधान गर्न जाँदैछौं? हामी नयाँ शब्द लिएर आउनेछौं! यो "Ops" संग समाप्त हुनेछ र समस्या हल हुन्छ।

त्यसैले म यो दृष्टिकोणलाई बोलाउँछु - "अप्स, र समस्या हल भयो।"

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

DevOps दुखाइबाट बढ्यो। अनि हामी पीडाले थाकेका छौं। र यो सबै हुनको लागि, हामी सदाबहार अभ्यासहरूमा भर पर्छौं: प्रभावकारी सहयोग, प्रवाह अभ्यासहरू, र सबैभन्दा महत्त्वपूर्ण, प्रणाली सोच, किनभने यो बिना कुनै DevOps काम गर्दैन।

प्रणाली के हो?

र यदि हामी पहिले नै प्रणाली सोचको बारेमा कुरा गर्दैछौं, हामी आफैलाई प्रणाली भनेको के हो भनेर सम्झौं।

यदि तपाइँ क्रान्तिकारी ह्याकर हुनुहुन्छ भने, तपाइँको लागि प्रणाली स्पष्ट रूपमा खराब छ। यो एक बादल हो जसले तपाईलाई झुण्ड्याउँछ र तपाईले गर्न नचाहने चीजहरू गर्न बाध्य पार्छ।

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

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

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

व्यवहारिक दृष्टिकोणबाट, त्यहाँ अर्को रोचक तथ्य छ। प्रणालीले केहि गर्न सक्छ जुन यसको कुनै पनि अंगले गर्न सक्दैन।

जसरी डा. रसेल अकफ (प्रणाली सोचका संस्थापकहरू मध्ये एक) ले भने, यो विचार प्रयोगबाट प्रमाणित गर्न एकदमै सजिलो छ। उदाहरणका लागि, कोठामा कसलाई कोड लेख्ने भनेर थाहा छ? त्यहाँ धेरै हातहरू छन्, र यो सामान्य छ, किनकि यो हाम्रो पेशाको लागि मुख्य आवश्यकताहरू मध्ये एक हो। के तपाईलाई लेख्न थाहा छ, तर के तपाईका हातले तपाईबाट अलग कोड लेख्न सक्नुहुन्छ? त्यहाँ मानिसहरू छन् जसले भन्नेछन्: "यो कोड लेख्ने मेरो हात होइन, यो मेरो दिमाग हो जसले कोड लेख्छ।" के तपाईको दिमागले तपाईबाट अलग कोड लेख्न सक्छ? खैर, सायद छैन।

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

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

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

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

अराजकताको अध्ययन गर्ने मानिसहरूले आफूलाई अराजकतावादी भन्छन्।

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

मलाई लाग्छ कि तपाईंहरू मध्ये धेरैले पनि प्राय: यस्तै महसुस गर्नुहुन्छ, त्यसैले तपाईं अराजकतावादी पनि हुनुहुन्छ। म तपाईंलाई अराजकताविद्हरूको गिल्डमा आमन्त्रित गर्दछु। तपाईं र म, प्रिय साथी अराजकताविद्हरूले अध्ययन गर्ने प्रणालीहरूलाई "जटिल अनुकूलन प्रणालीहरू" भनिन्छ।

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

त्यस्ता प्रणालीहरूको अर्को चाखलाग्दो गुण भनेको तिनीहरू स्वतन्त्र रूपमा मापनयोग्य छन्। निस्सन्देह, अराजकताविद्-इन्जिनियरहरूको रूपमा हामीलाई के चासो हुनुपर्छ। त्यसोभए, यदि हामीले भन्यौं कि जटिल प्रणालीको व्यवहार यसको भागहरूको अन्तरक्रियाद्वारा निर्धारण गरिन्छ, त्यसपछि हामीले केमा चासो लिनुपर्छ? अन्तरक्रिया।

त्यहाँ दुई थप रोचक निष्कर्षहरू छन्।


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

हामी कसरी अन्तरक्रिया गर्छौं? तपाईं र म मानव समाज भनिने ठूलो सूचना प्रणालीका सबै भाग हौं। हामी एक साझा भाषा मार्फत अन्तरक्रिया गर्छौं, यदि हामीसँग छ भने, यदि हामीले यसलाई फेला पार्छौं।

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

म भन्न चाहन्छु कि जटिलता तर्फ, अनुकूलनता तर्फ, विकेन्द्रीकरण तर्फ, अराजकता तर्फ प्रवृति सबै कुरामा पत्ता लगाउन सकिन्छ। र प्रणालीहरूमा जुन तपाईं र म निर्माण गर्दैछौं, र ती प्रणालीहरूमा जसको हामी भाग हौं।

र निराधार नहुनुहोस्, हामीले सिर्जना गर्ने प्रणालीहरू कसरी परिवर्तन हुँदैछन् हेरौं।

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

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

Microservices अन्त होइन, microservices, सामान्यतया, पहिले नै हिजो, किनभने Serverless आउँदैछ। सबै सर्भरहरू जलाए, कुनै सर्भरहरू छैनन्, कुनै अपरेटिङ सिस्टमहरू छैनन्, केवल शुद्ध कार्यान्वयन योग्य कोड। कन्फिगरेसनहरू अलग छन्, राज्यहरू अलग छन्, सबै कुरा घटनाहरूद्वारा नियन्त्रण गरिन्छ। सौन्दर्य, स्वच्छता, मौन, कुनै घटना, केहि हुँदैन, पूर्ण व्यवस्था।

जटिलता कहाँ छ ? कठिनाई, अवश्य पनि, अन्तरक्रियामा छ। एउटा कार्य आफैले कति गर्न सक्छ? यसले अन्य प्रकार्यहरूसँग कसरी अन्तरक्रिया गर्छ? सन्देश कतारहरू, डाटाबेसहरू, ब्यालेन्सरहरू। एक असफलता भयो जब केहि घटना कसरी पुन: सिर्जना गर्ने? धेरै प्रश्न र थोरै उत्तर।

माइक्रोसर्भिसेस र सर्भरलेसलाई हामी गीक हिप्स्टरहरूले क्लाउड नेटिभ भन्छौं। यो सबै बादल को बारे मा छ। तर क्लाउड पनि यसको स्केलेबिलिटीमा स्वाभाविक रूपमा सीमित छ। हामी यसलाई वितरण प्रणालीको रूपमा सोच्न अभ्यस्त छौं। वास्तवमा, क्लाउड प्रदायकहरूको सर्भरहरू कहाँ बस्छन्? डाटा केन्द्रहरूमा। त्यो हो, हामीसँग यहाँ एक प्रकारको केन्द्रीकृत, धेरै सीमित, वितरित मोडेल छ।

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

क्लाउड टिक्दैन, त्यसैले हामी बढ्दो रूपमा एज कम्प्युटिङ भनिने कुराको बारेमा कुरा गर्दैछौं। वा मलाई "फग कम्प्युटिङ" को अद्भुत परिभाषा पनि मनपर्छ। यो रोमान्टिकवाद र रहस्यको रहस्यवादले ढाकेको छ।

फग कम्प्युटिङ। बिन्दु यो हो कि बादलहरू पानी, भाप, बरफ र ढुङ्गाहरूको केन्द्रीकृत झुण्डहरू हुन्। र कुहिरो पानीका थोपाहरू हुन् जुन हाम्रो वरिपरि वायुमण्डलमा छरिएका छन्।

कुहिरो प्रतिमानमा, धेरै जसो काम यी थोपाहरू द्वारा पूर्ण रूपमा स्वायत्त रूपमा वा अन्य थोपाहरूसँगको सहकार्यमा गरिन्छ। र तिनीहरू क्लाउडमा फर्कन्छन् जब तिनीहरू वास्तवमै थिच्छन्।

त्यो हो, फेरि विकेन्द्रीकरण, स्वायत्तता, र, निस्सन्देह, तपाईं मध्ये धेरैले पहिले नै बुझ्नुहुन्छ कि यो सबै कहाँ गइरहेको छ, किनकि तपाईं ब्लकचेन उल्लेख नगरी विकेन्द्रीकरणको बारेमा कुरा गर्न सक्नुहुन्न।

त्यहाँ विश्वास गर्नेहरू छन्, यी ती हुन् जसले क्रिप्टोकरन्सीमा लगानी गरेका छन्। त्यहाँ विश्वास गर्नेहरू छन् तर डराउँछन्, उदाहरणका लागि, म जस्तै। अनि विश्वास नगर्नेहरू पनि छन्। यहाँ तपाईं फरक उपचार गर्न सक्नुहुन्छ। प्रविधि छ, नयाँ अज्ञात कुरा छ, समस्या छन् । कुनै पनि नयाँ प्रविधि जस्तै, यसले जवाफ भन्दा धेरै प्रश्नहरू खडा गर्छ।

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

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

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

अराजकता ईन्जिनियरिङ्

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

खैर, रिपोर्टमा काम गर्ने प्रक्रियामा, हामीले यो पाठलाई रूसीमा अनुवाद पनि गर्यौं, त्यसैले जानुहोस् लिङ्कपढ्नुहोस्, टिप्पणी गर्नुहोस्, गाली गर्नुहोस्।

छोटकरीमा, अराजकता ईन्जिनियरिङ् को सिद्धान्तहरू निम्न भन्छन्। जटिल वितरण प्रणालीहरू स्वाभाविक रूपमा अप्रत्याशित र स्वाभाविक रूपमा बग्गी छन्। त्रुटिहरू अपरिहार्य छन्, जसको मतलब हामीले यी त्रुटिहरूलाई स्वीकार गर्न र यी प्रणालीहरूसँग पूर्ण रूपमा फरक तरिकामा काम गर्न आवश्यक छ।

हामी आफैंले यी त्रुटिहरू हाम्रो उत्पादन प्रणालीहरूमा परिचय गराउने प्रयास गर्नुपर्छ ताकि हाम्रा प्रणालीहरू उही अनुकूलता, आत्म-संगठनको लागि यो क्षमता, बाँच्नको लागि परीक्षण गर्नुहोस्।

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

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

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

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

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

हामीले भनेझैं, हाम्रो प्रणालीहरू बढ्दो घटना-संचालित छन्। सर्भरलेस घटना-संचालित प्रणालीहरूको उत्कृष्ट उदाहरण हो। हामीलाई प्रणालीहरू बीच घटनाहरू स्थानान्तरण गर्न र तिनीहरूलाई ट्र्याक गर्नको लागि, हामीलाई केही साझा भाषा, हामी घटनाहरूको बारेमा कसरी कुरा गर्छौं, कसरी हामी तिनीहरूलाई एक-अर्कामा प्रसारण गर्छौं भनेर केही साझा प्रोटोकल चाहिन्छ। यसलाई परियोजना भनिन्छ क्लाउड घटनाहरू.

परिवर्तनहरूको निरन्तर स्ट्रिम जसले हाम्रो प्रणालीहरूमा धुन्छ, तिनीहरूलाई निरन्तर अस्थिर बनाउँछ, सफ्टवेयर कलाकृतिहरूको निरन्तर प्रवाह हो। हामीलाई परिवर्तनहरूको यो निरन्तर प्रवाह कायम राख्नको लागि, हामीलाई केहि प्रकारको साझा प्रोटोकल चाहिन्छ जसको माध्यमबाट हामी सफ्टवेयर आर्टिफ्याक्ट के हो, यो कसरी परीक्षण गरिन्छ, कुन प्रमाणीकरण पास भयो भन्ने बारे कुरा गर्न सक्छौं। यसलाई परियोजना भनिन्छ Grafeas। त्यो हो, सफ्टवेयर कलाकृतिहरूको लागि एक सामान्य मेटाडेटा प्रोटोकल।

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

यी सबै परियोजनाहरू जवान छन्, तिनीहरू सबैलाई हाम्रो माया, हाम्रो प्रमाणीकरण चाहिन्छ। यो सबै खुला स्रोत, हाम्रो परीक्षण, हाम्रो कार्यान्वयन हो। तिनीहरूले हामीलाई देखाउँछन् कि टेक्नोलोजी कता जाँदैछ।

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

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

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

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

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

DevOps संगठनको आधारभूत कुराहरू

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

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

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

बर्नआउट

हामी जसको हिस्सा हौं र हामीले निर्माण गर्ने प्रणालीहरू बढ्दो अराजकतामा छन्, र हामी मानिसहरूलाई यस विचारसँग सामना गर्न गाह्रो छ, नियन्त्रणको भ्रम त्याग्न गाह्रो छ। हामी तिनीहरूलाई नियन्त्रण गर्न जारी राख्ने प्रयास गर्छौं, र यसले प्रायः बर्नआउटमा जान्छ। म यो आफ्नै अनुभवबाट भन्छु, म पनि जलेको छु, म पनि उत्पादनमा अप्रत्याशित असफलताले अशक्त भएँ।

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

इन्जिनियरिङ पेशा, जसरी म प्रायः आफैलाई सम्झाउन चाहन्छु, पहिलो र प्रमुख एक रचनात्मक पेशा हो। यदि हामीले केहि सिर्जना गर्ने इच्छा गुमायौं भने, हामी खरानीमा परिणत हुन्छौं, खरानीमा परिणत हुन्छौं। मानिसहरू जल्छन्, सम्पूर्ण संगठनहरू जल्छन्।

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

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

अराजक बाँदर बाहेक अरू के?

वास्तवमा, यी सबै उपकरणहरू धेरै जवान छन्। उही नेटफ्लिक्सले आफ्नै लागि उपकरण बनाएको छ। तपाईंको आफ्नै उपकरणहरू निर्माण गर्नुहोस्। अराजकता ईन्जिनियरिङ्का सिद्धान्तहरू पढ्नुहोस् र अरू कसैले पहिले नै बनाएको अन्य उपकरणहरू फेला पार्ने प्रयास गर्नुको सट्टा ती सिद्धान्तहरूमा बाँच्नुहोस्।

तपाइँको प्रणाली कसरी बिग्रन्छ भनेर बुझ्न प्रयास गर्नुहोस् र तिनीहरूलाई तोड्न सुरु गर्नुहोस् र हेर्नुहोस् कि तिनीहरूले कसरी समात्छन्। यो पहिलो आउँछ। र तपाईं उपकरणहरू खोज्न सक्नुहुन्छ। त्यहाँ सबै प्रकारका परियोजनाहरू छन्।

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

यो सहि हो, माइक्रोसर्भिसेस सामान्य मा एक धेरै विवादास्पद विषय हो। वास्तवमा, भागहरू सरलीकरणले लचिलोपन बढाउँछ। माइक्रो सेवाहरूले के प्रदान गर्दछ? तिनीहरूले हामीलाई लचिलोपन र गति दिन्छ, तर तिनीहरूले निश्चित रूपमा हामीलाई सादगी दिँदैनन्। तिनीहरूले कठिनाइ बढाउँछन्।

त्यसोभए, DevOps दर्शनमा, microservices त्यस्तो राम्रो कुरा होइन?

कुनै पनि राम्रोको उल्टो पक्ष हुन्छ। फाइदा यो हो कि यसले लचिलोपन बढाउँछ, हामीलाई छिटो परिवर्तनहरू गर्न अनुमति दिन्छ, तर यसले जटिलता बढाउँछ र सम्पूर्ण प्रणालीको नाजुकता।

तैपनि, थप जोड के छ: अन्तरक्रियालाई सरल बनाउन वा भागहरू सरल बनाउनमा?

जोड, पक्कै पनि, अन्तरक्रियालाई सरल बनाउनमा छ, किनकि यदि हामीले तपाइँसँग कसरी काम गर्छौं भन्ने दृष्टिकोणबाट यसलाई हेर्छौं भने, सबैभन्दा पहिले, हामीले अन्तरक्रियालाई सरल बनाउनमा ध्यान दिनु पर्छ, कामलाई सरल बनाउनमा होइन। हामी प्रत्येकको छुट्टै। किनभने कामलाई सरल बनाउनु भनेको रोबोटमा परिणत हुनु हो। यहाँ म्याकडोनाल्डमा यो सामान्य रूपमा काम गर्दछ जब तपाइँसँग निर्देशनहरू छन्: यहाँ तपाइँ बर्गर राख्नुहुन्छ, यहाँ तपाइँ यसमा चटनी खन्याउनुहुन्छ। यो हाम्रो रचनात्मक कार्यमा काम गर्दैन।

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

ठिक छ, यो हामी कुन प्रकारको प्रतिस्पर्धाको बारेमा कुरा गर्दैछौं भन्ने कुरामा निर्भर गर्दछ। यो कार्यस्थलमा प्रतिस्पर्धा वा कम्पनीहरू बीचको प्रतिस्पर्धाको बारेमा हो?

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

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

के यसको मतलब अराजकता भनेको लक्ष्यको अभाव हो, जस्तो कि यो थियो? वा ती लक्ष्यहरू जुन हामी हेर्न चाहँदैनौं? हामी घरमा छौं र अरूको लक्ष्य बुझ्दैनौं। प्रतिस्पर्धा, वास्तवमा, यस तथ्यको कारण हो कि हामीसँग स्पष्ट लक्ष्यहरू छन् र हामीलाई थाहा छ कि हामी समयको प्रत्येक अर्को क्षणमा कहाँ पुग्छौं। यो, मेरो दृष्टिकोणबाट, DevOps को सार हो।

प्रश्न पनि एक नजर। मलाई लाग्छ कि हामी सबैको एउटै लक्ष्य छ: बाँच्नको लागि र यो गर्न
सबैभन्दा ठूलो आनन्द। र कुनै पनि संस्थाको प्रतिस्पर्धात्मक लक्ष्य एउटै हुन्छ। बाँच्नको लागि प्रायः प्रतिस्पर्धाको माध्यमबाट हुन्छ, त्यहाँ तपाईले गर्न सक्ने केहि छैन।

यस वर्षको सम्मेलन DevOpsDays मस्को Technopolis मा डिसेम्बर 7 मा हुनेछ। हामी नोभेम्बर 11 सम्म रिपोर्टहरूको लागि आवेदनहरू स्वीकार गर्दैछौं। लेख्नुहोस् हामी बोल्न चाहनुहुन्छ भने।

सहभागीहरूको लागि दर्ता खुला छ, टिकटहरू 7000 rubles को लागत। हामीसँग सामेल हुनुहोस्!

स्रोत: www.habr.com