DevOps आणि Chaos: विकेंद्रित जगात सॉफ्टवेअर वितरण

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

आम्ही अहवालाची मजकूर आवृत्ती तयार केली आहे.

सुप्रभात

मॉस्कोमध्ये सलग दुसऱ्या वर्षी DevOpsDays, या मंचावर माझी दुसरी वेळ आहे, तुमच्यापैकी बरेच जण दुसऱ्यांदा या खोलीत आहात. याचा अर्थ काय? याचा अर्थ रशियामधील 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 पद्धतींच्या प्रतिक्रिया म्हणून उदयास आले, जे आमच्या सिस्टमला अधिक लवचिक, अधिक स्केलेबल बनवण्यासाठी आणि सतत वितरण सुनिश्चित करण्यासाठी डिझाइन केलेले आहे. ती हे कसे करते? सेवांचे प्रमाण कमी करून, या सेवा प्रक्रिया करत असलेल्या समस्यांची व्याप्ती कमी करून, वितरण वेळ कमी करते. म्हणजेच, आम्ही सिस्टमचे भाग कमी करतो आणि सुलभ करतो, त्यांची संख्या वाढवतो आणि त्यानुसार, या भागांमधील परस्परसंवादाची जटिलता नेहमीच वाढते, म्हणजेच, नवीन समस्या उद्भवतात ज्यांचे निराकरण करणे आवश्यक आहे.

मायक्रोसर्व्हिसेस ही शेवटची गोष्ट नाही, मायक्रोसर्व्हिसेस सर्वसाधारणपणे कालच्याच आहेत, कारण सर्व्हरलेस येत आहे. सर्व सर्व्हर जळून खाक झाले, कोणतेही सर्व्हर नाहीत, ऑपरेटिंग सिस्टम नाहीत, फक्त शुद्ध एक्झिक्युटेबल कोड. कॉन्फिगरेशन वेगळे आहेत, राज्ये वेगळी आहेत, सर्वकाही इव्हेंटद्वारे नियंत्रित आहे. सौंदर्य, स्वच्छता, शांतता, कोणताही कार्यक्रम नाही, काहीही घडत नाही, संपूर्ण ऑर्डर.

गुंतागुंत कुठे आहे? अडचण अर्थातच संवादांमध्ये आहे. एखादे कार्य स्वतः किती करू शकते? ते इतर फंक्शन्सशी कसे संवाद साधते? संदेश रांगा, डेटाबेस, बॅलन्सर. अयशस्वी झाल्यास एखादी घटना पुन्हा कशी तयार करावी? बरेच प्रश्न आणि काही उत्तरे.

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

आज आपल्याला समजले आहे की इंटरनेट ऑफ थिंग्ज हे आता फक्त मोठे शब्द राहिले नाहीत की अगदी माफक अंदाजानुसार, इंटरनेटशी जोडलेली अब्जावधी उपकरणे येत्या पाच ते दहा वर्षांत आपली वाट पाहत आहेत. मोठ्या प्रमाणात उपयुक्त आणि निरुपयोगी डेटा जो क्लाउडमध्ये विलीन केला जाईल आणि क्लाउडवरून अपलोड केला जाईल.

क्लाउड टिकणार नाही, म्हणून आम्ही एज कॉम्प्युटिंग नावाच्या एखाद्या गोष्टीबद्दल बोलत आहोत. किंवा मला “फॉग कॉम्प्युटिंग” ची अप्रतिम व्याख्या देखील आवडते. हे रोमँटिसिझम आणि गूढतेच्या गूढतेने झाकलेले आहे.

धुके संगणन. मुद्दा असा आहे की ढग हे पाणी, वाफ, बर्फ आणि दगडांचे केंद्रीकृत गुच्छ असतात. आणि धुके म्हणजे पाण्याचे थेंब जे वातावरणात आपल्याभोवती विखुरलेले असतात.

धुक्याच्या प्रतिमानात, बहुतेक काम या थेंबांद्वारे पूर्णपणे स्वायत्तपणे किंवा इतर थेंबांच्या सहकार्याने केले जाते. आणि जेव्हा ते खरोखरच दाबले जातात तेव्हाच ते ढगाकडे वळतात.

