वेबिनारचे लिप्यंतरण "एसआरई - हायप किंवा भविष्य?"

वेबिनारमध्ये खराब ऑडिओ आहे, म्हणून आम्ही एक उतारा तयार केला आहे.

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

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

समस्या अशी आहे की आमच्याकडे DevOps ची स्पष्ट व्याख्या आणि DevOps ची स्पष्ट अंमलबजावणी नाही. मी 2 वर्षांपूर्वी येकातेरिनबर्ग येथे एका परिषदेत बोललो होतो आणि आत्तापर्यंत DevOps विभाग “DevOps म्हणजे काय आहे” या अहवालाने सुरू झाला. 2017 मध्ये, डेव्हॉप्स जवळजवळ 10 वर्षांचे आहेत, परंतु आम्ही अद्याप ते काय आहे याबद्दल वाद घालत आहोत. आणि ही एक अतिशय विचित्र परिस्थिती आहे जी Google ने काही वर्षांपूर्वी सोडवण्याचा प्रयत्न केला.

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

असे दिसून आले की SRE संघांमधील DevOps प्रतिमान स्ट्रक्चरल समस्यांचे निराकरण करणारे SRE अभियंते आहेत या वस्तुस्थितीद्वारे लागू केले गेले आहे. हे आहे, देव आणि ऑप्स यांच्यातील समान कनेक्शन ज्याबद्दल लोक 8 वर्षांपासून बोलत आहेत. SRE ची भूमिका वास्तुविशारदासारखीच असते कारण नवशिक्या SRE बनत नाहीत. त्यांच्या करिअरच्या सुरुवातीस असलेल्या लोकांना अद्याप कोणताही अनुभव नाही आणि आवश्यक ज्ञानाची रुंदी नाही. कारण SRE ला नेमके काय आणि केव्हा चूक होऊ शकते याचे अत्यंत अत्याधुनिक ज्ञान आवश्यक आहे. म्हणून, नियमानुसार, कंपनीच्या आत आणि बाहेर दोन्ही ठिकाणी काही प्रकारचे अनुभव आवश्यक आहे.

ते विचारतात की SRE आणि devops मधील फरक वर्णन केला जाईल का. तिचे नुकतेच वर्णन केले आहे. संस्थेतील एसआरईच्या जागेबद्दल आपण बोलू शकतो. क्लासिक DevOps दृष्टिकोनाच्या विपरीत, जिथे Ops अजूनही एक वेगळा विभाग आहे, SRE हा विकास संघाचा भाग आहे. ते उत्पादन विकासात गुंतलेले आहेत. असा एक दृष्टीकोन देखील आहे जेथे SRE ही भूमिका आहे जी एका विकसकाकडून दुसऱ्याकडे जाते. ते कोड पुनरावलोकनांमध्ये त्याच प्रकारे भाग घेतात, उदाहरणार्थ, UX डिझाइनर, स्वतः विकासक आणि कधीकधी उत्पादन व्यवस्थापक. SREs याच स्तरावर कार्य करतात. आम्हाला त्यांच्या मंजुरीची गरज आहे, आम्हाला त्यांचे पुनरावलोकन आवश्यक आहे, जेणेकरून प्रत्येक उपयोजनासाठी SRE म्हणते: “ठीक आहे, हे उपयोजन, हे उत्पादन विश्वासार्हतेवर नकारात्मक परिणाम करणार नाही. आणि जर तसे झाले तर ते काही मान्य मर्यादेत असेल.” आपण याबद्दल देखील बोलू.

त्यानुसार, कोड बदलांवर SRE ला व्हेटो आहे. आणि सर्वसाधारणपणे, SRE चुकीच्या पद्धतीने अंमलात आणल्यास यामुळे काही लहान संघर्ष देखील होतो. साइट विश्वसनीयता अभियांत्रिकीबद्दलच्या त्याच पुस्तकात, अनेक भाग, अगदी एकापेक्षा जास्त, हे संघर्ष कसे टाळायचे ते सांगतात.

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

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

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

आता SRE कामाच्या निकषांबद्दल बोलूया. आणि सर्व प्रथम विश्वासार्हतेबद्दल. छोट्या कंपन्या आणि स्टार्टअप्समध्ये अनेकदा असे घडते की लोक असे गृहीत धरतात की जर सेवा चांगली लिहिली गेली असेल, उत्पादन चांगले आणि योग्य लिहिले असेल तर ते चालेल, ते खंडित होणार नाही. तेच आहे, आम्ही चांगले कोड लिहितो, त्यामुळे तोडण्यासारखे काहीही नाही. कोड अगदी सोपा आहे, तोडण्यासारखे काहीही नाही. हे त्याच लोकांबद्दल आहेत जे म्हणतात की आम्हाला चाचण्यांची गरज नाही, कारण पहा, या तीन व्हीपीआय पद्धती आहेत, का त्रास घ्यायचा?

