मैले कसरी एक SRE इन्जिनियर इन्टर्नको रूपमा एक हप्ता बिताएँ। सफ्टवेयर इन्जिनियरको नजरबाट कर्तव्य

SRE इन्जिनियर - प्रशिक्षार्थी

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

मैले एक हप्ताको लागि जताततै SRE इन्जिनियरलाई पछ्याउनु पर्यो। त्यो हो, म हस्तान्तरणमा उपस्थित थिएँ, एउटै अलर्ट च्यानलहरूको अनुगमन गर्थे र घटनाहरू भएमा र कहिले घट्यो भनेर प्रतिक्रिया दिएँ।

घटनाहरू

एक साताभित्र २ वटा घटना भएका छन् ।

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

GitLab.com ले बुधबार प्रयोगमा उछाल देख्यो GitLab धावक'ए, क्रिप्टोकरेन्सी माइन गर्न रनरको मिनेट प्रयोग गर्ने प्रयासको कारणले गर्दा। घटनालाई हाम्रो आफ्नै उल्लङ्घन तटस्थीकरण उपकरण प्रयोग गरेर व्यवहार गरिएको थियो, जसले धावकको कार्यहरू रोक्छ र यससँग सम्बन्धित परियोजना र खाता मेटाउँछ।

यदि यो घटना याद गरिएको थिएन भने, एक स्वचालित उपकरणले यसलाई समात्ने थियो, तर यस अवस्थामा, SRE इन्जिनियरले पहिले उल्लङ्घन देखे। एउटा घटना कार्य सिर्जना गरिएको थियो, तर यसमा जानकारी बन्द छ।

2. क्यानरी र मुख्य अनुप्रयोगहरूको प्रदर्शन गिरावट

Gitlab.com मा क्यानरी र मुख्य वेब अनुप्रयोगहरूमा सुस्तता र त्रुटिहरूको बढ्दो आवृत्तिको कारणले गर्दा घटना भएको हो। धेरै Apdex मानहरू उल्लङ्घन गरियो।

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

कुञ्जी खोजीहरू

यहाँ केहि चीजहरू छन् जुन मैले मेरो हप्ता ड्यूटीमा सिकेको छु।

1. मानकबाट विचलन पत्ता लगाउँदा अलर्टहरू सबैभन्दा उपयोगी हुन्छन्।

अलर्टहरूलाई धेरै प्रकारमा विभाजन गर्न सकिन्छ:

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

सामान्यतया, प्रकार 2 र 3 ड्यूटीमा SREs को लागी अधिक उपयोगी छन्, किनकि तिनीहरूले प्रक्रियामा मानकबाट विचलन प्रकट गर्दछ।

2. धेरै अलर्टहरू घटनाहरूमा कहिल्यै बढ्दैनन्।

SR इन्जिनियरहरूले अलर्टहरूको निरन्तर स्ट्रिमसँग सम्झौता गर्छन्, जसमध्ये धेरै वास्तवमा महत्वपूर्ण छैनन्।

त्यसोभए किन तपाईका अलर्टहरूलाई वास्तवमै महत्त्वपूर्ण व्यक्तिहरूमा सीमित नगर्नुहोस्? यस दृष्टिकोणको साथ, तथापि, तपाईंले स्नोबललाई वास्तविक समस्यामा परिणत गर्ने प्रारम्भिक लक्षणहरू पहिचान गर्न सक्नुहुन्न जसले ठूलो क्षतिलाई धम्की दिन्छ।

अन-कल SRE को काम भनेको कुन अलर्टहरूले वास्तवमा कुनै गम्भीर कुरालाई सङ्केत गर्छ, र तिनलाई बढाएर व्यवहार गर्न आवश्यक छ कि छैन भनेर निर्धारण गर्नु हो। मलाई शंका छ कि यो अलर्टहरूको लचिलोपनको कारणले पनि हो: माथि वर्णन गरिएको अवस्था अनुसार अलर्टहरू कन्फिगर गर्ने धेरै स्तरहरू वा "स्मार्ट" तरिकाहरू छन् भने यो राम्रो हुनेछ।

सुविधा सुझाव: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. ड्युटीमा रहेका हाम्रा SRE ले धेरै उपकरणहरू प्रयोग गर्छन्।

आन्तरिक:

• GitLab इन्फ्रा प्रोजेक्ट: रनबुकहरू यहाँ लाइभ हुन्छन्, शिफ्ट/हप्ता असाइनमेन्टहरू, घटना प्रतिक्रिया कार्यहरू।
• GitLab मुद्दाहरू: अनुसन्धान, समीक्षा, र मर्मतसम्भार पनि मुद्दाहरूमा ट्र्याक गरिन्छ।
• GitLab लेबलहरू: स्वचालन कार्यहरू विशिष्ट लेबलहरू प्रयोग गरेर सुरु गरिन्छ, जुन बटहरूले कार्य गतिविधि ट्र्याक गर्न प्रयोग गर्दछ।

बाह्य:

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

र धेरै धेरै अन्य।

4. GitLab सँग GitLab.com को निगरानी असफलता को एकल बिन्दु हो

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

5. GitLab मा थप्न विचार गर्न केहि सुविधाहरू

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

SRE इन्जिनियरहरू धेरै जटिलताहरूको साथ कठिन समय छ। यी मुद्दाहरूलाई सम्बोधन गर्ने थप GitLab उत्पादनहरू हेर्न यो राम्रो हुनेछ। हामी पहिले नै उत्पादनमा केही थपहरूमा काम गरिरहेका छौं जसले माथि उल्लेखित कार्यप्रवाहहरूलाई सजिलो बनाउँदछ। मा उपलब्ध विवरणहरू Ops उत्पादन दृष्टि खण्ड.

हामी २०२० मा यी सबै उत्कृष्ट सुविधाहरू सँगै ल्याउन टोलीलाई विस्तार गर्दैछौं। यदि रुचि छ भने, कृपया जाँच गर्नुहोस् रिक्त पदहरू, र कुनै पनि प्रश्नको साथ हाम्रो टोलीमा कसैलाई सम्पर्क गर्न नहिचकिचाउनुहोस्।

स्रोत: www.habr.com