म्हणजेच, पुन्हा विकेंद्रीकरण, स्वायत्तता आणि अर्थातच, तुमच्यापैकी अनेकांना हे सर्व कुठे चालले आहे हे आधीच समजले आहे, कारण तुम्ही ब्लॉकचेनचा उल्लेख केल्याशिवाय विकेंद्रीकरणाबद्दल बोलू शकत नाही.

असे लोक आहेत जे विश्वास ठेवतात, हे असे आहेत ज्यांनी क्रिप्टोकरन्सीमध्ये गुंतवणूक केली आहे. असे लोक आहेत जे विश्वास ठेवतात परंतु घाबरतात, उदाहरणार्थ, माझ्यासारखे. आणि असे लोक आहेत जे विश्वास ठेवत नाहीत. येथे आपण वेगळ्या पद्धतीने उपचार करू शकता. तंत्रज्ञान आहे, एक नवीन अज्ञात बाब आहे, समस्या आहेत. कोणत्याही नवीन तंत्रज्ञानाप्रमाणे, ते उत्तर देण्यापेक्षा अधिक प्रश्न उपस्थित करते.

ब्लॉकचेन बद्दलचा प्रचार समजण्यासारखा आहे. सोन्याची गर्दी बाजूला ठेवून, तंत्रज्ञानामध्येच उज्ज्वल भविष्यासाठी उल्लेखनीय आश्वासने आहेत: अधिक स्वातंत्र्य, अधिक स्वायत्तता, वितरित जागतिक विश्वास. काय नको आहे?

त्यानुसार, जगभरातील अधिकाधिक अभियंते विकेंद्रित अनुप्रयोग विकसित करू लागले आहेत. आणि ही अशी शक्ती आहे जी फक्त असे सांगून नाकारली जाऊ शकत नाही: "अहो, ब्लॉकचेन हा फक्त एक खराब अंमलबजावणी केलेला वितरित डेटाबेस आहे." किंवा संशयवादी म्हणू इच्छितात: "ब्लॉकचेनसाठी कोणतेही वास्तविक अनुप्रयोग नाहीत." जर तुम्ही विचार केला तर 150 वर्षांपूर्वी त्यांनी विजेबद्दल असेच सांगितले होते. आणि ते काही मार्गांनी बरोबरही होते, कारण वीज आज जे शक्य करते ते 19व्या शतकात शक्य नव्हते.

बाय द वे, स्क्रीनवर कोणता लोगो आहे कोणास ठाऊक? हे हायपरलेजर आहे. हा एक प्रकल्प आहे जो लिनक्स फाऊंडेशनच्या पुढाकाराने विकसित केला जात आहे आणि त्यात ब्लॉकचेन तंत्रज्ञानाचा समावेश आहे. ही खरोखरच आमच्या मुक्त स्रोत समुदायाची ताकद आहे.

अनागोंदी अभियांत्रिकी

म्हणून, आपण विकसित करत असलेली प्रणाली अधिकाधिक गुंतागुंतीची, अधिकाधिक अराजक आणि अधिकाधिक अनुकूल होत चालली आहे. नेटफ्लिक्स हे मायक्रोसर्व्हिस सिस्टमचे प्रणेते आहेत. हे समजून घेणारे ते पहिले होते, त्यांनी सिमियन आर्मी नावाच्या साधनांचा एक संच विकसित केला, ज्यापैकी सर्वात प्रसिद्ध होते. अनागोंदी माकड. जे म्हणून ओळखले गेले ते त्याने परिभाषित केले "अराजक अभियांत्रिकीची तत्त्वे".

तसे, अहवालावर काम करण्याच्या प्रक्रियेत, आम्ही हा मजकूर रशियनमध्ये अनुवादित केला आहे, म्हणून जा दुवा, वाचा, टिप्पणी करा, निंदा करा.

