पुन्हा एकदा DevOps आणि SRE बद्दल

गप्पांच्या चर्चेवर आधारित AWS मिन्स्क समुदाय

अलीकडे, DevOps आणि SRE च्या व्याख्येवरून वास्तविक लढाया भडकल्या आहेत.
या विषयावरील चर्चेने माझ्यासह अनेक मार्गांनी माझे दात आधीच तयार केले आहेत हे असूनही, मी या विषयावर माझे मत हाब्रा समुदायाच्या दरबारात मांडण्याचे ठरवले. ज्यांना स्वारस्य आहे त्यांच्यासाठी, मांजरीमध्ये आपले स्वागत आहे. आणि सर्वकाही पुन्हा सुरू होऊ द्या!

prehistory

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

DevOps पद्धतींचा जन्म

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

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

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

आणि त्यांनी त्यांना DevOps पद्धती म्हणायचे ठरवले - मला वाटते की त्यांचा अर्थ विकास ते ऑपरेशन्स पर्यंत आहे. आम्ही विविध चतुर गोष्टी घेऊन आलो - CI/CD पद्धती, IaC तत्त्वावर आधारित सराव, त्यापैकी हजारो. आणि आम्ही निघून जातो, डेव्हलपर कोड लिहितात, DevOps अभियंते सिस्टमचे वर्णन कोडच्या स्वरूपात कार्यरत सिस्टममध्ये रूपांतरित करतात (होय, कोड, दुर्दैवाने, फक्त एक वर्णन आहे, परंतु सिस्टमचे मूर्त स्वरूप नाही), वितरण सुरू आहे, आणि असेच. कालचे प्रशासक, नवीन पद्धतींमध्ये प्रभुत्व मिळवून, अभिमानाने DevOps अभियंते म्हणून पुन्हा प्रशिक्षित झाले आणि तेथून सर्व काही झाले. आणि संध्याकाळ झाली आणि सकाळ झाली... माफ करा, तिथून नाही.

हे सर्व पुन्हा चांगले नाही, देवाचे आभार

सर्व काही शांत होताच आणि विविध धूर्त “पद्धतीतज्ञांनी” DevOps पद्धतींवर जाड पुस्तके लिहिण्यास सुरुवात केली, कुख्यात DevOps अभियंता कोण आहे आणि DevOps ही उत्पादन संस्कृती आहे याबद्दल वाद शांतपणे भडकला, पुन्हा असंतोष निर्माण झाला. अचानक असे दिसून आले की सॉफ्टवेअर वितरण हे अगदी क्षुल्लक कार्य आहे. प्रत्येक डेव्हलपमेंट इन्फ्रास्ट्रक्चरचा स्वतःचा स्टॅक असतो, कुठेतरी तुम्हाला ते एकत्र करणे आवश्यक आहे, कुठेतरी तुम्हाला पर्यावरण तैनात करणे आवश्यक आहे, येथे तुम्हाला टॉमकॅटची आवश्यकता आहे, येथे तुम्हाला ते लॉन्च करण्यासाठी एक धूर्त आणि क्लिष्ट मार्ग आवश्यक आहे - सर्वसाधारणपणे, तुमचे डोके धडधडत आहे. आणि समस्या, विचित्रपणे पुरेशी, प्रामुख्याने प्रक्रियेच्या संघटनेत असल्याचे दिसून आले - हे वितरण कार्य, अडथळ्यासारखे, प्रक्रिया अवरोधित करू लागले. याव्यतिरिक्त, कोणीही ऑपरेशन्स रद्द केले नाहीत. व्ही-मॉडेलमध्ये ते दृश्यमान नाही, परंतु उजवीकडे संपूर्ण जीवनचक्र अजूनही आहे. परिणामी, पायाभूत सुविधांची देखभाल करणे, देखरेख ठेवणे, घटनांचे निराकरण करणे आणि वितरणास सामोरे जाणे आवश्यक आहे. त्या. विकास आणि ऑपरेशन दोन्हीमध्ये एक पाय ठेवून बसा - आणि अचानक ते विकास आणि ऑपरेशन्स बनले. आणि मग मायक्रोसर्व्हिसेससाठी सामान्य प्रचार झाला. आणि त्यांच्यासह, स्थानिक मशीन्सचा विकास क्लाउडवर जाऊ लागला - स्थानिक पातळीवर काहीतरी डीबग करण्याचा प्रयत्न करा, जर तेथे डझनभर आणि शेकडो मायक्रो सर्व्हिसेस असतील तर सतत वितरण हे जगण्याचे साधन बनते. "लहान विनम्र कंपनी" साठी हे सर्व ठीक होते, परंतु तरीही? Google बद्दल काय?

Google द्वारे SRE