हे सर्व अर्थातच चुकीचे आहे. आणि व्यवहारात या प्रकारच्या कोडमुळे हे लोक बर्‍याचदा दुखावतात, कारण गोष्टी तुटतात. गोष्टी कधीकधी सर्वात अप्रत्याशित मार्गांनी खंडित होतात. कधी कधी लोक म्हणतात ना, असं कधीच होणार नाही. आणि ते अजूनही घडते. बरेचदा घडते. आणि म्हणूनच 100% उपलब्धतेसाठी कोणीही कधीही प्रयत्न करत नाही, कारण 100% उपलब्धता कधीच होत नाही. हे प्रमाण आहे. आणि म्हणूनच जेव्हा आम्ही सेवा उपलब्धतेबद्दल बोलतो तेव्हा आम्ही नेहमी नाइनबद्दल बोलतो. २ नाई, ३ नाई, ४ नाई, ५ नाई. जर आपण याचे डाउनटाइम टाइममध्ये भाषांतर केले तर, उदाहरणार्थ, 2 नाईन्स म्हणजे प्रति वर्ष 3 मिनिटांच्या डाउनटाइमपेक्षा थोडे जास्त, 4 नाईन्स म्हणजे 5 दिवसांचा डाउनटाइम.

परंतु हे उघड आहे की काही वेळा पीओआय आणि गुंतवणुकीवर परतावा कमी होतो. दोन नाइन्सवरून तीन नाइन्सवर जाणे म्हणजे डाउनटाइम 3 दिवसांपेक्षा कमी करणे. चार नाइन ते पाच वर गेल्याने डाउनटाइम दर वर्षी 47 मिनिटांनी कमी होतो. आणि असे दिसून आले की हे व्यवसायासाठी गंभीर असू शकत नाही. आणि सर्वसाधारणपणे, आवश्यक विश्वसनीयता ही तांत्रिक समस्या नाही, सर्व प्रथम, ही एक व्यावसायिक समस्या आहे, ही एक उत्पादन समस्या आहे. उत्पादनाच्या वापरकर्त्यांसाठी कोणत्या स्तरावरील डाउनटाइम स्वीकार्य आहे, ते काय अपेक्षा करतात, ते किती पैसे देतात, उदाहरणार्थ, ते किती पैसे गमावतात, सिस्टम किती पैसे गमावते.

उर्वरित घटकांची विश्वासार्हता काय आहे हा महत्त्वाचा प्रश्न आहे. कारण 4 आणि 5 नाईनमधील फरक 2 रिलायबिलिटी नाइन असलेल्या स्मार्टफोनवर दिसणार नाही. साधारणपणे सांगायचे तर, तुमच्या सेवेतील स्मार्टफोनवर वर्षातून १० वेळा काही बिघाड झाल्यास, बहुधा OS च्या बाजूने 10 वेळा ब्रेकडाउन झाले. वापरकर्त्याला याची सवय आहे आणि वर्षातून एक अतिरिक्त वेळ त्याकडे लक्ष देणार नाही. वाढत्या विश्वासार्हता आणि वाढत्या नफ्याच्या किंमतींची तुलना करणे आवश्यक आहे.
फक्त SRE वरील पुस्तकात 4 नाइन वरून 3 नाइन पर्यंत वाढण्याचे एक चांगले उदाहरण आहे. असे दिसून आले की उपलब्धतेतील वाढ 0,1% पेक्षा किंचित कमी आहे. आणि जर सेवेचा महसूल प्रति वर्ष $1 दशलक्ष असेल, तर महसूल वाढ $900 आहे. नऊने उपलब्धता वाढवल्यास आमची किंमत प्रति वर्ष $900 पेक्षा कमी असेल, तर वाढ आर्थिक अर्थपूर्ण आहे. जर त्याची किंमत वर्षाला $900 पेक्षा जास्त असेल, तर त्याला यापुढे अर्थ नाही, कारण महसुलात होणारी वाढ केवळ श्रम खर्च आणि संसाधन खर्चाची भरपाई करत नाही. आणि आमच्यासाठी 3 नाइन पुरेसे असतील.

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

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

SLA असे असू शकते असे म्हणूया. ही सेवा वर्षभरात ९९.९५% वेळ उपलब्ध असते. किंवा 99,95 क्रिटिकल टेक्निकल सपोर्ट तिकिटे प्रति तिमाही 99 तासांच्या आत बंद केली जातील. किंवा 3% प्रश्नांची उत्तरे दर महिन्याला 85 सेकंदात दिली जातील. म्हणजेच, आपल्याला हळूहळू समजत आहे की चुका आणि अपयश अगदी सामान्य आहेत. ही एक स्वीकारार्ह परिस्थिती आहे, आम्ही त्यासाठी योजना आखत आहोत, आम्ही काही प्रमाणात त्यावर अवलंबून आहोत. म्हणजेच, SRE अशा प्रणाली तयार करते ज्या चुका करू शकतात, ज्याने त्रुटींना सामान्यपणे प्रतिसाद दिला पाहिजे आणि त्या लक्षात घेतल्या पाहिजेत. आणि शक्य असल्यास, त्यांनी त्रुटी अशा प्रकारे हाताळल्या पाहिजेत की वापरकर्त्याला त्या लक्षात येत नाहीत किंवा लक्षात येत नाहीत, परंतु काही प्रकारचे उपाय आहेत जेणेकरुन सर्वकाही पूर्णपणे विस्कळीत होणार नाही.

