🍦 🧘🏻 🥖 थिंक एसआरई: एक एसआरई इंजीनियर की आंखों के माध्यम से परियोजनाओं को देखें 🍃 🚗 🍈

स्लुर्म की समीक्षाओं में, कुबेरनेट्स ने वाक्यांश की ध्वनि दी: "कुबेरनेट्स ने जितना सोचा था उससे कहीं अधिक निकला।" अब यह नहीं लगता है, k8s की जटिलता का मिथक अब और नहीं है। वह सीखने में आसान साधनों की श्रेणी में आ गया, गुरु के लिए कठिन।

हम SRE के साथ भी यही दोहराना चाहते हैं। दिखाएँ कि SRE आसान और अधिक समझ में आता है जितना लगता है। प्रतिमान को स्थानांतरित करें: लोगों को SRE इंजीनियर की आंखों के माध्यम से परियोजना को देखने दें।

हमेशा की तरह शुरुआत में, समीकरण में कई अज्ञात हैं। और हमेशा की तरह शुरुआत में, सबसे दिलचस्प पहले जाएगा।

3-5 फरवरी को, हम मॉस्को में स्लम एसआरई की मेजबानी करेंगे। तीन दिन के सघन टिकट की कीमत 60 हजार है। प्रतिभागी को उसके पैसे के लिए क्या मिलेगा?

जब मैं एसआरई के बारे में दोस्तों और सहयोगियों को बताता हूं, तो मुझे संदेह होता है:

मैंने पहली बार SRE के बारे में सुना, यह किसी तरह की कीमिया है।
Google जैसे दिग्गजों के लिए, SRE को लागू करना कठिन है।
यह महंगा और लंबा है, वे समय नहीं देंगे, वे एक बजट आवंटित नहीं करेंगे।
आप जो वर्णन करते हैं वह सच होना बहुत अच्छा है।

मैं ये सवाल करना चाहता हूं।

यह पता लगाने का समय है कि एसआरई क्या है।

स्लोगन स्तर पर: SRE, DevOps के कार्यान्वयन में से एक है। यह Google पर 10+ साल पहले दिखाई दिया था, लेकिन हाल ही में "नियमित रूप से" बाजार में प्रवेश करना शुरू कर दिया, मुख्य रूप से 2016 में Google द्वारा जारी पुस्तक साइट विश्वसनीयता एंगेजिंग के कारण।

SRE और DevOps के बीच संबंध इस वीडियो में अच्छी तरह से वर्णित है:

बुरी बात यह है कि नारे कुछ भी नहीं हैं। अच्छी तरह से DevOps, अच्छी तरह से, कार्यान्वयन, अगले "सभी अच्छे बनाम सभी बुरे" के लिए।

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

मूल्य में एसआरई दृष्टिकोण और उपकरणों की त्वरित और गहन समीक्षा शामिल है।

SRE को लागू करना जितना आसान लगता है, उससे कहीं ज्यादा आसान है

स्लम पर हम अपने हाथों से एसआरई को स्पर्श करेंगे: हम मैट्रिक्स का चयन करेंगे, उनके माप को कॉन्फ़िगर करेंगे, अलर्ट करेंगे, घटनाओं में भाग लेंगे, उन्हें हल करेंगे और उनका विश्लेषण करेंगे, सभी एसआरई कैनन के अनुसार परियोजना का पुनर्निर्माण करेंगे।

यही है, हम चरण-दर-चरण निर्देश देंगे जो आप गहन से लौटने पर अपने स्वयं के कार्यान्वयन कर सकते हैं।

मैं झूठ बोल रहा हूं। वास्तव में, हम निर्देश नहीं देंगे, लेकिन एक नमूना जिससे आप विचारों और समाधानों का एक समूह बना सकते हैं।

मूल्य में कार्यान्वयन के लिए एक नमूना शामिल है।

मुख्य समस्या यह है कि आपको उन लोगों को समझाना होगा जो स्लम के लिए नहीं हैं। इसलिए, आदर्श रूप में, यह पूरी टीम के रूप में तीव्रता से आने लायक है। इसलिए, हम समूहों के लिए बड़ी छूट देते हैं।

सर्विस स्टेशन के नेतृत्व में स्लेरम में आना अच्छा होगा। और CEO भी उपयोगी है, और इस सेक्शन के बारे में ...

... शीर्ष प्रबंधन को कैसे विश्वास दिलाया जाए कि एसआरई उपयोगी और आवश्यक है।

आमतौर पर सीईओ (शीर्ष प्रबंधन), एसटीओ (आईटी प्रबंधन), डेवलपर्स और संचालन के बीच कार्यों का टकराव होता है।

मैं जानबूझकर "हितों का टकराव" नहीं कहता, यह ठीक कार्यों का टकराव है।

