რატომ უნდა გახდნენ სისტემის ადმინისტრატორები DevOps-ის ინჟინრები

არ არსებობს სწავლისთვის უკეთესი დრო, ვიდრე დღეს.

2019 წელია და DevOps უფრო აქტუალურია, ვიდრე ოდესმე. ისინი ამბობენ, რომ სისტემის ადმინისტრატორების დღეები დასრულდა, ისევე როგორც მეინფრემის ეპოქა. მაგრამ მართლა ასეა?
როგორც ხშირად ხდება IT-ში, სიტუაცია შეიცვალა. გაჩნდა DevOps მეთოდოლოგია, მაგრამ ის ვერ იარსებებს სისტემის ადმინისტრატორის უნარების მქონე პირის გარეშე, ანუ Ops-ის გარეშე.

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

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

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

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

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

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

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

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

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

Რა უნდა ვქნა? სპეციალისტად მოთხოვნადი რომ დარჩე, საჭიროა შესაბამისი უნარ-ჩვევების შეძენა - მინიმუმ ერთი პროგრამირების ენის ათვისება, მაგალითად Python. ეს შეიძლება რთულად მოეჩვენოს ადამიანს, რომელიც პროფესიონალურად არის ჩართული ადმინისტრაციაში, რადგან ის მიჩვეულია იფიქროს, რომ მხოლოდ დეველოპერები პროგრამებენ. არ არის აუცილებელი გახდე ექსპერტი, არამედ პროგრამირების ერთ-ერთი ენის ცოდნა (ეს შეიძლება იყოს Python, Bash ან თუნდაც Powershell), აუცილებლად იქნება უპირატესობა.

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

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

მაგრამ რამდენად მართალია ეს განცხადება?

სისტემის ადმინისტრატორი: ერთი მეომარი მინდორში

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

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

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

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

სისტემის ადმინისტრატორის ამოცანაა არ დაკარგოს დრო და დაზოგოს კომპანიის ფული არანაირად. ზოგჯერ სისტემის ადმინისტრატორები მუშაობენ როგორც დიდი გუნდის წევრები, აერთიანებენ, მაგალითად, Linux-ის, Windows-ის, მონაცემთა ბაზების, შენახვისა და ა.შ. სამუშაო გრაფიკიც განსხვავებულია. მაგალითად, დღის ბოლოს ერთ სასაათო სარტყელში ცვლა საქმეებს გადასცემს შემდეგ ცვლას სხვა დროის სარტყელში, რათა პროცესები არ შეჩერდეს (follow-the-sun); ან თანამშრომლებს აქვთ ნორმალური სამუშაო დღე დილის 9-დან საღამოს 5-მდე; ან ის მუშაობს XNUMX/XNUMX მონაცემთა ცენტრში.

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

DevOps: განვითარება და შენარჩუნება, როგორც ერთი

DevOps არის განვითარებისა და შენარჩუნების პროცესების ერთგვარი ფილოსოფია. ეს მიდგომა IT სამყაროში მართლაც ინოვაციური გახდა.

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

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

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

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

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

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

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

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

თუ თქვენ ხართ სისტემის ადმინისტრატორი, მაშინ უკეთ უნდა შეისწავლოთ Git, გაიგოთ, თუ როგორ არის აგებული ვერსიის კონტროლი და გახსოვდეთ საერთო ბრძანებები: git სტატუსი, git commit -m, git add, git pull, git push, git rebase, git branch, git diff და სხვა. არსებობს მრავალი ონლაინ კურსი და წიგნი, რომელიც დაგეხმარებათ ამ თემის ნულიდან შესწავლაში და გახდეთ პროფესიონალი კონკრეტული უნარებით. ასევე არის მშვენიერი მოტყუების ფურცლები Git ბრძანებებით, ასე რომ თქვენ არ მოგიწევთ ყველა მათგანის გადატვირთვა, მაგრამ რაც უფრო მეტს იყენებთ Git-ს, მით უფრო ადვილი იქნება.

დასკვნა

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

წყარო: www.habr.com