उदाहरणार्थ, जर तुम्ही YouTube वर व्हिडिओ अपलोड केला असेल आणि YouTube ते लगेच रूपांतरित करू शकत नाही, जर व्हिडिओ खूप मोठा असेल, जर फॉरमॅट इष्टतम नसेल, तर विनंती स्वाभाविकपणे कालबाह्य होणार नाही, YouTube 502 प्रदर्शित करणार नाही. त्रुटी, YouTube म्हणेल: “आम्ही सर्वकाही तयार केले आहे, तुमच्या व्हिडिओवर प्रक्रिया केली जात आहे. ते सुमारे 10 मिनिटांत तयार होईल.” हे ग्रेसफुल डिग्रेडेशनचे तत्त्व आहे, जे परिचित आहे, उदाहरणार्थ, जर तुम्ही हे केले असेल तर समोरच्या विकासापासून.

आम्ही ज्या पुढील अटींबद्दल बोलू, ज्या विश्वासार्हतेसह, त्रुटींसह, अपेक्षांसह कार्य करण्यासाठी अत्यंत महत्त्वाच्या आहेत, त्या MTBF आणि MTTR आहेत. MTBF हा अपयशांमधील मध्य कालावधी आहे. MTTR म्हणजे पुनर्प्राप्तीसाठी वेळ, पुनर्प्राप्तीसाठी सरासरी वेळ. म्हणजेच, त्रुटी आढळल्याच्या क्षणापासून, सेवा पूर्णपणे सामान्य ऑपरेशनमध्ये पुनर्संचयित होईपर्यंत त्रुटी दिसून येईपर्यंत किती वेळ गेला. MTBF मुख्यत्वे कोड गुणवत्तेवर काम करून दुरुस्त केले जाते. म्हणजेच, SREs "नाही" म्हणू शकतात ही वस्तुस्थिती आहे. आणि संपूर्ण टीमला हे समजून घेणे आवश्यक आहे की जेव्हा SRE “नाही” म्हणतो तेव्हा तो म्हणतो की तो हानिकारक आहे म्हणून नाही, तो वाईट आहे म्हणून नाही, तर अन्यथा प्रत्येकाला त्रास होईल म्हणून.

पुन्‍हा, पुष्कळ लेख आहेत, पुष्कळ पद्धती आहेत, पुष्कळ मार्ग आहेत, ज्‍या पुस्‍तकाचाही मी वारंवार संदर्भ घेतो त्‍यामध्‍ये, इतर विकसक SRE चा तिरस्कार करू नयेत याची खात्री कशी करावी. MTTR, दुसरीकडे, तुमच्या SLO (सर्व्हिस लेव्हल उद्दिष्ट) वर काम करण्याबद्दल आहे. आणि हे मुख्यतः ऑटोमेशन आहे. कारण, उदाहरणार्थ, आमचा SLO प्रति तिमाही 4 नाइनचा अपटाइम आहे. याचा अर्थ असा की 3 महिन्यांत आम्ही 13 मिनिटांचा डाउनटाइम देऊ शकतो. आणि असे दिसून आले की आमची एमटीटीआर 13 मिनिटांपेक्षा जास्त असू शकत नाही. जर आम्हाला किमान 13 डाउनटाइमवर प्रतिक्रिया देण्यासाठी 1 मिनिटे लागली, तर याचा अर्थ आम्ही तिमाहीचे संपूर्ण बजेट आधीच संपवले आहे. आम्ही SLO चे उल्लंघन करत आहोत. 13 मिनिटे प्रतिक्रिया आणि बिघाड दुरुस्त करणे मशीनसाठी खूप आहे, परंतु एखाद्या व्यक्तीसाठी फारच कमी आहे. कारण जेव्हा एखाद्या व्यक्तीला अलर्ट प्राप्त होतो, तेव्हा तो प्रतिक्रिया देतो, त्रुटी शोधून काढतो तेव्हा काही मिनिटे असतात. जोपर्यंत ते कसे सोडवायचे, नेमके काय निराकरण करायचे, काय करायचे हे समजत नाही तोपर्यंत यास आणखी काही मिनिटे लागतील. आणि खरं तर, जरी आपल्याला सर्व्हर रीबूट करण्याची आवश्यकता असेल, जसे की ते वळते किंवा नवीन नोड वाढवते, तर MTTR व्यक्तिचलितपणे सुमारे 7-8 मिनिटे घेते. प्रक्रिया स्वयंचलित करताना, MTTR अनेकदा सेकंदापर्यंत, कधी कधी मिलिसेकंदपर्यंत पोहोचते. Google सहसा मिलिसेकंदांबद्दल बोलतो, परंतु प्रत्यक्षात, गोष्टी इतक्या चांगल्या नाहीत.