Google आले, सर्वात मोठे कॅक्टी खाल्ले आणि ठरवले - आम्हाला याची गरज नाही, आम्हाला विश्वासार्हता हवी आहे. आणि विश्वसनीयता व्यवस्थापित करणे आवश्यक आहे. आणि मी ठरवले की आम्हाला तज्ञांची आवश्यकता आहे जे विश्वासार्हता व्यवस्थापित करतील. मी त्यांना एसआर अभियंते बोलावले आणि म्हणालो, ते तुमच्यासाठी आहे, ते नेहमीप्रमाणे चांगले करा. येथे SLI आहे, येथे SLO आहे, येथे देखरेख आहे. आणि त्याने ऑपरेशनमध्ये नाक खुपसले. आणि त्याने त्याचे "विश्वसनीय DevOps" SRE म्हटले. सर्व काही ठीक आहे असे दिसते, परंतु एक घाणेरडा हॅक आहे जो Google ला परवडेल - SR अभियंत्यांच्या पदासाठी, पात्र विकासक असलेल्या लोकांना कामावर घ्या आणि त्यांनी थोडा गृहपाठ देखील केला आणि कार्यरत प्रणालींचे कार्य समजून घेतले. शिवाय, Google ला स्वतः अशा लोकांना कामावर घेण्यास समस्या आहेत - मुख्यतः कारण येथे ते स्वतःशी स्पर्धा करते - एखाद्या व्यक्तीला व्यवसाय तर्काचे वर्णन करणे आवश्यक आहे. डिलिव्हरी अभियंता, SR - अभियंते यांना रिलीझ करण्यासाठी नियुक्त केले गेले होते (अर्थातच, थेट नाही, परंतु पायाभूत सुविधांवर प्रभाव टाकून, आर्किटेक्चर बदलून, बदल आणि निर्देशकांचा मागोवा घेणे, घटनांना सामोरे जाणे). छान, तुम्ही करू शकता पुस्तके लिहा. परंतु आपण Google नसल्यास काय करावे, परंतु विश्वासार्हता अद्याप चिंताजनक आहे?

DevOps कल्पनांचा विकास

तेवढ्यात डॉकरचे आगमन झाले, जे lxc मधून वाढले, आणि नंतर डॉकर स्वॉर्म आणि कुबर्नेट्स सारख्या विविध ऑर्केस्ट्रेशन प्रणाली आणि DevOps अभियंते यांनी श्वास सोडला - प्रॅक्टिसच्या एकत्रीकरणाने वितरण सुलभ केले. त्याने ते इतके सोपे केले की डेव्हलपरला आउटसोर्स डिलिव्हरी करणे शक्य झाले - deployment.yaml म्हणजे काय. कंटेनरायझेशन समस्या सोडवते. आणि CI/CD सिस्टीमची परिपक्वता आधीच एक फाईल लिहिण्याच्या पातळीवर आहे आणि आम्ही पुढे जातो - विकासक ते स्वतः हाताळू शकतात. आणि मग आपण स्वतःचे SRE कसे बनवू शकतो याबद्दल बोलू लागतो,...किंवा किमान कोणाशी तरी.

SRE Google वर नाही

ठीक आहे, आम्ही वितरण केले, असे दिसते की आम्ही श्वास सोडू शकतो, जुन्या चांगल्या दिवसांकडे परत जाऊ शकतो, जेव्हा प्रशासकांनी प्रोसेसर लोड पाहिला, सिस्टम ट्यून केले आणि शांतपणे आणि शांततेने मग मधून काहीतरी अनाकलनीय पिळले... थांबा. म्हणूनच आम्ही सर्वकाही सुरू केले नाही (जे एक खेदाची गोष्ट आहे!). अचानक असे दिसून आले की Google च्या दृष्टीकोनातून आपण सहजपणे उत्कृष्ट पद्धती स्वीकारू शकतो - हे प्रोसेसर लोड महत्त्वाचे नाही आणि आम्ही तेथे किती वेळा डिस्क बदलतो किंवा क्लाउडमध्ये किंमत ऑप्टिमाइझ करतो हे महत्त्वाचे नाही, परंतु व्यवसाय मेट्रिक्स समान बदनाम आहेत. SLx. आणि कोणीही त्यांच्याकडून इन्फ्रास्ट्रक्चर मॅनेजमेंट काढून टाकले नाही, आणि त्यांना घटनांचे निराकरण करणे आवश्यक आहे, आणि वेळोवेळी कर्तव्यावर असणे आवश्यक आहे आणि सामान्यतः व्यवसाय प्रक्रियेच्या शीर्षस्थानी राहणे आवश्यक आहे. आणि मित्रांनो, एका चांगल्या स्तरावर हळूहळू प्रोग्रामिंग सुरू करा, Google आधीच तुमची वाट पाहत आहे.

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

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