DevOps दृष्टिकोनाच्या चाहत्यांसाठी परिषद

आम्ही अर्थातच याबद्दल बोलत आहोत DevOpsConf. तुम्ही तपशिलात न गेल्यास, ३० सप्टेंबर आणि १ ऑक्टोबरला आम्ही विकास, चाचणी आणि ऑपरेशन या प्रक्रिया एकत्रित करण्यावर एक परिषद आयोजित करू आणि जर तुम्ही तपशीलांमध्ये गेलात तर, कृपया, मांजरीच्या खाली.

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

कॉन्फरन्समध्ये आम्ही हे दाखवू इच्छितो की हा दृष्टिकोन उत्पादन विकासावर कसा प्रभाव पाडतो. क्लायंटसाठी सिस्टमची विश्वासार्हता आणि अनुकूलता कशी सुनिश्चित केली जाते. DevOps कंपनीची कार्यप्रक्रिया आयोजित करण्यासाठी त्याची रचना आणि दृष्टिकोन कसा बदलत आहे.

पडद्यामागे

DevOps दृष्टिकोनाच्या चौकटीत वेगवेगळ्या कंपन्या काय करत आहेत हे जाणून घेणे आमच्यासाठी महत्त्वाचे आहे, परंतु हे सर्व का केले जाते हे समजून घेणे देखील महत्त्वाचे आहे. म्हणून, आम्ही केवळ तज्ञांना कार्यक्रम समितीमध्ये सामील होण्यासाठी आमंत्रित केले नाही, तर विविध पदांवरून DevOps प्रवचन पाहणारे विशेषज्ञ:

• वरिष्ठ अभियंते;
• विकसक
• संघ आघाडीवर;
• CTO.

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

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

परिषदेचे विभाग जसेच्या तसे राहतील गेल्या वेळी.

• पायाभूत सुविधा मंच.
• कोड म्हणून पायाभूत सुविधा.
• सतत वितरण.
• अभिप्राय.
• DevOps मध्ये आर्किटेक्चर, CTO साठी DevOps.
• SRE सराव.
• प्रशिक्षण आणि ज्ञान व्यवस्थापन.
• सुरक्षा, DevSecOps.
• DevOps परिवर्तन.

पेपर्ससाठी कॉल करा: आम्ही कोणत्या प्रकारचे अहवाल शोधत आहोत

आम्ही कॉन्फरन्सच्या संभाव्य प्रेक्षकांना सशर्तपणे पाच गटांमध्ये विभागले: अभियंते, विकासक, सुरक्षा विशेषज्ञ, टीम लीड आणि CTO. परिषदेत येण्यासाठी प्रत्येक गटाची स्वतःची प्रेरणा असते. आणि, तुम्ही या पदांवरून DevOps पाहिल्यास, तुमच्या विषयावर कसे लक्ष केंद्रित करायचे आणि कुठे जोर द्यायचा हे तुम्ही समजू शकता.

अभियंत्यांसाठी, कोण इन्फ्रास्ट्रक्चर प्लॅटफॉर्म तयार करत आहेत, विद्यमान ट्रेंड समजून घेणे, कोणते तंत्रज्ञान आता सर्वात प्रगत आहेत हे समजून घेणे महत्वाचे आहे. त्यांना हे तंत्रज्ञान वापरण्यात आणि मतांची देवाणघेवाण करण्याच्या वास्तविक जीवनातील अनुभवाबद्दल जाणून घेण्यात रस असेल. एखाद्या अभियंत्याला काही हार्डकोर अपघाताचे विश्लेषण करणारा अहवाल ऐकून आनंद होईल आणि आम्ही त्या बदल्यात असा अहवाल निवडण्याचा आणि पॉलिश करण्याचा प्रयत्न करू.

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

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

टीम लीड्स जाणून घेऊ इच्छित आहेत, इतर कंपन्यांमध्ये सतत वितरण प्रक्रिया कशी कार्य करते. हे साध्य करण्यासाठी कंपन्यांनी कोणता मार्ग स्वीकारला, त्यांनी DevOps मध्ये विकास आणि गुणवत्ता हमी प्रक्रिया कशा तयार केल्या. टीम लीडना देखील क्लाउड नेटिव्हमध्ये स्वारस्य आहे. आणि संघामध्ये आणि विकास आणि अभियांत्रिकी संघांमधील परस्परसंवादाबद्दल प्रश्न.

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

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

