वेबिनार का ट्रांसक्रिप्शन "एसआरई - प्रचार या भविष्य?"

वेबिनार में खराब ऑडियो है, इसलिए हमने एक प्रतिलेख बनाया।

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

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

समस्या यह है कि हमारे पास DevOps की स्पष्ट परिभाषा और DevOps का स्पष्ट कार्यान्वयन नहीं है। मैंने 2 साल पहले येकातेरिनबर्ग में एक सम्मेलन में बात की थी, और अब तक DevOps अनुभाग "DevOps क्या है" रिपोर्ट के साथ शुरू हुआ था। 2017 में, डेपॉप्स लगभग 10 साल पुराना है, लेकिन हम अभी भी इस पर बहस कर रहे हैं कि यह क्या है। और यह एक बहुत ही अजीब स्थिति है जिसे Google ने कुछ साल पहले हल करने का प्रयास किया था।

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

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

वे पूछते हैं कि क्या एसआरई और डेवोप्स के बीच अंतर का वर्णन किया जाएगा। उसका अभी वर्णन किया गया है। हम संगठन में एसआरई के स्थान के बारे में बात कर सकते हैं। इस क्लासिक DevOps दृष्टिकोण के विपरीत, जहां Ops अभी भी एक अलग विभाग है, SRE विकास टीम का हिस्सा है। वे उत्पाद विकास में शामिल हैं। यहां तक ​​कि एक दृष्टिकोण भी है जहां एसआरई एक भूमिका है जो एक डेवलपर से दूसरे डेवलपर तक जाती है। वे कोड समीक्षाओं में उसी तरह भाग लेते हैं, जैसे, उदाहरण के लिए, यूएक्स डिजाइनर, स्वयं डेवलपर्स, कभी-कभी उत्पाद प्रबंधक। एसआरई इसी स्तर पर काम करते हैं। हमें उन्हें स्वीकृत करने की आवश्यकता है, हमें उनकी समीक्षा करने की आवश्यकता है, ताकि प्रत्येक तैनाती के लिए एसआरई कहे: "ठीक है, यह तैनाती, यह उत्पाद विश्वसनीयता को नकारात्मक रूप से प्रभावित नहीं करेगा। और यदि ऐसा होता है, तो यह कुछ स्वीकार्य सीमाओं के भीतर होगा।” हम इस बारे में भी बात करेंगे.

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

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

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

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

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

निःसंदेह, यह सब ग़लत है। और व्यवहार में ये लोग अक्सर इस तरह के कोड से आहत होते हैं, क्योंकि चीजें टूट जाती हैं। चीज़ें कभी-कभी सबसे अप्रत्याशित तरीके से टूटती हैं। कई बार लोग कहते हैं कि नहीं, ऐसा कभी नहीं होगा. और यह अभी भी होता है. अक्सर होता है. और यही कारण है कि कोई भी कभी भी 100% उपलब्धता के लिए प्रयास नहीं करता है, क्योंकि 100% उपलब्धता कभी नहीं होती है। यह आदर्श है. और इसलिए, जब हम किसी सेवा की उपलब्धता के बारे में बात करते हैं, तो हम हमेशा नौ के बारे में बात करते हैं। 2 नौ, 3 नौ, 4 नौ, 5 नौ। यदि हम इसे डाउनटाइम समय में अनुवादित करते हैं, तो, उदाहरण के लिए, 5 नाइन प्रति वर्ष 5 मिनट के डाउनटाइम से थोड़ा अधिक है, 2 नाइन 3,5 दिन का डाउनटाइम है।

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

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

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

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

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

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

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

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

