ვინ არიან DevOps?

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

ჩვენ ჯერ კიდევ ვეძებთ კოლეგებს, რადგან DevOps ეტიკეტის უკან იმალება სხვადასხვა სახის ინჟინრების ძალიან დიდი ფენა.

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

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

ვინ არიან DevOps ინჟინრები?

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

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

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

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

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

მშენებლობის ინჟინერი/გამოშვების ინჟინერი

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

ოპერაციები ძალიან განსხვავებულია

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

• TechOps - enikey სისტემის ადმინისტრატორები aka HelpDesk Engineer
• LiveOps - სისტემის ადმინისტრატორები, რომლებიც პასუხისმგებელნი არიან წარმოების გარემოზე
• CloudOps - სისტემის ადმინისტრატორები, რომლებიც სპეციალიზირებულნი არიან საჯარო ღრუბლებში Azure, AWS, GCP და ა.შ.
• PlatOps/InfraOps/SysOps - ინფრასტრუქტურის სისტემის ადმინისტრატორები.
• NetOps - ქსელის ადმინისტრატორები
• SecOps - სისტემური ადმინისტრატორები, რომლებიც სპეციალიზირებულნი არიან ინფორმაციულ უსაფრთხოებაში - PCI შესაბამისობა, CIS შესაბამისობა, პაჩინგი და ა.შ.

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

ამ სახის სამუშაოსა და პასუხისმგებლობების შესასრულებლად ამ ადამიანს უნდა ჰქონდეს საშუალება მართოს არა მხოლოდ განვითარებისა და ტესტირების პროცესები, არამედ პროდუქტის ინფრასტრუქტურის მართვა, ასევე რესურსების დაგეგმვა. DevOps ამ გაგებით არ შეიძლება განთავსდეს არც IT-ში, არც R&D-ში და არც PMO-ში; მას უნდა ჰქონდეს გავლენა ყველა ამ სფეროში - კომპანიის ტექნიკური დირექტორი, მთავარი ტექნიკური ოფიცერი.

მართალია ეს თქვენს კომპანიაში? - Ვეჭვობ. უმეტეს შემთხვევაში, ეს არის IT ან R&D.

სახსრების ნაკლებობა და აქტივობის ამ სამი სფეროდან მინიმუმ ერთზე გავლენის მოხდენის უნარი გადაიტანს პრობლემების წონას იქ, სადაც ეს ცვლილებები უფრო ადვილი გამოსაყენებელია, მაგალითად, ტექნიკური შეზღუდვების გამოყენება გამოშვებებზე „ბინძურ“ კოდთან დაკავშირებით სტატიკის მიხედვით. ანალიზატორი სისტემები. ანუ, როდესაც PMO ადგენს მკაცრ ვადას ფუნქციონალობის გამოშვებისთვის, R&D ვერ აწარმოებს მაღალი ხარისხის შედეგს ამ ვადების ფარგლებში და აწარმოებს მას, როგორც შეუძლია, ტოვებს რეფაქტორირებას მოგვიანებით, IT-თან დაკავშირებული DevOps ბლოკავს გამოშვებას ტექნიკური საშუალებებით. . სიტუაციის შეცვლის უფლებამოსილების არქონა, პასუხისმგებელი თანამშრომლების შემთხვევაში, იწვევს ჰიპერპასუხისმგებლობის გამოვლინებას იმაზე, რაზეც მათ არ შეუძლიათ გავლენა მოახდინონ, განსაკუთრებით იმ შემთხვევაში, თუ ეს თანამშრომლები ესმით და ხედავენ შეცდომებს და როგორ გამოასწორონ ისინი - „ნეტარება არის უცოდინრობა“. და შედეგად ამ თანამშრომლების დამწვრობა და დაკარგვა.

DevOps რესურსების ბაზარი

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

ჩვენ მზად ვართ შეგხვდეთ, თუ თქვენ:

1. თქვენ ფლობთ Zabbix-ს და იცით, რა არის პრომეთე;
2. Iptables;
3. BASH დოქტორანტი;
4. პროფესორი Ansible;
5. Linux Guru;
6. იცოდეთ როგორ გამოიყენოთ გამართვა და იპოვოთ აპლიკაციის პრობლემები დეველოპერებთან ერთად (php/java/python);
7. მარშრუტიზაცია არ გიქმნის ისტერიკას;
8. მნიშვნელოვანი ყურადღება მიაქციეთ სისტემის უსაფრთხოებას;
9. შექმენით სარეზერვო "ყველაფერი და ყველაფერი" და ასევე წარმატებით აღადგინეთ ეს "ყველაფერი და ყველაფერი";
10. თქვენ იცით, როგორ დააკონფიგურიროთ სისტემა ისე, რომ მიიღოთ მაქსიმუმი მინიმალურიდან;
11. დააყენეთ რეპლიკაცია ძილის წინ Postgres-სა და MySQL-ზე;
12. CI/CD-ის დაყენება და რეგულირება თქვენთვის ისეთივე აუცილებელია, როგორც საუზმე/ლანჩი/ვახშამი.
13. აქვს გამოცდილება AWS-თან;
14. მზად არის განვითარდეს კომპანიასთან ერთად;

ასე რომ:

• 1-დან 6-მდე - სისტემის ადმინისტრატორი
• 7 - პატარა ქსელის ადმინისტრირება, რომელიც ასევე ჯდება სისტემის ადმინისტრატორში, საშუალო დონეზე
• 8 - მცირე უსაფრთხოება, რომელიც სავალდებულოა საშუალო დონის სისტემის ადმინისტრატორისთვის
• 9-11 – შუა სისტემის ადმინისტრატორი
• 12 — დავალებული ამოცანების მიხედვით, ან Middle System Administrator ან Build Engineer
• 13 - ვირტუალიზაცია - შუა სისტემის ადმინისტრატორი, ან ე.წ. CloudOps, კონკრეტული ჰოსტინგის საიტის სერვისების გაფართოებული ცოდნა, სახსრების ეფექტური გამოყენებისა და ტექნიკური დატვირთვის შესამცირებლად.

ამ ვაკანსიის შეჯამებით შეგვიძლია ვთქვათ, რომ საშუალო/უფროსი სისტემის ადმინისტრატორი საკმარისია ბიჭებისთვის.

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

განვიხილოთ კიდევ ერთი ვაკანსია:

1. გამოცდილება მაღალი დატვირთვის სისტემების მშენებლობაში;
2. Linux OS, ზოგადი სისტემის პროგრამული უზრუნველყოფის და ვებ სტეკის (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) შესანიშნავი ცოდნა;
3. ვირტუალიზაციის სისტემებთან მუშაობის გამოცდილება (KVM, VMWare, LXC/Docker);
4. სკრიპტირების ენების ცოდნა;
5. ქსელის პროტოკოლის ქსელების მუშაობის პრინციპების გააზრება;
6. ხარვეზების ტოლერანტული სისტემების აგების პრინციპების გააზრება;
7. დამოუკიდებლობა და ინიციატივა;

მოდით შევხედოთ:

• 1 – სისტემის უფროსი ადმინისტრატორი
• 2 - ამ დასტაში ჩადებული მნიშვნელობიდან გამომდინარე - სისტემის შუა/უფროსი ადმინისტრატორი
• 3 - სამუშაო გამოცდილება, მათ შორის, შეიძლება ნიშნავდეს - "კლასტერმა არ შექმნა, არამედ შექმნა და მართა ვირტუალური მანქანები, იყო ერთი Docker ჰოსტი, კონტეინერებზე წვდომა არ იყო ხელმისაწვდომი" - Middle System Administrator
• 4 - უმცროსი სისტემის ადმინისტრატორი - დიახ, ადმინი, რომელმაც არ იცის ძირითადი ავტომატიზაციის სკრიპტების დაწერა, ენის მიუხედავად, არა ადმინ - enikey.
• 5 - შუა სისტემის ადმინისტრატორი
• 6 – სისტემის უფროსი ადმინისტრატორი

შეჯამება - საშუალო/უფროსი სისტემის ადმინისტრატორი

Სხვა:

