DevOps-ის მდგომარეობა რუსეთში 2020 წელი

როგორ გესმით რაღაცის მდგომარეობა?

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

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

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

DevOps კვლევა

საუბარი დაიწყო იგორ კუროჩკინმა.

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

აქ გვაქვს ჩვენი პირველი პრობლემა, რასაც მოჰყვება კიდევ ორი:

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

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

ისტორიული ინფორმაცია

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

2013 წელს გამოჩნდა IT Revolution, DevOps-ის ყველა ძირითადი წიგნის გამომცემელი. Puppet-თან ერთად მოამზადეს პირველი პუბლიკაცია „State of DevOps“, სადაც პირველად გამოჩნდა 4 ძირითადი მეტრიკა. მომდევნო წელს ჩაერთო საკონსულტაციო კომპანია ThoughtWorks, რომელიც ცნობილია თავისი რეგულარული ტექნოლოგიური რადარებით ინდუსტრიის პრაქტიკასა და ხელსაწყოებზე. 2015 წელს კი დაემატა განყოფილება მეთოდოლოგიით და გაირკვა, როგორ ახორციელებენ ანალიზს.

2016 წელს კვლევის ავტორებმა თავიანთი კომპანია DORA (DevOps Research and Assessment) შექმნეს ყოველწლიური ანგარიში. მომდევნო წელს DORA-მ და Puppet-მა გამოაქვეყნეს საბოლოო ერთობლივი ანგარიში.

და მერე საინტერესო გახდა:

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

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

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

როგორ არის საქმე რუსეთში?

ჩვენ არ ჩაგვიტარებია რაიმე კვლევა DevOps-ზე. ჩვენ ვისაუბრეთ კონფერენციებზე, ვუყვებოდით სხვა ადამიანების დასკვნებს და Raiffeisenbank-მა თარგმნა „DevOps-ის მდგომარეობა“ 2019 წლისთვის (შეგიძლიათ იპოვოთ მათი განცხადება Habré-ზე), დიდი მადლობა მათ. და ეს ყველაფერი.

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

კვლევის პროცესი

მოხსენება მხოლოდ დასკვნითი ნაწილია. მთელი კვლევის პროცესი შედგება ოთხი დიდი ეტაპისგან:

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

მონაწილეები

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

რუკა Accelerate State of DevOps 2019 ანგარიშიდან:

ჩვენს კვლევაში ჩვენ შევძელით 889 ადამიანის გასაუბრება - ეს საკმაოდ ბევრია (DORA ყოველწლიურად გამოკითხავს დაახლოებით ათას ადამიანს თავის ანგარიშებში) და აქ ჩვენ მივაღწიეთ ჩვენს მიზანს:

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

ინდუსტრიები და პოზიციები

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

ყოველი მეორე მუშაობს საშუალო ზომის კომპანიაში. ყოველი მესამე ადამიანი მუშაობს დიდ კომპანიებში. უმეტესობა მუშაობს 9 კაციან გუნდში. ცალ-ცალკე ვიკითხეთ ძირითადი აქტივობების შესახებ და უმეტესობა ასე თუ ისე დაკავშირებულია ოპერაციასთან და დაახლოებით 40% ჩართულია განვითარებაში:

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

ანალიზი და შედარება

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

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

ძირითადი მეტრიკა

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

ძირითადი მეტრიკა:

1. განლაგების სიხშირე. რამდენად ხშირად გამოიყენება აპლიკაციის ახალი ვერსია საწარმოო გარემოში (დაგეგმილი ცვლილებები, ცხელი შესწორებების და ინციდენტზე რეაგირების გამოკლებით)?
2. Მიტანის დრო. რა არის საშუალო დრო ცვლილების განხორციელებას (ფუნქციის კოდის სახით ჩაწერას) და ცვლილების წარმოების გარემოში განთავსებას შორის?
3. აღდგენის დრო. რამდენი დრო სჭირდება საშუალოდ აპლიკაციის აღდგენას საწარმოო გარემოში ინციდენტის, სერვისის დეგრადაციის ან შეცდომის გამოვლენის შემდეგ, რომელიც გავლენას ახდენს აპლიკაციის მომხმარებლებზე?
4. წარუმატებელი ცვლილებები. პროდუქტის გარემოში განლაგების რამდენ პროცენტს იწვევს აპლიკაციის დეგრადაცია ან ინციდენტები და საჭიროებს შედეგების აღმოფხვრას (ცვლილებების უკან დაბრუნება, ცხელი შესწორების ან პაჩის შექმნა)?

DORA-ს კვლევამ აღმოაჩინა კავშირი ამ მეტრიკასა და ორგანიზაციულ შესრულებას შორის. ჩვენ ასევე ვამოწმებთ მას ჩვენს კვლევაში.

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

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

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

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

რამდენი გათიშეთ გრამში?

ჩვენ გამოვიყენეთ იერარქიული კლასტერული ანალიზი:

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

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

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

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

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

მაშინ ჩნდება კითხვა: როგორ გამოვიყენოთ ეს ყველაფერი?

როგორ გამოვიყენოთ

თუ ავიღებთ რომელიმე გუნდს, 4 საკვანძო მეტრიკას და გამოვიყენებთ მაგიდაზე, მაშინ 85% შემთხვევაში ვერ მივიღებთ სრულ მატჩს - ეს არის მხოლოდ საშუალო მონაწილე და არა ის, რაც სინამდვილეშია. ჩვენ ყველანი (და ყველა გუნდი) ცოტა განსხვავებულები ვართ.

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

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

