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

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

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

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

მომხსენებლის შესახებ:

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

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

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

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

რა არის DevOps?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

მომსახურების ხაზი

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

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

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

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

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

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

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

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

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

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

5. კატას ვარჯიში

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

სულ

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

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

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

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

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

წყარო: www.habr.com