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

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

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

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

ჩვენ ამჟამად ვართ Sre Onboarding Team-ში, რომელიც შედგება ექვსი პროგრამისტისა და სამი ინფრასტრუქტურის ინჟინრისგან. ჩვენ ყველა ვცდილობთ დავწეროთ ინფრასტრუქტურა, როგორც კოდი (IaC). ჩვენ ამას ვაკეთებთ იმიტომ, რომ ძირითადად ვიცით როგორ დავწეროთ კოდი და გვაქვს „საშუალოზე მაღალი“ დეველოპერების ისტორია.

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

ტექნოლოგიური დასტა, რომელსაც ჩვენ ვიყენებთ ჩვენს IaC-ში.

• ტერაფორმა რესურსების შესაქმნელად.
• შეფუთვა სურათების აწყობისთვის. ეს არის Windows, CentOS 7 სურათები.
• Jsonnet მძლავრი კონსტრუქციის შესაქმნელად drone.io-ში, ასევე შეფუთვის json და ჩვენი ტერაფორმული მოდულების გენერირებისთვის.
• ცისფერთვალება.
• შესაძლებელია სურათების მომზადებისას.
• პითონი დამხმარე სერვისებისთვის და სკრიპტების მიწოდებისთვის.
• და ეს ყველაფერი VSCode-ში გუნდის წევრებს შორის გაზიარებული დანამატებით.

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

ჩვენ ამჟამად ვიბრძვით შემდეგ IaC პრობლემებთან:

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

ექსტრემალური პროგრამირება (XP) სამაშველოში

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

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

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

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

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

მოდით გადავხედოთ XP-ის ზოგიერთ პრაქტიკას და როგორ მოქმედებს ისინი უკუკავშირის სიჩქარესა და ხარისხზე.

XP უკუკავშირის მარყუჟის პრინციპი

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

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

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

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

როგორ გამოიყვანოთ თავი სასოწარკვეთის უფსკრულიდან: სამი პრაქტიკა

ტესტები

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

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

არსებობს კლასიკური ტესტირების პირამიდა, რომელიც აჩვენებს, რომ მეტი ტესტი უნდა იყოს.

როგორ გამოიყენება ეს ჩარჩო ჩვენთვის IaC პროექტში? სინამდვილეში... სულაც არა.

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

  ასე გამოიყურება ინტეგრაციის ტესტები.

  
  
  ეს არის მაგალითი Drone CI-ში სურათების აგებისას. მათთან მისასვლელად, თქვენ უნდა დაელოდოთ 30 წუთი Packer გამოსახულების ჩამოყალიბებას, შემდეგ დაელოდეთ კიდევ 15 წუთს, სანამ ისინი გაივლიან. მაგრამ ისინი არსებობენ!

  სურათის გადამოწმების ალგორითმი

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

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

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

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

მაგალითად, დაგვჭირდა დავრწმუნდეთ, რომ ვირტუალური აპარატის გაშვებისას ის თავად დარეგისტრირდება სერვისში ScaleFTდა როდესაც ვირტუალური მანქანა განადგურდა, ის თვითონ წაიშალა.

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

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

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

დაწყვილების პროგრამირება

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

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

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

ქვემოთ მოცემულია წყვილის პროგრამირების სტილები და მათი გამოყენებადობა IaC-ზე მუშაობისას:

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

მოდით განვიხილოთ ჩვენი პრობლემების თავსებადობა სტილთან:

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

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

დასკვნა: მისი სუფთა სახით ის ჩვენთვის არ არის შესაფერისი.

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

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

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

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

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

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

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

ზოგადი შედეგები წყვილური პროგრამირების გამოყენების შესახებ:

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

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

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

დაგეგმვა და კომუნიკაცია

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

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

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

ამოცანების ვიზუალური ხედვის უპირატესობები:

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

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

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

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

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

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

ანგარიში შეიძლება შესრულდეს საკონტროლო სიის გამოყენებით.1. შედით კონტექსტში. საიდან გაჩნდა დავალება, რატომ იყო საჭირო?

2. როგორ მოგვარდა პრობლემა ადრე? მაგალითად, საჭირო იყო მაუსის მასიური დაწკაპუნება, ან საერთოდ შეუძლებელი იყო რაიმეს გაკეთება.

3. როგორ გავაუმჯობესოთ იგი. მაგალითად: „აჰა, ახლა არის სკრიპტოსიკი, აქ არის რედმე“.

4. აჩვენე როგორ მუშაობს. მიზანშეწონილია უშუალოდ განახორციელოთ მომხმარებლის ზოგიერთი სცენარი. მე მინდა X, ვაკეთებ Y, ვხედავ Y (ან Z). მაგალითად, ვაყენებ NGINX-ს, ვეწევი url-ს და ვიღებ 200 OK-ს. თუ მოქმედება გრძელია, წინასწარ მოამზადეთ, რათა მოგვიანებით აჩვენოთ. მიზანშეწონილია არ დაამტვრიოთ ის დემომდე ერთი საათით ადრე, თუ ის მყიფეა.

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

მიზანშეწონილია, რომ თითოეულმა მომხსენებელმა შეინარჩუნოს ის 5-10 წუთამდე. თუ თქვენი მეტყველება აშკარად მნიშვნელოვანია და უფრო მეტხანს დასჭირდება, ამის კოორდინაცია წინასწარ sre-takeover არხზე.

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

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

გრძელი დასკვნები და რა არის შემდეგი

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

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

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

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

მოკლე დასკვნები ერთ ხაზზე

• HR პრაქტიკოსები მუშაობენ IaC-ში, მაგრამ ნაკლები ეფექტურობით.
• გააძლიერე ის, რაც მუშაობს.
• შეიმუშავეთ საკუთარი კომპენსატორული მექანიზმები და პრაქტიკა.

წყარო: www.habr.com