वेबिनारको ट्रान्सक्रिप्शन "SRE - हाइप वा भविष्य?"

वेबिनारमा कमजोर अडियो छ, त्यसैले हामीले यसलाई ट्रान्सक्राइब गरेका छौं।

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

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

समस्या यो हो कि हामीसँग DevOps को स्पष्ट परिभाषा र DevOps को स्पष्ट कार्यान्वयन छैन। मैले 2 वर्ष पहिले येकातेरिनबर्गको सम्मेलनमा बोलेको थिएँ, र अहिले सम्म DevOps खण्ड "DevOps के हो" रिपोर्टको साथ सुरु भयो। 2017 मा, Devops लगभग 10 वर्ष पुरानो छ, तर हामी अझै पनि यो के हो बहस गर्दैछौं। र यो एक धेरै अनौठो स्थिति हो जुन गुगलले केहि वर्ष पहिले समाधान गर्ने प्रयास गर्यो।

2016 मा, Google ले Site Reliability Engineering नामक पुस्तक जारी गर्‍यो। र वास्तवमा, यो पुस्तक संग थियो कि SRE आन्दोलन सुरु भयो। SRE एक विशिष्ट कम्पनी मा DevOps प्रतिमान को एक विशिष्ट कार्यान्वयन हो। SRE इन्जिनियरहरू यो सुनिश्चित गर्न प्रतिबद्ध छन् कि प्रणालीहरू विश्वसनीय रूपमा सञ्चालन हुन्छन्। तिनीहरू प्रायः विकासकर्ताहरूबाट आउँछन्, कहिलेकाहीँ बलियो विकास पृष्ठभूमि भएका प्रशासकहरू। र तिनीहरूले प्रणाली प्रशासकहरूले गरे जस्तै गर्छन्, तर कोडको सन्दर्भमा प्रणालीको विकास र ज्ञानको बलियो पृष्ठभूमिले यो तथ्यलाई निम्त्याउँछ कि यी व्यक्तिहरू नियमित प्रशासनिक काममा झुकाव छैनन्, तर स्वचालनमा झुकाव छन्।

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

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

तदनुसार, SRE सँग कोड परिवर्तन गर्न भिटो छ। र सामान्यतया, यसले कुनै प्रकारको सानो द्वन्द्व पनि निम्त्याउँछ यदि SRE गलत रूपमा लागू गरिएको छ। साइट रिलायबिलिटी इन्जिनियरिङको बारेमा एउटै पुस्तकमा, धेरै भागहरू, एक पनि होइन, यी विवादहरूबाट कसरी बच्ने भनेर बताउनुहोस्।

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

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

प्रश्न यो हो कि टोलीमा धेरै ज्ञान भएको एक ईन्जिनियर, प्रणाली प्रशासकलाई मात्र किन नराख्ने। ईन्जिनियरको भूमिकामा विकासकर्ता, हामीलाई भनिएको छ, उत्तम कर्मचारी समाधान होइन। एक इन्जिनियरको भूमिकामा विकासकर्ता सधैं राम्रो स्टाफिंग समाधान होइन, तर यहाँ कुरा यो हो कि Ops मा संलग्न विकासकर्तालाई स्वचालनको लागि अलि बढी चाहना हुन्छ, अलि बढी ज्ञान र कार्यान्वयन गर्नको लागि एक सीप सेट हुन्छ। यो स्वचालन। र तदनुसार, हामीले केही विशिष्ट कार्यहरूका लागि समय मात्र घटाउँदैन, दिनचर्या मात्र होइन, MTTR (Mean Time To Recovery, Recovery time) जस्ता महत्त्वपूर्ण व्यापारिक मापदण्डहरू पनि घटाउँछौं। यसैले, र हामी यस बारे केहि पछि कुरा गर्नेछौं, हामी संस्थाको लागि पैसा बचत गर्छौं।

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