थोडक्यात, अनागोंदी अभियांत्रिकीची तत्त्वे पुढील गोष्टी सांगतात. कॉम्प्लेक्स डिस्ट्रिब्युटेड सिस्टीम्स जन्मजात अप्रत्याशित आणि अंतर्निहित बग्गी आहेत. त्रुटी अपरिहार्य आहेत, याचा अर्थ आम्हाला या त्रुटी स्वीकारण्याची आणि या प्रणालींसह पूर्णपणे भिन्न मार्गाने कार्य करण्याची आवश्यकता आहे.

आपल्या सिस्टमची त्याच अनुकूलतेसाठी, स्वयं-संस्थेची ही क्षमता, जगण्यासाठीची चाचणी घेण्यासाठी आपण स्वतः या त्रुटी आपल्या उत्पादन प्रणालींमध्ये आणण्याचा प्रयत्न केला पाहिजे.

आणि ते सर्वकाही बदलते. आम्ही उत्पादनामध्ये सिस्टीम कसे लाँच करतो एवढेच नाही, तर आम्ही त्यांचा विकास कसा करतो, आम्ही त्यांची चाचणी कशी करतो. कोडचे स्थिरीकरण किंवा गोठवण्याची कोणतीही प्रक्रिया नाही; उलटपक्षी, अस्थिरतेची सतत प्रक्रिया असते. आम्ही व्यवस्थेला मारण्याचा प्रयत्न करत आहोत आणि ती टिकून राहते हे पाहत आहोत.

वितरित सिस्टम इंटिग्रेशन प्रोटोकॉल

त्यानुसार, यासाठी आमच्या सिस्टीममध्ये कसा तरी बदल करणे आवश्यक आहे. ते अधिक स्थिर होण्यासाठी, त्यांना त्यांच्या भागांमधील परस्परसंवादासाठी काही नवीन प्रोटोकॉलची आवश्यकता आहे. जेणेकरुन हे भाग सहमत होऊ शकतील आणि काही प्रकारच्या स्वयं-संस्थेत येऊ शकतील. आणि सर्व प्रकारची नवीन साधने, नवीन प्रोटोकॉल तयार होतात, ज्याला मी "वितरित प्रणालींच्या परस्परसंवादासाठी प्रोटोकॉल" म्हणतो.

मी कशाबद्दल बोलत आहे? प्रथम, प्रकल्प ओपनट्रेसिंग. काही सामान्य वितरित ट्रॅकिंग प्रोटोकॉल तयार करण्याचा प्रयत्न करतात, जे जटिल वितरित सिस्टम डीबग करण्यासाठी पूर्णपणे अपरिहार्य साधन आहे.

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

आम्ही म्हटल्याप्रमाणे, आमच्या सिस्टम्स वाढत्या प्रमाणात इव्हेंट-चालित आहेत. सर्व्हरलेस हे इव्हेंट-चालित सिस्टमचे उत्कृष्ट उदाहरण आहे. आम्‍हाला सिस्‍टममध्‍ये इव्‍हेंट स्‍थानांतरित करण्‍यासाठी आणि त्‍यांचा मागोवा घेण्‍यासाठी, आम्‍ही इव्‍हेंटबद्दल कसे बोलतो, ते एकमेकांना कसे प्रसारित करतो यासाठी काही सामान्य भाषा, काही सामाईक प्रोटोकॉलची आवश्‍यकता असते. यालाच प्रकल्प म्हणतात क्लाउड इव्हेंट्स.

बदलांचा सतत प्रवाह जो आपल्या सिस्टम्सवर धुऊन टाकतो, त्यांना सतत अस्थिर करतो, हा सॉफ्टवेअर कलाकृतींचा एक सतत प्रवाह आहे. बदलांचा हा सतत प्रवाह कायम ठेवण्यासाठी, आम्हाला काही सामान्य प्रोटोकॉलची आवश्यकता आहे ज्याद्वारे आम्ही सॉफ्टवेअर आर्टिफॅक्ट म्हणजे काय, त्याची चाचणी कशी केली जाते, कोणती पडताळणी उत्तीर्ण झाली आहे याबद्दल बोलू शकतो. यालाच प्रकल्प म्हणतात ग्राफीज. म्हणजेच, सॉफ्टवेअर आर्टिफॅक्ट्ससाठी एक सामान्य मेटाडेटा प्रोटोकॉल.

