DevOps LEGO: როგორ დავხატეთ მილსადენი კუბებად

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

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

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

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

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

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

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

DevOps კონსტრუქტორის შექმნა

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

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

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

Процессы

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

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

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

კულტურა

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

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

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

ხალხი

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

ტექნიკა

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

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

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

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

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

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

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

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

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

ვის დასჭირდება ჩვენი DevOps დიზაინერი?

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

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

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

წყარო: www.habr.com