რამდენიმე თვის წინ საერთო ინტერესების წყალობით ორი ძალიან კარგი ადამიანი გავიცანი – ერეკლე მაღრაძე და ვაჟა ფირცხალაიშვილი. მალევე დაიბადა იდეა, რომ ეს საერთო ინტერესი უფრო გაგვეძლიერებინა და მეტი მსგავსი ადამიანი გვეპოვა ან მოგვეჯადოვებინა. ასე დავიწყეთ ტექნოლოგიური შეკრებისთვის მზადება, რომელიც ბოლოს ორდღიან კონფერენციაში გადაიზარდა. ვინც ჩემს ბლოგს კითხულობს, სავარაუდოდ, ისედაც უკვე დასწრებია ან სმენია მის შესახებ. უბრალოდ, მინდა ბლოგზეც შემომრჩეს მოგონება :))
ჩემი აზრით, გადამწყვეტ პერიოდში ვდგავართ ტექ სფეროს წარმომადგნლები. ეს რევოლუცია 10 წლის წინ დაიწყო და ნელნელა ჩვენამდეც მოაღწია. ალბათ თითზე ჩამოსათვლელია ქართული ბიზნესები, რომლებიც ავტომატიზაციის ძალას ნახევრად მაინც იყენებენ. თუ არ ავუწყეთ ფეხი, ვეღარანაირ კონკურენციას ვერ გავუწევთ უცხოურს ვერც კომპანიებს და ვერც სამუშაო ძალას.
კონფერენციის მონაწილეთა უმრავლესობამ სწორედ არაქართულ კომპანიასთან თანამშრომლობის გამოცდილება გაგვიზიარა. არ გავაზვიადებ თუ ვიტყვი, ყველას გამოსვლას დიდი ინტერესით მოვუსმინე რამდენჯერმე. მიხარია, რომ დრო გამონახეს და ასეთი პროდუქტიული შაბათ-კვირა მოგვიწყეს. მათი ნახვა DevOps Georgia-ს Facebook გვერდზე ან Youtube-ზე შეგიძლიათ: DevOps Con Tbilisi 2018 – Tech talks
ჩემი საუბარიც ჩაწერილი იყო, თუ ვინმეს მოუნდება მოსმენა 🙂
მომხსენებლების, ორგანიზატორების, მხარდამჭერებისა და სხვა დეტალების შესახებ ინფორმაცია ჩვენს საიტსა და FB გვერდზე შეგიძლიათ მიიღოთ. DevOps Con Tbilisi 2018 DevOps Georgia
29-30 სექტემბერს კახა ბენდუქიძის საუნივერსიტეტო კამპუსში გაიმართა ტექნოლოგიური კონფერენცია DevOps Con Tbilisi 2018
როვერის ნაფეხურები მარსზე, რომელიც არსაიდან იწყება.
სულ მაინტერესებდა, როგორ წერენ უზარმაზარ წარმატებულ პროგრამებს შეცდომების გარეშე, მაგალითად მარს როვერი “Curiosity”, რომელიც მარსზე გაფრინდა, 8 თვეში გაიარა 350 მილიონი მილი, დაეშვა 6 მილის რადიუსში, უცხო გარემოში დადის და დედამიწაზე გზავნის მონაცემებს.
როგორ გაუშვეს როვერი მარსზე
ინტერნეტში არის ერთ-ერთი უიშვიათესი ტექნიკური ხასიათის გამოსვლა მარს როვერის შესახებ. ნასას JPL – Jet Propulsion Laboratory ლაბორატორიის ერთ-ერთი მთავარი მეცნიერი, Gerard Holzmann აღწერს, თუ როგორ ცდილობდნენ პროგრამირების პროცესის წარმართვას, რომ მაქსიმალურად აეცილებინათ პრობლემები.
მოკლედ ვიტყვი რამდენიმე ფაქტს ვიდეოდან:
დაახლოებით 4 მილიონი ხაზი კოდი, 100-ზე მეტი მოდული, 120 ნაკადი ერთ პროცესორზე (+1 ბეკაპი). ხუთი წელი და 40 პროგრამისტი. ყველაფერს კი ერთი მომხარებლისთვის და პირველივე გამოყენებაზე უნდა ემუშავა.
უფრო მეტი კოდი იყო, ვიდრე მთელი წინა მარსის მისიების ერთად აღებული. ასეთი ზომის გამო ადამიანური კოდის რევიუები აღარ მუშაობდა ეფექტურად.
შემოიღეს რისკების შესამცირებელი სტანდარტი და მუდმივად ამოწმებდნენ ავტომატური ხელსაწყოებით. იმის გამო, რომ ადამიანები არ კითხულობდნენ და იცავდნენ დოკუმენტებს ასობით წესებით, ჩაატარეს გამოკითხვა და გამოარჩიეს ათი ყველაზე მნიშვნელოვანი წესი: Power of ten
მაგალითად: ნუ გამოიყენებთ რეკურსიას, goto-ს და მსვლელობის სხვა რთულ კონსტრუქციებს; მონაცემების ხედვის არე (scope) იყოს მინიმალური; ყველა ციკლს ჰქონდეს ფიქსირებული საზღვრები; პოინტერის მხოლოდ ერთი განმისამართება გააკეთეთ, ფუნქციის პოინტერებს ნუ გამოიყენებთ; ა.შ.
ყოველ ღამე ხდებოდა კოდის დაბილდვა, სტატიკური ანალიზი და სხვადასხვა ავტომატური ტესტირება. ღამე იმიტომ, რომ 15 საათი სჭირდებოდა ანალიზს.
ვინც ბილდს გააფუჭებდა, დაჯარიმდებოდა და ბრიტნი სპირსის პლაკატს გამოაკრავდა თავის კუბში. ხოლო ვინც ბევრ warning-ებს დატოვებდა კოდში, “სირცხვილის კედელზე” მოხვდებოდა. როგორც ჩანს ნასაშიც კი სჭირდებათ ადამიანებს მოტივაცია წესების დასაცავად 😀
სპეციალური ტრენინგის და სერტიფიცირების გარეშე არ უშვებდნენ კოდთან ადამიანს.
ითხოვდნენ 100% code coverage-ს. ვისაც გაუკეთებია ეს, მიხვდება თუ რა შრომატევადი ამოცანაა 100%, რადგან არარსებული სცენარების გატესტვაც მოუწევთ – მაგალითად if-ების ისეთი განშტოებები, რომელიც შეუძლებელია ოდესმე შესრულდეს.
კოდის რევიუ არ იყო ხანგრძლივი ჯგუფური შეკრება. იკრიბებოდნენ მხოლოდ უთანხმოების განსახილველად. შენიშვნები და მითითები ერთმანეთში სპეციალური პროგრამის გამოყენებით იცვლებოდა, რომელიც კოდის სხვადასხვა სტატუსებსაც აჩვენებდა წინა ღამის შემოწმებიდან.
კომპილატორიდან და სტატიკური ანალიზიდან 0 warning უნდა ყოფილიყო, რაც საკმაოდ რთული შესასრულებელი აღმოჩნდა და დიდი დრო დასჭირდა. უცნობია კორელაცია ამ პუნქტის შესრულებასა და პროექტის წარმატებულობას შორის, თუმცა ეს ყველაზე სუფთა კოდი იყო, წინა მისიებთან შედარებით.
კრიტიკულ ნაწილებში იცავდნენ MISRA პროგრამირების სტანდარტს – რომელიც ძრავების და სასიცოცხლო მნიშვნელობის აპარატურაში გამოიყენება.
კრიტიკული ქვესისტემებისთვის ლოგიკურ ვერიფიკაციას აკეთებდნენ – მათემატიკურად ამტკიცებდნენ ალგორითმის სისწორეს.
ინტერნეტში ცნობილი შემთხვევებიდან ყველაზე ძვირიანი კოდი Space Shuttle-ისთვის დაიწერა – 1000$/ხაზი. მაგრამ 2013 წელს ტოიოტამ სასამართლო წააგო და კომპენსაციის თანხით თუ დავთვლით დაახლოებით 1200$ დაუჯდა თითო ხაზი. ტოიოტას უნებური აჩქარების პრობლემა არაერთხელ მოხვდა სიახლეებში ავტო ავარიების და საჩივრების გამო. ხან ხალიჩები გაიწვიეს უკან, ხან გაზის პედლები, მაგრამ საკმარისი არ აღმოჩნდა. მერე NASA-ს გუნდმა შეამოწმა გაზის კონტროლის პროგრამა ტოიოტას მანქანაზე და, მართალია, თავიანთ სტანდარტთან შედარებით 243 დარღვევა ნახეს, მაგრამ საბოლოოდ ვერ დაადასტურეს, რომ პროგრამის შეცდომის ბრალი იყო. სასამართლოს გარე ექსპერტად ერთი ტიპი ჰყავდა, რომელმაც მიწასთან გაასწორა ტოიოტას კოდი, უწესო რეკურსიაო, სტეკ ოვერფლოუვო და კიდევ ათასი რაღაც.
თურმე პროგრამისტები ძალიან ბევრს ვრისკავთ 🙂 ვენდობით ოპერაციულ სისტემას, გარე ბიბლიოთეკებს, არ ვამოწმებთ ფუნქციიდან დაბრუნებულ მნიშვნელობას ვალიდურობაზე. მართალია, მომხმარებლის მიერ შეყვანილ მონაცემებს ვფილტრავთ, მაგრამ ვაკეთებთ კი იგივეს, როცა სხვადასხვა სერვისს ვესაუბრებით? ეს ბუნებრივია ჩემი აზრით, ყველა შემთხვევის შემოწმება ძალიან შრომატევადი და შესაბამისად ძვირი პროცესია. შეგიძლიათ გადახედოთ Defensive programming სტრატეგიებს.
არსებობს პროგრამები, რომელსაც შეცდომა თითქმის არ მოსდის, მაგრამ თუ მოუვა უზარმაზარს ზარალს მოიტანს. ანალოგიურად არსებობს ისეთებიც, რომელშიც ხშირად ხდება შეცდომა, მაგრამ მარტივი და იაფი ჯდება მისი გასწორება. დაახლოებით ისე, როგორც მანქანებში – იშვიათად გაფუჭებული BMW-ს შეკეთება ძვირია, ამერიკას კი ომის დროს ჰყავდა Willys MB ჯიპები, რომელსაც დაზიანებისას ძალიან სწრაფად აღადგენდნენ. საერთოდ შლიდნენ და ისე გადაჰქონდათ აქეთ-იქით. ვიდეოც არის ინტერნეტში, სადაც კანადელი ჯარისკაცები 4 წუთში შლიან და აწყობენ მთელ მანქანას.
ჩვენი პროგრამების უმრავლესობაც წესით ამ მეორე კატეგორიას მიეკუთვნება. მთავარია ცვლილების შეტანა სწრაფად და იაფად შევძლოთ, თორემ ეგეთი კოდიც თუ ძვირი დაუჯდათ, აღარ დაგვიკვეთავენ 😀
ჩვენი პროგრამები არასრულყოფილ სამყაროში ცხოვრობენ, არასტაბილური ქსელით ლაპარაკობენ და არაგარანტირებულ რესურსებს ეძახიან. ბოლო დროს განსაკუთრებით კიდევ უფრო მეტი ჩავარდნის შესაძლებლობა გაჩნდა, როცა ყველაფერი სერვისებად იქცა.
კოდში ზოგჯერ ძირითად ლოგიკაზე მეტი ადგილი ამ ჩავარდნებისგან დაზღვევას უჭირავს.
ერთ-ერთ ასეთ მათგანზე მინდა დავწერო, როცა სერვისის გამოძახება წარუმატებლად სრულდება.
პრობლემური შედეგი შეიძლება სხვადასხვა ხასიათის იყოს: გარდამავალი – მაგალითად,
– 503 Service unavailable – როდესაც სერვისი გადატვირთულია ან დროებით გათიშულია;
– 504 Gateway Timeout – როდესაც ბექ სერვერიდან პასუხი დროულად არ მოდის პროქსისთან;
– ასევე ნებისმიერი timeout, როდესაც სერვერიდან საერთოდ არ მოდის პასუხი.
ეს გარდამავალი შეცდომებია და შეიძლება გამოსწორდეს რაღაც დროის შემდეგ
მუდმივი – არასწორი პაროლის შეცდომა თავისით არასოდეს გამოსწორდება, რამდენჯერაც არ უნდა გაიგზავნოს.
როდესაც დავადგენთ, რომ გარდამავალ შეცდომასთან გვაქვს საქმე, შეგვიძლია ავდგეთ და რამდენიმე წამში ერთხელ კვლავ გავიმეოროთ მოთხოვნა. ოღონდ ერთი მომენტია კიდევ: თუ სერვისი დიდი დატვირთვის გამო ვერ აბრუნებს პასუხს, მაშინ ჩვენი ასეთი მიმართვები კიდევ უფრო გაზრდის მოთხოვნების რიგს და ხელს შეუშლის სერვისს აღდგენაში. მდგომარეობის გამოსასწორებლად რამდენიმე დიზაინ პატერნია გავრცელებული:
Exponential backoff
ალბათ შეგიმჩნევიათ, როცა GMail არის გახსნილი და ინტერნეტი ითიშება, თავზე ეწერება შეტყობინება Connecting in 1s… ჯერ ერთ წამში ცდის, მერე 2 წამში, მერე 4 წამში, მერე 8-ში და ასე ექსპონენციალურად ზრდის დროს მცდელობებს შორის. საათებზეც კი ადის.
საუბარი არ არის მხოლოდ ბრაუზერს და სერვერს შორის ურთიერთობაზე. შეიძლება ასეთი პრობლემური კავშირები მთელიანად სერვერის მხარეს არსებულ სხვადასხვა კომპონენტს შორის იყოს. ზოგჯერ უკეთესი შედეგის მისაღებად ‘შემთხვევითობაც’ შემოაქვთ, მაგალითად Amazon AWS არქიტექტურაში ორივე ერთად გამოიყენება: Exponential Backoff and Jitter.
ანუ მეორე მცდელობა 4 წამის შემდეგ კი არა იყოს, არამედ 1-4 ფარგლებში შემთხვევითად შერჩეულ X წამის შემდეგ.
ეს რიცხვები ახსნის ხათრით შემოვიტანე. ცხადია, რამდენიმე კონსტანტა იქნება საჭირო:
საბაზო დაყოვნების დრო, ცდების მაქსიმალური რაოდენობა და დაყოვნების მაქსიმალური დრო.
ანალოგიურად, ჩვენც შეგვიძლია სერვისის წარუმატებელი გამოძახების შემდეგ ყოველ წამს კი არ გავიმეოროთ მოთხოვნა, არამედ უფრო და უფრო მეტი დაყოვნება გავაკეთოთ და სერვისს აღდგენის საშუალება მივცეთ.
Exponential backoff ალგორითმი Ethernet პროტოკოლშიც გამოიყენება. როცა ქსელში ორი მანქანა ერთდროულად ცდილობს პაკეტის გაგზავნას, კოლიზია ხდება. ზუსტად იგივე დაყოვნების შემდეგ რომ გაგზავნოს ორივემ, ისევ ისე დაემთხვევა და ასე უსასრულოდ. ამიტომ დაყოვნების ფორმულა ასეთია 0 ≤ r < 2^k სადაც k = min (n, 10)
n არის კოლიზიების რაოდენობა და r შემთხვევითად ირჩევა. ანუ რაც უფრო მეტი კოლიზია ხდება, ექსპონენციალურად იზრდება საზღვარი, და მერე ამ საზღვრიდან ხდება დაყოვნების დროის ამორჩევა შემთხვევითად.
Circuit breaker
ეს ალგორითმი ჰგავს ელექტრო ქსელის ავტომატურ ამომრთველს, რომელიც ყველას გვიყენია სახლში.
სერვისს და კლიენტს შორის დამატებით დგება ერთი შუალედური ობიექტი, რომელიც სერვისის მცველის როლს ასრულებს. როცა ხედავს რომ დროის გარკვეულ მონაკვეთში სერვერისგან ცუდი პასუხები მოდის ან საერთოდ არ მოდის, გადადის “Open” რეჟიმში, აღარ უშვებს მასთან კლიენტის მოთხოვნებს და თვითონვე პასუხობს ჩავარდნით.
როცა ელექტრო ამომრთველს მოსდის ასე, ხელით ვრთავთ უკან, მაგრამ აქ ხელით ვერ ჩავრთავთ, ამიტომ რაღაც ინტერვალის შემდეგ ეს მცველი ობიექტი გადაგვყავს “Half-Open” რეჟიმში და ის ერთ მოთხოვნას სერვისამდე გაატარებს საცდელად. პასუხის მიხედვით ან ისევ “Open” რეჟიმში დაბრუნდება, ან “Closed” გახდება და ყველა მომდევნო მოთხოვნას სერვერთან გაუშვებს ჩვეულებრივ.
რამდენიმე ტაიმაუტის შემდეგ მცველი ჩაირთვება და ის დაიწყებს პასუხის დაბრუნებას
სურათი აღებულია მარტინ ფოულერის ბლოგიდან
ზოგიერთ ფრეიმვორკში (განსაკუთრებით ბაზასთან ურთიერთობისას) უკვე იმპლემენტირებულია მსგავსი ალგორითმები.
თუ თქვენ public API გაქვთ და გსურთ რომ უცხო კლიენტებმა retry-ის სწორი მექანიზმი გამოიყენონ – სულ მთლად არ მოკლან თქვენი სერვისი გაჭირვების ჟამს, მაშინ შეგიძლიათ თქვენ თვითონ დაწეროთ რამდენიმე კლიენტი-ბიბლიოთეკა სხვადასხვა ენისთვის და მომხმარებლებიც მათ გამოიყენებენ.
