ჩავარდნილი ხელახალი გამოქვეყნება არასდროს შლის მუშა ბექენდს

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

როგორ ქვეყნდება ბექენდი

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

თუ გზაში რამე ჩავარდება, ამის გასაუქმებლად უკან დაბრუნება (rollback) იწყება. ამ დაბრუნების სწორად მუშაობა თითქმის ყველაზე მნიშვნელოვანია გამოქვეყნებაში, რადგან ის სწორედ მაშინ მუშაობს, როცა რაღაც უკვე არასწორად მიდის.

პრობლემა 1: დაბრუნებამ წაშალა ის, რაც უნდა აღედგინა

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

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

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

გამოსწორება: წაშალე მხოლოდ ის, რაც შექმენი, დანარჩენი აღადგინე

ახლა თითოეული გამოქვეყნება, თითოეულ სერვერულ აპზე, რომელსაც ეხება, იწერს:

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

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

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

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

პრობლემა 2: დეპლოის ინსტრუმენტმა შეიძლება ჩაავარდეს, სანამ დავწერდით, როგორ უნდა გავაუქმოთ

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

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

გამოსწორება: გააკეთე გაუქმების ჩანაწერი დაწყებამდე

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

პრობლემა 3: მძინარე აპი „არასდროს დაწყებულად“ ჩაითვალა

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

9 სექტემბერს ამ ერთადერთმა მოთხოვნამ ვერ მიაღწია მიზანს. ჯანსაღი API გაჩერებული დარჩა მთელი ხუთწუთიანი ჯანმრთელობის შემოწმების განმავლობაში და ჩაითვალა წარუმატებლად შეტყობინებით „1 მანქანა არასდროს დაწყებულა (ბოლო მდგომარეობა: გაჩერებული)“.

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

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

ახლა ჯანმრთელობის შემოწმება:

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

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

რა ვისწავლეთ

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

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