ვებინარის ტრანსკრიფცია "SRE - აჟიოტაჟი თუ მომავალი?"

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

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

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

პრობლემა ის არის, რომ ჩვენ არ გვაქვს DevOps-ის მკაფიო განმარტება და DevOps-ის მკაფიო განხორციელება. მე ვისაუბრე კონფერენციაზე ეკატერინბურგში 2 წლის წინ და აქამდე DevOps განყოფილება იწყებოდა მოხსენებით "რა არის DevOps". 2017 წელს devops თითქმის 10 წლისაა, მაგრამ ჩვენ ჯერ კიდევ ვკამათობთ იმაზე, თუ რა არის ეს. და ეს არის ძალიან უცნაური სიტუაცია, რომლის მოგვარებაც Google-მა რამდენიმე წლის წინ სცადა.

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

გამოდის, რომ DevOps პარადიგმა SRE გუნდებში განხორციელებულია იმით, რომ არსებობენ SRE ინჟინრები, რომლებიც წყვეტენ სტრუქტურულ პრობლემებს. აი, იგივე კავშირი Dev-სა და Ops-ს შორის, რაზეც ხალხი 8 წელია საუბრობს. SRE-ის როლი მსგავსია არქიტექტორის როლში, რომ ახალბედები არ ხდებიან SRE. კარიერის დასაწყისში ადამიანებს ჯერ არ აქვთ გამოცდილება და არ გააჩნიათ საჭირო ცოდნის სიგანე. იმის გამო, რომ SRE მოითხოვს ძალიან დახვეწილ ცოდნას იმის შესახებ, თუ რა და როდის შეიძლება მოხდეს არასწორი. ამიტომ, აქ საჭიროა გარკვეული გამოცდილება, როგორც წესი, როგორც კომპანიის შიგნით, ასევე მის ფარგლებს გარეთ.

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

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

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

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

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

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

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

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

მნიშვნელოვანი საკითხია, რა არის დარჩენილი კომპონენტების საიმედოობა. იმის გამო, რომ განსხვავება 4 და 5 ცხრას შორის არ იქნება ხილული სმარტფონზე, რომელსაც აქვს 2 სანდო ცხრა. უხეშად რომ ვთქვათ, თუ სმარტფონზე რაიმე გაფუჭდა თქვენს სერვისში წელიწადში 10-ჯერ, სავარაუდოდ 8-ჯერ მოხდა ავარია OS მხარეს. მომხმარებელი ამას მიჩვეულია და წელიწადში ერთხელ დამატებით ყურადღებას არ მიაქცევს. აუცილებელია საიმედოობის გაზრდისა და მოგების გაზრდის ფასის შედარება.
მხოლოდ SRE-ის წიგნში არის კარგი მაგალითი იმისა, რომ 4 ცხრადან 3 ცხრამდე გაზარდოთ. გამოდის, რომ ხელმისაწვდომობის ზრდა ოდნავ ნაკლებია 0,1%-ზე. და თუ სერვისის შემოსავალი არის $1 მილიონი წელიწადში, მაშინ შემოსავლის ზრდა $900-ია. თუ ხელმისაწვდომობის 900-ით გაზრდა გვიჯდება 900 დოლარზე ნაკლები წელიწადში, ზრდას აქვს ფინანსური აზრი. თუ ის წელიწადში 3 დოლარზე მეტი ღირს, აზრი აღარ აქვს, რადგან შემოსავლის ზრდა უბრალოდ არ ანაზღაურებს შრომის და რესურსების ხარჯებს. და XNUMX ცხრა საკმარისი იქნება ჩვენთვის.

