როგორ გავატარე ერთი კვირა, როგორც SRE ინჟინრის სტაჟიორი. მოვალეობა პროგრამული უზრუნველყოფის ინჟინრის თვალით

SRE ინჟინერი - სტაჟიორი

პირველ რიგში, ნება მომეცით წარმოგიდგინოთ ჩემი თავი. ᲛᲔ - @tristan.read, ფრონტ-ენდის ინჟინერი ჯგუფში მონიტორი::ჯანმრთელობა GitLab. გასულ კვირას მე მქონდა პატივი სტაჟირებას ჩვენს ერთ-ერთ გამოძახებულ SRE ინჟინერთან. მიზანი იყო დაკვირვება, თუ როგორ რეაგირებდა მორიგე ოფიცერი ინციდენტებზე ყოველდღიურად და სამუშაოზე რეალური გამოცდილების მიღება. ჩვენ გვინდა, რომ ჩვენმა ინჟინრებმა უკეთ გაიგონ მომხმარებლის საჭიროებები ფუნქციები მონიტორი::ჯანმრთელობა.

SRE ინჟინერს ყველგან უნდა გავყოლოდი ერთი კვირის განმავლობაში. ანუ, მე ვიყავი ჩაბარების დროს, ვადევნებდი თვალყურს იმავე სიგნალიზაციის არხებს და ვპასუხობდი ინციდენტებს თუ და როდის ხდებოდა.

ინციდენტები

ერთი კვირის განმავლობაში 2 შემთხვევა იყო.

1. კრიპტო მაინერი

GitLab.com-მა ოთხშაბათს გამოყენების ნახტომი დაინახა GitLab Runner"ა, გამოწვეული მცდელობით, გამოიყენოს მორბენალი წუთები კრიპტოვალუტის მაინინგისთვის. ინციდენტი განიხილება ჩვენი საკუთარი დარღვევების განეიტრალების ინსტრუმენტის გამოყენებით, რომელიც აჩერებს მორბენალს დავალებებს და წაშლის პროექტს და მასთან დაკავშირებულ ანგარიშს.

ეს მოვლენა რომ არ ყოფილიყო შემჩნეული, ავტომატური ხელსაწყო დაიჭერდა მას, მაგრამ ამ შემთხვევაში, SRE ინჟინერმა შეამჩნია პირველი დარღვევა. შეიქმნა ინციდენტის დავალება, მაგრამ ამის შესახებ ინფორმაცია დახურულია.

2. კანარის და ძირითადი აპლიკაციების შესრულების დეგრადაცია

ინციდენტი გამოწვეული იყო შენელებით და შეცდომების გაზრდილი სიხშირით კანარის და მთავარ ვებ აპლიკაციებში Gitlab.com-ზე. დაირღვა Apdex-ის რამდენიმე მნიშვნელობა.

გახსენით ინციდენტის დავალება: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

ძირითადი აღმოჩენები

აქ არის რამდენიმე რამ, რაც ვისწავლე ჩემი მორიგე კვირის განმავლობაში.

1. სიგნალიზაცია ყველაზე სასარგებლოა ნორმიდან გადახრების გამოვლენისას.

გაფრთხილებები შეიძლება დაიყოს რამდენიმე ტიპად:

• გაფრთხილებები დაფუძნებული გარკვეულ ზღვრულ მნიშვნელობაზე, როგორიცაა „10 5xx შეცდომა მოხდა წამში“.
• გაფრთხილებები, რომლებშიც ბარიერი არის პროცენტული მნიშვნელობა, როგორიცაა „5xx შეცდომების სიხშირე მოცემულ დროს მოთხოვნების მთლიანი მოცულობის 10%-ზე“.
• გაფრთხილებები ისტორიულ საშუალოზე დაფუძნებული, როგორიცაა „5xx შეცდომები 90 პროცენტულზე“.

ზოგადად, მე-2 და მე-3 ტიპები უფრო სასარგებლოა მორიგე SRE-ებისთვის, რადგან ისინი ავლენენ გადახრებს ნორმიდან პროცესში.

2. ბევრი გაფრთხილება არასოდეს გადაიზრდება ინციდენტებად.

SR ინჟინრები გაფრთხილების მუდმივ ნაკადს ახორციელებენ, რომელთაგან ბევრი რეალურად არ არის კრიტიკული.

მაშ, რატომ არ შემოიფარგლოთ თქვენი გაფრთხილებები მხოლოდ რეალურად მნიშვნელოვანით? თუმცა, ამ მიდგომით, თქვენ შეიძლება ვერ ამოიცნოთ ადრეული სიმპტომები იმისა, თუ რა გადააქცევს თოვლს რეალურ პრობლემად, რომელიც დიდ ზიანს ემუქრება.