तद्वतच, SRE ने त्याचे काम जवळजवळ पूर्णपणे स्वयंचलित केले पाहिजे, कारण याचा थेट परिणाम MTTR, त्याचे मेट्रिक्स, संपूर्ण सेवेचा SLO आणि त्यानुसार व्यवसायाच्या नफ्यावर होतो. वेळ ओलांडल्यास, आम्हाला विचारले जाते की दोष SRE वर आहे का. सुदैवाने, दोष कोणावरही टाकला जात नाही. आणि ही एक वेगळी संस्कृती आहे, ज्याला निर्दोष पोस्टमॉर्टम म्हणतात, ज्याबद्दल आपण आज बोलणार नाही, परंतु आम्ही स्लर्ममध्ये विश्लेषण करू. हा एक अतिशय मनोरंजक विषय आहे ज्याबद्दल बरेच काही बोलले जाऊ शकते. ढोबळपणे सांगायचे तर, जर प्रत्येक तिमाहीत दिलेला वेळ ओलांडला असेल, तर प्रत्येकाला थोडासा दोष द्यावा लागेल, याचा अर्थ असा आहे की प्रत्येकाला दोष देणे फलदायी नाही, त्याऐवजी, कदाचित, कोणालाही दोष देऊ नका, परंतु परिस्थिती दुरुस्त करू आणि आपल्याकडे जे आहे त्यासह कार्य करूया. माझ्या अनुभवानुसार, हा दृष्टिकोन बहुतेक संघांसाठी थोडा परदेशी आहे, विशेषत: रशियामध्ये, परंतु तो अर्थपूर्ण आहे आणि खूप चांगले कार्य करतो. म्हणून, शेवटी मी या विषयावर वाचू शकणार्‍या लेख आणि साहित्याची शिफारस करेन. किंवा Slurm SRE वर या.

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

पुढच्या प्रश्नाकडे वळू. ऑटोमेशन. मी सहसा, जेव्हा मी इतर संदर्भांमध्ये ऑटोमेशनबद्दल बोलतो, तेव्हा बर्‍याचदा टेबलचा संदर्भ घेतो जे तुम्ही एखादे कार्य स्वयंचलित करण्यासाठी किती वेळ काम करू शकता याबद्दल बोलतो जेणेकरुन तुम्ही सामान्यतः बचत करण्यापेक्षा ते स्वयंचलित करण्यासाठी जास्त वेळ लागू नये. एक झेल आहे. पकड अशी आहे की जेव्हा SRE एखादे कार्य स्वयंचलित करतात, तेव्हा ते केवळ वेळच वाचवत नाहीत तर ते पैसे वाचवतात कारण ऑटोमेशनचा थेट MTTR वर परिणाम होतो. ते कर्मचार्‍यांचे आणि विकासकांचे मनोबल वाचवतात, जे एक संपुष्टात येणारे संसाधन देखील आहे. ते दिनचर्या कमी करतात. आणि या सर्वांचा कामावर आणि परिणामी, व्यवसायावर सकारात्मक परिणाम होतो, जरी असे दिसते की वेळेच्या खर्चाच्या बाबतीत ऑटोमेशनचा अर्थ नाही.

खरं तर, हे जवळजवळ नेहमीच घडते आणि अशी काही प्रकरणे आहेत जिथे SRE भूमिकेत काहीतरी स्वयंचलित करणे योग्य नाही. पुढे आपण एरर बजेट, एरर बजेट बद्दल बोलू. खरं तर, हे दिसून येते की आपण स्वत: साठी सेट केलेल्या SLO पेक्षा आपण लक्षणीयरीत्या चांगले करत असल्यास, हे देखील फार चांगले नाही. हे त्याऐवजी वाईट आहे, कारण SLO केवळ खालच्या बाउंडच्या रूपातच नाही तर अंदाजे वरच्या बाउंड म्हणून देखील कार्य करते. जेव्हा तुम्ही स्वतःला 99% उपलब्धतेचा SLO सेट करता आणि प्रत्यक्षात तुमच्याकडे 99,99% असतो, तेव्हा असे दिसून येते की तुमच्याकडे प्रयोगासाठी काही जागा आहे, ज्यामुळे व्यवसायाला अजिबात नुकसान होणार नाही, कारण तुम्ही स्वतः हे सर्व एकत्र ठरवले आहे आणि तुम्ही ही जागा वापरू नका. तुमच्याकडे त्रुटींसाठी बजेट आहे, जे तुमच्या बाबतीत खर्च होत नाही.

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