यो सबै गलत हो, अवश्य पनि। र यी मानिसहरू प्रायः व्यवहारमा यस्तो कोडले काट्छन्, किनभने चीजहरू बिग्रन्छ। चीजहरू कहिलेकाहीँ सबैभन्दा अप्रत्याशित तरिकामा टुट्छन्। कहिलेकाहीँ मानिसहरू भन्छन्, यो कहिल्यै हुँदैन। र यो सबै समय हुन्छ। यो अक्सर पर्याप्त हुन्छ। र त्यसैले कसैले पनि 100% उपलब्धताको लागि प्रयास गर्दैन, किनकि 100% उपलब्धता कहिल्यै हुँदैन। यो नियम हो। र त्यसकारण, जब हामी सेवाको उपलब्धताको बारेमा कुरा गर्छौं, हामी सधैं नाइनहरूको बारेमा कुरा गर्छौं। 2 नौ, 3 नौ, 4 नौ, 5 नौ। यदि हामीले यसलाई डाउनटाइममा अनुवाद गर्छौं भने, उदाहरणका लागि, ५ नाइन्स, त्यसपछि यो प्रति वर्ष ५ मिनेटको डाउनटाइम भन्दा अलि बढी हो, २ नाइन भनेको ३.५ दिनको डाउनटाइम हो।

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

यहाँ एउटा महत्त्वपूर्ण प्रश्न बाँकी घटकहरूको विश्वसनीयता के हो। किनभने 4 र 5 नाइन बीचको भिन्नता 2 नाइन विश्वसनीयता भएको स्मार्टफोनमा देखिने छैन। सामान्य रूपमा भन्नुपर्दा, यदि तपाइँको सेवामा स्मार्टफोनमा वर्षमा 10 पटक केहि बिग्रन्छ भने, सम्भवतः 8 पटक OS साइडमा ब्रेकडाउन भएको छ। प्रयोगकर्ता यसलाई प्रयोग गरिएको छ, र वर्षमा एक पटक थप ध्यान दिनुहुन्न। बढ्दो विश्वसनीयता र बढ्दो नाफाको मूल्यलाई जोड्न आवश्यक छ।
SRE को पुस्तकमा मात्र 4 बाट 3 नाइनमा बढेको राम्रो उदाहरण छ। यो उपलब्धता मा वृद्धि 0,1% भन्दा अलि कम छ भनेर बाहिर जान्छ। र यदि सेवाको राजस्व एक वर्षमा $ 1 मिलियन छ भने, राजस्वमा वृद्धि $ 900 हो। यदि यसले हामीलाई नौले किफायती क्षमता बढाउन एक वर्षमा $ 900 भन्दा कम खर्च गर्छ भने, वृद्धिले आर्थिक अर्थ राख्छ। यदि यो एक वर्षमा 900 डलर भन्दा बढी खर्च हुन्छ भने, यसले अब कुनै अर्थ राख्दैन, किनभने राजस्वमा वृद्धिले मात्र श्रम लागत, स्रोत लागतको लागि क्षतिपूर्ति गर्दैन। र 3 नाइनहरू हाम्रो लागि पर्याप्त हुनेछ।

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

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

मानौं SLA यस्तो हुन सक्छ। सेवा वर्षभरि 99,95% समय उपलब्ध छ। वा 99 महत्वपूर्ण समर्थन टिकटहरू प्रति क्वार्टर 3 घण्टा भित्र बन्द हुनेछन्। वा 85% अनुरोधहरू प्रत्येक महिना 1,5 सेकेन्ड भित्र जवाफ दिइनेछ। अर्थात्, हामी बिस्तारै बुझ्छौं कि त्रुटि र विफलता एकदम सामान्य छन्। यो एक स्वीकार्य अवस्था हो, हामी यसलाई योजना गर्दैछौं, हामी यसलाई केहि हदसम्म गणना गर्दैछौं। त्यो हो, SRE ले गल्तीहरू गर्न सक्ने प्रणालीहरू बनाउँछ, जसले त्रुटिहरूलाई सामान्य रूपमा प्रतिक्रिया दिनुपर्दछ, जसले तिनीहरूलाई ध्यानमा राख्नुपर्दछ। र जबसम्म सम्भव हुन्छ, तिनीहरूले त्रुटिहरू यसरी ह्यान्डल गर्नुपर्छ कि प्रयोगकर्ताले तिनीहरूलाई याद गर्दैन, वा सूचनाहरू, तर त्यहाँ केहि प्रकारको समाधान छ, जसको लागि सबै कुरा पूर्ण रूपमा खस्नेछैन।