आणि शेवटी, जर आम्हाला आमची प्रणाली पूर्णपणे स्वतंत्र, अनुकूल आणि स्वयं-संघटित हवी असेल, तर आम्ही त्यांना स्व-ओळखण्याचा अधिकार दिला पाहिजे. प्रकल्प म्हणतात spiffe तो नेमका हेच करतो. क्लाउड नेटिव्ह कंप्युटिंग फाउंडेशनच्या अंतर्गत हा देखील एक प्रकल्प आहे.

हे सर्व प्रकल्प तरुण आहेत, त्यांना आमच्या प्रेमाची, आमच्या प्रमाणीकरणाची गरज आहे. हे सर्व ओपन सोर्स, आमची चाचणी, आमची अंमलबजावणी आहे. तंत्रज्ञान कुठे चालले आहे हे ते दाखवतात.

परंतु DevOps हे कधीच प्रामुख्याने तंत्रज्ञानाबद्दल नव्हते, ते नेहमीच लोकांमधील सहकार्याबद्दल होते. आणि, त्यानुसार, आपण विकसित केलेल्या प्रणाली बदलू इच्छित असल्यास, आपण स्वतः बदलले पाहिजे. खरं तर, आम्ही तरीही बदलत आहोत; आमच्याकडे जास्त पर्याय नाही.

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

मग एक खूप मोठा काळ होता - एक गडद काळ जेव्हा विश्वास केंद्रीकृत होता, जेव्हा आपण अशा लोकांवर विश्वास ठेवू लागलो ज्यांना आपण त्याच सार्वजनिक किंवा राज्य संस्थेचे आहोत या वस्तुस्थितीच्या आधारावर आपण ओळखत नाही.

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

याचा विचार केल्यास, हीच सुलभता, ज्यामुळे हा विश्वास शक्य होतो, तेच तुम्ही आणि मी राबवत आहोत. याचा अर्थ असा आहे की आपण ज्या प्रकारे सहकार्य करतो आणि आपण ते करतो ते दोन्ही बदलले पाहिजेत, कारण जुन्या केंद्रीकृत, श्रेणीबद्ध आयटी संस्था आता काम करत नाहीत. ते मरायला लागतात.

DevOps संस्थेची मूलभूत तत्त्वे

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

अर्थात, सांस्कृतिक बदलाशिवाय यातील काहीही शक्य नाही. आपल्यात परिवर्तनवादी नेतृत्व, वैयक्तिक जबाबदारी, अंतर्गत प्रेरणा असली पाहिजे.

हा DevOps संस्थांचा आधार आहे: माहिती पारदर्शकता, असिंक्रोनस संप्रेषण, परिवर्तनात्मक नेतृत्व, विकेंद्रीकरण.

बर्नआउट

आपण ज्या सिस्टीमचा भाग आहोत आणि आपण ज्या सिस्टीम बनवतो त्या अधिकाधिक अराजक होत आहेत आणि आपल्या मानवांसाठी या विचाराचा सामना करणे कठीण आहे, नियंत्रणाचा भ्रम सोडणे कठीण आहे. आम्ही त्यांच्यावर नियंत्रण ठेवण्याचा प्रयत्न करतो आणि यामुळे बर्‍याचदा बर्नआउट होते. मी हे माझ्या स्वत: च्या अनुभवावरून सांगतो, मी देखील भाजलो, उत्पादनातील अनपेक्षित अपयशांमुळे मी अक्षम देखील झालो.

बर्नआउट उद्भवते जेव्हा आपण एखाद्या गोष्टीवर नियंत्रण ठेवण्याचा प्रयत्न करतो जे मूळतः अनियंत्रित असते. जेव्हा आपण जळून जातो, तेव्हा प्रत्येक गोष्ट त्याचा अर्थ गमावते कारण आपण काहीतरी नवीन करण्याची इच्छा गमावतो, आपण बचावात्मक बनतो आणि आपल्याकडे जे आहे त्याचा बचाव करू लागतो.

