ჩვენ ვსაუბრობთ DevOps-ზე გასაგებ ენაზე

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

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

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

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

რა არის DevOps: 6 განმარტებები და ანალოგიები

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

1. DevOps არის კულტურული მოძრაობა

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

2. DevOps არის დეველოპერების გაძლიერება.

„DevOps აძლევს დეველოპერებს უფლებას ფლობდნენ აპლიკაციებს, მართონ ისინი და მართონ მიწოდება თავიდან ბოლომდე“.

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

3. DevOps არის თანამშრომლობა აპლიკაციების შექმნასა და მიწოდებაში.

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

4. DevOps არის მილსადენი

"კონვეიერის აწყობა შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ ყველა ნაწილი ერთმანეთთან ჯდება."

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

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

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

5. DevOps არის ხალხის, პროცესებისა და ავტომატიზაციის სწორი კომბინაცია

ჯეინ გროლმა, DevOps ინსტიტუტის აღმასრულებელმა დირექტორმა, შესთავაზა შესანიშნავი ანალოგია DevOps-ის ასახსნელად. მისი სიტყვებით, „DevOps ჰგავს რეცეპტს სამი ძირითადი კატეგორიის ინგრედიენტებით: ხალხი, პროცესი და ავტომატიზაცია. ამ ინგრედიენტების უმეტესი ნაწილი შეიძლება იქნას მიღებული სხვა სფეროებიდან და წყაროებიდან: Lean, Agile, SRE, CI/CD, ITIL, ლიდერობა, კულტურა, ხელსაწყოები. DevOps-ის საიდუმლო, ისევე როგორც ნებისმიერი კარგი რეცეპტი, არის ის, თუ როგორ მივიღოთ სწორი პროპორციები და ამ ინგრედიენტების შერევა, რათა გაზარდოს აპლიკაციების შექმნისა და გამოშვების სიჩქარე და ეფექტურობა.

6. DevOps არის, როდესაც პროგრამისტები მუშაობენ ფორმულა 1-ის გუნდის მსგავსად

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

„როდესაც ვსაუბრობ იმაზე, თუ რას უნდა ველოდოთ DevOps-ის ინიციატივისგან, ვიყენებ NASCAR-ის ან ფორმულა 1-ის სარბოლო გუნდის მაგალითს“, - ამბობს კრის შორტი, ღრუბლოვანი პლატფორმის მარკეტინგის უფროსი მენეჯერი Red Hat-ში და DevOps'ish ბიულეტენის გამომცემელი. – ასეთი გუნდის ლიდერს აქვს ერთი მიზანი: დაიკავოს რბოლის ბოლოს რაც შეიძლება მაღალი ადგილი, გუნდისთვის ხელმისაწვდომი რესურსებისა და მასზე არსებული გამოწვევების გათვალისწინებით. ამ შემთხვევაში, რბოლა დაგეგმილია არა თავიდან ბოლომდე, არამედ პირიქით, ბოლოდან დაწყებამდე. ჯერ დგინდება ამბიციური მიზანი, შემდეგ კი მისი მიღწევის გზები. შემდეგ ისინი იყოფა ქვეამოცნებებად და გადაეცემა გუნდის წევრებს“.

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

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

როგორ გავზარდოთ DevOps: 10 რჩევა ექსპერტებისგან

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

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

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

ადვილი მისახვედრია, რომ შედეგი არის „ჩვენ“ და „მათ“ ​​შორის გაყოფის კულტურა.

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

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

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

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

1. გახსოვდეთ, რომ კულტურის შეცვლას დრო სჭირდება.

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

2. საკმარისი დრო დაუთმეთ პლატფორმის დაგეგმვასა და არჩევას

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

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

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

3. ამოიღეთ დანაშაული პასუხისმგებლობისგან.

გორდონ ჰაფი, RedHat ევანგელისტი: ”სისტემისა და ატმოსფეროს შექმნა, რომელიც საშუალებას აძლევს და წაახალისებს ექსპერიმენტებს, საშუალებას იძლევა, რომ წარმატებული წარუმატებლობაა სწრაფი პროგრამული უზრუნველყოფის შემუშავებაში. ეს არ ნიშნავს, რომ სხვა არავინ არის პასუხისმგებელი წარუმატებლობაზე. სინამდვილეში, პასუხისმგებლობის დადგენა კიდევ უფრო ადვილი ხდება, რადგან „პასუხისმგებლობა“ აღარ ნიშნავს „ავარიის გამოწვევას“. ანუ პასუხისმგებლობის არსი ხარისხობრივად იცვლება. ოთხი ფაქტორი ხდება კრიტიკული: შეფერხების მასშტაბი, მიდგომები, წარმოების პროცესები და წახალისება.” (ამ ფაქტორების შესახებ მეტი შეგიძლიათ წაიკითხოთ გორდონ ჰაფის სტატიაში „DevOps გაკვეთილები: ჯანსაღი ექსპერიმენტების 4 ასპექტი“.)

4. გაასუფთავეთ წინსვლის გზა

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

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

5. ინსტრუმენტების დემოკრატიზაცია

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

6. შექმენით იდეალური პირობები გუნდური მუშაობისთვის

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

7. არ დაივიწყოთ კონვეის კანონი და კანბანის დაფები

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

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

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

8. მოძებნეთ ძველი ნაწიბურები

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

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

9. ნუ გამოიმუშავებთ DevOps-ის ვარიანტებს

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

10. ქადაგეთ DevOps-ის ბიზნეს ღირებულება

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

ბონუსი

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

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

მაგრამ ეს ყველაფერი არ არის:

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

წყარო: www.habr.com