उदाहरण को लागी, यदि तपाइँ YouTube मा भिडियो अपलोड गर्नुहुन्छ, र YouTube ले तुरुन्तै रूपान्तरण गर्न सक्दैन, यदि भिडियो धेरै ठूलो छ भने, यदि ढाँचा इष्टतम छैन भने, अनुरोध स्वाभाविक रूपमा टाइमआउट संग असफल हुनेछैन, YouTube ले 502 त्रुटि दिनेछैन। , YouTube ले भन्‍नेछ: “हामीले सबै कुरा सिर्जना गरेका छौं, तपाईंको भिडियो प्रशोधन भइरहेको छ। यो लगभग 10 मिनेटमा तयार हुनेछ।" यो ग्रेसफुल डिग्रेडेसनको सिद्धान्त हो, जुन परिचित छ, उदाहरणका लागि, फ्रन्ट-एन्ड विकासबाट, यदि तपाईंले कहिल्यै यो गर्नुभयो भने।

अर्को सर्तहरू जुन हामीले कुरा गर्नेछौं, जुन विश्वसनीयताका साथ काम गर्नका लागि धेरै महत्त्वपूर्ण छन्, त्रुटिहरू, अपेक्षाहरू सहित, MTBF र MTTR हुन्। MTBF असफलताहरू बीचको औसत समय हो। MTTR रिकभरी को लागि औसत समय, रिकभरी को लागी औसत समय। अर्थात्, त्रुटि पत्ता लागेको क्षणदेखि सेवा पूर्ण सामान्य सञ्चालनमा पुनर्स्थापित भएको क्षणदेखि त्रुटि देखा परेको क्षणसम्म कति समय बितिसकेको छ। MTBF मुख्यतया कोड गुणस्तर मा काम द्वारा निश्चित छ। त्यो हो, तथ्य यो हो कि SRE ले "होइन" भन्न सक्छ। र तपाईलाई सम्पूर्ण टोलीको बुझाइ चाहिन्छ कि जब SRE ले "होइन" भन्छ, उसले यो भन्छ किनभने ऊ हानिकारक छ, होइन किनभने ऊ खराब छ, तर किनभने अन्यथा सबैले दुःख पाउनेछन्।

फेरि, त्यहाँ धेरै लेखहरू छन्, धेरै विधिहरू छन्, धेरै तरिकाहरू छन् जुन धेरै पुस्तकमा पनि मैले प्रायः सन्दर्भ गर्दछु, कसरी सुनिश्चित गर्ने कि अन्य विकासकर्ताहरूले SRE घृणा गर्न थालेनन्। MTTR, अर्कोतर्फ, तपाईंको SLOs (सेवा स्तर उद्देश्य) मा काम गर्ने बारे हो। र यो प्राय: स्वचालन हो। किनभने, उदाहरणका लागि, हाम्रो SLO प्रति क्वार्टर 4 नाइनको अपटाइम हो। यसको मतलब 3 महिनामा हामी 13 मिनेट डाउनटाइम अनुमति दिन सक्छौं। र यो बाहिर जान्छ कि MTTR 13 मिनेट भन्दा बढी हुन सक्दैन। यदि हामीले 13 मिनेटमा कम्तिमा 1 डाउनटाइममा प्रतिक्रिया दियौं भने, यसको मतलब हामीले त्रैमासिकको लागि सम्पूर्ण बजेट पहिले नै समाप्त गरिसकेका छौं। हामी SLO तोड्दै छौं। 13 मिनेट प्रतिक्रिया गर्न र दुर्घटना समाधान गर्न एक मेसिन को लागी धेरै छ, तर मानव को लागी धेरै छोटो छ। किनभने जबसम्म एक व्यक्तिले चेतावनी प्राप्त गर्दैन, जबसम्म उसले प्रतिक्रिया गर्दैन, जबसम्म उसले त्रुटि बुझ्दैन, यो पहिले नै धेरै मिनेट हो। जबसम्म एक व्यक्तिले यसलाई कसरी ठीक गर्ने, के ठीक गर्ने, के गर्ने भन्ने बुझ्दैन, त्यसपछि यो केहि मिनेट हो। र वास्तवमा, यदि तपाइँ भर्खर सर्भर पुन: सुरु गर्न आवश्यक छ भने, यो बाहिर जान्छ, वा नयाँ नोड उठाउनुहोस्, त्यसपछि मैन्युअल रूपमा MTTR पहिले नै 7-8 मिनेटको छ। प्रक्रिया स्वचालित गर्दा, MTTR धेरै पटक एक सेकेन्ड, कहिलेकाहीं मिलिसेकेन्ड पुग्छ। गुगलले सामान्यतया मिलिसेकेन्डको बारेमा कुरा गर्छ, तर वास्तवमा, निस्सन्देह, सबै कुरा यति राम्रो छैन।

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

