SRE (Site Reliability Engineering) არის მიდგომა ვებ პროექტების ხელმისაწვდომობის უზრუნველსაყოფად. ის განიხილება DevOps-ის ჩარჩოდ და საუბრობს იმაზე, თუ როგორ მიაღწიოთ წარმატებას DevOps პრაქტიკის გამოყენებაში. თარგმანი ამ სტატიაში თავი 4 მომსახურების დონის მიზნები წიგნები საიტის საიმედოობის ინჟინერია Google-ისგან. მე თვითონ მოვამზადე ეს თარგმანი და ვეყრდნობოდი საკუთარ გამოცდილებას მონიტორინგის პროცესების გაგებაში. ტელეგრამის არხზე monitorim_it и ბოლო პოსტი ჰაბრეზე მე ასევე გამოვაქვეყნე იმავე წიგნის მე-6 თავის თარგმანი მომსახურების დონის მიზნების შესახებ.

თარგმანი კატის მიერ. ისიამოვნეთ კითხვით!

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

ჩვენ ვიყენებთ ჩვენს ინტუიციას, გამოცდილებას და გაგებას, რომ მომხმარებელთა სურვილი გაიგონ სერვისის დონის ინდიკატორები (SLIs), სერვისის დონის მიზნები (SLOs) და მომსახურების დონის ხელშეკრულებები (SLAs). ეს ზომები აღწერს ძირითად მეტრიკას, რომლის მონიტორინგიც გვინდა და რომლებზეც ჩვენ ვიმოქმედებთ, თუ ვერ მივაწოდებთ მომსახურების მოსალოდნელ ხარისხს. საბოლოო ჯამში, სწორი მეტრიკის არჩევა დაგეხმარებათ სწორი ქმედებების წარმართვაში, თუ რამე არასწორედ მოხდება, და ასევე აძლევს SRE გუნდს ნდობას სერვისის სიჯანსაღეში.

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

მომსახურების დონის ტერმინოლოგია

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

P RЅRґReRєR ° C RѕSЂS <

SLI არის მომსახურების დონის ინდიკატორი - მოწოდებული მომსახურების დონის ერთი ასპექტის საგულდაგულოდ განსაზღვრული რაოდენობრივი საზომი.

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

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

SLI-ის კიდევ ერთი ტიპი, რომელიც მნიშვნელოვანია SRE-ებისთვის, არის ხელმისაწვდომობა, ან დროის ის ნაწილი, რომლის დროსაც შესაძლებელია სერვისის გამოყენება. ხშირად განისაზღვრება, როგორც წარმატებული მოთხოვნების მაჩვენებელი, რომელსაც ზოგჯერ შემოსავლიანობას უწოდებენ. (Lifetime - ალბათობა იმისა, რომ მონაცემები შეინახება დიდი ხნის განმავლობაში - ასევე მნიშვნელოვანია მონაცემთა შენახვის სისტემებისთვის.) მიუხედავად იმისა, რომ 100% ხელმისაწვდომობა შეუძლებელია, ხელმისაწვდომობა 100% -თან ახლოს ხშირად მიიღწევა; ხელმისაწვდომობის მნიშვნელობები გამოიხატება როგორც "ცხრათა" რაოდენობა » ხელმისაწვდომობის პროცენტი. მაგალითად, 99% და 99,999% ხელმისაწვდომობა შეიძლება იყოს მონიშნული, როგორც "2 ცხრა" და "5 ცხრა". Google Compute Engine-ის ამჟამინდელი განცხადებული ხელმისაწვდომობის მიზანია "სამ და ნახევარი ცხრა" ან 99,95%.

მიზნები

SLO არის მომსახურების დონის მიზანი: სამიზნე მნიშვნელობა ან მნიშვნელობების დიაპაზონი მომსახურების დონისთვის, რომელიც იზომება SLI-ით. SLO-სთვის ნორმალური მნიშვნელობა არის „SLI ≤ Target“ ან „Lower Limit ≤ SLI ≤ Upper Limit“. მაგალითად, შეიძლება გადავწყვიტოთ, რომ შექსპირის ძიების შედეგებს „სწრაფად“ დავაბრუნებთ SLO-ის დაყენებით საძიებო მოთხოვნის საშუალო შეყოვნებაზე 100 მილიწამზე ნაკლები.

