मैंने एसआरई इंजीनियर इंटर्न के रूप में एक सप्ताह कैसे बिताया। एक सॉफ्टवेयर इंजीनियर की नज़र से कर्तव्य

एसआरई इंजीनियर - प्रशिक्षु

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

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

घटनाएं

एक सप्ताह के भीतर दो घटनाएं हुईं।

1. क्रिप्टो माइनर

GitLab.com के उपयोग में बुधवार को उछाल देखा गया गिटलैब रनर'ए, क्रिप्टोकरेंसी माइन करने के लिए रनर के मिनटों का उपयोग करने के प्रयासों के कारण हुआ। इस घटना से हमारे अपने उल्लंघन निराकरण उपकरण का उपयोग करके निपटा गया, जो धावक के कार्यों को रोकता है और उससे जुड़े प्रोजेक्ट और खाते को हटा देता है।

यदि इस घटना पर ध्यान नहीं दिया गया होता, तो एक स्वचालित उपकरण ने इसे पकड़ लिया होता, लेकिन इस मामले में, एसआरई इंजीनियर ने सबसे पहले उल्लंघन को देखा। एक घटना कार्य बनाया गया था, लेकिन उस पर जानकारी बंद है।

2. कैनरी और मुख्य अनुप्रयोगों के प्रदर्शन में गिरावट

यह घटना Gitlab.com पर कैनरी और मुख्य वेब अनुप्रयोगों में मंदी और त्रुटियों की बढ़ती आवृत्ति के कारण हुई थी। कई एपडेक्स मूल्यों का उल्लंघन किया गया।

खुला घटना कार्य: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

मुख्य निष्कर्ष

यहां कुछ चीजें हैं जो मैंने ड्यूटी के दौरान अपने सप्ताह के दौरान सीखीं।

1. मानक से विचलन का पता लगाने पर अलर्ट सबसे उपयोगी होते हैं।

अलर्ट को कई प्रकारों में विभाजित किया जा सकता है:

• एक निश्चित सीमा मान पर आधारित अलर्ट, जैसे "प्रति सेकंड 10 5xx त्रुटियाँ हुईं।"
• अलर्ट जिसमें सीमा एक प्रतिशत मान है जैसे "किसी दिए गए समय में अनुरोधों की कुल मात्रा के प्रति 5% 10xx त्रुटियों की आवृत्ति।"
• ऐतिहासिक औसत पर आधारित अलर्ट जैसे "5वें प्रतिशतक पर 90xx त्रुटियाँ"।

सामान्यतया, प्रकार 2 और 3 ड्यूटी पर एसआरई के लिए अधिक उपयोगी होते हैं, क्योंकि वे प्रक्रिया में मानक से विचलन प्रकट करते हैं।

2. कई चेतावनियाँ कभी भी घटनाओं को आगे नहीं बढ़ातीं।

एसआर इंजीनियर अलर्ट की निरंतर धारा से निपटते हैं, जिनमें से कई वास्तव में महत्वपूर्ण नहीं हैं।

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

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

फ़ीचर सुझाव: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. हमारे एसआरई ड्यूटी पर बहुत सारे उपकरणों का उपयोग करते हैं।

आंतरिक:

• गिटलैब इन्फ्रा प्रोजेक्ट: रनबुक यहां रहते हैं, शिफ्ट/सप्ताह असाइनमेंट, घटना प्रतिक्रिया कार्य।
• GitLab मुद्दे: मुद्दों में जांच, समीक्षा और रखरखाव को भी ट्रैक किया जाता है।
• GitLab लेबल: स्वचालन कार्य विशिष्ट लेबल का उपयोग करके लॉन्च किए जाते हैं, जिनका उपयोग बॉट कार्य गतिविधि को ट्रैक करने के लिए करते हैं।

बाहरी:

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

और भी बहुत सारे।

4. GitLab के साथ GitLab.com की निगरानी करना विफलता का एक बिंदु है

यदि GitLab.com किसी बड़ी सेवा में रुकावट का अनुभव करता है, तो हम नहीं चाहते कि इससे समस्या को हल करने की हमारी क्षमता प्रभावित हो। GitLab.com को प्रबंधित करने के लिए दूसरा GitLab इंस्टेंस लॉन्च करके इसे रोका जा सकता है। वास्तव में, यह हमारे लिए पहले से ही काम करता है: https://ops.gitlab.net/.

5. GitLab में जोड़ने पर विचार करने योग्य कुछ सुविधाएँ

• बहु-उपयोगकर्ता कार्य संपादन, Google डॉक्स के समान। इससे किसी कार्यक्रम के दौरान घटनाओं के कार्यों के साथ-साथ डीब्रीफिंग के कार्यों में भी मदद मिलेगी। दोनों ही मामलों में, कई प्रतिभागियों को वास्तविक समय में कुछ जोड़ने की आवश्यकता हो सकती है।
• कार्यों के लिए अधिक वेबहुक. भीतर से विभिन्न GitLab वर्कफ़्लो चरणों को चलाने की क्षमता स्लैक एकीकरण पर आपकी निर्भरता को कम करने में मदद करेगी। उदाहरण के लिए, GitLab मुद्दे में स्लैश कमांड के माध्यम से PagerDuty में अलर्ट की अनुमति देने की क्षमता।
  निष्कर्ष

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

हम इन सभी बेहतरीन सुविधाओं को एक साथ लाने के लिए 2020 में टीम का विस्तार कर रहे हैं। यदि रुचि हो तो कृपया देखें रिक्त पद, और किसी भी प्रश्न के लिए हमारी टीम में किसी से भी बेझिझक संपर्क करें।

स्रोत: www.habr.com