1. Devops გამოცდილება;
2. ერთი ან მეტი პროდუქტის გამოყენების გამოცდილება CI/CD პროცესების შესაქმნელად. Gitlab CI იქნება უპირატესობა;
3. კონტეინერებთან მუშაობა და ვირტუალიზაცია; თუ იყენებდი დოკერს, კარგია, მაგრამ თუ იყენებდი k8-ს, შესანიშნავია!
4. მოქნილ გუნდში მუშაობის გამოცდილება;
5. ნებისმიერი პროგრამირების ენის ცოდნა;

Მოდი ვნახოთ:

• 1 - ჰმ... რას გულისხმობენ ბიჭები? =) დიდი ალბათობით მათ თავად არ იციან რა იმალება მის უკან
• 2 - სამშენებლო ინჟინერი
• 3 - შუა სისტემის ადმინისტრატორი
• 4 - რბილი უნარი, ჩვენ არ განვიხილავთ მას ახლა, თუმცა Agile არის კიდევ ერთი რამ, რაც ინტერპრეტირებულია მოსახერხებელი გზით.
• 5 - ზედმეტად ვრცელი - ეს შეიძლება იყოს სკრიპტირების ენა ან შედგენილი. მაინტერესებს სკოლაში პასკალზე და საბაზისოზე წერა მოერგებათ მათ? =)

მე ასევე მსურს დავტოვო შენიშვნა მე-3 პუნქტთან დაკავშირებით, რათა გავაძლიერო იმის გაგება, თუ რატომ არის დაფარული ეს პუნქტი სისტემის ადმინისტრატორის მიერ. Kubernetes არის მხოლოდ ორკესტრირება, ინსტრუმენტი, რომელიც პირდაპირ ბრძანებებს ახვევს ქსელის დრაივერებს და ვირტუალიზაციის/იზოლაციის ჰოსტებს რამდენიმე ბრძანებაში და საშუალებას გაძლევთ, მათთან ურთიერთობა აბსტრაქტული გახადოთ, ეს ყველაფერია. მაგალითად, ავიღოთ 'build Framework' Make, რომელიც, სხვათა შორის, მე არ მიმაჩნია ფრეიმიკად. კი, მე ვიცი მაკის სადმე გადაყრის მოდა, სადაც არის საჭირო და არა საჭირო - მავენის შეფუთვა მაგალითად, სერიოზულად?
არსებითად, Make არის მხოლოდ შეფუთვა ჭურვიზე, რომელიც ამარტივებს კომპილაციის, დაკავშირების და კომპილაციის გარემოს ბრძანებებს, ისევე როგორც k8s.

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

კიდევ ერთხელ შევაჯამოთ - მათთვის საკმარისი იქნება სისტემის საშუალო/უფროსი ადმინისტრატორი.

რამდენს იწონის გრამებში

მითითებულ ვაკანსიებზე შემოთავაზებული ხელფასის დიაპაზონი 90-200 ათასია
ახლა მინდა გავავლო პარალელი სისტემის ადმინისტრატორებისა და DevOps ინჟინრების ფულად ჯილდოებს შორის.

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

Გამოცდილება:

1. 3 წლამდე - უმცროსი
2. 6 წლამდე – შუა
3. 6-ზე მეტი - უფროსი

თანამშრომლების საძიებო საიტი გთავაზობთ:
სისტემის ადმინისტრატორები:

1. უმცროსი - 2 წელი - 50 ათასი რუბლი.
2. საშუალო - 5 წელი - 70 ათასი რუბლი.
3. უფროსი - 11 წელი - 100 ათასი რუბლი.

DevOps ინჟინრები:

1. უმცროსი - 2 წელი - 100 ათასი რუბლი.
2. საშუალო - 3 წელი - 160 ათასი რუბლი.
3. უფროსი - 6 წელი - 220 ათასი რუბლი.

"DevOps"-ის გამოცდილების თანახმად, გამოყენებული იქნა გამოცდილება, რომელიც გარკვეულწილად იმოქმედა SDLC-ზე.

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

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

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

მაშ ვინ არიან ისინი? DevOps თუ ხარბი სისტემის ადმინისტრატორები? =)

როგორ გავაგრძელო ცხოვრება?

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

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

წყარო: www.habr.com