სწორი SLO-ს არჩევა რთული პროცესია. პირველი, თქვენ ყოველთვის არ შეგიძლიათ აირჩიოთ კონკრეტული მნიშვნელობა. თქვენი სერვისისთვის გარე შემომავალი HTTP მოთხოვნებისთვის, Query Per Second (QPS) მეტრიკა, პირველ რიგში, განისაზღვრება თქვენი მომხმარებლების სურვილით, მოინახულონ თქვენი სერვისი, და თქვენ არ შეგიძლიათ ამისთვის SLO-ის დაყენება.

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

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

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

შეთანხმებები

სერვისის დონის შეთანხმება არის აშკარა ან იმპლიციტური კონტრაქტი თქვენს მომხმარებლებთან, რომელიც მოიცავს მათ მიერ შემავალ SLO-ებთან შეხვედრის (ან არ შეხვედრის) შედეგებს. შედეგები ყველაზე ადვილად აღიარებულია, როდესაც ისინი ფინანსურია - ფასდაკლება ან ჯარიმა - მაგრამ მათ შეუძლიათ მიიღონ სხვა ფორმები. SLO-სა და SLA-ს შორის განსხვავებაზე საუბრის მარტივი გზაა კითხვა: „რა მოხდება, თუ SLO-ები არ დაკმაყოფილდება?“ თუ არ არსებობს მკაფიო შედეგები, თქვენ თითქმის ნამდვილად უყურებთ SLO-ს.

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

Google Search არის მნიშვნელოვანი სერვისის მაგალითი, რომელსაც არ აქვს საჯარო SLA: ჩვენ გვინდა, რომ ყველამ გამოიყენოს Search რაც შეიძლება ეფექტურად, მაგრამ ჩვენ არ გავაფორმეთ კონტრაქტი მსოფლიოსთან. თუმცა, ჯერ კიდევ არსებობს შედეგები, თუ ძებნა მიუწვდომელია - მიუწვდომლობა იწვევს ჩვენი რეპუტაციის დაქვეითებას და ასევე სარეკლამო შემოსავლის შემცირებას. Google-ის ბევრ სხვა სერვისს, როგორიცაა Google for Work, აქვს მკაფიო მომსახურების დონის შეთანხმებები მომხმარებლებთან. მიუხედავად იმისა, აქვს თუ არა კონკრეტულ სერვისს SLA, მნიშვნელოვანია SLI და SLO-ის განსაზღვრა და მათი გამოყენება სერვისის მართვისთვის.

ამდენი თეორია - ახლა გამოცდილება.

ინდიკატორები პრაქტიკაში

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

რა გაინტერესებთ თქვენ და თქვენს მომხმარებლებს?

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

სერვისები ზოგადად შეიძლება დაიყოს რამდენიმე ნაწილად SLI-ის თვალსაზრისით, რომლებიც მათთვის შესაბამისია:

• მორგებული წინა სისტემები, როგორიცაა შექსპირის სერვისის საძიებო ინტერფეისები ჩვენი მაგალითიდან. ისინი ხელმისაწვდომი უნდა იყოს, არ ჰქონდეს შეფერხებები და ჰქონდეს საკმარისი გამტარობა. შესაბამისად, შეიძლება დაისვას კითხვები: შეგვიძლია თუ არა თხოვნაზე პასუხის გაცემა? რამდენი დრო დასჭირდა თხოვნაზე პასუხის გაცემას? რამდენი მოთხოვნის დამუშავება შეიძლება?
• შენახვის სისტემები. ისინი აფასებენ რეაგირების დაბალ შეყოვნებას, ხელმისაწვდომობას და გამძლეობას. დაკავშირებული კითხვები: რამდენი დრო სჭირდება მონაცემების წაკითხვას ან ჩაწერას? შეგვიძლია თუ არა წვდომა მონაცემებზე მოთხოვნის შემთხვევაში? არის თუ არა მონაცემები ხელმისაწვდომი როცა გვჭირდება? იხილეთ თავი 26 მონაცემთა მთლიანობა: რას კითხულობთ არის ის, რასაც წერთ ამ საკითხების დეტალური განხილვისთვის.
• დიდი მონაცემთა სისტემები, როგორიცაა მონაცემთა დამუშავების მილსადენები, ეყრდნობა გამტარუნარიანობას და შეკითხვის დამუშავების შეყოვნებას. დაკავშირებული კითხვები: რამდენი მონაცემი მუშავდება? რამდენი დრო სჭირდება მონაცემთა გადაადგილებას მოთხოვნის მიღებიდან პასუხის გაცემამდე? (სისტემის ზოგიერთ ნაწილს ასევე შეიძლება ჰქონდეს შეფერხებები გარკვეულ ეტაპებზე.)