ეს, რა თქმა უნდა, გამარტივებული მაგალითია, სადაც ყველა მოთხოვნა თანაბარია. და 3 ცხრიდან 4 ცხრამდე წასვლა საკმაოდ მარტივია, მაგრამ ამავდროულად, მაგალითად, 2 ცხრიდან 3-მდე გადასვლა უკვე 9 ათასი დოლარის დანაზოგია, შეიძლება ფინანსური აზრი ჰქონდეს. ბუნებრივია, სინამდვილეში, მოთხოვნის დარეგისტრირება უარესია, ვიდრე გვერდის წარუმატებლობა; მოთხოვნებს განსხვავებული წონა აქვთ. მათ შეიძლება ჰქონდეთ სრულიად განსხვავებული კრიტერიუმები ბიზნესის თვალსაზრისით, მაგრამ მაინც, როგორც წესი, თუ რაიმე კონკრეტულ სერვისზე არ არის საუბარი, ეს საკმაოდ სანდო მიახლოებაა.
ჩვენ მივიღეთ კითხვა, არის თუ არა SRE ერთ-ერთი კოორდინატორი სამსახურისთვის არქიტექტურული გადაწყვეტის არჩევისას. ეს მისაღებია არსებულ ინფრასტრუქტურაში ინტეგრაციის თვალსაზრისით, რათა არ მოხდეს მისი სტაბილურობის დაკარგვა. დიახ, SRE-ები გავლენას ახდენენ მოთხოვნებზე, ვალდებულებებზე, გამოშვებებზე იმავე გზით; ისინი გავლენას ახდენენ არქიტექტურაზე, ახალი სერვისების დანერგვაზე, მიკროსერვისებზე და ახალი გადაწყვეტილებების განხორციელებაზე. აქამდე რატომ ვთქვი, გამოცდილება გჭირდება, კვალიფიკაცია. სინამდვილეში, SRE არის ერთ-ერთი დამბლოკავი ხმა ნებისმიერ არქიტექტურულ და პროგრამულ გადაწყვეტაში. შესაბამისად, SRE, როგორც ინჟინერმა, უპირველეს ყოვლისა, არა მხოლოდ უნდა გააცნობიეროს, არამედ გააცნობიეროს, თუ როგორ იმოქმედებს ზოგიერთი კონკრეტული გადაწყვეტილება სანდოობაზე, სტაბილურობაზე და გაიგოს, თუ როგორ უკავშირდება ეს ბიზნესის საჭიროებებს და რა თვალსაზრისით შეიძლება იყოს ეს დასაშვები. და რომელთანაც არ არის.

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

ვთქვათ, SLA შეიძლება იყოს ასეთი. სერვისი ხელმისაწვდომია დროის 99,95%-ში მთელი წლის განმავლობაში. ან 99 კრიტიკული ტექნიკური დახმარების ბილეთი დაიხურება კვარტალში 3 საათის განმავლობაში. ან შეკითხვების 85%-ს ყოველთვიურად 1,5 წამში გაეცემა პასუხი. ანუ თანდათან ვაცნობიერებთ, რომ შეცდომები და წარუმატებლობები საკმაოდ ნორმალურია. ეს მისაღები სიტუაციაა, ამას ვგეგმავთ, გარკვეულწილად იმედიც გვაქვს. ანუ, SRE აშენებს სისტემებს, რომლებსაც შეუძლიათ შეცდომები დაუშვან, რომლებიც ნორმალურად უნდა რეაგირებდნენ შეცდომებზე და უნდა გაითვალისწინონ ისინი. და თუ შესაძლებელია, შეცდომებს ისე უნდა გაუმკლავდნენ, რომ მომხმარებელმა ან ვერ შეამჩნია ისინი, ან შეამჩნია, მაგრამ არსებობს რაიმე გამოსავალი, რომ ყველაფერი მთლიანად არ დაინგრა.

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

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