सीईओ को वित्तीय प्रदर्शन की आवश्यकता है STO - एक समझने योग्य, प्रबंधनीय और यथासंभव आरामदायक स्थिति। यही है, समझने योग्य व्यावसायिक मूल्य के साथ समझने योग्य कार्य, समय सीमा को पूरा करना, एक सामान्य स्टैक, अधिक सुविधाएँ और कम फ़ैपैप्स। डेवलपर्स को एक्सेसिबिलिटी सुनिश्चित करने के लिए और अधिक सुविधाओं को रोल करने और शोषण करने की आवश्यकता है - (जो "अधिक सुविधाओं" के साथ स्पष्ट रूप से टकराव करता है)।

एसआरई का कहना है कि प्रक्रिया में सभी प्रतिभागियों का एक ही काम है: उपयोगकर्ता की खुशी। उपयोगकर्ता नई सुविधाओं और सेवा की विश्वसनीयता के बीच एक स्वस्थ संतुलन से खुश है। खुश उपयोगकर्ता अधिक पैसे देता है। उपयोगकर्ता की खुशी का प्रबंधन करने के लिए, आपको विशेष उपकरणों की आवश्यकता होती है।

इसके अलावा, एसआरई, मेट्रिक्स पर आधारित होने के नाते, आपको वित्तीय संकेतकों को विभिन्न मेट्रिक्स के लक्ष्य संकेतकों में अनुवाद करने की अनुमति देता है, और वे, बदले में, DevOps टीमों के कार्यों में।

आपको अनुवाद करने की अनुमति देता है - मैंने अतिरंजित किया। इन मैट्रिक्स की उपस्थिति आपको मैट्रिक्स और वित्तीय संकेतकों की स्थिति के बीच संबंध खोजने की अनुमति देती है। यह एक अलग लेकिन समझने योग्य कार्य है।

एक परियोजना DORA, DevOps Research & आकलन है , यह व्यापार और ROI DevOps और इसके उपवर्ग SRE के मूल्य पर वार्षिक अध्ययन जारी करता है। अब हम वर्तमान रिपोर्ट का रूसी में अनुवाद कर रहे हैं। मूल्यांकन फ़ार्मुले हैं जो आपकी कंपनी के लिए कुछ हद तक सटीकता के साथ लागू किए जा सकते हैं।

सारांश: SRE व्यवसायों को मीट्रिक लक्ष्य निर्धारित करके वित्तीय प्रदर्शन का प्रबंधन करने की क्षमता देता है, और DevOps टीम, वर्तमान मैट्रिक्स को देखते हुए, स्पष्ट रूप से समझती है कि वित्तीय प्रदर्शन के लिए अधिकतम लाभ के लिए क्या करने की आवश्यकता है। कौन सा सीईओ ऐसे उपकरण को मना करेगा?

SRE कार्यान्वयन के लिए संसाधन प्राप्त करना बहुत संभव है।

पाठ्यक्रम की कीमत में SRE और DevOps पर स्विच करने के पक्ष में तर्क शामिल हैं।

और छोटी कंपनियों में भी एसआरई के लिए एक जगह है।

SRE को उपकरण, संस्कृति और संगठनात्मक संरचना में विभाजित किया गया है।

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

संस्कृति किसी भी कंपनी में उपयोगी है। क्लासिक व्यवस्थापक, प्रोमेथियस की स्थापना, मानक के अनुसार कार्य करेगा: इसमें मेमोरी और डिस्क की खपत की निगरानी और अन्य परिचित निगरानी शामिल होगी। SRE इंजीनियर पहले व्यापार के साथ व्यापार प्रक्रियाओं के प्रमुख संकेतकों पर चर्चा करेगा, और फिर अपनी निगरानी स्थापित करेगा। यह तुरंत स्पष्ट है कि एसआरई-इंजीनियरिंग संस्कृति माइक्रो-स्टार्टअप में भी उपयोगी है।

लेकिन छोटी कंपनियों में संगठनात्मक संरचना की जरूरत नहीं है और यहां तक कि हानिकारक भी है। जब सभी कर्मचारी सामान्यवादी होते हैं, तो SRE आदेशों को जबरन आवंटित करने की आवश्यकता नहीं होती है।

हम जो कुछ भी वर्णन करते हैं वह पहले से ही काम कर रहा है

पाठ्यक्रम उन लोगों द्वारा बनाया गया था जिन्होंने अपनी टीमों में लंबे समय तक एसआरई को लागू किया है और लंबे समय से इस प्रतिमान में रहते हैं। इवान क्रुग्लोव और बेन टायलर, दोनों Booking.com पर प्रिंसिपल डेवलपर हैं। यूजीन वरवा, Google पर एक व्यापक प्रोफ़ाइल डेवलपर एडुअर्ड मेदवेदेव, टंगस्टन लैब्स में सीटीओ, जो एक एसआरई इंजीनियर से बड़े हुए थे।

एडवर्ड एक वेबिनार "SRE - HYIP या भविष्य?" 12 दिसंबर को 11:00 बजे आयोजित करता है।

कार्यक्रम के बारे में

कार्यक्रम के लिए के रूप में। मुझे पहले से ही विशेषज्ञ की प्रतिक्रिया मिल रही है कि यह कार्यक्रम लड़ नहीं रहा है: यह बहुत व्यापक है और कभी-कभी अतार्किक भी है। यह वास्तव में है।

