აპები, რომლებიც გამოქვეყნების შემდეგ მაშინვე იშლება, და მათი დაჭერა
9 სექტემბერს სამი გამოქვეყნება წარმატებულად აღინიშნა, მიუხედავად იმისა, რომ აპის API ყოველი გაშვებიდან წამებში ავარდებოდა. იმის გამო, რომ ისინი „წარმატებულად“ ჩაითვალა, დაბრუნება (rollback) არ გაშვებულა; ფონურმა შემოწმებამ ისინი რამდენიმე წუთის შემდეგ ჩაშალა, და მთელი საიტი 404-ზე გადავიდა. ჯანმრთელობის შემოწმება ავარიებს ითვლიდა ჰოსტინგ პლატფორმის მოვლენების სიაში, რომელიც თითო მანქანაზე მხოლოდ ბოლო ხუთ მოვლენას ინახავს. ავარიების ციკლი ამ სიას ავსებს და დათვლა არასდროს იზრდება. ახლა ის უახლესი ავარიის დროს ადარებს, და ავარიების ციკლში მყოფი გამოქვეყნება ჩავარდება და წინა ვერსიას აღადგენს.
რას ელოდება გამოქვეყნება
როცა Mythex-ზე ბექენდიანი აპს აქვეყნებ, ახალი ვერსია ჰოსტინგ პლატფორმის მანქანებზე ვრცელდება, და ჯანმრთელობის შემოწმება წყვეტს, გამოქვეყნება ცოცხალი გახდა თუ ჩაიშალა. თუ ჩაიშალა, დაბრუნება წინა ვერსიას აღადგენს.
რთული ის არის, რომ „გაშვებული“ არ ნიშნავს „მუშაობს“. პლატფორმა მანქანას გაშვებულად აღნიშნავს, როგორც კი ის ავა. აპი, რომელიც გაშვებიდან წამში ავარდება, მაშინვე თავიდან იწყება, და მცირე ხნის შემდეგ ისევ გაშვებულად ჩანს. ამიტომ ჯანმრთელობის შემოწმებამ დროთა განმავლობაში რამდენიმე ფენა შეიძინა:
- ორჯერ შეამოწმე. მანქანის გაშვებულად მონიშვნის შემდეგ ცოტა ხანს ელოდები და ისევ ამოწმებ. გაშვებისას ავარია ხშირად მეორე შემოწმებას ჩაშლის.
- დააკვირდი ავარიის ციკლებს. თუ პლატფორმა იტყობინება, რომ მანქანა მუდმივად ავარდებოდა და მას გადატვირთვაზე უარი უთქვამს, ჩავარდი.
- დათვალე ავარიები გამოქვეყნების დაწყებიდან. ორი „გაშვებულია“ შემოწმება შეიძლება რესტარტს მოიცავდეს. ამიტომ თუ ამ გამოქვეყნების დაწყებიდან რაიმე ავარია მოხდა, მესამედ ვამოწმებთ; თუ ავარიები წინა შემოწმებაზე მეტია, აპი არ რჩება ფეხზე.
მესამე შემოწმება იყო ის, რომელიც აქ ვერ იმუშავა.
რატომ რჩებოდა დათვლა უცვლელი
ავარიების ინფორმაცია მოდის თითოეული მანქანის მოვლენების სიიდან: გაშვებები, გასვლები, რესტარტები. პლატფორმა თითო მანქანაზე მხოლოდ ბოლო ხუთ მოვლენას ინახავს.
წარმოიდგინე აპი, რომელიც გაშვებიდან 2.5 წამში ავარდება, როგორც ერთ-ერთი მათგანი. ყოველი ციკლი ამატებს ავარიას და გაშვებას. რამდენიმე ციკლის შემდეგ სია სავსეა. მას შემდეგ ყოველი ახალი მოვლენა ერთ ძველს უბიძგებს გარეთ. სია წინ მოძრაობს, მაგრამ ყოველთვის დაახლოებით ერთნაირ ნაზავს ინახავს: ორი-ორი ავარია და გაშვება.
ამიტომ „რამდენი ავარია იყო გამოქვეყნების დაწყებიდან“ ყოველ შემოწმებაზე ერთსა და იმავე რიცხვს აბრუნებდა. მეორე შემოწმებამ, ვთქვათ, ორი ავარია დაინახა. მესამემ ისევ ორი დაინახა — სხვადასხვა ავარიები, მაგრამ იგივე რაოდენობა. შემოწმებამ დაასკვნა, რომ ავარიები შეწყდა, და გამოქვეყნება ჩააბარა.
ეს სამჯერ მოხდა 9 სექტემბერს, ორ აპზე. ყოველ ჯერზე:
- გამოქვეყნება ცოცხლად აღინიშნა,
- დაბრუნება არ გაშვებულა, რადგან არაფერი ჩაიშალა,
- ჩვენმა შემდგომმა შემმოწმებელმა, ფონურმა სამუშაომ, რომელიც დეპლოიებს შემდეგ ამოწმებს, დეპლოი რამდენიმე წუთის შემდეგ ჩაშალა,
- და მთელი საიტი 404-ს აბრუნებდა.
გამოქვეყნება, რომელიც დროულად ჩაიშლება, გადარჩენადია: დაბრუნება წინა ვერსიას აღადგენს. გამოქვეყნება, რომელიც რამდენიმე წუთით გვიან ჩაიშლება, მას შემდეგ რაც წარმატებულად გამოცხადდა, უკვე გამოტოვა თავისი დაბრუნება.
როგორ ვიპოვეთ
ლოკალურად ავიძულეთ ხელახლა შეგვექმნა: ავიღეთ მუშა API, მივაძინეთ, და შემდეგ ხელახლა გამოვაქვეყნეთ ცვლილებით, რომელიც გაშვებისას ავარდებოდა. ჯანმრთელობის შემოწმებამ ის ცოცხლად აღნიშნა.
ეს დაემთხვა წარმოებას: სამივე გამოქვეყნებაში აპი ყოველი გაშვებიდან წამებში კვდებოდა, მაგრამ შემოწმებული ავარიების რაოდენობა შედარებებს შორის არასდროს გაზრდილა.
გამოსწორება: შეადარე უახლესი ავარია და არა რაოდენობა
ავარიების დათვლის ნაცვლად, შემოწმება ახლა უყურებს უახლესი ავარიის დროს გამოქვეყნების დაწყებიდან.
თუ მეორე შემოწმება აჩვენებს რაიმე ავარიას გამოქვეყნების დაწყებიდან, შემოწმება ელოდება და მესამედ ამოწმებს. თუ მესამე შემოწმებაზე უახლესი ავარია უფრო გვიანია, ვიდრე მეორეზე უახლესი, მანქანა ამ დროს ისევ ავარდა. ის არ რჩება ფეხზე, და გამოქვეყნება ჩაიშლება შეტყობინებით, რომ მანქანა გამოქვეყნების შემდეგ მრავალჯერ ავარდა და ისევ რესტარტდება.
ეს მუშაობს მოვლენების სიის ზომის მიუხედავად. ხუთმოვლენიანი მცურავი ფანჯარა შეიძლება დამალავდეს, რამდენი ავარია იყო, მაგრამ ვერ დაფარავს, რომ ახალი ავარია ახლახან მოხდა — უახლესი მოვლენა ყოველთვის ინახება.
ამ ცვლილებით ლოკალური რეპროდუქცია სწორად იქცევა: გამოქვეყნება ჩავარდება და წინა იმიჯი აღდგება. ასევე არის ტესტი, რომელიც პლატფორმის ქცევას იმეორებს — ყოველი შემოწმება ამატებს ავარიასა და გაშვებას და ჩამონათვალს ხუთამდე ამცირებს — და ამოწმებს, რომ განაჩენი ჩაშლაა და არა გავლა.
რა ვისწავლეთ
- იცოდე მონაცემების ფორმა, რომელსაც ითვლი. რაოდენობა შეზღუდულ სიაზე აზრს კარგავს, როცა სია ივსება. შეზღუდვა დამალული არ იყო; უბრალოდ შემოწმება მის გარშემო არ იყო დაპროექტებული.
- უპირატესად მიიღე „ახალი რამ მოხდა?“ — „რამდენი მოხდა?“ ნაცვლად. უახლესი დროის ნიშანი შეკვეთილობას უძლებს. ჯამი — არა.
- გვიანი ჩავარდნა უარესია, ვიდრე ადრეული. ერთი და იგივე გაუმართავი ბილდი უვნებელია, თუ გამოქვეყნება ჩაიშლება და დაბრუნდება, მაგრამ საიტს აგდებს, თუ ჯერ წარმატებულად გამოცხადდება.
- რეპროდუცირება რეალურ პირობებში. შეცდომას სჭირდებოდა მანქანა, რომელიც უკვე საკმარისად ხშირად ავარდა, რომ მოვლენების სია აევსო. ერთი სწრაფი ავარია ტესტში ვერ გამოავლენდა მას.
ეს გამოსწორება ემატება სხვა შესწორებას იმავე დღიდან, რომელმაც უზრუნველყო, რომ დაბრუნება ძველ ვერსიას აღადგენს და არა შლის მას: წარუმატებელი ხელახალი გამოქვეყნება არასდროს შლის მუშა ბექენდს. თუ შენი აპი გამოქვეყნდება ვერ ხერხდება, რადგან იწყებისას იშლება, გამოქვეყნების პრობლემების დოკუმენტაცია (publish troubleshooting) და ჩვენი გზამკვლევი AI-ით აგებული აპის გამართვის შესახებ კარგი ადგილებია დასაწყებად.