არ არსებობს DevOps ინჟინრები. მაშინ ვინ არსებობს და რა ვუყოთ მას?

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

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

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

კულტურისა და პროცესების შესახებ

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

მაგალითად, აღწერს განსხვავებას სისტემის ადმინისტრატორსა და სერვისის მართვის SRE მიდგომას შორის ცნობილი Google SRE Book იწყება. ფარგლებში ჩატარდა საინტერესო კვლევები DORA-ს გამოკითხვა - ნათელია, რომ საუკეთესო დეველოპერები როგორღაც ახერხებენ ახალი ცვლილებების წარმოებაში უფრო სწრაფად, ვიდრე საათში ერთხელ. ისინი ამოწმებენ ხელით არაუმეტეს 10% (ეს ჩანს შარშანდელი DORA). როგორ აკეთებენ ამას? „გააკეთე ან მოკვდე“, ნათქვამია მოხსენების ერთ-ერთ სათაურში. ამ სტატისტიკის დეტალური განხილვისთვის ტესტირების კონტექსტში შეგიძლიათ მიმართოთ ბარუხ სადოგურსკის მთავარ ნოტას. „ჩვენ გვყავს DevOps. ყველა ტესტერი გავათავისუფლოთ“. ჩვენს სხვა კონფერენციაზე, Heisenbug.

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

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

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

მანკიერი წრე

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

წარმოიდგინე: გუშინ ხიმკიში შაურმას აკეთებდი, დღეს კი უკვე დიდი კაცი ხარ, უფროსი რეკრუტერი. კანდიდატების ძიების და შერჩევის მთელი პროცესია, ყველაფერი ადვილი არ არის, უნდა გაიგო. ვთქვათ, დეპარტამენტის უფროსი ამბობს: იპოვნეთ სპეციალისტი X-ში. ჩვენ მივაკუთვნებთ სიტყვას „ინჟინერი“ X-ს და დავასრულეთ. გჭირდება Linux? კარგად, ეს ნამდვილად Linux ინჟინერია, თუ გსურთ DevOps, მაშინ DevOps ინჟინერი. ვაკანსია შედგება არა მხოლოდ სათაურისაგან, არამედ გარკვეული ტექსტიც უნდა იყოს შეყვანილი შიგნით. უმარტივესი გზაა Google-ის საკვანძო სიტყვების ნაკრების შეყვანა, თქვენი ფანტაზიიდან გამომდინარე. DevOps შედგება ორი სიტყვისგან - "Dev" და "Ops", რაც ნიშნავს, რომ ჩვენ უნდა გავაერთიანოთ დეველოპერებთან და ადმინისტრატორებთან დაკავშირებული საკვანძო სიტყვები, ყველაფერი ერთ გროვად. ასე ჩნდება ვაკანსიები 42 პროგრამირების ენის ცოდნისა და Kubernetes-ისა და Swarm-ის ერთდროულად გამოყენების 20 წლის შესახებ. სამუშაო დიაგრამა.

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

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

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

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

რას აკეთებენ ადამიანები DevOps-ში (ნამდვილად)

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

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

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

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

რა თქმა უნდა, საკითხის ტექნიკური ნაწილიც არის. თუ თქვენი ახალი კოდი ერთ თვეში შემოწმდება, მაგრამ გამოქვეყნდება მხოლოდ ერთი წლის შემდეგ და ფიზიკურად შეუძლებელია ამ ყველაფრის დაჩქარება, შეიძლება არ გაამართლოთ კარგი პრაქტიკა. კარგი პრაქტიკა მხარდაჭერილია კარგი ინსტრუმენტებით. მაგალითად, ინფრასტრუქტურის-როგორც კოდის იდეის გათვალისწინებით, შეგიძლიათ გამოიყენოთ ყველაფერი AWS CloudFormation-დან და Terraform-დან დაწყებული შეფ-Ansible-Puppet-მდე. ეს ყველაფერი უნდა იცოდე და შეგეძლოს და ეს უკვე საკმაოდ საინჟინრო დისციპლინაა. მნიშვნელოვანია, რომ არ ავურიოთ მიზეზი და შედეგი: ჯერ თქვენ მუშაობთ SRE-ს პრინციპების მიხედვით და მხოლოდ ამის შემდეგ ახორციელებთ ამ პრინციპებს გარკვეული სპეციფიკური ტექნიკური გადაწყვეტილებების სახით. ამავდროულად, SRE არის ძალიან ყოვლისმომცველი მეთოდოლოგია, რომელიც არ გეტყვით როგორ დააყენოთ Jenkins, არამედ დაახლოებით ხუთი ძირითადი პრინციპი:

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

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

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

თავის მხრივ, Cloud Native გადაწყვეტილებები ახლა ძალიან პოპულარული გახდა. როგორც დღეს Cloud Native Computing Foundation-ის მიერ არის განსაზღვრული, Cloud Native ტექნოლოგიები საშუალებას აძლევს ორგანიზაციებს განავითარონ და გაუშვან მასშტაბური აპლიკაციები დღევანდელ დინამიურ გარემოში, როგორიცაა საჯარო, კერძო და ჰიბრიდული ღრუბლები. მაგალითები მოიცავს კონტეინერებს, სერვისის ბადეებს, მიკროსერვისებს, უცვლელ ინფრასტრუქტურას და დეკლარაციულ API-ებს. ყველა ეს ტექნიკა საშუალებას აძლევს თავისუფლად დაწყვილებულ სისტემებს დარჩეს ელასტიური, მართვადი და მაღალი დაკვირვებადი. კარგი ავტომატიზაცია საშუალებას აძლევს ინჟინრებს განახორციელონ დიდი ცვლილებები ხშირად და პროგნოზირებადი შედეგებით ისე, რომ ეს არ იყოს შრომატევადი. ამ ყველაფერს მხარს უჭერს ისეთი ცნობილი ინსტრუმენტების დასტა, როგორიცაა Docker და Kubernetes.

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

რა უნდა გავაკეთოთ ამ ყველაფერთან

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

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

• პროცესები და კულტურა;
• საიტის საიმედოობის ინჟინერია;
• Cloud Native;

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

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

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

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

არსებობს კიდევ ერთი ვარიანტი: თქვენ განაგრძობთ და განაგრძობთ იმის მტკიცებას, რომ ხართ კონკრეტულად DevOps ინჟინერი და სხვა არაფერი, რასაც ეს ნიშნავს. მაშინ ჩვენ უნდა გაგიცრუოთ, DevOops არ არის კონფერენცია DevOps ინჟინრებისთვის!

სრიალი საწყისი კონსტანტინე დინერის მოხსენება მიუნხენში

DevOops 2020 მოსკოვი 29-30 აპრილს მოსკოვში გაიმართება, ბილეთები უკვე ხელმისაწვდომია. შეძენა ოფიციალურ ვებსაიტზე.

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

წყარო: www.habr.com