अभियांत्रिकी व्यवसाय, जसे की मला स्वतःला वारंवार आठवण करून द्यायला आवडते, हा पहिला आणि सर्वात महत्वाचा सर्जनशील व्यवसाय आहे. जर आपण काहीतरी निर्माण करण्याची इच्छा गमावली तर आपण राख बनतो, राख बनतो. लोक जळतात, संपूर्ण संस्था जळून जातात.

माझ्या मते, केवळ अनागोंदीची सर्जनशील शक्ती स्वीकारणे, केवळ त्याच्या तत्त्वांनुसार सहकार्य निर्माण करणे हेच आपल्याला आपल्या व्यवसायात जे चांगले आहे ते गमावू नये म्हणून मदत करेल.

मला तुमच्यासाठी हेच वाटते: तुमच्या कामावर प्रेम करणे, आम्ही जे करतो त्यावर प्रेम करणे. हे जग माहितीवर भरवते, ती खायला देण्याचा मान आपल्याला आहे. तर चला अराजकतेचा अभ्यास करूया, चला अराजकशास्त्रज्ञ बनूया, मूल्य आणूया, काहीतरी नवीन तयार करूया, चांगले, समस्या, जसे की आपण आधीच शोधून काढले आहे, त्या अपरिहार्य आहेत आणि जेव्हा त्या दिसतात तेव्हा आपण फक्त "ऑप्स!" म्हणू आणि समस्या सोडवली जाते.

अराजक माकड व्यतिरिक्त काय?

खरे तर ही सर्व वाद्ये तशी तरुण आहेत. त्याच Netflix ने स्वतःसाठी साधने तयार केली. तुमची स्वतःची साधने तयार करा. अराजक अभियांत्रिकीची तत्त्वे वाचा आणि इतर कोणीतरी आधीच तयार केलेली इतर साधने शोधण्याचा प्रयत्न करण्याऐवजी त्या तत्त्वांचे पालन करा.

तुमची सिस्टीम कशी तुटते हे समजून घेण्याचा प्रयत्न करा आणि त्यांना तोडण्यास सुरुवात करा आणि ते कसे टिकून राहतात ते पहा. हे प्रथम येते. आणि तुम्ही साधने शोधू शकता. सर्व प्रकारचे प्रकल्प आहेत.

मला तो क्षण समजला नाही जेव्हा तुम्ही म्हणाला होता की सिस्टीमचे घटक सरलीकृत करून सरलीकृत केले जाऊ शकत नाही आणि लगेच मायक्रोसर्व्हिसेसकडे वळलो, जे घटक स्वतःच सोपे करून आणि परस्परसंवाद गुंतागुंत करून सिस्टम सुलभ करतात. हे मूलत: दोन भाग आहेत जे एकमेकांच्या विरुद्ध आहेत.

हे बरोबर आहे, मायक्रोसर्व्हिसेस हा सर्वसाधारणपणे एक अतिशय वादग्रस्त विषय आहे. खरं तर, भाग सरलीकृत केल्याने लवचिकता वाढते. मायक्रो सर्व्हिसेस काय देतात? ते आपल्याला लवचिकता आणि गती देतात, परंतु ते नक्कीच आपल्याला साधेपणा देत नाहीत. ते अडचण वाढवतात.

तर, DevOps तत्त्वज्ञानात, मायक्रोसर्व्हिसेस ही चांगली गोष्ट नाही?

कोणत्याही चांगल्याला उलट बाजू असते. फायदा असा आहे की ते लवचिकता वाढवते, आम्हाला जलद बदल करण्यास अनुमती देते, परंतु यामुळे जटिलता वाढते आणि त्यामुळे संपूर्ण प्रणालीची नाजूकता वाढते.

तरीही, अधिक जोर कशावर आहे: परस्परसंवाद सुलभ करण्यावर किंवा भाग सुलभ करण्यावर?

