რა არის DevOps

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

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

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

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

რატომ DevOps

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

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

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

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

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

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

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

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

ეს პროდუქტი Unilever-მა 1 მილიარდ დოლარად იყიდა. ის ახლა კონკურენციას უწევს Gillette-ს და წაართვა მომხმარებლების მნიშვნელოვანი წილი ამერიკულ ბაზარზე. One Box Shave ამბობს:

- 4 პირი? Სერიოზულად? რატომ გჭირდებათ ეს - ეს არ აუმჯობესებს გაპარსვის ხარისხს. სპეციალურად შერჩეული კრემი, სურნელი და მაღალი ხარისხის საპარსი ორი პირით ბევრად მეტ პრობლემას წყვეტს, ვიდრე ის სულელური 4 Gillette-ის პირი! მალე მივალთ 10-მდე?

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

Time-to-market-ის აზრი არ არის ის, თუ რამდენად ხშირად ვაყენებთ. ხშირად შეგიძლიათ განათავსოთ, მაგრამ გამოშვების ციკლები გრძელი იქნება. თუ სამთვიანი გამოშვების ციკლები ერთმანეთზეა გადანაწილებული, მათი გადანაცვლება ერთი კვირით, გამოდის, რომ კომპანია, როგორც ჩანს, კვირაში ერთხელ განათავსებს. იდეიდან საბოლოო განხორციელებამდე კი 3 თვე სჭირდება.

დრო ბაზარზე არის იდეიდან საბოლოო განხორციელებამდე დროის მინიმუმამდე შემცირება.

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

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

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

1968 წელს ხილვატორმა ბიჭმა, მელვინ კონვეიმ ჩამოაყალიბა შემდეგი იდეა.

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

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

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

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

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

რატომ გჭირდებათ DevOps?

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

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

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

DevOps-ით ყველაფერი უფრო გართულდება.

Avito-ს სტენდზე გამართულ კონფერენციაზე ხედავდით, როგორი იყო Docker კონტეინერის განლაგება - არარეალური ამოცანა. სირთულე ხდება აკრძალული; თქვენ უნდა ჯონგლირდეთ ბევრი ბურთით ერთდროულად.

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

კითხვები სპეციალისტს

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

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

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

არის თქვენი კომპანია ბაზრის ერთ-ერთი ლიდერი ციფრული პროდუქტის ნიშაში? Spotify, Yandex, Uber არის კომპანიები, რომლებიც ამჟამად ტექნოლოგიური პროგრესის პიკზე არიან.

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

ორგანიზაცია

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

"ჭების" პრობლემა

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

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

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

ამას ორი ფაქტორი უშლის ხელს.

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

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

— ჩვენ უბრალოდ გვინდოდა CI-ის გაშვება, მაგრამ აღმოჩნდა, რომ მენეჯმენტს ეს არ სჭირდებოდა.

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

პროცესის თითოეული მონაწილე კომპანიაში: backend და frontend დეველოპერები, ტესტირება, DBA, ოპერაცია, ქსელი, იჭრება საკუთარი მიმართულებით და არავის აქვს საერთო რუკა მენეჯერის გარდა, რომელიც როგორღაც აკონტროლებს მათ და მართავს მათ "გაყოფის" გამოყენებით. და დაიპყრო“ მეთოდი.

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

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

თქვენს კომპანიაშიც ასეა?

ამის შესამოწმებლად შეგიძლიათ საკუთარ თავს დაუსვათ შემდეგი კითხვები.

იყენებენ თუ არა გუნდები საერთო ინსტრუმენტებს და ხელს უწყობენ ამ საერთო ინსტრუმენტების ცვლილებებს?

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

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

რამდენად მნიშვნელოვანია მენეჯერებისთვის პირადი მიღწევების მიღება კომპანიის მიღწევების გათვალისწინების გარეშე?

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

ინფრასტრუქტურა როგორც კოდი

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

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

— მოდით, ყველაფერი ბაშში ავტომატიზირდეთ, თავი დავიფაროთ სკრიპტებით, რომ ადმინებს ნაკლები ხელით მუშაობა ჰქონდეთ!

მაგრამ ეს ასე არ არის.

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

სხვა გუნდებთან ერთად, თქვენ ქმნით რუკას კოდის სახით, რომლის გაგებაც ყველას შეუძლია და შეუძლია ნავიგაცია და ნავიგაცია. არ აქვს მნიშვნელობა რაზე კეთდება ეს - Chef, Ansible, Salt, თუ YAML ფაილების გამოყენება Kubernetes-ში - განსხვავება არ არის.

კონფერენციაზე 2GIS-ის კოლეგამ თქვა, თუ როგორ შექმნეს საკუთარი შიდა ნივთი Kubernetes-ისთვის, რომელიც აღწერს ინდივიდუალური სისტემების სტრუქტურას. 500 სისტემის აღსაწერად მათ სჭირდებოდათ ცალკე ინსტრუმენტი, რომელიც გამოიმუშავებს ამ აღწერას. როდესაც არის ეს აღწერა, ყველას შეუძლია შეამოწმოს ერთმანეთთან, აკონტროლოს ცვლილებები, როგორ შეცვალოს და გააუმჯობესოს, რა აკლია.

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

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

კოდი შენახულია საუკეთესო კოდექსის პრაქტიკის მიხედვით: ერთობლივი განვითარება, კოდის მიმოხილვა, XP-პროგრამირება, ტესტირება, pull მოთხოვნები, CI კოდის ინფრასტრუქტურისთვის - ეს ყველაფერი შესაფერისია და შეიძლება გამოყენებულ იქნას.

კოდი ხდება საერთო ენა ყველა ინჟინრისთვის.