बरं, तुम्हाला सार्वजनिकपणे बोलण्याची गरज नसल्यास, फक्त तिकीट खरेदी करा आणि सहकाऱ्यांशी संवाद साधण्यासाठी 30 सप्टेंबर आणि 1 ऑक्टोबर रोजी या. आम्ही वचन देतो की ते मनोरंजक आणि प्रेरणादायी असेल.

आम्ही DevOps कसे पाहतो

DevOps म्हणजे नेमके काय हे समजून घेण्यासाठी, मी माझा अहवाल वाचण्याची (किंवा पुन्हा वाचण्याची) शिफारस करतो.DevOps म्हणजे काय" बाजाराच्या लाटांमधून चालत असताना, मी निरनिराळ्या आकाराच्या कंपन्यांमध्ये DevOps ची कल्पना कशी बदलत आहे हे पाहिले: लहान स्टार्टअपपासून बहुराष्ट्रीय कंपन्यांपर्यंत. हा अहवाल प्रश्नांच्या मालिकेवर आधारित आहे, त्यांची उत्तरे देऊन तुम्ही समजू शकता की तुमची कंपनी DevOps कडे वाटचाल करत आहे की कुठेतरी समस्या आहेत.

DevOps ही एक जटिल प्रणाली आहे, त्यात समाविष्ट असणे आवश्यक आहे:

• डिजिटल उत्पादन.
• हे डिजिटल उत्पादन विकसित करणारे व्यवसाय मॉड्यूल.
• कोड लिहिणारे उत्पादन संघ.
• सतत वितरण पद्धती.
• सेवा म्हणून प्लॅटफॉर्म.
• सेवा म्हणून पायाभूत सुविधा.
• कोड म्हणून पायाभूत सुविधा.
• विश्वासार्हता राखण्यासाठी वेगळ्या पद्धती, DevOps मध्ये अंतर्भूत.
• या सर्वांचे वर्णन करणारा अभिप्राय सराव.

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

तुम्ही अहवालाचा व्हिडिओ पाहू शकता येथे.

आणि आता एक बोनस असेल: RIT++ 2019 मधील अनेक व्हिडिओ, जे DevOps परिवर्तनाच्या सर्वात सामान्य समस्यांना स्पर्श करतात.

उत्पादन म्हणून कंपनी पायाभूत सुविधा

Artyom Naumenko Skyeng येथे DevOps संघाचे नेतृत्व करतात आणि त्यांच्या कंपनीच्या पायाभूत सुविधांच्या विकासाची काळजी घेतात. SkyEng मधील व्यवसाय प्रक्रियांवर पायाभूत सुविधांचा कसा परिणाम होतो हे त्यांनी सांगितले: त्यासाठी ROI ची गणना कशी करावी, गणनासाठी कोणते मेट्रिक्स निवडले जावे आणि ते सुधारण्यासाठी कसे कार्य करावे.

मायक्रो सर्व्हिसेसच्या रस्त्यावर

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

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

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

• प्रकल्पासाठी योग्य आर्किटेक्चर कसे निवडायचे आणि पायाभूत सुविधा व्यवस्थित कसे ठेवायचे;
• कोणती साधने वापरायची आणि परिवर्तनाच्या मार्गावर कोणते अडचणी येतात;
• पुढे काय करायचे.

रिलीझचे ऑटोमेशन किंवा जलद आणि वेदनारहित कसे वितरित करावे

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

अपघात तुम्हाला शिकण्यास कशी मदत करतात?

Alexey Kirpichnikov SKB Kontur येथे 5 वर्षांपासून DevOps आणि पायाभूत सुविधांची अंमलबजावणी करत आहे. तीन वर्षांच्या कालावधीत, त्याच्या कंपनीमध्ये विविध प्रकारच्या महाकाव्यांचे अंदाजे 1000 फॅकॅप्स आले. त्यापैकी, उदाहरणार्थ, 36% उत्पादनामध्ये कमी-गुणवत्तेचे प्रकाशन रोल आउट केल्यामुळे झाले आणि 14% डेटा सेंटरमधील हार्डवेअर देखभाल कार्यामुळे झाले.