ისევ და ისევ, არის ბევრი სტატია, ბევრი მეთოდი, მრავალი გზა, თუნდაც იმ წიგნში, რომელსაც მე ასე ხშირად ვახსენებ, როგორ დავრწმუნდეთ, რომ სხვა დეველოპერები არ დაიწყებენ SRE-ს სიძულვილს. MTTR, თავის მხრივ, ეხება თქვენს SLO-ზე მუშაობას (სერვისის დონის მიზანი). და ეს ძირითადად ავტომატიზაციაა. რადგან, მაგალითად, ჩვენი SLO არის 4 ცხრა კვარტალში მუშაობის დრო. ეს ნიშნავს, რომ 3 თვეში ჩვენ შეგვიძლია დავუშვათ 13 წუთი შესვენება. და გამოდის, რომ ჩვენი MTTR არ შეიძლება იყოს 13 წუთზე მეტი. თუ 13 წუთს გამოვყოფთ რეაგირებას მინიმუმ 1 შეფერხებაზე, ეს ნიშნავს, რომ ჩვენ უკვე ამოწურეთ მთელი კვარტალის ბიუჯეტი. ჩვენ ვარღვევთ SLO-ს. 13 წუთი რეაგირებისთვის და მარცხის გამოსასწორებლად ბევრია მანქანისთვის, მაგრამ ძალიან ცოტა ადამიანისთვის. იმის გამო, რომ იმ დროისთვის, როდესაც ადამიანი მიიღებს გაფრთხილებას, როდესაც ის რეაგირებს, სანამ ის გაარკვევს შეცდომას, ეს უკვე რამდენიმე წუთია. სანამ ადამიანი არ გაიგებს, როგორ გამოსწორდეს, კონკრეტულად რა გაასწოროს, რა გააკეთოს, ამას კიდევ რამდენიმე წუთი დასჭირდება. სინამდვილეში, მაშინაც კი, თუ თქვენ უბრალოდ გჭირდებათ სერვერის გადატვირთვა, როგორც ირკვევა, ან ახალი კვანძის ამაღლება, მაშინ MTTR ხელით დაახლოებით 7-8 წუთი სჭირდება. პროცესის ავტომატიზაციისას, MTTR ძალიან ხშირად აღწევს წამს, ზოგჯერ მილიწამებში. Google ჩვეულებრივ საუბრობს მილიწამებზე, მაგრამ სინამდვილეში, რა თქმა უნდა, ყველაფერი არც ისე კარგად არის.

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

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

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

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

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

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

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

გამოდის, რომ წარმოებაში ექსპერიმენტები საკმაოდ მნიშვნელოვანი და თითქმის განუყოფელი ნაწილია SRE-ს დიდ გუნდებში. და მას ჩვეულებრივ უწოდებენ ქაოსის ინჟინერიას, რომელიც მოდის Netflix-ის გუნდიდან, რომელმაც გამოუშვა პროგრამა სახელწოდებით Chaos Monkey.
Chaos Monkey უერთდება CI/CD მილსადენს და შემთხვევით არღვევს სერვერს წარმოების პროცესში. ისევ SRE სტრუქტურაში ვამბობთ, რომ ავარიული სერვერი თავისთავად ცუდი არ არის, მოსალოდნელია. ხოლო თუ ბიუჯეტში შედის, მისაღებია და ბიზნესს ზიანს არ აყენებს. რა თქმა უნდა, Netflix-ს აქვს საკმარისი ზედმეტი სერვერები, საკმარისი რეპლიკაცია, რომ ეს ყველაფერი შეიძლება გამოსწორდეს ისე, რომ მომხმარებელმა საერთოდ ვერ შეამჩნია, და რა თქმა უნდა, არავინ დატოვებს ერთ სერვერს რაიმე ბიუჯეტისთვის.

Netflix-ს ერთ დროს ჰქონდა ასეთი კომუნალური საშუალებების მთელი ნაკრები, რომელთაგან ერთ-ერთი, Chaos Gorilla, მთლიანად გამორთავს ერთ-ერთ ხელმისაწვდომობის ზონას Amazon-ში. და ასეთი რამ კარგად გვეხმარება, პირველ რიგში, ფარული დამოკიდებულებების იდენტიფიცირებაში, როდესაც ბოლომდე არ არის ნათელი რა გავლენას ახდენს რაზე, რაზეა დამოკიდებული. და ეს, თუ თქვენ მუშაობთ მიკროსერვისთან და დოკუმენტაცია არ არის მთლად სრულყოფილი, ეს შეიძლება თქვენთვის ნაცნობი იყოს. და კიდევ, ეს ხელს უწყობს კოდის შეცდომების დაჭერას, რომელთა დაჭერა შეუძლებელია დადგმის დროს, რადგან ნებისმიერი დადგმა არ არის ზუსტი სიმულაცია, იმის გამო, რომ დატვირთვის მასშტაბი განსხვავებულია, დატვირთვის ნიმუში განსხვავებულია, აღჭურვილობა ასევე არის სავარაუდოდ, სხვა. პიკური დატვირთვები ასევე შეიძლება იყოს მოულოდნელი და არაპროგნოზირებადი. და ასეთი ტესტირება, რომელიც კვლავ არ სცდება ბიუჯეტს, ძალიან კარგად ეხმარება ინფრასტრუქტურაში არსებული შეცდომების დადგენას, რომლებსაც დადგმა, ავტოტესტირება და CI/CD მილსადენები ვერასოდეს დაიჭერენ. და სანამ ეს ყველაფერი შედის თქვენს ბიუჯეტში, არ აქვს მნიშვნელობა, რომ თქვენი სერვისი იქ დაეცა, თუმცა ძალიან საშინლად ჩანდა, სერვერი გაფუჭდა, რა კოშმარია. არა, ეს ნორმალურია, ეს კარგია, ეს ეხმარება შეცდომების დაჭერას. თუ ბიუჯეტი გაქვთ, შეგიძლიათ დახარჯოთ.

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

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

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

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

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

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

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

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

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

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

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

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

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