კოდში ინფრასტრუქტურის შეცვლას დიდი დრო არ სჭირდება. დიახ, ინფრასტრუქტურის კოდს შეიძლება ჰქონდეს ტექნიკური დავალიანებაც. ჩვეულებრივ, გუნდები მას ხვდებიან წელიწადნახევრის შემდეგ, რაც დაიწყეს „ინფრასტრუქტურის როგორც კოდის“ დანერგვა სკრიპტების ან თუნდაც Ansible-ის სახით, რომელსაც წერენ როგორც სპაგეტის კოდი და ასევე ყრიან bash სკრიპტებს მიქსში!

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

ინფრასტრუქტურა როგორც კოდი არის ინფრასტრუქტურის კოდის ცალკეულ ფენებად დაყოფა.

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


ბაზის ფენა - ასე არის კონფიგურირებული OS, სარეზერვო ასლები და სხვა დაბალი დონის ნივთები, მაგალითად, როგორ არის განლაგებული Kubernetes საბაზისო დონეზე.

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

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

საკონტროლო კითხვები

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

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

უწყვეტი მიწოდება

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

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

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

საშუალებების გამუდმებით მიწოდება

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

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

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

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

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

"თანმიმდევრულად მიწოდება" ასე გამოიყურება.

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

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

თვითტესტის კითხვები

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

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

კავშირი

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

მაგალითად, დიდი ხნის წინ, როდესაც მე ვმუშაობდი Qik-ში და მივხვდით, რომ ყველაფრის მონიტორინგი გვჭირდებოდა. ჩვენ ეს გავაკეთეთ და ახლა გვაქვს 150 000 ნივთი Zabbix-ში, რომლებსაც მუდმივად აკვირდებიან. საშინელება იყო, ტექნიკურმა დირექტორმა თითი ტაძარში გადაატრიალა:

-ბიჭებო რატომ აძალებთ სერვერს რაღაც გაუგებარით?

მაგრამ შემდეგ მოხდა ინციდენტი, რომელმაც აჩვენა, რომ ეს მართლაც ძალიან მაგარი სტრატეგიაა.

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

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

- ბიჭებო, რა დაგემართათ კვირანახევრის წინ?

საპასუხოდ, ჩვენ მოვისმინეთ საინტერესო ამბავი იმის შესახებ, თუ როგორ გადააკეთეს UI. ნაკლებად სავარაუდოა, რომ ვინმემ დაუყოვნებლივ იტყვის, რომ მათ შეცვალეს HTTP ბიბლიოთეკა. Android-ის კლიენტებისთვის ეს ჰგავს საპნის შეცვლას აბაზანაში - მათ უბრალოდ არ ახსოვს. შედეგად, 40 წუთიანი საუბრის შემდეგ, აღმოვაჩინეთ, რომ მათ შეცვალეს HTTP ბიბლიოთეკა და შეიცვალა მისი ნაგულისხმევი დრო. ამან გამოიწვია ტრაფიკის ქცევა API სერვერზე, რამაც გამოიწვია სიტუაცია, რამაც გამოიწვია რბოლა ბროკერში და დაიწყო ავარია.

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

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

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

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

კითხვები თვითკონტროლისთვის

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

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

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

ინფრასტრუქტურის პლატფორმა

საქმე არ არის ის, რომ ეს არის სხვადასხვა ინსტრუმენტების ნაკრები, რომელიც ყველა კომპანიას აქვს.

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

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

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

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

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

ამ ეტაპზე ინფრასტრუქტურული პლატფორმა ხდება თქვენი კონკურენტული უპირატესობა, რადგან მასში ჩაშენებულია რაღაც, რაც არ არის კონკურენტის ინსტრუმენტში. რაც უფრო ღრმაა თქვენი IP, მით უფრო დიდია თქვენი კონკურენტული უპირატესობა Time-to-Market-ის თვალსაზრისით. აქ ჩნდება გამყიდველის დაბლოკვის პრობლემა: შეგიძლიათ აიღოთ სხვისი პლატფორმა, მაგრამ სხვისი გამოცდილების გამოყენებით ვერ გაიგებთ რამდენად აქტუალურია თქვენთვის. დიახ, ყველა კომპანიას არ შეუძლია შექმნას პლატფორმა, როგორიცაა Amazon. ეს არის რთული ხაზი, სადაც კომპანიის გამოცდილება შეესაბამება მის პოზიციას ბაზარზე და იქ ვერ გამოიყენებ გამყიდველის საკეტს. ეს ასევე მნიშვნელოვანია დაფიქრება.

სქემა

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

მოდით შევხედოთ რისგან შედგება.

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

უმაღლესი დონის მომსახურება: მონაცემთა ბაზა, როგორც სერვისი, რიგები, როგორც სერვისი, Load Balance, როგორც სერვისი, გამოსახულების ზომის შეცვლა, როგორც სერვისი, Big Data ქარხანა, როგორც სერვისი. ამის თავზე - მილსადენი, რომელიც აწვდის მუდმივად შეცვლილ კოდს თქვენს კლიენტს.

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

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

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

პლატფორმის შექმნა

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

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

Რა გაქვს?

კიდევ ერთხელ, კითხვები შეგიძლიათ დაუსვათ საკუთარ თავს.

არის თუ არა ინფრასტრუქტურის პლატფორმა გამოყოფილი? ვინ არის პასუხისმგებელი მის განვითარებაზე? გესმით თქვენი ინფრასტრუქტურული პლატფორმის კონკურენტული უპირატესობები?

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

ასე რომ, DevOps...

... ეს რთული სისტემაა, მას უნდა ჰქონდეს:

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

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

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

წყარო: www.habr.com