म्हणजेच, असे दिसून आले की जर सेवा स्वतःच चांगली कार्य करत नसेल आणि SLO खर्च केला गेला असेल आणि बजेट प्रयोगांवर नाही, कोणत्याही रिलीझवर नाही तर स्वतःच खर्च केले जाईल, तर काही मनोरंजक निराकरणांऐवजी, मनोरंजक ऐवजी मनोरंजक प्रकाशनांऐवजी वैशिष्ट्ये. कोणतेही सर्जनशील कार्य करण्याऐवजी, तुम्हाला बजेट परत व्यवस्थित करण्यासाठी मूक निराकरण करावे लागेल किंवा SLO संपादित करावे लागेल आणि ही देखील एक प्रक्रिया आहे जी वारंवार होऊ नये.

म्हणूनच, असे दिसून आले की आमच्याकडे त्रुटींसाठी अधिक बजेट आहे अशा परिस्थितीत, प्रत्येकाला स्वारस्य आहे: SRE आणि विकसक दोघेही. विकसकांसाठी, त्रुटींसाठी मोठ्या बजेटचा अर्थ असा आहे की ते प्रकाशन, चाचण्या आणि प्रयोगांना सामोरे जाऊ शकतात. SRE साठी, त्रुटींसाठी बजेट आणि या बजेटमध्ये प्रवेश करणे म्हणजे ते खरोखर चांगले काम करत आहेत. आणि हे काही प्रकारच्या संयुक्त कार्याच्या प्रेरणावर परिणाम करते. तुम्ही विकासक म्हणून तुमचे SRE ऐकल्यास, तुमच्याकडे चांगले काम करण्यासाठी अधिक जागा आणि खूप कमी कामे असतील.

असे दिसून आले की मोठ्या संघांमध्ये उत्पादनातील प्रयोग हे SRE चा एक अत्यंत महत्त्वाचा आणि जवळजवळ अविभाज्य भाग आहेत. आणि हे सहसा अराजक अभियांत्रिकी नावाने जाते, जे Netflix मधील संघाकडून येते ज्याने Chaos Monkey नावाची उपयुक्तता जारी केली.
कॅओस मंकी सीआय/सीडी पाइपलाइनला जोडतो आणि उत्पादनामध्ये यादृच्छिकपणे सर्व्हर क्रॅश करतो. पुन्हा, SRE संरचनेत आम्ही म्हणतो की क्रॅश झालेला सर्व्हर स्वतःच वाईट नाही, तो अपेक्षित आहे. आणि जर ते बजेटमध्ये समाविष्ट केले असेल तर ते स्वीकार्य आहे आणि व्यवसायाचे नुकसान होत नाही. अर्थात, Netflix कडे पुरेसे निरर्थक सर्व्हर आहेत, पुरेशी प्रतिकृती, जे वापरकर्त्याच्या संपूर्णपणे लक्षात न घेता हे सर्व निश्चित केले जाऊ शकते आणि नक्कीच कोणीही कोणत्याही बजेटसाठी एक सर्व्हर सोडत नाही.

Netflix मध्ये एकेकाळी अशा युटिलिटीजचा संपूर्ण संच होता, ज्यापैकी एक, Chaos Gorilla, Amazon मधील एक उपलब्धता झोन पूर्णपणे अक्षम करते. आणि अशा गोष्टी ओळखण्यास चांगली मदत करतात, प्रथम, लपलेले अवलंबित्व, जेव्हा हे पूर्णपणे स्पष्ट नसते की कशावर काय प्रभाव पडतो, कशावर अवलंबून असतो. आणि हे, जर तुम्ही मायक्रोसर्व्हिसवर काम करत असाल आणि दस्तऐवजीकरण पूर्णपणे परिपूर्ण नसेल, तर हे तुमच्यासाठी परिचित असेल. आणि पुन्हा, हे कोडमधील त्रुटी पकडण्यास मदत करते जे आपण स्टेजिंग दरम्यान पकडू शकत नाही, कारण कोणतेही स्टेजिंग अचूक सिम्युलेशन नसते, या वस्तुस्थितीमुळे लोड स्केल भिन्न आहे, लोड पॅटर्न भिन्न आहे, उपकरणे देखील आहेत, बहुतेक शक्यता, इतर. पीक लोड देखील अनपेक्षित आणि अप्रत्याशित असू शकतात. आणि अशी चाचणी, जी पुन्हा बजेटच्या पलीकडे जात नाही, स्टेजिंग, ऑटोटेस्ट आणि सीआय/सीडी पाइपलाइन कधीही पकडू शकणार नाहीत अशा पायाभूत सुविधांमधील त्रुटी शोधण्यात खूप चांगली मदत करते. आणि जोपर्यंत हे सर्व तुमच्या बजेटमध्ये समाविष्ट आहे, तोपर्यंत तुमची सेवा तेथे कमी झाली आहे हे महत्त्वाचे नाही, जरी ते खूप भितीदायक वाटेल, सर्व्हर क्रॅश झाला आहे, किती भयानक स्वप्न आहे. नाही, हे सामान्य आहे, ते चांगले आहे, ते त्रुटी पकडण्यात मदत करते. जर तुमच्याकडे बजेट असेल तर तुम्ही ते खर्च करू शकता.

