SRE इंजिनियर इंटर्न म्हणून मी एक आठवडा कसा घालवला. सॉफ्टवेअर इंजिनिअरच्या नजरेतून कर्तव्य

SRE अभियंता - प्रशिक्षणार्थी

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

मला आठवडाभर सर्वत्र एसआरई इंजिनीअरला फॉलो करावा लागला. म्हणजेच, मी हँडओव्हरच्या वेळी उपस्थित होतो, त्याच अलर्ट चॅनेलचे निरीक्षण केले आणि घटना घडल्यास आणि केव्हा घडल्या त्यांना प्रतिसाद दिला.

घटना

आठवडाभरात २ घटना घडल्या.

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

GitLab.com ने बुधवारी वापरात मोठी वाढ पाहिली GitLab धावपटू'a, क्रिप्टोकरन्सी खाण करण्यासाठी धावपटूच्या मिनिटांचा वापर करण्याच्या प्रयत्नांमुळे झाले. आमच्या स्वतःचे उल्लंघन तटस्थीकरण साधन वापरून ही घटना हाताळली गेली, ज्यामुळे धावपटूची कार्ये थांबतात आणि त्याच्याशी संबंधित प्रकल्प आणि खाते हटवते.

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

2. कॅनरी आणि मुख्य ऍप्लिकेशन्सचे कार्यप्रदर्शन खराब होणे

Gitlab.com वरील कॅनरी आणि मुख्य वेब ऍप्लिकेशन्समध्ये मंदी आणि त्रुटींची वाढती वारंवारता यामुळे ही घटना घडली. अनेक Apdex मूल्यांचे उल्लंघन झाले.

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

की निष्कर्ष

माझ्या आठवड्यात ड्युटी दरम्यान मी शिकलेल्या काही गोष्टी येथे आहेत.

1. सर्वसामान्य प्रमाणातील विचलन शोधताना सूचना सर्वात उपयुक्त असतात.

सूचना अनेक प्रकारांमध्ये विभागल्या जाऊ शकतात:

• विशिष्ट थ्रेशोल्ड मूल्यावर आधारित सूचना, जसे की “प्रति सेकंद १० 10xx त्रुटी आल्या.”
• सूचना ज्यामध्ये थ्रेशोल्ड हे टक्केवारीचे मूल्य आहे जसे की "दिलेल्या वेळी विनंत्यांच्या एकूण व्हॉल्यूमच्या 5% प्रति 10xx त्रुटींची वारंवारता."
• ऐतिहासिक सरासरीवर आधारित सूचना जसे की "5 व्या टक्केवारीवर 90xx त्रुटी".

साधारणपणे बोलायचे झाले तर, ड्युटीवरील SRE साठी प्रकार 2 आणि 3 अधिक उपयुक्त आहेत, कारण ते प्रक्रियेतील सर्वसामान्य प्रमाणातील विचलन प्रकट करतात.

2. अनेक इशारे घटनांकडे कधीच वाढवत नाहीत.

SR अभियंते सतत सतर्कतेचा सामना करतात, ज्यापैकी बरेच गंभीर नसतात.

तर मग तुमचे अलर्ट केवळ खरोखरच महत्त्वाच्या गोष्टींपुरते मर्यादित का ठेवू नये? तथापि, या दृष्टीकोनातून, स्नोबॉलमुळे मोठ्या नुकसानास धोका असलेल्या वास्तविक समस्येत काय होईल याची सुरुवातीची लक्षणे तुम्हाला कदाचित ओळखता येणार नाहीत.

ऑन-कॉल SRE चे कार्य हे ठरवणे आहे की कोणते अलर्ट खरोखर काहीतरी गंभीर सूचित करतात आणि त्यांना वाढवण्याची आणि हाताळण्याची आवश्यकता आहे का. मला शंका आहे की हे अलर्टच्या लवचिकतेमुळे देखील आहे: वर वर्णन केलेल्या परिस्थितीनुसार अलर्ट कॉन्फिगर करण्याचे अनेक स्तर किंवा "स्मार्ट" मार्ग असल्यास ते चांगले होईल.

वैशिष्ट्य सूचना: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. कर्तव्यावर असलेले आमचे SRE बरेच साधने वापरतात.