• DORA კალკულატორი
• კალკულატორი Express 42* (დამუშავების პროცესში)
• საკუთარი განვითარება (შეგიძლიათ შექმნათ თქვენი საკუთარი შიდა კალკულატორი).

რისთვის არიან საჭირო? Გაგება:

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

თქვენ ასევე შეგიძლიათ გამოიყენოთ ისინი კომპანიის შიგნით სტატისტიკის შესაგროვებლად:

• როგორი გუნდები გვყავს?
• დაყავით გუნდები პროფილებად;
• იხილეთ: ოჰ, ეს გუნდები არასაკმარისად მუშაობენ (ცოტა ნელი), მაგრამ ისინი შესანიშნავია: ისინი განალაგებენ ყოველდღე, შეცდომების გარეშე, მათი მოქმედების დრო ერთ საათზე ნაკლებია.

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

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

ჯარიმა. და თუ თქვენ ხართ Elit ჯგუფში DORA კალკულატორის მიხედვით, მაშინ რა უნდა გააკეთოთ? აქ კარგი გამოსავალი არ არის. დიდი ალბათობით, თქვენ ხართ ინდუსტრიის წინა პლანზე და შემდგომი აჩქარება და საიმედოობის გაუმჯობესება შესაძლებელია შიდა R&D და დიდი რესურსების დახარჯვით.

გადავიდეთ ყველაზე ტკბილ ნაწილზე - შედარებაზე.

შედარება

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

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

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

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

• ახალი პროდუქტები გამოვიდა 1,5-2-ჯერ უფრო ხშირად,
• აპლიკაციის ინფრასტრუქტურის საიმედოობის და/ან მუშაობის გაზრდა 2-ჯერ უფრო ხშირად.

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

კიდევ რა დაეხმარა ჩვენს გუნდებს?

საინჟინრო პრაქტიკა

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

პლატფორმა, როგორც სერვისი

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

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

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

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

ინტეგრაცია და მიწოდება

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

არქიტექტურა

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

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

როგორ აღმოვაჩინეთ ეს ყველაფერი?

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

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

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

კიდევ რა აღმოვაჩინეთ?

ინსტრუმენტები

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

ორკესტრებს შორის საიდუმლო არ არის, რომ Kubernetes ლიდერობს (52%). რიგის შემდეგი ორკესტრი არის Docker Swarm (დაახლოებით 12%). ყველაზე პოპულარული CI სისტემებია Jenkins და GitLab. ყველაზე პოპულარული კონფიგურაციის მართვის სისტემა არის Ansible, რომელსაც მოჰყვება ჩვენი საყვარელი Shell.

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

სიტყვას ვაძლევ იგორს, რომელიც კიდევ რამდენიმე სტატისტიკას მოგვცემს.

პრაქტიკის გავრცელება

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

Agile და DevOps

Agile-სა და DevOps-ს შორის ურთიერთობა ხშირად განიხილება ინდუსტრიაში. ეს კითხვა ასევე ჩნდება Agile-ის მდგომარეობის ანგარიშში 2019/2020 წლებისთვის, ამიტომ გადავწყვიტეთ შევადაროთ როგორ არის დაკავშირებული Agile და DevOps აქტივობები კომპანიებში. ჩვენ აღმოვაჩინეთ, რომ DevOps Agile-ის გარეშე იშვიათია. გამოკითხულთა ნახევრისთვის Agile-ის გავრცელება შესამჩნევად ადრე დაიწყო და დაახლოებით 20%-მა დააფიქსირა ერთდროული დაწყება და დაბალი პროფილის ერთ-ერთი ნიშანი იქნება Agile და DevOps პრაქტიკის არარსებობა:

გუნდის ტოპოლოგია

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

რესპონდენტთა ნახევარში დაკვირვებულია ინფრასტრუქტურის გუნდები, ასევე ცალკეული განვითარების, ტესტირებისა და ოპერაციების ჯგუფები. DevOps-ის ცალკეულმა გუნდებმა აღნიშნეს 45%, რომელთა შორის უფრო ხშირია მაღალი წარმომადგენლები. შემდეგი მოდის ჯვარედინი ფუნქციური გუნდები, რომლებიც ასევე უფრო ხშირია High-ში. ცალკეული SRE ბრძანებები გამოჩნდება მაღალი, საშუალო პროფილებში და იშვიათად გვხვდება დაბალი პროფილში:

DevQaOps თანაფარდობა

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

გეგმები 2021 წელი

მომავალი წლის გეგმებში რესპონდენტებმა აღნიშნეს შემდეგი აქტივობები:

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

• ინფრასტრუქტურა, როგორც პროდუქტი
• DevOps ტრანსფორმაცია
• DevOps პრაქტიკის განაწილება
• DevSecOps
• საქმის კლუბები და დისკუსიები

მაგრამ ჩვენს საუბარს არ ექნება საკმარისი დრო ყველა თემის გასაშუქებლად. Სცენის მიღმა:

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

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

შეჯამება

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

რუსეთში DevOps-ის მდგომარეობის პირველი კვლევის შედეგები:

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

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

წყარო: www.habr.com