प्रश्न: मी कोणत्या साहित्याची शिफारस करू शकतो? यादी शेवटी आहे. भरपूर साहित्य आहे, मी अनेक अहवालांची शिफारस करतो. हे कसे कार्य करते आणि SRE कंपन्यांमध्ये त्यांच्या स्वतःच्या सॉफ्टवेअर उत्पादनाशिवाय किंवा कमीतकमी विकासासह कार्य करते का. उदाहरणार्थ, एखाद्या एंटरप्राइझमध्ये, जिथे मुख्य क्रियाकलाप सॉफ्टवेअर नाही. एखाद्या एंटरप्राइझमध्ये, जिथे मुख्य क्रियाकलाप सॉफ्टवेअर नसतो, SRE इतर कोठेही सारखेच कार्य करते, कारण एखाद्या एंटरप्राइझमध्ये तुम्हाला देखील वापरण्याची आवश्यकता असते, जरी तुम्ही सॉफ्टवेअर उत्पादने विकसित केली नसली तरीही, तुम्हाला अद्यतने रोल आउट करणे आवश्यक आहे, तुम्ही पायाभूत सुविधा बदलण्याची गरज आहे, तुम्हाला वाढण्याची गरज आहे, तुम्हाला मोजमाप करण्याची गरज आहे. आणि SREs या प्रक्रियेतील संभाव्य समस्या ओळखण्यात आणि अंदाज लावण्यास मदत करतात आणि काही वाढ सुरू झाल्यानंतर आणि व्यवसायाच्या गरजा बदलल्यानंतर त्या नियंत्रित करतात. कारण तुमच्याकडे किमान अनेक सर्व्हर असतील आणि तुम्हाला किमान काही वाढ अपेक्षित असेल तर SRE असण्यासाठी सॉफ्टवेअर डेव्हलपमेंटमध्ये गुंतणे आवश्यक नाही.

लहान प्रकल्प, छोट्या संस्थांसाठीही हेच आहे, कारण मोठ्या कंपन्यांकडे प्रयोगासाठी बजेट आणि जागा असते. परंतु त्याच वेळी, प्रयोगांची ही सर्व फळे कुठेही वापरली जाऊ शकतात, म्हणजे, SREs, अर्थातच, Google, Netflix आणि Dropbox मध्ये दिसू लागले. परंतु त्याच वेळी, लहान कंपन्या आणि स्टार्टअप आधीच कंडेन्स्ड साहित्य वाचू शकतात, पुस्तके वाचू शकतात आणि अहवाल पाहू शकतात. ते याबद्दल अधिक वेळा ऐकू लागतात, विशिष्ट उदाहरणे पहा, मला वाटते, ठीक आहे, हे खरोखर उपयुक्त ठरू शकते, आम्हाला याची देखील गरज आहे, छान.

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

त्यानुसार, देखरेखीची देखरेख आणि संघटना कोणत्याही आकाराच्या कंपनीसाठी उपयुक्त आहे. आणि सर्वसाधारणपणे, विचार करण्याची ही पद्धत, जिथे चुका काहीतरी स्वीकार्य आहेत, जिथे बजेट आहे, जिथे उद्दिष्टे अस्तित्वात आहेत, 3-व्यक्तींच्या स्टार्टअपपासून सुरू होणाऱ्या कोणत्याही आकाराच्या कंपनीसाठी पुन्हा उपयुक्त आहे.

आम्ही ज्या तांत्रिक बारकाव्यांबद्दल बोलू शकतो त्यापैकी शेवटचे निरीक्षण आहे. कारण जर आपण SLA, SLI, SLO बद्दल बोललो तर, आम्ही बजेटमध्ये बसतो की नाही, आम्ही आमच्या उद्दिष्टांचे पालन करतो की नाही आणि आम्ही अंतिम SLA वर कसा प्रभाव पाडतो हे निरीक्षण केल्याशिवाय समजू शकत नाही. मी बर्‍याच वेळा निरीक्षण केले आहे की निरीक्षण खालील प्रकारे होते: काही मूल्य आहे, उदाहरणार्थ, सर्व्हरला विनंती करण्याची वेळ, सरासरी वेळ किंवा डेटाबेसला विनंतीची संख्या. त्याच्याकडे अभियंत्यांनी ठरवलेले एक मानक आहे. जर मेट्रिक सर्वसामान्य प्रमाणापेक्षा विचलित असेल, तर ईमेल पाठवला जाईल. नियमानुसार, हे सर्व पूर्णपणे निरुपयोगी आहे, कारण यामुळे अलर्टचे अतिसंपृक्तता, मॉनिटरिंग संदेशांचे ओव्हरसॅच्युरेशन होते, जेव्हा एखाद्या व्यक्तीने, प्रथम, प्रत्येक वेळी त्यांचा अर्थ लावला पाहिजे, म्हणजेच मेट्रिक मूल्याचा अर्थ आवश्यक आहे की नाही हे निर्धारित करा. काही प्रकारची कृती. आणि दुसरे म्हणजे, मुळात त्याच्याकडून कोणतीही कारवाई आवश्यक नसताना तो या सर्व अलर्ट्सकडे लक्ष देणे थांबवतो. म्हणजेच, एक चांगला देखरेखीचा नियम आणि SRE लागू करताना पहिला नियम हा आहे की जेव्हा एखादी कारवाई आवश्यक असेल तेव्हाच सूचना याव्यात.

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

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