कंपनीचे अभियंते सलग अनेक वर्षे देखरेख करत असलेल्या अहवालांचे संग्रहण (पोस्ट-मॉर्टम) अपघातांबद्दल अशी अचूक माहिती मिळवणे शक्य करते. पोस्टमॉर्टम ड्युटीवरील अभियंत्याने लिहिले आहे, ज्याने आपत्कालीन सिग्नलला प्रतिसाद देणारा पहिला होता आणि सर्वकाही ठीक करण्यास सुरुवात केली. रिपोर्ट्स लिहून रात्री फेकॅप्स घेऊन धडपडणाऱ्या अभियंत्यांना का छळताय? हा डेटा तुम्हाला संपूर्ण चित्र पाहण्याची आणि पायाभूत सुविधांच्या विकासाला योग्य दिशेने वाटचाल करण्यास अनुमती देतो.

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

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

आम्ही प्रोग्राममध्ये कोणते अहवाल आधीच स्वीकारले आहेत?

या आठवड्यात कार्यक्रम समितीने 4 अहवाल स्वीकारले: सुरक्षा, पायाभूत सुविधा आणि SRE पद्धती.

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

• काय संरक्षित करणे आवश्यक आहे आणि कोणापासून;
• नियमित सुरक्षा प्रक्रिया काय आहेत;
• आयटी आणि माहिती सुरक्षा प्रक्रिया कशा एकमेकांना एकमेकांना देतात;
• CIS CSC म्हणजे काय आणि त्याची अंमलबजावणी कशी करावी;
• नियमित माहिती सुरक्षा तपासणी कशी आणि कोणत्या निर्देशकांद्वारे करावी.

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

ऑटोमेशन आणि विकास सुलभ करण्याच्या उद्देशाने कोड प्लेसमेंट पॅटर्न कसे कार्य करतात हे Maxim दर्शवेल.

दुसरा अहवाल कडून पायाभूत सुविधांबद्दल ऐकू प्लेकी मधील व्लादिमीर रायबोव्ह. येथे आपण इन्फ्रास्ट्रक्चर प्लॅटफॉर्मबद्दल बोलू, आणि आपण शिकू:

• स्टोरेज स्पेस प्रभावीपणे वापरली जात आहे की नाही हे कसे समजून घ्यावे;
• केवळ 10 TB स्टोरेज वापरल्यास शेकडो वापरकर्ते 20 TB सामग्री कशी प्राप्त करू शकतात;
• डेटा 5 वेळा संकुचित कसा करायचा आणि वापरकर्त्यांना तो रिअल-टाइममध्ये कसा प्रदान करायचा;
• अनेक डेटा सेंटर्स दरम्यान फ्लायवर डेटा सिंक्रोनाइझ कसा करायचा;
• एक व्हर्च्युअल मशीन क्रमाक्रमाने वापरताना वापरकर्त्यांचा एकमेकांवरील प्रभाव कसा दूर करायचा.

या जादूचे रहस्य तंत्रज्ञान आहे फ्रीबीएसडीसाठी ZFS आणि त्याचा ताजा काटा लिनक्सवरील झेडएफएस. व्लादिमीर Playkey वरून प्रकरणे सामायिक करेल.

Amixr.IO कडून Matvey Kukuy जीवनातील उदाहरणांसह तयार सांगणे, काय झाले एसआरई आणि ते विश्वसनीय प्रणाली तयार करण्यात कशी मदत करते. Amixr.IO त्याच्या बॅकएंडद्वारे क्लायंटच्या घटना पार पाडते; जगभरातील डझनभर ऑन-ड्यूटी संघांनी आधीच 150 हजार प्रकरणे हाताळली आहेत. कॉन्फरन्समध्ये, मॅटवे त्यांच्या कंपनीने ग्राहकांच्या समस्या सोडवून आणि अपयशांचे विश्लेषण करून जमा केलेली आकडेवारी आणि अंतर्दृष्टी शेअर करेल.

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

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