ინდიკატორების შეგროვება

მომსახურების დონის მრავალი ინდიკატორი ყველაზე ბუნებრივად გროვდება სერვერის მხარეს, მონიტორინგის სისტემის გამოყენებით, როგორიცაა Borgmon (იხ. ქვემოთ). თავი 10 პრაქტიკული გაფრთხილებები დროის სერიების მონაცემებზე დაყრდნობით) ან პრომეთე, ან უბრალოდ პერიოდულად აანალიზებს ჟურნალებს, HTTP პასუხების იდენტიფიცირებას 500 სტატუსით. თუმცა, ზოგიერთი სისტემა აღჭურვილი უნდა იყოს კლიენტის მხრიდან მეტრიკის შეგროვებით, რადგან კლიენტის მხრიდან მონიტორინგის ნაკლებობამ შეიძლება გამოიწვიოს მთელი რიგი პრობლემების გამოტოვება, რომლებიც გავლენას ახდენს მომხმარებლები, მაგრამ არ იმოქმედებს სერვერის მეტრიკაზე. მაგალითად, ჩვენი შექსპირის საძიებო ტესტის აპლიკაციის საპასუხო შეყოვნებაზე ფოკუსირებამ შეიძლება გამოიწვიოს მომხმარებლის მხრიდან შეყოვნება JavaScript-ის პრობლემების გამო: ამ შემთხვევაში, იმის გაზომვა, თუ რამდენი დრო სჭირდება ბრაუზერს გვერდის დასამუშავებლად, უკეთესი მეტრიკაა.

Აგრეგაცია

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

ზოგიერთი მეტრიკა, როგორც ჩანს, მარტივია, როგორიცაა მოთხოვნა წამში, მაგრამ ეს აშკარად მარტივი გაზომვაც კი დროთა განმავლობაში აგროვებს მონაცემებს. არის თუ არა გაზომვა მიღებული კონკრეტულად წამში ერთხელ თუ გაზომვა საშუალოდ ფასდება წუთში მოთხოვნის რაოდენობაზე? ამ უკანასკნელ ვარიანტს შეუძლია დამალოს მოთხოვნების გაცილებით მეტი მყისიერი რაოდენობა, რომელიც გრძელდება მხოლოდ რამდენიმე წამში. განვიხილოთ სისტემა, რომელიც ემსახურება 200 მოთხოვნას წამში ლუწი რიცხვებით და 0 დანარჩენ დროს. მუდმივი საშუალო მნიშვნელობის სახით 100 მოთხოვნა წამში და ორჯერ მყისიერი დატვირთვა არ არის იგივე. ანალოგიურად, საშუალო შეფერხების შეფერხება შეიძლება მიმზიდველად გამოიყურებოდეს, მაგრამ ის მალავს მნიშვნელოვან დეტალს: შესაძლებელია, რომ მოთხოვნების უმეტესობა იყოს სწრაფი, მაგრამ იქნება ბევრი მოთხოვნა, რომელიც ნელია.

ინდიკატორების უმეტესობა უკეთესად განიხილება როგორც განაწილება, ვიდრე საშუალო. მაგალითად, SLI შეყოვნებისთვის, ზოგიერთი მოთხოვნა სწრაფად დამუშავდება, ზოგიერთს კი ყოველთვის უფრო მეტი დრო დასჭირდება, ზოგჯერ გაცილებით მეტი დრო. უბრალო საშუალოს შეუძლია ამ ხანგრძლივი შეფერხებების დამალვა. სურათი გვიჩვენებს მაგალითს: მიუხედავად იმისა, რომ ტიპიური მოთხოვნის შესრულებას დაახლოებით 50 ms სჭირდება, მოთხოვნების 5% 20-ჯერ ნელია! მხოლოდ საშუალო შეყოვნებაზე დაფუძნებული მონიტორინგი და გაფრთხილება არ აჩვენებს ქცევის ცვლილებებს მთელი დღის განმავლობაში, როდესაც ფაქტიურად შესამჩნევია ცვლილებები ზოგიერთი მოთხოვნის დამუშავების დროს (უმაღლესი ხაზი).