देखरेखीपासून आपण निरीक्षणक्षमता नावाच्या संज्ञेकडे जातो. गेल्या काही वर्षांपासून या शब्दाभोवती थोडा प्रचारही आहे. आणि संदर्भाबाहेर याचा अर्थ काय हे काही लोकांना समजते. पण मुख्य मुद्दा असा आहे की निरीक्षणक्षमता ही प्रणालीच्या पारदर्शकतेची मेट्रिक आहे. जर काहीतरी चूक झाली असेल, तर नक्की काय चूक झाली आणि त्या क्षणी सिस्टमची स्थिती काय होती हे तुम्ही किती लवकर ठरवू शकता. कोडच्या दृष्टिकोनातून: कोणते कार्य अयशस्वी झाले, कोणती सेवा अयशस्वी झाली. उदाहरणार्थ, अंतर्गत चल, कॉन्फिगरेशनची स्थिती काय होती. पायाभूत सुविधांच्या दृष्टिकोनातून, हे कोणत्या उपलब्धतेच्या झोनमध्ये बिघाड झाले आणि जर तुमच्याकडे काही प्रकारचे कुबर्नेट्स असतील, तर कोणत्या पॉडमध्ये बिघाड झाला, पॉडची स्थिती काय होती. आणि त्यानुसार, निरीक्षणक्षमतेचा MTTR शी थेट संबंध आहे. सेवेची निरीक्षणक्षमता जितकी जास्त असेल तितकी त्रुटी ओळखणे सोपे आहे, त्रुटी दूर करणे सोपे आहे, त्रुटी स्वयंचलित करणे सोपे आहे, MTTR कमी आहे.

जर आपण पुन्हा छोट्या कंपन्यांकडे गेलो, तर ते बरेचदा विचारतात, आताही, संघाच्या आकाराचे काय करावे आणि लहान संघात स्वतंत्र SRE घेणे आवश्यक आहे का. मी याबद्दल थोडे आधी बोललो आहे. स्टार्टअपच्या विकासाच्या पहिल्या टप्प्यात किंवा, उदाहरणार्थ, एक संघ, हे अजिबात आवश्यक नाही, कारण SRE ला संक्रमणकालीन भूमिका बनवता येते. आणि हे संघाला थोडे जिवंत करेल, कारण त्यात किमान काही विविधता आहे. आणि शिवाय ते लोकांना या वस्तुस्थितीसाठी तयार करेल की ते जसजसे वाढतील, सर्वसाधारणपणे, SRE च्या जबाबदाऱ्या खूप लक्षणीय बदलतील. आपण एखाद्या व्यक्तीला कामावर घेतल्यास, नक्कीच त्याच्या काही अपेक्षा आहेत. आणि या अपेक्षा काळानुसार बदलणार नाहीत, पण गरजा खूप बदलतील. म्हणून, सुरुवातीच्या टप्प्यात एसआरईची नियुक्ती करणे खूप कठीण आहे. स्वतःचे मोठे करणे खूप सोपे आहे. पण विचार करण्यासारखे आहे.

एकमात्र अपवाद, कदाचित, जेव्हा खूप कठोर आणि चांगल्या प्रकारे परिभाषित उंची आवश्यकता असतात. म्हणजेच, स्टार्टअपच्या बाबतीत, हे गुंतवणूकदारांकडून एक प्रकारचे दबाव असू शकते, एकाच वेळी अनेक वेळा वाढीचा अंदाज असू शकतो. मग SRE नियुक्त करणे सामान्यतः न्याय्य आहे कारण ते न्याय्य असू शकते. आम्हाला वाढीची आवश्यकता आहे, आम्हाला अशा व्यक्तीची गरज आहे जी अशा वाढीसह काहीही खंडित होणार नाही याची खात्री करण्यासाठी जबाबदार असेल.

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

