რას წყვეტს SRE [BLOCK_TYPE SECTION/STEP]
მოგესალმებათ Site Reliability Engineering-ში
[BLOCK_TYPE SECTION/STEP]Site Reliability Engineering (SRE) დაიწყო Google-ში 2003 წელს. ბენ ტრეინორ სლოსმა აიღო პასუხისმგებლობა მცირე ოპერაციების გუნდზე და გადააკეთა ის ისე, თითქოს წარმოებას მართავდნენ ინჟინრები და არა ადამიანური პეიჯერები. შედეგი გახდა დიდი ინტერნეტ სერვისების მართვის სტანდარტული მოდელი. [BLOCK_TYPE SECTION/STEP]
ტრადიციული ოპერაციების გუნდები ინარჩუნებდნენ სერვისების მუშაობას ხელით შესრულებული სამუშაოს მეშვეობით: გადატვირთეთ ეს სერვერი, გამოიძახეთ ის ინჟინერი, დაწერეთ runbook, იმედი გქონდეთ რომ გაძლებს. ეს მოდელი იშლება მასშტაბის ზრდასთან ერთად. ორმოცდაათი ოპერატორისგან შემდგარი გუნდი ვერ შეძლებს ხელით გადატვირთოს ხუთი ათასი სერვერი. გარკვეული ზომის მიღმა ხელით ოპერაციები ხდება გადასახადი, რომელიც მოიხმარს ყველა პროდუქტიულ საათს. [BLOCK_TYPE SECTION/STEP]
SRE ცვლის მოდელს. სისტემების ზრდისას მეტი ოპერატორის დაქირავების ნაცვლად, SRE ქირაობს პროგრამული უზრუნველყოფის ინჟინრებს და ეუბნება მათ: დაწერეთ კოდი, რომელიც თავად შეასრულებს ოპერაციულ სამუშაოს. თქვენი სამუშაო კვალიფიცირდება როგორც პროგრამული უზრუნველყოფის ინჟინერია, რომელიც გამოიყენება ოპერაციულ პრობლემებზე. თქვენი შედეგი: ავტომატიზაცია, მონიტორინგი და ინჟინერიული საიმედოობა, არა ხელით ჩარევები.
SRE პრაქტიკას სამი საბაზისო იდეა უდევს საფუძვლად:
- Service Level Objectives (SLOs): რიცხვობრივი საიმედოობის მიზნები, წინასწარ შეთანხმებული
- Error budgets: SLO-ის ინვერსია, რომელიც იხარჯება რისკების მიღებაზე
- Toil elimination: ნებისმიერი ოპერაციული სამუშაო, რომელიც სისტემის ზომასთან ერთად წრფივად იზრდება, უნდა გაქრეს
ეს სამი იდეა გადადის SRE-ის ყველა პრაქტიკაში: პოსტმორტემები, on-call როტაციები, სიმძლავრის დაგეგმვა, მონიტორინგი და რელიზების ინჟინერია.
ტრადიციული ოპერაციები SRE-ის წინააღმდეგ
რატომ იშლება ტრადიციული ოპერაციები მასშტაბის ზრდისას
ტიპური ოპერაციების გუნდი იზრდება წრფივად იმ სისტემების რაოდენობის მიხედვით, რომლებსაც მართავს. თუ სერვერების რაოდენობა გაორმაგდება, ოპერატორების რაოდენობაც გაორმაგდება. ეს ფინანსურად მისაღებია მცირე მასშტაბის განლაგებისთვის, მაგრამ კატასტროფულია დიდ მასშტაბზე: კვადრატული პრობლემიდან ვერ გამოხვალთ დამატებითი დაქირავებით.
SRE ოპერაციულ სამუშაოს ზღუდავს ინჟინრის დროის ორმოცდაათ პროცენტამდე. დანარჩენი ნახევარი უნდა დაეთმოს ინჟინერიას: ინსტრუმენტების შექმნას, პროცესების ავტომატიზაციას და იმ ტოილის აღმოფხვრას, რომელმაც გუნდი ორმოცდაათ პროცენტამდე მიიყვანა. თუ ტოილი ორმოცდაათ პროცენტს დიდი ხნით გადააჭარბებს, გუნდმა უნდა დააბრუნოს სამუშაო განვითარების გუნდს ან დაიქირაოს დამატებითი SRE-ები. ორმოცდაათ პროცენტის წესი ხელს უშლის SRE გუნდის ტრადიციულ ოპერაციების გუნდად გადაქცევას მუდმივი ზეწოლის ქვეშ.
შევადაროთ წარუმატებლობის რეჟიმები:
- ტრადიციული ოპერაციები: მეტი ინციდენტი იწვევს მეტ მანუალურ რეაგირებას, რაც ნაკლებ დროს ტოვებს პრევენციისთვის, რაც კიდევ უფრო მეტ ინციდენტს ქმნის. დუმის მარყუჟი.
- SRE: მეტი ინციდენტი იწვევს პოსტმორტემებს, რომლებიც ავლენენ ავტომატიზაციის შესაძლებლობებს, რაც ამცირებს შემდეგი ინციდენტის რეაგირების დროს. სათნო მარყუჟი, როდესაც მუშაობს.
SLI, SLO, SLA
სამი ასო, რომლებიც მართავენ წარმოებას
საიმედოობა გაზომვის გარეშე თეატრია. SRE საიმედოობას აქცევს რიცხვად, რომელიც წინასწარ არის შეთანხმებული და ყველას შეუძლია მისი გადამოწმება.
სერვისის დონის ინდიკატორი (SLI): სერვისის ქცევის გაზომვა. მაგალითები: მოთხოვნის დაყოვნება, შეცდომების სიხშირე, გამტარუნარიანობა, რიგის სიღრმე. SLI არის ის, რისი გრაფიკის დახატვაც შეგიძლია.
სერვისის დონის მიზანი (SLO): SLI-ის სამიზნე მნიშვნელობა ან დიაპაზონი. მაგალითი: „28-დღიანი მოძრავი ფანჯრის განმავლობაში HTTP მოთხოვნების 99.9% წარმატებით სრულდება.“ SLO არის დაპირება, რომელსაც თქვენ საკუთარ თავს და მომხმარებლებს აძლევთ მისაღები სერვისის ხარისხის შესახებ.
სერვისის დონის შეთანხმება (SLA): საკონტრაქტო ვალდებულება, რომელიც ჩვეულებრივ ითვალისწინებს ფინანსურ ჯარიმებს დარღვევისთვის. მაგალითი: „თუ თვიური ხელმისაწვდომობა 99.9%-ზე დაბლა დაეცემა, ვაბრუნებთ 10%-ს.“ SLA არის დაპირება, რომელსაც იურისტები აღასრულებენ.
კრიტიკული განსხვავება: თქვენი SLA ყოველთვის უფრო ფხვიერი უნდა იყოს, ვიდრე თქვენი SLO. თუ შიდა მიზნად 99.9%-ს აყენებთ და გარე კონტრაქტში 99.9%-ს აფიქსირებთ, მარჟა გაქვთ ნულოვანი. SRE-ები ჩვეულებრივ SLO-ებს ერთი „ცხრით“ უფრო მკაცრად აყენებენ, ვიდრე SLA-ს: 99.95% მიზანი, 99.9% კონტრაქტი. ეს უფსკრული შთანთქავს გარდაუვალ ცუდ კვირას.
შეცდომის ბიუჯეტები: შებრუნებული SLO
საიმედოობის მიზნებიდან საინჟინრო გადაწყვეტილებებამდე
SLO ადგენს საიმედოობის მიზანს. შეცდომის ბიუჯეტი არის ის, რაც რჩება: წარუმატებლობის რაოდენობა, რომლის დახარჯვაც შეგიძლიათ მიზნის გაცდენამდე.
თუ თქვენი SLO 28 დღეში 99.9%-იან წარმატებას გპირდებათ, თქვენი შეცდომის ბიუჯეტი არის მოთხოვნების 0.1%, ანუ თვეში დაახლოებით 40 წუთი სრული შეფერხება. ეს ბიუჯეტი თქვენია, რომ გამოიყენოთ როგორც გსურთ: დაგეგმილ რელიზებზე, ექსპერიმენტულ ფუნქციებზე, ქაოსის ინჟინერიაზე ან არასწორად მომუშავე დამოკიდებულების მიმართულებით.
შეცდომის ბიუჯეტები გარდაქმნის dev-სა და ops-ს შორის კონფლიქტს. ბიუჯეტის გარეშე, ყველა შეფერხება იწყებს კამათს იმის შესახებ, თუ ვინ გამოუშვა ცუდი ცვლილება და როგორ ავიცილოთ თავიდან შემდეგი. ბიუჯეტით:
- ბიუჯეტი რჩება: გაგზავნეთ უფრო სწრაფად, მიიღეთ მეტი რისკი, ჩაატარეთ ექსპერიმენტები. ბიუჯეტი ანაზღაურებს ამას.
- ბიუჯეტი ამოიწურა: შეწყვიტეთ ახალი ფუნქციების გაშვება, გაყინეთ რისკიანი ცვლილებები, ფოკუსირდით საიმედოობის სამუშაოზე, სანამ ბიუჯეტი აღდგება.
ეს გარდაქმნის საიმედოობას ემოციური კამათიდან გაზომვად რესურსად. ინჟინრებს შეუძლიათ ბიუჯეტის განზრახ დახარჯვა, როგორც ნებისმიერი სხვა წარმოების შეყვანა.
[BLOCK_TYPE QUESTION slos/error_budget]
Toil-ის განსაზღვრება
რა ითვლება Toil-ად
არა ყველა ოპერაციული ამოცანა ითვლება toil-ად. SRE განსაზღვრავს toil-ს ზუსტად: სამუშაო, რომელიც არის ხელით, განმეორებადი, ავტომატიზირებადი, ტაქტიკური, მუდმივი ღირებულების გარეშე და წრფივად მასშტაბირდება სერვისის ზრდასთან ერთად.
ყველა ექვსი თვისება უნდა არსებობდეს. ერთჯერადი მონაცემთა მიგრაცია ხელითაა, მაგრამ არ არის განმეორებადი: ეს არ ითვლება toil-ად. უფროსი ინჟინერი, რომელიც ახალი სერვისის არქიტექტურას აპროექტებს, იღებს ტაქტიკურ გადაწყვეტილებას, მაგრამ ამატებს მუდმივ ღირებულებას: ეს არ ითვლება toil-ად.
მაგალითები, რომლებიც ითვლება toil-ად:
- სერვისის ხელით გადატვირთვა მეხსიერების გაჟონვის შემდეგ
- ლოგის ფრაგმენტების ჩატის არხში ჩასმა ინციდენტის ანალიზის დროს
- ახალი მონაცემთა ბაზის უზრუნველყოფისთვის ბილეთის ფორმის შევსება
- ყოველკვარტალური ტევადობის ანგარიშის ხელით გაშვება
- რუტინული დეპლოიმენტის მოთხოვნების ერთ-ერთი დამტკიცება
ორმოცდაათი პროცენტის წესი ზღუდავს ტოილს SRE-ის დროის ნახევრამდე. 50%-ზე მეტის შემთხვევაში, გუნდმა უნდა დააბრუნოს პასუხისმგებლობა პროდუქტის გუნდს ან დაიქირაოს დამატებითი ინჟინრები, მაგრამ მიზანი რჩება მკაფიო: ტოილის ნულამდე შემცირება მისი ინჟინერიული სისტემებით ჩანაცვლებით, რომლებიც იგივე სამუშაოს ასრულებენ ადამიანის ჩარევის გარეშე.
ავტომატიზაცია არა მხოლოდ დროს ზოგავს. ის მთლიანად აღმოფხვრის ადამიანური შეცდომების კლასს. სკრიპტი, რომელიც მონაცემთა ბაზას ამზადებს, არ დაივიწყებს ნაბიჯებს ხანგრძლივი ცვლის შემდეგ.
ტოილის აუდიტის მსჯელობა
თქვენი გუნდი აკვირდება, როგორ იხარჯება მისი დრო. წინა კვარტალში განაწილება იყო: 30% დეპლოიმენტები, 25% ინციდენტებზე რეაგირება, 20% ტევადობის სამუშაო, 15% ფუნქციონალის ინჟინერია, 10% ერთჯერადი მოთხოვნები პროდუქტის გუნდებისგან.
On-Call Hygiene
Engineers, Not Pagers
On-call-ს რეალური ღირებულება აქვს. ძილი ირღვევა, შაბათ-კვირა იწყვეტება და უცნობი პრობლემების სტრესი იზრდება. SRE მიიჩნევს on-call-ს შეზღუდულ რესურსად, რომელიც უნდა იყოს მდგრადი და არა გმირული ტვირთი იმისთვის, ვისაც ყველაზე მეტად აღელვებს.
ჯანსაღი on-call როტაციები რამდენიმე პრინციპს მიჰყვება:
- კომპენსირებული დრო: on-call საათები ითარგმნება დასვენების დროში, დამატებით ანაზღაურებაში ან შესაბამის სარგებელში. უფასო on-call იწვევს გუნდის გადაწვას.
- გონივრული როტაციის სიღრმე: ექვსკაციან გუნდში, სადაც არის პირველადი და მეორადი პასუხისმგებელი, თითოეული ინჟინერი ერთ ცვლას იღებს ყოველ სამ კვირაში ერთხელ. ორკაციანი როტაციები კარიერას ანადგურებს.
- გვერდის მოცულობის ბიუჯეტი: Google-ის SRE წიგნი გვთავაზობს მაქსიმუმ ორ გვერდის მოვლენას თორმეტსაათიან ცვლაში. ამაზე მეტი მოითხოვს გუნდისგან ინჟინერიის დროის ინვესტირებას გაფრთხილებების მოცულობის შესამცირებლად და არა მხოლოდ მათ გადასატანად.
- მხოლოდ მოქმედებადი გაფრთხილებები: ყველა გვერდი უნდა მოითხოვდეს ადამიანის ჩარევას. თუ გვერდი იგნორირებული იქნება, ავტომატიზებული ან განმეორებით იმუშავებს ნორმალური მუშაობის დროს, ის არ უნდა არსებობდეს. გაფრთხილებების დაღლილობა საიმედოობის დეფექტია.
- მზის მიყოლებითი გადაცემები: გლობალურად განაწილებული გუნდები ცვლებს გადასცემენ დროის სარტყლების საზღვრებზე, რათა არავინ მიიღოს გვერდი დილის 3 საათზე, თუ სისტემა მართლაც ვერ დაელოდება დილამდე.
Blameless Postmortems
როგორ იქცევა გაჩერებები გაუმჯობესებებად
ყველა მნიშვნელოვანი ინციდენტი იღებს პოსტმორტემს: წერილობით ანალიზს იმის შესახებ, თუ რა მოხდა, რატომ მოხდა, რამ გამოასწორა და რა ცვლილებები უზრუნველყოფს განმეორების თავიდან აცილებას. პოსტმორტემი არის SRE-ის ეკვივალენტი რთული პროცენტის: თითოეული მათგანი სისტემას მუდმივ საიმედოობას მატებს.
უდანაშაულო ნიშნავს, რომ დოკუმენტი მარცხებს მიაწერს სისტემებსა და პროცესებს, არასოდეს ინდივიდებს. თუ ინჟინერმა არასწორი ბრძანება გასცა, პოსტმორტემი კითხულობს: რატომ დაუშვა სისტემამ ეს ბრძანება? რატომ არ დაიჭირა იგი არანაირი დამცავი მექანიზმით? რა ცვლილება სისტემაში, დოკუმენტაციაში ან ინსტრუმენტებში დაიცავს შემდეგ ინჟინერს იგივე შეცდომის გამეორებისგან?
უდანაშაულობა არსებობს ერთი მიზეზის გამო: ადამიანები მალავენ შეცდომებს, როდესაც სჯის შიში აქვთ. დამალული შეცდომები ხდება შემდეგი ინციდენტი. უდანაშაულო კულტურის ღირებულება იაფია დაგროვილი გამოუვლენელი ხარვეზების ღირებულებასთან შედარებით.
პოსტმორტემები ჩვეულებრივ მოიცავს:
- შეჯამება: ინციდენტისა და მისი გავლენის ერთპარაგრაფიანი აღწერა
- ქრონოლოგია: წუთ-წუთიერი რეკონსტრუქცია დროის ნიშნებით
- Root cause analysis: ტექნიკური და პროცესის ფაქტორები, რომლებმაც გამოიწვია წარუმატებლობა
- Detection: როგორ შეიტყო გუნდმა ინციდენტის შესახებ და რამდენი დრო დასჭირდა ამას
- Resolution: ქმედებები, რომლებიც განხორციელდა სერვისის აღსადგენად
- Lessons learned: რამ იმუშავა, რამ არ იმუშავა
- Action items: კონკრეტული, პასუხისმგებელი, ვადიანი საინჟინრო ამოცანები
Action items live in a tracker. They get prioritized like any other engineering work. Postmortems without action items reduce to story time. The work changes nothing.
ოთხი ოქროს სიგნალი
რა უნდა გაზომოს ყველა სერვისმა
Google-ის SRE წიგნი გვთავაზობს ოთხ სიგნალს, რომელიც ყველა მომხმარებლისთვის ხელმისაწვდომმა სერვისმა უნდა გამოაჩინოს: latency, traffic, errors და saturation. ერთად ისინი აღწერენ სერვისის ჯანმრთელობას მომხმარებლის თვალსაზრისით. ნაკლები სიგნალით მონიტორინგი ტოვებს ბრმა წერტილებს; ასობით მეტრიკით მონიტორინგი კი გუნდს აფრთხილებს გაფრთხილებების დაღლილობაში.
Latency: რამდენი ხანი სჭირდება მოთხოვნებს. თვალყური ადევნეთ განაწილებებს, არა საშუალო მნიშვნელობებს. p50 (მედიანა) აღწერს ტიპურ გამოცდილებას. p99 აღწერს მომხმარებელთა ყველაზე ცუდ 1%-ს. საშუალო მხოლოდ მალავს გრძელ კუდებს: სერვისი, რომლის მედიანა 50 ms და p99 5,000 ms არის, საშუალოზე კარგად გამოიყურება, მაგრამ აფუჭებს ერთ მომხმარებელს ასიდან.
Traffic: მოთხოვნა სერვისზე. ვებ სერვისისთვის ეს ნიშნავს მოთხოვნებს წამში. სტრიმინგ სერვისისთვის — ერთდროული კავშირები. პარტიული დავალებისთვის — დამუშავებული ელემენტები წუთში. Traffic კორელაციაშია ტევადობის გადაწყვეტილებებთან და ავლენს დატვირთვის ანომალიებს.
Errors: წარუმატებელი მოთხოვნების მაჩვენებელი. აშკარა წარუმატებლობები (HTTP 500), იმპლიციტური წარუმატებლობები (HTTP 200 დაზიანებული მონაცემებით) და პოლიტიკის წარუმატებლობები (პასუხი ძალიან ნელია SLO-ს დასაკმაყოფილებლად) — ყველა ითვლება. მათ შორის განსხვავება მნიშვნელოვანია: 200 ცუდი პეილოუდით ხშირად უფრო მეტად აზიანებს მომხმარებლებს, ვიდრე გულწრფელი 500.
გაჯერება: რამდენად სავსეა სისტემა. CPU-ის გამოყენება, რიგის სიღრმე, მეხსიერების დატვირთვა, კავშირების პულის დაკავებულობა. გაჯერება წინასწარმეტყველებს მომავალ ლატენტურობას: სისტემა, რომელიც მუშაობს 95%-იანი CPU-ით, ძალიან მცირე რესურსს ფლობს მანამ, სანამ მომხმარებლისთვის ხილული ლატენტურობა მკვეთრად გაიზრდება.
ამ ოთხი სიგნალიდან მომდინარეობს SRE-ის უმეტესი გაფრთხილებები. სიმპტომებზე დაფუძნებული გაფრთხილება (როდესაც მომხმარებლები შეამჩნევენ პრობლემას) უკეთესია მიზეზებზე დაფუძნებულ გაფრთხილებაზე (როდესაც CPU აღემატება 80%-ს). ოთხი ოქროს სიგნალი აღწერს სიმპტომებს.
SRE-ის კარიერული გზები
სად იხდის SRE-ის უნარები
SRE-ის კარიერა განსხვავდება იმის მიხედვით, თუ დისციპლინის რომელი ნაწილი უყვარს ინჟინერს ყველაზე მეტად:
ინფრასტრუქტურის SRE: ქმნის პლატფორმებს, რომლებზეც სხვა გუნდები მუშაობენ. Kubernetes, სერვის მეშები, შიდა ღრუბელი. მძიმე სისტემური ინჟინერია, განაწილებული სისტემების თეორია და პლატფორმის დიზაინი. დიდ კომპანიებში ძალიან კარგად ანაზღაურდება, რადგან სამუშაო მასშტაბირებადია: ერთი ინფრასტრუქტურის SRE მხარს უჭერს ასობით პროდუქტის ინჟინერს.
ჩადგმული SRE: თანამშრომლობს პროდუქტის ინჟინერიის გუნდთან კონკრეტული სერვისის საიმედოობის გასაუმჯობესებლად. ნახევრად ინჟინერი, ნახევრად მწვრთნელი. ძლიერი კომუნიკაციისა და კოდის მიმოხილვის უნარები ისეთივე მნიშვნელოვანია, როგორც ტექნიკური სიღრმე. ხშირად საუკეთესო გზაა იმ ინჟინრებისთვის, რომლებსაც სწავლება მოსწონთ.
საიმედოობის ინსტრუმენტები: ქმნის დაკვირვებადობის სტეკს: მონიტორინგი, გაფრთხილება, დეშბორდები, პოსტმორტემის ინსტრუმენტები, ინციდენტების მართვის პლატფორმები. მძიმე ფრონტენდისა და მონაცემთა ინჟინერიის სამუშაო. შედეგს იყენებს ყველა სხვა გუნდი.
წარმოების ინჟინერია: Facebook/Meta-ს ტერმინი SRE-სთვის, რომელიც ფოკუსირებულია ტევადობაზე, განლაგებაზე და ტრაფიკის მართვაზე. მძიმე ქსელური და სისტემური სამუშაო.
ტექნიკური სერტიფიკატები, რომლებიც ღირს ფლობა: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional და CNCF სერტიფიკატები (Kubernetes Administrator, Kubernetes Application Developer) აჩვენებს cloud-native უნარებს. Linux Foundation-ის სერტიფიკატები აჩვენებს სისტემების სიღრმეს. არცერთი მათგანი არ ცვლის პორტფოლიოს სამუშაოს, მაგრამ ისინი ეხმარება რეკრუტერების სკრინინგის გავლაში.
შეჯამება
რა იცით ახლა
საიტის საიმედოობის ინჟინერია დაიწყო როგორც Google-ის პასუხი მასშტაბირების პრობლემაზე და გადაიზარდა დისციპლინად, რომელიც ახლა ინდუსტრიაში ფართოდ გამოიყენება. თქვენ გაიარეთ:
- ხელით ოპერაციებიდან საიმედოობის ინჟინერიაზე გადასვლა
- SLI, SLO, SLA და შეცდომის ბიუჯეტის ინვერსიული SLO კონცეფცია
- Toil-ის განმარტება, 50%-იანი წესი და ინჟინერიაზე დაფუძნებული შემცირება
- მდგრადი on-call როტაციები და უდანაშაულო postmortem პრაქტიკა
- ოთხი ოქროს სიგნალი, როგორც სერვისის მონიტორინგის საწყისი წერტილი
- SRE კარიერული გზები და სერტიფიკატები, რომლებიც კარებს ხსნიან
ორი იდეაა ყველაზე მნიშვნელოვანი. საიმედოობა არის რიცხვი, რომელიც წინასწარ არის შეთანხმებული. და შრომა არის დეფექტი, არა სამუშაოს აღწერა. თუ ამ ორს გაითვალისწინებთ, დანარჩენი SRE თავისით მოჰყვება.
რეკომენდებული ლიტერატურა: Google-ის SRE წიგნი (უფასოდ ხელმისაწვდომია: sre.google/books/), SRE Workbook პრაქტიკული სავარჯიშოებისთვის და Charity Majors-ის ნაშრომები observability-ზე. geometry-of თანმხლები გაკვეთილი უფრო ღრმად ეხება ვიზუალურ სტრუქტურას, რომელიც SRE პრაქტიკის საფუძველია: latency-ის განაწილებები, error budget-ის კონუსები, დამოკიდებულების გრაფები და დეშბორდის განლაგებები.