डिकोडिंग वेबिनार "SRE - प्रचार या भविष्य?"

वेबिनार की आवाज खराब है, इसलिए हमने इसे डिक्रिप्ट किया।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .

: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .

, , . , SRE , , . , , . , , , , , , .

, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .

. , - , , Objectives, , 3 .

, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .

3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .

, , , , , . , . . . . . , .

, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.

, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .

, , , . - , - . SRE, -, , . , , , .

. , , , , , , . . , . canary, , , , - , , , . , , , , .

SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .

. - . , SRE . , , . , , , , , , . SRE.

SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .

2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.

: SRE as a life choice

, . , - . , , . . .
.

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