आदर्श रूप से, एसआरई को अपना काम लगभग पूरी तरह से स्वचालित करना चाहिए, क्योंकि यह सीधे एमटीटीआर, इसके मेट्रिक्स, संपूर्ण सेवा के एसएलओ और, तदनुसार, व्यावसायिक लाभ को प्रभावित करता है। यदि समय अधिक हो जाता है, तो हमसे पूछा जाता है कि क्या दोष एसआरई का है। सौभाग्य से, दोष किसी पर नहीं मढ़ा गया है। और यह एक अलग संस्कृति है जिसे बाल्मलेस पोस्टमॉर्टम कहा जाता है, जिसके बारे में हम आज बात नहीं करेंगे, लेकिन हम स्लम पर इसका विश्लेषण करेंगे। यह बहुत दिलचस्प विषय है जिस पर खूब बात की जा सकती है. मोटे तौर पर कहें तो, यदि प्रति तिमाही आवंटित समय पार हो जाता है, तो थोड़ा-थोड़ा हर किसी को दोषी ठहराया जाता है, जिसका अर्थ है कि हर किसी को दोष देना उत्पादक नहीं है, आइए इसके बजाय, शायद किसी को भी दोष न दें, लेकिन स्थिति को सुधारें और जो हमारे पास है उसके साथ काम करें। मेरे अनुभव में, यह दृष्टिकोण ज्यादातर टीमों के लिए थोड़ा अलग है, खासकर रूस में, लेकिन यह समझ में आता है और बहुत अच्छी तरह से काम करता है। इसलिए, मैं लेख और साहित्य के अंत में अनुशंसा करूंगा कि आप इस विषय पर पढ़ सकें। या स्लम एसआरई में आएं।

मुझे समझाने दो। यदि प्रति तिमाही एसएलओ समय पार हो गया है, यदि डाउनटाइम 13 मिनट नहीं, बल्कि 15 था, तो इसके लिए किसे दोषी ठहराया जा सकता है? निःसंदेह, एसआरई को दोष दिया जा सकता है, क्योंकि उसने स्पष्ट रूप से किसी प्रकार की खराब प्रतिबद्धता या तैनाती की है। इसके लिए डेटा सेंटर का व्यवस्थापक दोषी हो सकता है, क्योंकि हो सकता है कि उसने किसी प्रकार का अनिर्धारित रखरखाव किया हो। यदि डेटा सेंटर का प्रशासक इसके लिए दोषी है, तो ऑप्स का वह व्यक्ति इसके लिए दोषी है, जिसने एसएलओ का समन्वय करते समय रखरखाव की गणना नहीं की थी। प्रबंधक, तकनीकी निदेशक या कोई व्यक्ति जिसने डेटा सेंटर अनुबंध पर हस्ताक्षर किए और इस तथ्य पर ध्यान नहीं दिया कि डेटा सेंटर का एसएलए आवश्यक डाउनटाइम के लिए डिज़ाइन नहीं किया गया है, इसके लिए दोषी है। तदनुसार, इस स्थिति में धीरे-धीरे सभी दोषी हैं। और इसका मतलब यह है कि इस स्थिति में किसी पर दोष मढ़ने का कोई मतलब नहीं है। लेकिन निःसंदेह इसे ठीक करने की जरूरत है। इसीलिए तो पोस्टमॉर्टम होते हैं. और यदि आप पढ़ते हैं, उदाहरण के लिए, GitHub पोस्टमॉर्टम, और यह हमेशा प्रत्येक विशिष्ट मामले में एक बहुत ही दिलचस्प, छोटी और अप्रत्याशित कहानी होती है, तो आप यह बदल सकते हैं कि कोई भी कभी नहीं कहता कि यह विशेष व्यक्ति दोषी था। दोष सदैव विशिष्ट अपूर्ण प्रक्रियाओं पर मढ़ा जाता है।

