फेरि एक पटक DevOps र SRE को बारेमा

च्याट छलफलमा आधारित AWS मिन्स्क समुदाय

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

प्रागितिहास

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

DevOps अभ्यासहरूको जन्म

त्यसपछि गम्भीर केटाहरू आएर भने– यो उद्योग होइन, यसरी काम गर्न मिल्दैन । र तिनीहरूले जीवन चक्र मोडेलहरू ल्याए। यहाँ, उदाहरण को लागी, V-मोडेल छ।

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

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

र तिनीहरूले तिनीहरूलाई DevOps अभ्यासहरू कल गर्ने निर्णय गरे - मलाई लाग्छ कि तिनीहरूको मतलब विकासदेखि सञ्चालनसम्म थियो। हामीले विभिन्न चतुर चीजहरू लिएर आएका छौं - CI/CD अभ्यासहरू, IaC सिद्धान्तमा आधारित अभ्यासहरू, ती हजारौं। र हामी जान्छौं, विकासकर्ताहरूले कोड लेख्छन्, DevOps ईन्जिनियरहरूले प्रणालीको विवरणलाई कोडको रूपमा कार्य प्रणालीमा रूपान्तरण गर्छन् (हो, कोड, दुर्भाग्यवश, केवल एक विवरण हो, तर प्रणालीको अवतार होइन), वितरण जारी छ, र यस्तै। हिजोका प्रशासकहरू, नयाँ अभ्यासहरूमा महारत हासिल गर्दै, गर्वका साथ DevOps इन्जिनियरहरूको रूपमा पुन: प्रशिक्षित भए, र सबै कुरा त्यहाँबाट गयो। र त्यहाँ साँझ थियो, र त्यहाँ बिहान थियो ... माफ गर्नुहोस्, त्यहाँबाट होइन।

यो सबै फेरि राम्रो छैन, भगवानलाई धन्यवाद

सबै कुरा शान्त हुने बित्तिकै, र विभिन्न चालाक "विधिविद्हरू" ले DevOps अभ्यासहरूमा मोटा पुस्तकहरू लेख्न थाले, कुख्यात DevOps ईन्जिनियर को हो भन्ने बारे विवाद चुपचाप भड्कियो र DevOps उत्पादन संस्कृति हो, असन्तुष्टि फेरि उठ्यो। अचानक यो बाहिर निस्कियो कि सफ्टवेयर वितरण एक बिल्कुल गैर-तुच्छ कार्य हो। प्रत्येक विकास पूर्वाधारको आ-आफ्नै स्ट्याक हुन्छ, कतै तपाईंले यसलाई भेला गर्न आवश्यक छ, कतै तपाईंले वातावरण प्रयोग गर्न आवश्यक छ, यहाँ तपाईंलाई Tomcat चाहिन्छ, यहाँ तपाईंलाई यसलाई सुरु गर्न एक चालाक र जटिल तरिका चाहिन्छ - सामान्यतया, तपाईंको टाउको धड्किरहेको छ। र समस्या, अनौठो रूपमा पर्याप्त, मुख्य रूपमा प्रक्रियाहरूको संगठनमा देखा पर्‍यो - यो डेलिभरी प्रकार्य, अवरोध जस्तै, प्रक्रियाहरू रोक्न थाल्यो। थप रूपमा, कसैले पनि सञ्चालनहरू रद्द गरेनन्। यो V-model मा देखिने छैन, तर अझै पनि दाँयामा सम्पूर्ण जीवन चक्र छ। नतिजाको रूपमा, यो कुनै न कुनै रूपमा पूर्वाधारको मर्मत, अनुगमन अनुगमन, घटनाहरू समाधान गर्न, र डेलिभरीको पनि व्यवहार गर्न आवश्यक छ। ती। विकास र सञ्चालन दुवैमा एक खुट्टा राखेर बस्नुहोस् - र अचानक यो विकास र सञ्चालन भयो। र त्यसपछि त्यहाँ माइक्रोसेवाहरूको लागि सामान्य प्रचार थियो। र तिनीहरूसँग, स्थानीय मेसिनहरूबाट विकास क्लाउडमा सार्न थाल्यो - स्थानीय रूपमा केहि डिबग गर्ने प्रयास गर्नुहोस्, यदि त्यहाँ दर्जनौं र सयौं माइक्रोसर्भिसेसहरू छन् भने, त्यसपछि निरन्तर डेलिभरी बाँच्ने माध्यम बन्छ। एक "सानो मामूली कम्पनी" को लागी यो सबै ठीक थियो, तर अझै पनि? गुगलको बारेमा के हो?

Google द्वारा SRE

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

DevOps विचारहरूको विकास

ठीक त्यसपछि डकर आइपुग्यो, जुन lxc बाट बढ्यो, र त्यसपछि विभिन्न आर्केस्ट्रेशन प्रणालीहरू जस्तै डकर स्वार्म र कुबर्नेट्स, र DevOps इन्जिनियरहरूले श्वास छोडे - अभ्यासहरूको एकीकरणले वितरणलाई सरल बनायो। यसले यसलाई यति हदसम्म सरल बनायो कि विकासकर्ताहरूलाई आउटसोर्स डेलिभरी गर्न सम्भव भयो - deployment.yaml भनेको के हो। कन्टेनराइजेशनले समस्या समाधान गर्छ। र CI/CD प्रणालीहरूको परिपक्वता पहिले नै एउटा फाइल लेख्ने स्तरमा छ र हामी जान्छौं - विकासकर्ताहरूले यसलाई आफैं ह्यान्डल गर्न सक्छन्। र त्यसपछि हामी कसरी हाम्रो आफ्नै SRE बनाउन सक्छौं, वा कम्तिमा कसैसँग कुरा गर्न थाल्छौं।

SRE Google मा छैन

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

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

स्रोत: www.habr.com