შვიდი ტრანსფორმაციის არქეტიპი DevOps-ის პრინციპებზე დაფუძნებული

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

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

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

სპიკერის შესახებ:

35 წელზე მეტი ხნის განმავლობაში IT მენეჯმენტში, მონაწილეობა მიიღო OpenCloud-ის წინამორბედის შექმნაში Canonical-ში, მონაწილეობა მიიღო 10 სტარტაპში, რომელთაგან ორი გაიყიდა Dell-სა და Docker-ზე. ამჟამად ის არის SJ Technologies-ის DevOps და ციფრული პრაქტიკის ვიცე პრეზიდენტი.

შემდეგი არის ამბავი ჯონის თვალსაზრისით.

მე მქვია ჯონ უილისი და ყველაზე ადვილი საპოვნელი ადგილია Twitter-ზე. @botchagalupe. იგივე მეტსახელი მაქვს Gmail-ზე და GitHub-ზე. ა ამ ბმულით თქვენ შეგიძლიათ იპოვოთ ჩემი მოხსენებების ვიდეოჩანაწერები და პრეზენტაციები მათთვის.

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

რა არის DevOps?

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

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

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

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

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

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

ცუდი კულტურა საუზმეზე კარგ მიდგომებს ჭამს

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

ამ მთავარი პრობლემის გადასაჭრელად, თქვენ უნდა გადადგათ შემდეგი ნაბიჯები:

1. გახადე ყველა სამუშაო ხილული: თქვენ უნდა გახადოთ ყველა სამუშაო ხილული. არა იმ გაგებით, რომ ის აუცილებლად უნდა იყოს ნაჩვენები რომელიმე ეკრანზე, არამედ იმ გაგებით, რომ ის დაკვირვებადი უნდა იყოს.
2. სამუშაოების მართვის კონსოლიდირებული სისტემები: მართვის სისტემები უნდა იყოს კონსოლიდირებული. „გვაროვნული“ ცოდნისა და ინსტიტუციური ცოდნის პრობლემაში 9-დან 10 შემთხვევაში ბოსტნეულობა ხალხია. Წიგნში "ფენიქსის პროექტი" პრობლემა იყო ერთ ადამიანთან, ბრენტთან, რომელმაც განაპირობა პროექტი სამი წლით ჩამორჩენილი გეგმის მიხედვით. და ყველგან ვხვდები ამ "ბრენტებს". ამ შეფერხებების მოსაგვარებლად, მე ვიყენებ ჩვენი სიის შემდეგ ორ ელემენტს.
3. შეზღუდვების თეორია მეთოდოლოგია: შეზღუდვების თეორია.
4. თანამშრომლობის ჰაკები: თანამშრომლობის ჰაკები.
5. ტოიოტა კატა (მწვრთნელი კატა): ტოიოტა კატაზე ბევრს არ ვისაუბრებ. დაინტერესების შემთხვევაში, ჩემს github-ზე არის პრეზენტაციები თითქმის ყველა ამ თემაზე.
6. ბაზარზე ორიენტირებული ორგანიზაცია: ბაზარზე ორიენტირებული ორგანიზაცია.
7. Shift-მარცხნივ აუდიტორები: აუდიტი ციკლის ადრეულ ეტაპებზე.

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

(ეს ილუსტრაცია შეიძლება ცალკე იხილოთ იხილეთ ბმული)

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

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

(ეს ილუსტრაცია შეიძლება ცალკე იხილოთ იხილეთ ბმული)

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

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

(ეს ილუსტრაცია შეიძლება ცალკე იხილოთ იხილეთ ბმული)

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

(ეს ილუსტრაცია შეიძლება ცალკე იხილოთ იხილეთ ბმული)

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

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

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

(ეს ილუსტრაცია შეიძლება ცალკე იხილოთ იხილეთ ბმული)

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

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

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

1. გახადეთ ყველა სამუშაო ხილული: გახადეთ სამუშაო ხილული

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

• ძალიან ბევრი სამუშაო პროცესის პროცესში (WIP)
• უცნობი დამოკიდებულებები
• დაუგეგმავი სამუშაო
• ურთიერთგამომრიცხავი პრიორიტეტები
• უგულებელყოფილი სამუშაო

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