मलाई बयान गर्न देउ। यदि प्रति त्रैमासिक SLO समय नाघेको छ, यदि डाउनटाइम 13 मिनेट होइन, तर 15 थियो, यसको लागि को दोषी हुन सक्छ? निस्सन्देह, SRE दोषी हुन सक्छ, किनभने उसले स्पष्ट रूपमा कुनै प्रकारको खराब प्रतिबद्धता वा तैनाती गरेको थियो। यसका लागि डाटा सेन्टरको प्रशासक दोषी हुन सक्छ, किनभने उसले कुनै प्रकारको अनुसूचित मर्मत सम्भार गरेको हुन सक्छ। यदि डाटा सेन्टरको प्रशासक यसको लागि दोषी छ भने, Ops को व्यक्ति यसको लागि दोषी छ, जसले SLO को समन्वय गर्दा मर्मत गणना गरेन। प्रबन्धक, प्राविधिक निर्देशक वा डाटा सेन्टरको सम्झौतामा हस्ताक्षर गर्ने र डाटा सेन्टरको SLA आवश्यक डाउनटाइमको लागि डिजाइन गरिएको छैन भन्ने तथ्यमा ध्यान नदिने व्यक्ति यसको लागि दोषी हो। तदनुसार, यस अवस्थामा सबै बिस्तारै दोषी छन्। र यसको मतलब यो अवस्थामा कसैलाई दोष लगाउनुको कुनै अर्थ छैन। तर पक्कै पनि यसलाई सच्याउन आवश्यक छ। त्यही भएर पोष्टमार्टम भइरहेको छ । र यदि तपाइँ पढ्नुहुन्छ, उदाहरणका लागि, GitHub postmortems, र यो सधैं एक धेरै चाखलाग्दो, सानो र प्रत्येक मामला मा अप्रत्याशित कथा हो, तपाइँ यसलाई प्रतिस्थापन गर्न सक्नुहुन्छ कि यो विशेष व्यक्ति दोषी थियो भनेर कसैले कहिल्यै भन्न सक्दैन। दोष सधैं विशिष्ट अपूर्ण प्रक्रियाहरूमा राखिएको छ।

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

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

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

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

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

यसले उत्पादनमा प्रयोगहरू ठूला टोलीहरूमा SRE को एक महत्त्वपूर्ण र लगभग अभिन्न अंग हो भनेर बाहिर जान्छ। र यसलाई सामान्यतया अराजकता ईन्जिनियरिङ् भनिन्छ, जुन Netflix मा रहेको टोलीबाट आउँछ जसले Chaos Monkey नामक उपयोगिता जारी गर्‍यो।
Chaos Monkey CI/CD पाइपलाइनमा जडान हुन्छ र उत्पादनमा सर्भरलाई अनियमित रूपमा क्र्यास गर्छ। फेरि, SRE संरचनामा, हामी तथ्यको बारेमा कुरा गर्दैछौं कि डाउन गरिएको सर्भर आफैमा खराब छैन, यो अपेक्षित छ। र यदि यो बजेट भित्र छ भने, यो स्वीकार्य छ र व्यवसायलाई हानि गर्दैन। निस्सन्देह, Netflix सँग पर्याप्त अनावश्यक सर्भरहरू छन्, पर्याप्त प्रतिकृति, ताकि यो सबै ठीक गर्न सकिन्छ, र ताकि प्रयोगकर्ताले समग्र रूपमा ध्यान दिँदैन, र अझ बढि, कसैले कुनै पनि बजेटको लागि एक सर्भर छोड्दैन।