გამოძახების SRE-ის ამოცანაა განსაზღვროს რომელი სიგნალიზაცია მიუთითებს რაიმე სერიოზულზე და საჭიროა თუ არა მათი გაძლიერება და მოგვარება. მეეჭვება, რომ ეს ასევე გამოწვეულია სიგნალების მოუქნელობით: უკეთესი იქნებოდა, რომ არსებობდეს რამდენიმე დონის ან "ჭკვიანი" გზა სიგნალიზაციის კონფიგურაციისთვის ზემოთ აღწერილი სიტუაციის შესაბამისად.

მახასიათებლის შემოთავაზება: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. ჩვენი SRE-ები მორიგეობით იყენებენ უამრავ ინსტრუმენტს.

შიდა:

• GitLab ინფრაპროექტი: runbooks აქ ცხოვრობს, ცვლა/კვირის დავალებები, ინციდენტებზე რეაგირების ამოცანები.
• GitLab-ის საკითხები: გამოძიებები, მიმოხილვები და ტექნიკური მომსახურება ასევე კონტროლდება საკითხებში.
• GitLab ეტიკეტები: ავტომატიზაციის ამოცანები იხსნება კონკრეტული ეტიკეტების საფუძველზე, რომლებსაც ბოტები იყენებენ დავალების აქტივობის თვალყურის დევნებისთვის.

გარე:

• PagerDuty: გაფრთხილებები
• Slack: PagerDuty/AlertManager შეტყობინებების ნაკადი აქ მიდის. სლეშის ბრძანებებთან ინტეგრაცია სხვადასხვა ამოცანების შესასრულებლად, როგორიცაა გაფრთხილების დახურვა ან ინციდენტამდე გადასვლა.
• Grafana: მეტრიკის ვიზუალიზაცია გრძელვადიან ტენდენციებზე ფოკუსირებით.
• Kibana: იძლევა ვიზუალიზაციას/ლოგის ძიებას, კონკრეტულ მოვლენებში ღრმად ჩაღრმავების უნარს.
• Zoom: Zoom-ში მუდმივად მუშაობს „ბრეაუტის ოთახი“. ეს საშუალებას აძლევს SRE ინჟინრებს სწრაფად განიხილონ მოვლენები ოთახის შექმნისა და მონაწილეთა დაკავშირების გარეშე ძვირფასი დროის დაკარგვის გარეშე.

და მრავალი სხვა.

4. GitLab.com-ის მონიტორინგი GitLab-ით არის ერთი მარცხის წერტილი

თუ GitLab.com-ს აქვს სერვისის მნიშვნელოვანი შეფერხება, არ გვინდა, რომ ეს გავლენა იქონიოს პრობლემის გადაჭრის ჩვენს უნარზე. მისი შეჩერება შესაძლებელია GitLab-ის მეორე ინსტანციის გაშვებით GitLab.com-ის სამართავად. სინამდვილეში, ეს უკვე მუშაობს ჩვენთვის: https://ops.gitlab.net/.

5. რამდენიმე ფუნქცია GitLab-ში დამატება

• მრავალ მომხმარებლის დავალების რედაქტირება, Google Docs-ის მსგავსი. ეს დაგეხმარება ღონისძიების დროს ინციდენტებთან დაკავშირებული ამოცანების შესრულებაში, ისევე როგორც დებრიფინგზე. ორივე შემთხვევაში, რამდენიმე მონაწილეს შეიძლება დასჭირდეს რაღაცის დამატება რეალურ დროში.
• მეტი ვებ-ჰუკი ამოცანებისთვის. GitLab-ის სამუშაო პროცესის სხვადასხვა ნაბიჯების შიგნიდან გაშვების შესაძლებლობა დაგეხმარებათ შეამციროთ თქვენი დამოკიდებულება Slack-ის ინტეგრაციებზე. მაგალითად, გაფრთხილების დაშვების შესაძლებლობა PagerDuty-ში slash ბრძანების მეშვეობით GitLab-ის საკითხში.
  დასკვნა

SRE ინჟინრებს უჭირთ ბევრი სირთულე. კარგი იქნება, რომ ნახოთ მეტი GitLab პროდუქტი ამ საკითხებზე. ჩვენ უკვე ვმუშაობთ პროდუქტზე რამდენიმე დამატებაზე, რომელიც გაადვილებს ზემოთ აღნიშნულ სამუშაო პროცესს. დეტალები ხელმისაწვდომია მისამართზე Ops Product Vision განყოფილება.

ჩვენ ვაფართოებთ გუნდს 2020 წელს, რათა გავაერთიანოთ ყველა ეს შესანიშნავი ფუნქცია. დაინტერესების შემთხვევაში, გთხოვთ შეამოწმოთ ვაკანსიებიდა თავისუფლად დაუკავშირდით ჩვენს გუნდს ნებისმიერ შეკითხვაზე.

წყარო: www.habr.com