अर्थातच, परस्परसंवाद सुलभ करण्यावर भर दिला जातो, कारण आम्ही तुमच्यासोबत कसे कार्य करतो या दृष्टिकोनातून हे पाहिल्यास, सर्वप्रथम, आम्हाला परस्परसंवाद सुलभ करण्याकडे लक्ष देणे आवश्यक आहे, काम सोपे करण्यावर नाही. आपल्यापैकी प्रत्येकाचे स्वतंत्रपणे. कारण काम सोपे करणे म्हणजे रोबोटमध्ये बदलणे. येथे मॅकडोनाल्डमध्ये जेव्हा तुम्हाला सूचना असतील तेव्हा ते सामान्यपणे कार्य करते: येथे तुम्ही बर्गर ठेवता, येथे तुम्ही त्यावर सॉस घाला. हे आपल्या सर्जनशील कार्यात अजिबात चालत नाही.

तुम्ही सांगितलेली प्रत्येक गोष्ट स्पर्धाविरहित जगात जगते आणि तिथली अराजकता खूप दयाळू आहे आणि या अनागोंदीत कोणतेही विरोधाभास नाहीत, कोणालाही खाण्याची किंवा मारण्याची इच्छा नाही हे खरे आहे का? स्पर्धा आणि DevOps भाडे कसे असावे?

बरं, आपण कोणत्या प्रकारच्या स्पर्धेबद्दल बोलत आहोत यावर ते अवलंबून आहे. हे कामाच्या ठिकाणी किंवा कंपन्यांमधील स्पर्धेबद्दल आहे का?

सेवा अनेक कंपन्या नसल्यामुळे अस्तित्त्वात असलेल्या सेवांच्या स्पर्धेबद्दल. आम्ही नवीन प्रकारचे माहिती वातावरण तयार करत आहोत आणि कोणतेही वातावरण स्पर्धेशिवाय जगू शकत नाही. सर्वत्र स्पर्धा आहे.

त्याच Netflix, आम्ही त्यांना एक आदर्श म्हणून घेतो. त्यांना हे का आले? कारण त्यांना स्पर्धात्मक बनण्याची गरज होती. ही लवचिकता आणि हालचालींची गती ही अतिशय स्पर्धात्मक आवश्यकता आहे; यामुळे आपल्या प्रणालींमध्ये अराजकता निर्माण होते. म्हणजेच, अराजकता ही अशी गोष्ट नाही जी आपण जाणीवपूर्वक करतो कारण आपल्याला ती हवी असते, ती अशी गोष्ट आहे जी जगाने मागणी केली म्हणून घडते. आपल्याला फक्त जुळवून घ्यायचे आहे. आणि अनागोंदी, तो तंतोतंत स्पर्धेचा परिणाम आहे.

याचा अर्थ अराजकता म्हणजे उद्दिष्टांची अनुपस्थिती आहे का? किंवा ती उद्दिष्टे जी आपण पाहू इच्छित नाही? आपण घरात आहोत आणि इतरांचे ध्येय समजत नाही. स्पर्धा, खरं तर, या वस्तुस्थितीमुळे आहे की आमची स्पष्ट उद्दिष्टे आहेत आणि आम्हाला माहित आहे की आम्ही वेळेत प्रत्येक पुढच्या क्षणी कोठे संपणार आहोत. हे, माझ्या दृष्टिकोनातून, DevOps चे सार आहे.

तसेच प्रश्नावर एक नजर. मला वाटते की आपल्या सर्वांचे ध्येय एकच आहे: जगणे आणि ते करणे
सर्वात मोठा आनंद. आणि कोणत्याही संस्थेचे स्पर्धात्मक उद्दिष्ट एकच असते. टिकून राहणे बहुतेक वेळा स्पर्धेद्वारे होते, आपण त्याबद्दल काहीही करू शकत नाही.

यंदाची परिषद DevOpsDays मॉस्को 7 डिसेंबर रोजी टेक्नोपोलिस येथे होणार आहे. आम्ही 11 नोव्हेंबरपर्यंत अहवालांसाठी अर्ज स्वीकारत आहोत. लिहा जर तुम्हाला बोलायचे असेल तर आम्हाला.

सहभागींसाठी नोंदणी खुली आहे, तिकिटांची किंमत 7000 रूबल आहे. आमच्यात सामील व्हा!

स्त्रोत: www.habr.com