आइए अगले प्रश्न पर चलते हैं। स्वचालन। मैं आमतौर पर, जब मैं अन्य संदर्भों में स्वचालन के बारे में बात करता हूं, तो अक्सर एक तालिका का उल्लेख करता हूं जो बताती है कि आप किसी कार्य को स्वचालित करने पर कितने समय तक काम कर सकते हैं ताकि इसे स्वचालित करने में आपके द्वारा आमतौर पर बचाए जाने से अधिक समय न लगे। एक रोड़ा है. समस्या यह है कि जब एसआरई किसी कार्य को स्वचालित करते हैं, तो वे न केवल समय बचाते हैं, बल्कि पैसे भी बचाते हैं क्योंकि स्वचालन सीधे एमटीटीआर को प्रभावित करता है। वे कर्मचारियों और डेवलपर्स के मनोबल को बचाते हैं, जो कि एक संपूर्ण संसाधन भी है। वे दिनचर्या कम कर देते हैं. और इन सबका काम पर सकारात्मक प्रभाव पड़ता है और परिणामस्वरूप, व्यवसाय पर, भले ही ऐसा लगता है कि समय की लागत के संदर्भ में स्वचालन का कोई मतलब नहीं है।

वास्तव में, यह लगभग हमेशा होता है, और ऐसे बहुत कम मामले होते हैं जहां एसआरई की भूमिका में किसी चीज़ को स्वचालित नहीं किया जाना चाहिए। आगे हम बात करेंगे कि त्रुटि बजट किसे कहते हैं, त्रुटियों के लिए बजट। वास्तव में, यह पता चला है कि यदि आपके लिए सब कुछ आपके द्वारा निर्धारित एसएलओ से कहीं बेहतर है, तो यह भी बहुत अच्छा नहीं है। यह काफी बुरा है, क्योंकि एसएलओ न केवल निचली सीमा के रूप में काम करता है, बल्कि अनुमानित ऊपरी सीमा के रूप में भी काम करता है। जब आप अपने लिए 99% उपलब्धता का एसएलओ निर्धारित करते हैं, और वास्तव में आपके पास 99,99% है, तो यह पता चलता है कि आपके पास प्रयोगों के लिए कुछ जगह है जो व्यवसाय को बिल्कुल भी नुकसान नहीं पहुंचाएगी, क्योंकि आपने स्वयं यह सब एक साथ निर्धारित किया है, और आप हैं इस स्थान का उपयोग न करें. आपके पास गलतियों के लिए एक बजट है जिसे आपके मामले में खर्च नहीं किया जाता है।

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

यही है, यह पता चला है कि यदि सेवा स्वयं अच्छी तरह से काम नहीं करती है, और एसएलओ खर्च किया जाता है और बजट प्रयोगों पर नहीं, किसी रिलीज पर नहीं, बल्कि अपने दम पर खर्च किया जाता है, तो कुछ दिलचस्प सुधारों के बजाय, दिलचस्प दिलचस्प रिलीज़ के बजाय सुविधाएँ। कोई भी रचनात्मक कार्य करने के बजाय, आपको बजट को वापस व्यवस्थित करने के लिए मूर्खतापूर्ण सुधार करने होंगे, या एसएलओ को संपादित करना होगा, और यह भी एक ऐसी प्रक्रिया है जो बहुत बार नहीं होनी चाहिए।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SRE टूल्स के बारे में एक प्रश्न था। अर्थात्, क्या ऐसी कोई विशिष्ट चीज़ है जिसका उपयोग एसआरई करेंगे जिसका उपयोग अन्य सभी नहीं करेंगे? वास्तव में, कुछ अत्यधिक विशिष्ट उपयोगिताएँ हैं, कुछ सॉफ़्टवेयर हैं जो, उदाहरण के लिए, लोड का अनुकरण करते हैं या कैनरी ए/बी परीक्षण करते हैं। लेकिन मूल रूप से एसआरई टूलकिट वह है जो आपके डेवलपर्स पहले से ही उपयोग कर रहे हैं। क्योंकि SRE सीधे विकास टीम के साथ बातचीत करता है। और यदि आपके पास अलग-अलग उपकरण हैं, तो यह पता चलता है कि सिंक्रनाइज़ होने में समय लगता है। विशेष रूप से यदि एसआरई बड़ी टीमों में काम करते हैं, बड़ी कंपनियों में जहां कई टीमें हो सकती हैं, तो कंपनी-व्यापी मानकीकरण यहां बहुत मददगार होगा, क्योंकि यदि 50 टीमें 50 अलग-अलग उपयोगिताओं का उपयोग करती हैं, तो इसका मतलब है कि एसआरई को उन सभी को जानना होगा। और निःसंदेह ऐसा कभी नहीं होगा. और काम की गुणवत्ता, कम से कम कुछ टीमों के नियंत्रण की गुणवत्ता में काफी कमी आएगी।

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