नेटफ्लिक्ससँग केही समयको लागि त्यस्ता उपयोगिताहरूको सम्पूर्ण सूट थियो, जसमध्ये एउटा, केओस गोरिल्लाले अमेजनको उपलब्धता क्षेत्रहरू मध्ये एकलाई पूर्ण रूपमा बन्द गर्दछ। र त्यस्ता चीजहरूले प्रकट गर्न मद्दत गर्दछ, पहिलो, लुकेको निर्भरता, जब यो पूर्ण रूपमा स्पष्ट छैन कि के असर गर्छ, के मा निर्भर गर्दछ। र यो, यदि तपाइँ माइक्रोसर्भिससँग काम गर्दै हुनुहुन्छ, र कागजात एकदम सही छैन, यो तपाइँलाई परिचित हुन सक्छ। र फेरि, यसले कोडमा त्रुटिहरू समात्न धेरै मद्दत गर्दछ जुन तपाईंले स्टेजिङमा समात्न सक्नुहुन्न, किनकि कुनै पनि स्टेजिङ ठ्याक्कै सही सिमुलेशन होइन, लोड स्केल फरक छ, लोड ढाँचा फरक छ, उपकरणहरू छन्। पनि, सम्भवतः, अन्य। शिखर भार पनि अप्रत्याशित र अप्रत्याशित हुन सक्छ। र त्यस्ता परीक्षणहरू, जुन फेरि बजेटभन्दा बाहिर जाँदैन, स्टेजिङ, अटोटेस्टहरू, CI / CD पाइपलाइनले कहिल्यै नमिल्ने पूर्वाधारमा त्रुटिहरू समात्न राम्रोसँग मद्दत गर्दछ। र जब सम्म यो सबै तपाइँको बजेट मा समावेश छ, यो केहि फरक पर्दैन कि तपाइँको सेवा त्यहाँ तल गयो, यद्यपि यो धेरै डरलाग्दो देखिन्छ, सर्भर तल गयो, कस्तो दुःस्वप्न। होइन, त्यो सामान्य हो, त्यो राम्रो छ, यसले बगहरू समात्न मद्दत गर्छ। यदि तपाइँसँग बजेट छ भने, तपाइँ यसलाई खर्च गर्न सक्नुहुन्छ।

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

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

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

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

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

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

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

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

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

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

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

त्यहाँ SRE उपकरणहरूको बारेमा प्रश्न थियो। अर्थात्, त्यहाँ केहि विशेष छ जुन SRE ले प्रयोग गर्दछ जुन अरू सबैले गर्दैनन्। वास्तवमा, त्यहाँ केहि उच्च विशिष्ट उपयोगिताहरू छन्, त्यहाँ केहि प्रकारको सफ्टवेयर छ जुन, उदाहरणका लागि, भार अनुकरण गर्दछ वा क्यानरी A / B परीक्षणमा संलग्न छ। तर मूलतः SRE टूलकिट भनेको तपाइँको विकासकर्ताहरूले पहिले नै प्रयोग गरिरहनुभएको छ। किनभने SRE ले विकास टोलीसँग प्रत्यक्ष अन्तरक्रिया गर्छ। र यदि तपाईंसँग बिभिन्न उपकरणहरू छन् भने, यसले सिङ्क्रोनाइज गर्न समय लिन्छ भनेर बाहिर जान्छ। विशेष गरी यदि SREs ले ठूला टोलीहरूमा काम गर्छ भने, ठूला कम्पनीहरूमा जहाँ धेरै टोलीहरू हुन सक्छन्, यो कम्पनी-व्यापी मानकीकरण हो जसले यहाँ धेरै मद्दत गर्नेछ, किनकि यदि 50 टोलीहरूमा 50 विभिन्न उपयोगिताहरू प्रयोग गरिन्छ, यसको मतलब यो हो कि SRE ले तिनीहरूलाई थाहा हुनुपर्छ। सबै। र पक्कै पनि यो कहिल्यै हुनेछैन। र कामको गुणस्तर, कम्तिमा केही टोलीहरूको नियन्त्रणको गुणस्तर उल्लेखनीय रूपमा घट्नेछ।

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