SRE टूल्सबद्दल प्रश्न होता. म्हणजेच, SRE वापरतील असे काही विशिष्ट आहे जे इतर प्रत्येकजण वापरणार नाही? खरं तर, काही अत्यंत विशेष उपयुक्तता आहेत, काही सॉफ्टवेअर आहेत जे, उदाहरणार्थ, भारांचे अनुकरण करतात किंवा कॅनरी A/B चाचणी करतात. पण मुळात, SRE टूलिंग हे तुमचे विकसक आधीच वापरत आहेत. कारण SRE थेट विकास संघाशी संवाद साधतो. आणि जर तुमच्याकडे वेगवेगळी साधने असतील, तर ते सिंक्रोनाइझ होण्यासाठी वेळ लागतो. विशेषत: SRE मोठ्या संघांमध्ये काम करत असल्यास, मोठ्या कंपन्यांमध्ये जेथे अनेक संघ असू शकतात, कंपनी-व्यापी मानकीकरण येथे खूप उपयुक्त ठरेल, कारण 50 संघ 50 भिन्न उपयुक्तता वापरत असल्यास, याचा अर्थ SRE ला त्या सर्व माहित असणे आवश्यक आहे. आणि अर्थात हे कधीच होणार नाही. आणि कामाची गुणवत्ता, किमान काही संघांच्या नियंत्रणाची गुणवत्ता लक्षणीयरीत्या कमी होईल.

आमचा वेबिनार हळूहळू संपत आहे. मी तुम्हाला काही मूलभूत गोष्टी सांगू शकलो. अर्थात, SRE बद्दल तासाभरात काहीही सांगता आणि समजू शकत नाही. परंतु मला आशा आहे की मी या विचारसरणीचे, मुख्य मुख्य मुद्दे व्यक्त करण्यात व्यवस्थापित केले आहे. आणि मग, तुम्हाला स्वारस्य असल्यास, तुम्ही या विषयाचा सखोल अभ्यास करू शकता, स्वतः अभ्यास करू शकता आणि इतर लोकांकडून, इतर कंपन्यांमध्ये ते कसे लागू केले जात आहे ते पाहू शकता. आणि त्यानुसार, फेब्रुवारीच्या सुरुवातीस, स्लर्म एसआरई येथे आमच्याकडे या.

स्लर्म एसआरई हा तीन दिवसांचा गहन अभ्यासक्रम आहे ज्यामध्ये मी आता जे बोलतो आहे ते अंदाजे कव्हर करेल, परंतु अधिक खोलवर, वास्तविक प्रकरणांसह, सरावासह, संपूर्ण गहन अभ्यासाचे उद्दीष्ट व्यावहारिक कार्य आहे. लोक संघात विभागले जातील. तुम्ही सर्व खर्‍या केसेसवर काम कराल. त्यानुसार, आमच्याकडे Booking.com इव्हान क्रुग्लोव्ह आणि बेन टायलरचे प्रशिक्षक आहेत. आमच्याकडे सॅन फ्रान्सिस्कोमधील Google कडून एक अद्भुत इव्हगेनी वरब्बास आहे. आणि मी पण तुला काहीतरी सांगेन. तर नक्की भेट द्या.
तर, संदर्भांची यादी. SRE वर लिंक्स आहेत. पहिला त्याच पुस्तकावर, किंवा Google ने लिहिलेल्या SRE बद्दलच्या 2 पुस्तकांवर. आणखी एक SLA, SLI, SLO वर छोटा लेख, जेथे अटी आणि त्यांचे अर्ज थोडे अधिक तपशीलाने स्पष्ट केले आहेत. पुढील 3 वेगवेगळ्या कंपन्यांमधील SRE वरील अहवाल आहेत. पहिला - SRE च्या कळा, ही Google वरील बेन ट्रेनरची मुख्य सूचना आहे. दुसरा - ड्रॉपबॉक्स वर SRE. तिसरा पुन्हा बद्दल आहे Google वर SRE. पासून चौथा अहवाल Netflix वर SRE, ज्याचे 5 देशांमध्ये फक्त 190 प्रमुख SRE कर्मचारी आहेत. हे सर्व पाहणे खूप मनोरंजक आहे, कारण ज्याप्रमाणे DevOps म्हणजे वेगवेगळ्या कंपन्यांसाठी आणि अगदी भिन्न संघांसाठी अगदी भिन्न गोष्टी, त्याच आकाराच्या कंपन्यांमध्येही SRE कडे खूप भिन्न जबाबदाऱ्या आहेत.

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

मनोरंजक लेख: जीवन निवड म्हणून SRE

या सर्व वेळी माझे ऐकल्याबद्दल धन्यवाद. मला आशा आहे की तुम्ही काहीतरी शिकलात. मला आशा आहे की तुमच्याकडे आणखी शिकण्यासाठी पुरेसे साहित्य आहे. आणि नंतर भेटू. आशा आहे की फेब्रुवारीमध्ये.
वेबिनारचे आयोजन एडवर्ड मेदवेदेव यांनी केले होते.

PS: ज्यांना वाचायला आवडते त्यांच्यासाठी, एडवर्डने संदर्भांची यादी दिली. ज्यांना ते व्यवहारात समजून घेण्यास प्राधान्य आहे त्यांचे स्वागत आहे Slurme SRE.

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