एक सप्ताह के रूप में मैं SRE- इंजीनियर में इंटर्न था। एक सॉफ्टवेयर इंजीनियर की आंखों से देखें

एसआरई इंजीनियर - इंटर्न

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

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

घटनाओं

सप्ताह के दौरान 2 घटनाएं हुईं।

1. क्रिप्टोकरंसी

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

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

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

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

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

मुख्य खोज

यहां कुछ बिंदु दिए गए हैं जो मैंने ड्यूटी के सप्ताह के दौरान सीखे थे।

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

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

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

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

2. कई अलर्ट घटनाओं को कभी नहीं बढ़ाते हैं

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

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

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

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

3. हमारे एसआरई परिचारक कई उपकरणों का उपयोग करते हैं।

घरेलू:

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

बाहरी:

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

और बहुत, बहुत अधिक।

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

यदि GitLab.com पर एक प्रमुख सेवा आउटेज होता है, तो हम यह नहीं चाहेंगे कि समस्या को हल करने की हमारी क्षमता प्रभावित हो। GitLab.com को स्थापित करने के लिए दूसरा GitLab उदाहरण चलाकर इसे रोका जा सकता है। वास्तव में, यह पहले से ही हमारे लिए काम करता है: https://ops.gitlab.net/ ।

5. GitLab को जोड़ने पर विचार करने के लिए कुछ सुविधाएँ

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

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

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