ბლოგი

უფრო დიდ სამუშაო სივრცეებზე გადასვლა ისე, რომ არავინ დაელოდოს

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

რატომ დარჩა ძველი სამუშაო სივრცეები პატარა

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

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

პირველი მცდელობა: პროექტის გადატანა გაღვიძებისას

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

გადატანა ასე მუშაობდა:

  1. შეამოწმე ზომა. თუ სამუშაო სივრცე 2 GB-ზე პატარაა, გადაიტანე. თუ ზომა უცნობია, არაფერს აკეთებ.
  2. არ შეაწუხო გამოქვეყნება. გამოქვეყნება სამუშაო სივრცის ფაილებს კითხულობს, ამიტომ თუ ის მიმდინარეობს, გადატანას გამოტოვებ.
  3. შეფუთე პროექტი. დაარქივე პროექტის ყველაფერი — მათ შორის git-ის ისტორია, ანუ ყველა checkpoint, რაც პროექტს აქვს, და აპის საკუთარი .env ფაილი, რომელიც მფლობელს ეკუთვნის — მაგრამ დატოვე დაინსტალირებული დამოკიდებულებები (node_modules), რადგან მათი ხელახლა ინსტალაცია შეიძლება.
  4. გადაიტანე პირდაპირ. არქივი ძველი სამუშაო სივრციდან ახალ, 2 GB-იან სამუშაო სივრცეში ნაკადურად გადადის, ასე რომ არასდროს უწევს ჩვენი სერვერის მეხსიერებაში მოთავსება.
  5. შეადარე გადართვამდე. ორივე სამუშაო სივრცეში დათვალე ფაილები, წაიკითხე ბოლო checkpoint და დათვალე checkpoint-ები. გადართე მხოლოდ მაშინ, თუ სამივე ემთხვევა.
  6. ნებისმიერი ჩავარდნისას დატოვე ძველი. ნებისმიერი შეცდომა ან შეუსაბამობა ახალ სამუშაო სივრცეს შლის და პროექტს ისევ ძველში ხსნის, როგორც ადრე.

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

რა შეცდა პირველ დღეს

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

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

მეორე მცდელობა: მკაცრი ბიუჯეტი

იმავე დღეს ოთხი რამ შევცვალეთ:

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

მესამე მცდელობა: გაღვიძებიდან ამოღება

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

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

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

რა ვისწავლეთ

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

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

Mythex · Pricing · ააშენეთ ყველაფერი AI-ით · ვებსაიტისა და აპლიკაციის შაბლონები · Mythex შედარებით · AI-ით აპლიკაციის შექმნის ტერმინოლოგია · უფასო ინსტრუმენტები AI-ით აპლიკაციის შესაქმნელად · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)