Slurm SRE. სრული ექსპერიმენტი Booking.com-ისა და Google.com-ის ექსპერტებთან

ჩვენს გუნდს უყვარს ექსპერიმენტები. თითოეული Slurm არ არის წინას სტატიკური გამეორება, არამედ გამოცდილებაზე ასახვა და კარგიდან უკეთესზე გადასვლა. მაგრამ თან Slurm SRE ჩვენ გადავწყვიტეთ გამოგვეყენებინა სრულიად ახალი ფორმატი - მონაწილეებს მივცეთ „საბრძოლო“ მაქსიმალურად მიახლოებული პირობები.

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

მონაწილეები დაიყვნენ გუნდებად, რათა ენერგიული კონკურენტული სულისკვეთება არავის მისცემდა ძილში ან „Angry Birds“-ის გაშვებას iPhone-ზე, დიმიტრი ანატოლიევიჩის მაგალითზე.

პრობლემები, ხარვეზები, შეცდომები და ამოცანები მონაწილეებს ოთხმა მენტორმა მიაწოდა. ივან კრუგლოვი, Booking.com-ის მთავარი დეველოპერი (ნიდერლანდები). ბენ ტაილერი, Booking.com-ის მთავარი დეველოპერი (აშშ). ედუარდ მედვედევი, CTO ვოლფრამის ლაბორატორიაში (გერმანია). ევგენი ვარავვა, Google-ის გენერალური დეველოპერი (სან ფრანცისკო).

უფრო მეტიც, მონაწილეები იყოფიან გუნდებად და ეჯიბრებიან ერთმანეთს. საინტერესოა?

ივანე, ბენი, ედუარდი და ევგენი შეჯიბრის დაწყებამდე კეთილი ლენინური თვალებით უყურებენ Slurm SRE-ის ღარიბ მონაწილეებს.

ასე რომ, ამოცანა:

ჩვენ ჩვენი ვართ, ჩვენ ავაშენებთ ახალ სამყაროს...

არის კინოს ბილეთების აგრეგატორის ვებგვერდი. ინციდენტები იგონებს მენტორებს წინასწარ დამუშავებულ სცენარში (თუმცა არავინ გამორიცხავს განსაკუთრებით დახვეწილ და მზაკვრულ იმპროვიზაციას), საიტის შესრულება აღწერილია სხვადასხვა მეტრიკით. პრობლემები შეიძლება ძალიან განსხვავებული იყოს: მულენ რუჟის თეატრის ბილეთები არ იტვირთება მონაცემთა ბაზაში; ფილმებისა და სპექტაკლების პლაკატები იტვირთება მონაცემთა ბაზაში 10 წამზე მეტ ხანში; ინდივიდუალური ფილმის აღწერა იყინება; შეკვეთების 0,1% უკვე რეზერვირებულია; დროდადრო გადახდის დამუშავების სისტემა ერთი-ორი წუთის განმავლობაში იშლება. და ბევრი, ბევრი, ბევრი უსიამოვნო რამ, რაც შეიძლება დაემართოს Slurm SRE მონაწილეს თავის რეალურ სამუშაოზე.

ჩვენ მზად ვართ გავუმკლავდეთ ყველაფერს...და ყველას.

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

ინტენსიური საიტისთვის, ჩვენ შევქმენით SLO, SLI, SLA ინდიკატორები, განვავითარეთ არქიტექტურა და ინფრასტრუქტურა, განვათავსეთ საიტი, დავაყენეთ მონიტორინგი და გაფრთხილება. და მივდივართ.

SLO, SLI, SLA

SLI - მომსახურების დონის ინდიკატორები. SLO არის მომსახურების დონის მიზნები. SLA - მომსახურების დონის ხელშეკრულებები.

SLA არის ITIL მეთოდოლოგიის ტერმინი, რომელიც აღნიშნავს ოფიციალურ შეთანხმებას მომსახურების მომხმარებელსა და მის მიმწოდებელს შორის, რომელიც შეიცავს მომსახურების აღწერას, მხარეთა უფლებებსა და მოვალეობებს და, რაც მთავარია, ხარისხის შეთანხმებულ დონეს ამ მომსახურების მიწოდებისთვის. სერვისი.

SLO არის მომსახურების დონის მიზანი: სამიზნე მნიშვნელობა ან მნიშვნელობების დიაპაზონი მომსახურების დონისთვის, რომელიც იზომება SLI-ით. SLO-სთვის ნორმალური მნიშვნელობა არის „SLI ≤ Target“ ან „Lower Limit ≤ SLI ≤ Upper Limit“.

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

ჯერ თვითმფრინავებს დავამტვრევთ და მერე გოგოებს და მერე გოგოებს...

შიდა და გარე ფაქტორებმა SLO-ს „გაფუჭება“ პირველივე წუთებიდანვე დაიწყეს. ყველაფერი ადმინისტრატორების თავზე დაეცა - დეველოპერის შეცდომები, ინფრასტრუქტურის გაუმართაობა, ვიზიტორების შემოდინება და DDoS შეტევები. ყველაფერი, რაც აუარესებს SLO-ს.

"- ძვირფასო მონაწილეებო, მე მეჩქარება გაგახაროთ, პირველი, რაც თქვენ ვერ შეძლებთ არის... ყველაფერი!"

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

ჩვენ არ ვართ დურგლები და არც დურგლები...

შემდეგ მონაწილეებმა დაიწყეს ნივთების გამოსწორება - მთავარია გაიგოთ, რა უნდა დაიჭიროთ პირველ რიგში.

- უფალო, მე არასოდეს მინახავს, ​​რომ ასე გატეხილიყო, ამ სახით და ასეთ მდგომარეობაში!

ასე რომ, ავარია მოხდა. გადახდის დამუშავების სერვისი გათიშულია. როგორ მოვიქცეთ ფუნქციონირების უმოკლეს დროში აღსადგენად?

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

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

"რა საშინელება გამოვიდა?!"

ამოისუნთქეთ... და დაასრულეთ ვარჯიში

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

„სხვას ვის უნდა ტანჯვა! - ᲛᲔ!"

გუნდების წარმატებები მკაცრად და მკაფიოდ ჩაიწერა ელექტრონულ დაფაზე.

პირველი ადგილებისთვის - ბონუსი დაინტერესებული მხარეებისგან.

წყარო: www.habr.com