50, 85, 95 და 99 პროცენტული სისტემის შეყოვნება. Y ღერძი არის ლოგარითმული ფორმატით.

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

შენიშვნა სტატისტიკურ შეცდომებზე

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

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

ინდიკატორების სტანდარტიზაცია

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

• დაგროვების ინტერვალები: „საშუალოდ 1 წუთზე მეტი“
• აგრეგაციის სფეროები: „ყველა ამოცანა კლასტერში“
• რამდენად ხშირად ხდება გაზომვები: "ყოველ 10 წამში"
• რა მოთხოვნები შედის: "HTTP GET შავი ყუთის მონიტორინგის სამუშაოებიდან"
• როგორ მიიღება მონაცემები: "სერვერზე გაზომილი ჩვენი მონიტორინგის წყალობით"
• მონაცემთა წვდომის შეყოვნება: "დრო ბოლო ბაიტამდე"

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

მიზნები პრაქტიკაში

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

განსაზღვრეთ მიზნები

მაქსიმალური სიცხადისთვის, უნდა განისაზღვროს, თუ როგორ იზომება SLO-ები და რა პირობებშია ისინი მოქმედი. მაგალითად, შეგვიძლია ვთქვათ შემდეგი (მეორე ხაზი იგივეა, რაც პირველი, მაგრამ იყენებს SLI ნაგულისხმევს):

• Get RPC ზარების 99% (საშუალოდ 1 წუთზე მეტი) დასრულდება 100ms-ზე ნაკლებ დროში (იზომება ყველა backend სერვერზე).
• Get RPC ზარების 99% დასრულდება 100 ms-ზე ნაკლებ დროში.

თუ შესრულების მრუდების ფორმა მნიშვნელოვანია, შეგიძლიათ მიუთითოთ მრავალი SLO:

• Get RPC ზარების 90% სრულდება 1 ms-ზე ნაკლებ დროში.
• Get RPC ზარების 99% სრულდება 10 ms-ზე ნაკლებ დროში.
• Get RPC ზარების 99.9% სრულდება 100 ms-ზე ნაკლებ დროში.

თუ თქვენი მომხმარებლები წარმოქმნიან ჰეტეროგენულ დატვირთვას: ნაყარი დამუშავება (რისთვისაც გამტარუნარიანობა მნიშვნელოვანია) და ინტერაქტიული დამუშავება (რისთვისაც მნიშვნელოვანია შეყოვნება), შეიძლება ღირებული იყოს თითოეული დატვირთვის კლასისთვის ცალკეული მიზნების განსაზღვრა:

• მომხმარებელთა მოთხოვნების 95% მოითხოვს გამტარუნარიანობას. დააყენეთ შესრულებული RPC ზარების რაოდენობა <1 წმ.
• კლიენტების 99% ზრუნავს შეყოვნებაზე. დააყენეთ RPC ზარების რაოდენობა ტრაფიკით <1 KB და გაშვებული <10 ms.

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

SLO-ს დარღვევის პროცენტული მაჩვენებელი შეიძლება შევადაროთ შეცდომის ბიუჯეტს (იხ. თავი 3 და ნაწილი "შეცდომის ბიუჯეტის მოტივაცია"), განსხვავების მნიშვნელობით გამოიყენება როგორც შესატანი პროცესი, რომელიც წყვეტს როდის განათავსოს ახალი გამოშვებები.

სამიზნე მნიშვნელობების შერჩევა

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

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

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

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

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

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

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

აკონტროლეთ თქვენი გაზომვები

SLI და SLO არის ძირითადი ელემენტები, რომლებიც გამოიყენება სისტემების მართვისთვის:

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

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

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

თქვენი მომხმარებლებისთვის რეალისტური მოლოდინების დასაყენებლად გამოიყენეთ შემდეგი ტაქტიკებიდან ერთი ან ორივე:

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

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

შეთანხმებები პრაქტიკაში

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

გმადლობთ, რომ თარგმანი ბოლომდე წაიკითხეთ. გამოიწერეთ ჩემი ტელეგრამის არხი მონიტორინგის შესახებ monitorim_it и ბლოგი საშუალოზე.

წყარო: www.habr.com