Slurm SRE एक तीन दिने गहन पाठ्यक्रम हो जुन मैले अहिले के कुरा गरिरहेको छु भन्ने बारेमा कुरा गर्नेछ, तर धेरै गहिराइका साथ, वास्तविक केसहरूसँग, अभ्यासको साथ, सम्पूर्ण गहन व्यावहारिक कार्यको उद्देश्य हो। मानिसहरू टोलीमा विभाजित हुनेछन्। तपाईं सबै वास्तविक केसहरूमा काम गर्नुहुनेछ। तदनुसार, हामीसँग Booking.com प्रशिक्षकहरू इभान क्रुग्लोभ र बेन टायलर छन्। हामीसँग गुगलबाट सान फ्रान्सिस्कोबाट अद्भुत यूजीन बारब्बास छ। अनि म तिमीलाई पनि केही भन्छु। त्यसैले हामीलाई भ्रमण गर्न निश्चित हुनुहोस्।
त्यसैले, ग्रन्थसूची। SRE मा सन्दर्भहरू छन्। पहिलो एउटै पुस्तकमा, वा बरु Google द्वारा लेखिएको SRE बारे २ पुस्तकहरूमा। अर्को SLA, SLI, SLO मा सानो लेख, जहाँ सर्तहरू र तिनीहरूको आवेदन थोरै विस्तृत छन्। अर्को 3 विभिन्न कम्पनीहरूमा SRE मा रिपोर्टहरू छन्। पहिलो - SRE को कुञ्जीहरू, यो गुगलको बेन ट्रेनरको मुख्य टिप्पणी हो। दोस्रो - Dropbox मा SRE। तेस्रो हो फेरि Google लाई SRE। बाट चौथो रिपोर्ट Netflix मा SRE, जसमा 5 देशहरूमा केवल 190 प्रमुख SRE कर्मचारीहरू छन्। यो सबै हेर्नको लागि यो धेरै रोचक छ, किनकि जसरी DevOps को अर्थ विभिन्न कम्पनीहरू र विभिन्न टोलीहरूका लागि धेरै फरक चीजहरू हुन्, SRE सँग समान आकारका कम्पनीहरूमा पनि धेरै फरक जिम्मेवारीहरू छन्।

अराजकता ईन्जिनियरिङ्का सिद्धान्तहरूमा 2 थप लिङ्कहरू: (1), (2)। र अन्तमा त्यहाँ श्रृंखलाबाट 3 सूचीहरू छन् अद्भुत सूचीहरू बारे अराजकता ईन्जिनियरिङ्, बारे SRE र बारे SRE टूलकिट। SRE मा सूची अविश्वसनीय रूपमा ठूलो छ, यो सबै मार्फत जान आवश्यक छैन, त्यहाँ लगभग 200 लेखहरू छन्। म त्यहाँबाट क्षमता योजना र दोषरहित पोस्टमार्टमको बारेमा लेखहरू सिफारिस गर्दछु।

चाखलाग्दो लेख: जीवन छनौटको रूपमा SRE

यो सबै समय मेरो कुरा सुन्नु भएकोमा धन्यवाद। आशा छ तपाईंले केहि सिक्नुभयो। आशा छ तपाईसँग अझै धेरै सिक्नको लागि पर्याप्त सामग्री छ। अनि भेटौला। आशा छ फेब्रुअरीमा।
वेबिनार एडुआर्ड मेदवेदेव द्वारा होस्ट गरिएको थियो।

PS: पढ्न मन पराउनेहरूका लागि, एडवार्डले सन्दर्भहरूको सूची दिए। व्यवहारमा बुझ्न रुचाउनेहरूलाई स्वागत छ Slurme SRE.

स्रोत: www.habr.com