स्लम एसआरई एक तीन दिवसीय गहन पाठ्यक्रम है जो उस बारे में बात करेगा जिसके बारे में मैं अब बात कर रहा हूं, लेकिन बहुत अधिक गहराई के साथ, वास्तविक मामलों के साथ, अभ्यास के साथ, संपूर्ण गहनता का उद्देश्य व्यावहारिक कार्य है। लोगों को टीमों में बांटा जाएगा. आप सभी वास्तविक मामलों पर काम कर रहे होंगे। तदनुसार, हमारे पास बुकिंग.कॉम इवान क्रुग्लोव और बेन टायलर के प्रशिक्षक हैं। हमारे पास सैन फ़्रांसिस्को से Google का एक अद्भुत एवगेनी वरब्बास है। और मैं तुम्हें भी कुछ बताऊंगा. इसलिए हमसे मिलने अवश्य आएं।
तो, संदर्भों की एक सूची। एसआरई पर लिंक हैं. पहले उसी किताब पर, या यूं कहें कि Google द्वारा SRE के बारे में लिखी गई दो किताबों पर। दूसरा एसएलए, एसएलआई, एसएलओ पर छोटा लेख, जहां शर्तों और उनके अनुप्रयोग को थोड़ा और विस्तार से समझाया गया है। अगली 3 विभिन्न कंपनियों में एसआरई पर रिपोर्ट हैं। पहला - एसआरई की कुंजी, यह Google के बेन ट्रेनर का मुख्य भाषण है। दूसरा - ड्रॉपबॉक्स पर एसआरई. तीसरे के बारे में फिर से है Google को SRE. से चौथी रिपोर्ट नेटफ्लिक्स पर एसआरईजिसके 5 देशों में केवल 190 प्रमुख एसआरई कर्मचारी हैं। यह सब देखना बहुत दिलचस्प है, क्योंकि जिस तरह अलग-अलग कंपनियों और यहां तक ​​कि अलग-अलग टीमों के लिए DevOps का मतलब बहुत अलग होता है, उसी तरह SRE की जिम्मेदारियां भी अलग-अलग होती हैं, यहां तक ​​कि समान आकार की कंपनियों में भी।

कैओस इंजीनियरिंग के सिद्धांतों पर 2 और लिंक: (1), (2). और अंत में विस्मयकारी सूचियाँ श्रृंखला से 3 सूचियाँ हैं अराजकता इंजीनियरिंग, के बारे में एसआरई और के बारे में एसआरई टूलकिट. एसआरई पर सूची अविश्वसनीय रूप से बहुत बड़ी है, सभी को पढ़ना आवश्यक नहीं है, इसमें लगभग 200 लेख हैं। मैं क्षमता नियोजन और दोषरहित पोस्टमॉर्टम के बारे में वहां के लेखों की अत्यधिक अनुशंसा करता हूं।

दिलचस्प लेख: जीवन विकल्प के रूप में एसआरई

इतने समय तक मेरी बात सुनने के लिए धन्यवाद। मुझे आशा है कि आपने कुछ सीखा होगा। मुझे आशा है कि आपके पास और भी अधिक सीखने के लिए पर्याप्त सामग्री होगी। और आप देखे। उम्मीद है फरवरी में.
वेबिनार की मेजबानी एडुआर्ड मेदवेदेव ने की थी।

पुनश्च: जो लोग पढ़ना पसंद करते हैं, उनके लिए एडवर्ड ने संदर्भों की एक सूची प्रदान की है। जो लोग इसे व्यवहार में समझना पसंद करते हैं उनका यहां स्वागत है स्लर्मे एसआरई.

स्रोत: www.habr.com