The Phoenix Project არის მშვენიერი ამბავი პროექტის შესახებ, რომელიც სამი წლით დაგვიანებული იყო. ერთ-ერთ პერსონაჟს ამის გამო სამსახურიდან გათავისუფლება ემუქრება და ის ხვდება სხვა პერსონაჟს, რომელიც ერთგვარ სოკრატედ არის წარმოდგენილი. ის ეხმარება იმის გარკვევაში, თუ რა მოხდა არასწორად. ირკვევა, რომ კომპანიას ჰყავს ერთი სისტემური ადმინისტრატორი, რომლის სახელია ბრენტი და მთელი სამუშაო რატომღაც მასზე გადის. ერთ-ერთ შეხვედრაზე ერთ-ერთ ქვეშევრდომს ეკითხებიან: რატომ სჭირდება ყოველ ნახევარსაათიან დავალებას კვირაში? პასუხი არის რიგის თეორიისა და ლიტლის კანონის ძალიან გამარტივებული პრეზენტაცია და ამ პრეზენტაციაში ირკვევა, რომ 90% დაკავებულობისას, სამუშაოს ყოველ საათს 9 საათი სჭირდება. თითოეული დავალება უნდა გაეგზავნოს სხვა შვიდ ადამიანს, ასე რომ, ეს საათი გახდება 63 საათი, 7-ჯერ 9. მე ვამბობ, რომ იმისათვის, რომ გამოიყენოთ ლიტლის კანონი ან რაიმე რთული რიგის თეორია, თქვენ მინიმუმ უნდა გქონდეთ მონაცემები.

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

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

2. სამუშაოს მართვის სისტემების კონსოლიდაცია: დავალების მართვა

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

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

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

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

მომსახურების მილსადენი

ეს ისევ მხოლოდ დიდ კორპორაციებს ეხება. თუ ახალი კომპანია ხართ ახალ სფეროში, ასწიეთ ხელები და იმუშავეთ Travis CI-ით ან CircleCI-ით. რაც შეეხება Fortune 5000 კომპანიებს, ასეთი შემთხვევა მოხდა ბანკში, სადაც მე ვმუშაობდი. Google მივიდა მათთან და აჩვენეს ძველი IBM სისტემების დიაგრამები. გუგლის ბიჭებმა დაბნეულმა ჰკითხეს - სად არის ამის წყაროს კოდი? მაგრამ არ არსებობს წყაროს კოდი, თუნდაც GUI. ეს არის რეალობა, რომელსაც დიდი ორგანიზაციები უწევთ საქმე: 40 წლის წინანდელი საბანკო ჩანაწერები უძველეს მეინფრეიმზე. ჩემი ერთ-ერთი კლიენტი იყენებს Kubernetes კონტეინერებს Circuit Breaker-ის შაბლონებით, პლუს Chaos Monkey, ყველაფერი KeyBank აპლიკაციისთვის. მაგრამ ეს კონტეინერები საბოლოოდ უკავშირდება COBOL აპლიკაციას.

გუგლის ბიჭები სრულიად დარწმუნებულნი იყვნენ, რომ გადაჭრიდნენ ჩემი კლიენტის ყველა პრობლემას და შემდეგ დაიწყეს კითხვების დასმა: რა არის IBM datapipe? მათ ეუბნებიან: ეს არის დამაკავშირებელი. რას აკავშირებს? Sperry სისტემისკენ. და რა არის ეს? Და ასე შემდეგ. ერთი შეხედვით ჩანს: როგორი DevOps შეიძლება იყოს? მაგრამ სინამდვილეში ეს შესაძლებელია. არსებობს მიწოდების სისტემები, რომლებიც საშუალებას გაძლევთ გადასცეთ სამუშაო პროცესი მიწოდების გუნდებს.

3. შეზღუდვების თეორია: შეზღუდვების თეორია

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

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

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

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

4. თანამშრომლობის ჰაკები: თანამშრომლობის ჰაკები

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

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

5. მწვრთნელი კატა

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

ამ თემაზე ასევე კარგი საუბარია მაიკ როტერისგან:

6. ბაზარზე ორიენტირებული: ბაზარზე ორიენტირებული ორგანიზაცია

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

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

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

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

7. Shift-მარცხნივ აუდიტორები: აუდიტი ციკლის დასაწყისში. ჩვენებაზე უსაფრთხოების წესების დაცვა

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

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

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

მიხედვით მოხსენებაSonatype-ის მიერ 2018 წელს შექმნილი, 2017 წელს 87 მილიარდი OSS ჩამოტვირთვის მოთხოვნა იყო.

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

ამ თანმიმდევრობის მაგალითი:


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

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

სულ

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

სასარგებლო ბმულები

აქ არის რამდენიმე საუბარი DevOops კონფერენციიდან, რომელიც შეიძლება გამოგადგეთ:

• სერგეი ბერდნიკოვი, არტიომ კალიჩკინი - წარმატების ისტორია, ან "Dev+DevOps+Ops" (ვიდეო, მოხსენების ჩანაწერი)
• ბარუხ სადოგურსკი, ლეონიდ იგოლნიკი - DevOps მასშტაბით: ბერძნული ტრაგედია სამ მოქმედებად (ვიდეო, მოხსენების ჩანაწერი)
• ალექსანდრე ტიტოვი, კირილ ტოლკაჩოვი - DevOps, ინჟინრები და საზოგადოება
• ტიმოთი ლისტერი - პერსონაჟები, საზოგადოება და კულტურა: კეთილდღეობის მნიშვნელოვანი ფაქტორები

შეხედეთ პროგრამა DevOops 2020 მოსკოვი — იქაც ბევრი საინტერესო რამ არის.

წყარო: www.habr.com