अंतर्गत:

• GitLab इन्फ्रा प्रोजेक्ट: रनबुक्स येथे राहतात, शिफ्ट/आठवडा असाइनमेंट, घटना प्रतिसाद कार्ये.
• GitLab समस्या: समस्यांमध्ये तपास, पुनरावलोकने आणि देखभाल देखील ट्रॅक केली जाते.
• GitLab लेबल्स: ऑटोमेशन टास्क विशिष्ट लेबले वापरून लाँच केले जातात, जे कार्य क्रियाकलाप ट्रॅक करण्यासाठी बॉट्स वापरतात.

बाह्य:

• PagerDuty: अलर्ट
• स्लॅक: PagerDuty/AlertManager संदेश प्रवाह येथे जातो. विविध कार्ये करण्यासाठी स्लॅश कमांडसह एकत्रीकरण, जसे की अलर्ट बंद करणे किंवा एखाद्या घटनेकडे वाढ करणे.
• ग्राफना: दीर्घकालीन ट्रेंडवर लक्ष केंद्रित करून मेट्रिक्सचे व्हिज्युअलायझेशन.
• किबाना: व्हिज्युअलायझेशन/लॉग शोध, विशिष्ट घटनांमध्ये खोलवर जाण्याची क्षमता देते.
• झूम: झूममध्ये सतत चालू असलेली “ब्रेकआउट रूम” असते. हे SRE अभियंत्यांना एक खोली तयार करणे आणि सहभागींना लिंक न करता मौल्यवान वेळ वाया न घालवता घटनांवर त्वरीत चर्चा करण्यास अनुमती देते.

आणि इतर अनेक.

4. GitLab.com सह GitLab चे निरीक्षण करणे हा अपयशाचा एकच मुद्दा आहे

GitLab.com ला सेवा बंद पडल्यास, समस्येचे निराकरण करण्याच्या आमच्या क्षमतेवर त्याचा परिणाम होऊ नये असे आम्हाला वाटते. GitLab.com व्यवस्थापित करण्यासाठी दुसरे GitLab उदाहरण लाँच करून हे थांबवले जाऊ शकते. खरं तर, हे आधीच आमच्यासाठी कार्य करते: https://ops.gitlab.net/.

5. GitLab मध्ये जोडण्याचा विचार करण्यासाठी काही वैशिष्ट्ये

• बहु-वापरकर्ता कार्य संपादन, Google डॉक्स प्रमाणेच. हे इव्हेंट दरम्यानच्या घटनांवरील कार्ये तसेच डीब्रीफिंगच्या कार्यांमध्ये मदत करेल. दोन्ही प्रकरणांमध्ये, अनेक सहभागींना रिअल टाइममध्ये काहीतरी जोडण्याची आवश्यकता असू शकते.
• कार्यांसाठी अधिक वेबहुक. आतून वेगवेगळ्या GitLab वर्कफ्लो पायऱ्या चालवण्याची क्षमता स्लॅक इंटिग्रेशनवरील तुमचा अवलंबित्व कमी करण्यात मदत करेल. उदाहरणार्थ, GitLab समस्येमध्ये स्लॅश कमांडद्वारे PagerDuty मध्ये अलर्टला अनुमती देण्याची क्षमता.
  निष्कर्ष

SRE अभियंत्यांना बर्‍याच जटिलतेसह कठीण वेळ असतो. या समस्यांचे निराकरण करणारी आणखी GitLab उत्पादने पाहणे चांगले होईल. आम्‍ही आधीच उत्‍पादनात काही अॅडिशन्सवर काम करत आहोत जे वर नमूद केलेले वर्कफ्लो सोपे करतील. येथे तपशील उपलब्ध आहेत Ops उत्पादन दृष्टी विभाग.

या सर्व उत्तम वैशिष्ट्यांना एकत्र आणण्यासाठी आम्ही २०२० मध्ये संघाचा विस्तार करत आहोत. स्वारस्य असल्यास, कृपया पहा रिक्त पदे, आणि कोणत्याही प्रश्नांसाठी आमच्या कार्यसंघातील कोणाशीही मोकळ्या मनाने संपर्क साधा.

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