वास्तव में, हमारे पास कार्यक्रम के लिए एक रूपरेखा है, विचारों का एक सेट है जिसे हम प्रकट करना चाहते हैं। हमारे सामने दो महीने की कड़ी मेहनत है, जैसा कि हम तैयार करते हैं, कार्यक्रम को स्पष्ट किया जाएगा: हम अनावश्यक को हटा देते हैं और शेष को निर्दिष्ट करते हैं।

लेकिन पहले से ही अपने वर्तमान रूप में, कार्यक्रम स्पष्ट रूप से उस दिशा को दर्शाता है जिसमें हम काम कर रहे हैं।

स्लरम एसआरई कार्यक्रम

थीम # 1: एसआरई के मूल सिद्धांत और तरीके

SRE बनने में क्या लगता है?
DevOps बनाम SRE
डेवलपर्स एसआरई की सराहना क्यों करते हैं और जब वे परियोजना में नहीं होते हैं तो बहुत दुखी होते हैं
SLI, SLO और SLA
बजट में त्रुटि और एसआरई में इसकी भूमिका

थीम नंबर 2: वितरित सिस्टम का डिजाइन

आवेदन वास्तुकला और कार्यक्षमता
गैर-सार बड़े सिस्टम डिज़ाइन
विफलता के लिए संचालन / डिजाइन
gRPC या REST
वर्जनिंग और बैकवर्ड कम्पेटिबिलिटी

थीम .3: SRE प्रोजेक्ट को कैसे स्वीकार करें

एसआरई से सर्वश्रेष्ठ अभ्यास
प्रोजेक्ट एडमिशन चेकलिस्ट
लॉगिंग, मेट्रिक्स, ट्रेसिंग
CI / CD को अपने हाथों में लें

थीम .4: वितरित प्रणाली का डिज़ाइन और लॉन्च

रिवर्स इंजीनियरिंग - सिस्टम कैसे काम करता है?
हम SLI और SLO का समन्वय करते हैं
क्षमता योजना अभ्यास
आवेदन के लिए ट्रैफ़िक लॉन्च करना, हमारे उपयोगकर्ता "इसका उपयोग करना" शुरू करते हैं
प्रोमेथियस, ग्राफाना, इलास्टिक लॉन्च करें

विषय # 5: निगरानी, अवलोकन और चेतावनी

निगरानी बनाम observability
प्रोमेथियस के साथ निगरानी और अलर्ट सेट करें
एसएलआई और एसएलओ की व्यावहारिक निगरानी
लक्षण बनाम। कारण
ब्लैक-बॉक्स बनाम सफेद बॉक्स की निगरानी
वितरित अनुप्रयोग और सर्वर उपलब्धता की निगरानी
4 सोने के संकेत (विसंगति का पता लगाना)

थीम systems6: सिस्टम की विश्वसनीयता का परीक्षण करने का अभ्यास

दबाव में काम करें
विफलता इंजेक्शन
अराजक बंदर

थीम # 7: घटना की प्रतिक्रिया का अभ्यास करें

तनाव प्रबंधन एल्गोरिथ्म
घटना के प्रतिभागियों के बीच बातचीत
पोस्टमार्टम किया
ज्ञान बांटना
संस्कृति का निर्माण
गलती की निगरानी
निर्मम बहस का आयोजन

विषय # 8: प्रबंधन अभ्यास लोड करें

लोड संतुलन
अनुप्रयोग दोष सहिष्णुता: रिट्री, टाइमआउट, विफलता इंजेक्शन, सर्किट ब्रेकर
DDoS (भार बनाएं) + कैस्केडिंग विफलताएँ

विषय # 9: हादसा प्रतिक्रिया

डीब्रीफिंग
ऑन-कॉल प्रैक्टिस
विभिन्न प्रकार की विफलताएँ (परीक्षण, कॉन्फ़िगरेशन परिवर्तन, हार्डवेयर विफलताएँ)
हादसा प्रबंधन प्रोटोकॉल

थीम Theme10: निदान और समस्या का समाधान

journaling
डिबगिंग
हमारे आवेदन पर विश्लेषण और डिबगिंग अभ्यास

थीम Theme11: सिस्टम की विश्वसनीयता का परीक्षण

लोड परीक्षण
कॉन्फ़िगरेशन परीक्षण
प्रदर्शन परीक्षण
कैनरी जारी

थीम Theme12: स्वतंत्र कार्य और समीक्षा

क्या उपरोक्त सभी पैसे के लायक है?

पुनश्च। कुबेरनेट्स हब का इससे क्या लेना-देना है

सभी अभ्यास कुबेरनेट्स में किया जाता है। कुबेरनेट के मालिक SRE इंजीनियरों के लिए सीधी सड़क है। जो लोग स्वयं नहीं हैं, वे हमारे कुबेरनेट पाठ्यक्रमों में जाएं ।

थिंक एसआरई: एक एसआरई इंजीनियर की आंखों के माध्यम से परियोजनाओं को देखें