კიდევ ერთხელ DevOps-ისა და SRE-ის შესახებ

ჩატის დისკუსიის საფუძველზე AWS მინსკის საზოგადოება

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

წინაისტორია

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

DevOps პრაქტიკის დაბადება

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

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

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

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

ისევ არ არის ყველაფერი კარგად, მადლობა ღმერთს

როგორც კი ყველაფერი დაწყნარდა და სხვადასხვა მზაკვრულმა „მეთოდებმა“ დაიწყეს სქელი წიგნების წერა DevOps პრაქტიკაზე, ჩუმად გაჩნდა კამათი იმის შესახებ, თუ ვინ იყო ცნობილი DevOps ინჟინერი და რომ DevOps არის წარმოების კულტურა, კვლავ გაჩნდა უკმაყოფილება. მოულოდნელად აღმოჩნდა, რომ პროგრამული უზრუნველყოფის მიწოდება აბსოლუტურად არა ტრივიალური ამოცანაა. თითოეულ დეველოპერულ ინფრასტრუქტურას აქვს თავისი სტეკი, სადღაც უნდა აკრიფოთ იგი, სადღაც უნდა განათავსოთ გარემო, აქ გჭირდებათ Tomcat, აქ გჭირდებათ ეშმაკური და რთული გზა მის გასაშვებად - ზოგადად, თქვენი თავი ფეთქვას. და პრობლემა, უცნაურად საკმარისი აღმოჩნდა, უპირველეს ყოვლისა, პროცესების ორგანიზებაში იყო - მიწოდების ამ ფუნქციამ, როგორც ბოსტნეულობა, დაიწყო პროცესების დაბლოკვა. გარდა ამისა, არავინ გააუქმა ოპერაციები. ეს არ ჩანს V-მოდელში, მაგრამ ჯერ კიდევ არის მთელი სასიცოცხლო ციკლი მარჯვნივ. შედეგად, საჭიროა როგორმე ინფრასტრუქტურის შენარჩუნება, მონიტორინგის მონიტორინგი, ინციდენტების მოგვარება და ასევე მიწოდების საკითხი. იმათ. დაჯექი ცალი ფეხით როგორც განვითარებაში, ასევე ექსპლუატაციაში - და უცებ აღმოჩნდა, რომ ეს იყო Development & Operations. შემდეგ კი იყო ზოგადი აჟიოტაჟი მიკროსერვისებისთვის. და მათთან ერთად, ადგილობრივი მანქანებიდან განვითარებამ დაიწყო ღრუბელში გადასვლა - სცადეთ რაიმეს გამართვა ადგილობრივად, თუ არსებობს ათობით და ასობით მიკროსერვისი, მაშინ მუდმივი მიწოდება ხდება გადარჩენის საშუალება. "პატარა მოკრძალებული კომპანიისთვის" ყველაფერი კარგად იყო, მაგრამ მაინც? და გუგლი?

SRE Google-ის მიერ

Google მოვიდა, შეჭამა ყველაზე დიდი კაქტუსები და გადაწყვიტა - ჩვენ არ გვჭირდება ეს, ჩვენ გვჭირდება საიმედოობა. და საიმედოობა უნდა მართოს. და მე გადავწყვიტე, რომ ჩვენ გვჭირდება სპეციალისტები, რომლებიც მართავენ საიმედოობას. მე დავურეკე მათ SR ინჟინრები და ვუთხარი, ეს შენთვისაა, გააკეთე კარგად, როგორც ყოველთვის. აქ არის SLI, აქ არის SLO, აქ არის მონიტორინგი. და მან ცხვირი ოპერაციებში ჩაიძირა. და მან უწოდა თავის "სანდო DevOps" SRE. როგორც ჩანს, ყველაფერი კარგადაა, მაგრამ არის ერთი ბინძური ჰაკი, რომელსაც Google-ს შეუძლია - SR ინჟინრების თანამდებობაზე დაქირავება ადამიანები, რომლებიც იყვნენ კვალიფიციური დეველოპერები და ასევე გააკეთეს პატარა საშინაო დავალება და ესმოდათ სამუშაო სისტემების ფუნქციონირება. უფრო მეტიც, თავად Google-ს აქვს პრობლემები ასეთი ადამიანების დაქირავებასთან დაკავშირებით - ძირითადად იმიტომ, რომ აქ საკუთარ თავს კონკურენციას უწევს - აუცილებელია ვინმესთვის ბიზნეს ლოგიკის აღწერა. მიწოდება დაევალა ინჟინრების გათავისუფლებას, SR - ინჟინრები მართავენ საიმედოობას (რა თქმა უნდა, არა უშუალოდ, მაგრამ ინფრასტრუქტურაზე ზემოქმედებით, არქიტექტურის შეცვლით, ცვლილებებისა და ინდიკატორების თვალყურის დევნებით, ინციდენტებთან გამკლავებით). კარგია, შეგიძლია წერენ წიგნებს. მაგრამ რა მოხდება, თუ არ ხართ Google, მაგრამ საიმედოობა მაინც რატომღაც შეშფოთებულია?

DevOps იდეების განვითარება

სწორედ მაშინ ჩამოვიდა Docker, რომელიც გაიზარდა lxc-დან, შემდეგ კი სხვადასხვა საორკესტრო სისტემები, როგორიცაა Docker Swarm და Kubernetes, და DevOps ინჟინრებმა ამოისუნთქეს - პრაქტიკის გაერთიანებამ გაამარტივა მიწოდება. მან ის იმდენად გაამარტივა, რომ შესაძლებელი გახდა დეველოპერებისთვის მიწოდების აუთსორსინგიც კი - რა არის deployment.yaml. კონტეინერიზაცია პრობლემას წყვეტს. და CI/CD სისტემების სიმწიფე უკვე არის ერთი ფაილის დაწერის დონეზე და ჩვენ მივდივართ - დეველოპერებს შეუძლიათ თავად გაუმკლავდნენ მას. და შემდეგ ვიწყებთ საუბარს იმაზე, თუ როგორ შეგვიძლია შევქმნათ საკუთარი SRE, ... ან თუნდაც ვინმესთან ერთად.

SRE არ არის Google-ში

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

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

წყარო: www.habr.com