Slurm SRE არის სამდღიანი ინტენსიური კურსი, რომელიც მოიცავს დაახლოებით იმას, რაზეც ახლა ვსაუბრობ, მაგრამ ბევრად უფრო დიდი სიღრმისეულით, რეალური შემთხვევებით, პრაქტიკით, მთელი ინტენსიური მიმართულია პრაქტიკულ მუშაობაზე. ხალხი დაიყოფა გუნდებად. თქვენ ყველა იმუშავებთ რეალურ საქმეებზე. შესაბამისად, გვყავს Booking.com-ის ინსტრუქტორები ივან კრუგლოვი და ბენ ტაილერი. ჩვენ გვყავს მშვენიერი ევგენი ვარაბასი Google-ისგან, სან-ფრანცისკოდან. და მეც გეტყვი რაღაცას. ასე რომ აუცილებლად გვესტუმრეთ.
ასე რომ, მითითებების სია. SRE-ზე არის ლინკები. პირველი იმავე წიგნზე, უფრო სწორად, 2 წიგნზე SRE-ის შესახებ, დაწერილი Google-ის მიერ. Სხვა მცირე სტატია SLA, SLI, SLO-ზე, სადაც ტერმინები და მათი გამოყენება ცოტა უფრო დეტალურად არის ახსნილი. შემდეგი 3 არის ანგარიშები SRE-ზე სხვადასხვა კომპანიებში. Პირველი - გასაღებები SRE-სთვის, ეს არის Google-ის ბენ ტრენერის მთავარი ნოტა. მეორე - SRE Dropbox-ზე. მესამე ისევ დაახლოებით SRE Google-ში. მეოთხე მოხსენება SRE Netflix-ზე, რომელსაც ჰყავს მხოლოდ 5 ძირითადი SRE თანამშრომელი 190 ქვეყანაში. ძალიან საინტერესოა ამ ყველაფრის ნახვა, რადგან ისევე, როგორც DevOps ნიშნავს ძალიან განსხვავებულს სხვადასხვა კომპანიისთვის და თუნდაც სხვადასხვა გუნდისთვის, SRE-ს აქვს ძალიან განსხვავებული პასუხისმგებლობა, თუნდაც მსგავსი ზომის კომპანიებში.

კიდევ 2 ბმული ქაოსის ინჟინერიის პრინციპებზე: (1), (2). და ბოლოს არის 3 სია Awesome Lists სერიიდან შესახებ ქაოსის ინჟინერიაშესახებ SRE და დაახლოებით SRE ინსტრუმენტარიუმის. სია SRE-ზე წარმოუდგენლად დიდია, თქვენ არ გჭირდებათ ყველაფრის გავლა, დაახლოებით 200 სტატიაა. უაღრესად გირჩევთ სტატიებს შესაძლებლობების დაგეგმვისა და უმწიკვლო პოსტმოკვლის შესახებ.

საინტერესო სტატია: SRE, როგორც ცხოვრებისეული არჩევანი

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

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

წყარო: www.habr.com