ინჟინერია

ინჟინერია

როგორ იქმნება და მუშაობს Mythex, მათ შორის რა გაფუჭდა და როგორ გამოვასწორეთ.

• ჩავარდნილი ხელახალი გამოქვეყნება არასდროს შლის მუშა ბექენდს — ჩავარდნილმა ხელახალმა გამოქვეყნებამ შეიძლება წაშალოს ცოცხალი API ან დატოვოს გაუმართავი ვერსია. სამი შესწორება, როგორ აუქმებს Mythex წარუმატებელ გამოქვეყნებას.
• გაფრთხილებები, რომლებიც ერთხელ იგზავნება და არა სერვერზე ერთხელ — დღეში ერთხელ გასაგზავნი გაფრთხილება ერთ შუადღეს ხუთჯერ მოვიდა. მეხსიერებაში დედუპლიკაცია ორ სერვერსა და დეპლოისას იშლება; საერთო მდგომარეობამ ეს გამოასწორა.
• უფრო დიდ სამუშაო სივრცეებზე გადასვლა ისე, რომ არავინ დაელოდოს — სამუშაო სივრცეების მეოთხედი 1 GB-ზე დარჩა 2 GB-ზე გადასვლის შემდეგ. ჩვენმა პირველმა შესწორებამ ერთი ადამიანი შვიდი წუთით დააყოვნა. რა შევცვალეთ და კიდევ ერთხელ შევცვალეთ.
• მონაცემთა ბაზების ანგარიშსწორება იმის მიხედვით, რას ნამდვილად იყენებენ — ადრე ყოველი აპის მონაცემთა ბაზის ღირებულებას ვაფასებდით, და შეფასება ორივე მხარეს ცდებოდა. ახლა ყოველი მონაცემთა ბაზა იხდის გაზომილი გამოყენების მიხედვით, საათობრივად.
• აპები, რომლებიც გამოქვეყნების შემდეგ მაშინვე იშლება, და მათი დაჭერა — სამი გამოქვეყნება ჯანმრთელობის შემოწმებას გაიარა, მიუხედავად იმისა, რომ API ყოველ გაშვებაზე ავარდებოდა. მიზეზი: ავარიების დათვლა ხუთ ჩანაწერზე შეზღუდულ სიაში.
• სურათებით მძიმე აგენტის ციკლების მეხსიერებაში დატევა — აგენტის ერთმა ციკლმა, რომელიც კატალოგის სკანებს უყურებდა, 952 მბ-ზე მეხსიერება ამოწურა. სამი ცალკეული მიზეზი, რომელიც სურათებს ზედმეტ ხანს ინახავდა, და როგორ გამოვასწორეთ.
• გრძელი აგენტის ციკლების დატევა კონტექსტის ფანჯარაში — ქვე-აგენტები იზრდებოდა მოდელის უარის თქმამდე, ჩერდებოდა ადრე და რუსულ და აზიურ ტექსტს ცდებოდა. სამი შესწორება, რომელმაც გრძელი სამუშაო დაასრულა.
• ჩატის გაძლიერება, როცა ტელეფონი იძინებს — ტელეფონები იძინებენ, ტაბებს ცვლიან და ქსელს აგდებენ აშენების შუაში. ორმა შეცდომამ ჩატი გააჩერა ან პასუხის ნახევარი აჩვენა. როგორ ვიპოვეთ და გავასწორეთ ორივე.
• როგორ შეიძლებოდა ერთმა მძიმე ჩატს API ჩამოერთმია — 28 სექტემბერს ჩვენი ორივე API სერვერი ერთდროულად ამოიწურა მეხსიერება. პირველი შესწორება მეტი მეხსიერება იყო; ნამდვილი — ჩატის ისტორიის ზომით, არა რაოდენობით ჩატვირთვა.
• Publish ორჯერ დაჭერა ახლა ერთხელ აქვეყნებს — ერთი აპის სამი publish 84 მილიწამში მოვიდა და სამივემ სრული დეპლოი გაუშვა. ახლა მონაცემთა ბაზა წყვეტს, ვინ აქვეყნებს, დანარჩენებს კი სიმართლეს ეუბნება.
• SEO-ის გაკვეთილები საკუთარი საიტის გასწორებიდან — ორმაგი FAQ მარკაპი, Google-ში არასწორი სურათი, შაბლონის გვერდები, რომლებზეც არავინ აჭერდა, და გზა, რომელსაც ჩვენი ედჟი უარყოფდა: რა ვიპოვეთ mythex.ai-ზე და რა გავასწორეთ.
• სტატიკური საიტები ხელახალი გამოქვეყნებისას აქტიურად რჩება — სტატიკური საიტის ხელახალი გამოქვეყნება ადრე ატვირთვამდე ცარიელს ხდიდა. ახლა ძველი საიტი მუშაობს, სანამ ახალი მის ადგილზე არ მოვა, ცვლილებები კი წამებში ჩანს.
• მეხსიერების ამოწურვის შეცდომა, რომელიც პროგრესის ეტიკეტში იმალებოდა — ჩვენმა AI აგენტმა მეხსიერება ამოწურა ერთი დიდი ფაილის წერისას. მიზეზი არც მოდელი იყო და არც პარალელური ქვეაგენტები — სტატუსის ეტიკეტი იყო, რომელიც 41 000-ჯერ გაიგზავნა.
• გამოტოვებული swap ფაილი, რომელმაც სერვერები გაყინა — production სერვერი პასუხს შეწყვეტდა, მაგრამ არ ჩამოვარდნილა — არ არსებობდა out-of-memory მკვლელობა, მხოლოდ page-cache-ის თრეშინგი swap-ის გარეშე. რა მოხდა და რა შევცვალეთ.
• მონაცემთა ბაზის გაღვიძება მკვდარი კავშირების გარეშე — გამოქვეყნებული აპი, რომელიც ძილიდან იღვიძებს, პირველ მოთხოვნას 10–12 წამით აჩერებდა მონაცემთა ბაზის კავშირებზე, რომლებიც ძილის დროს მოკვდა. როგორ მივიყვანეთ ეს 2.3 წამამდე.
• ჩვენ საკუთარ სერვისებს ვზღუდავდით — API-ის მისამართის ლიმიტმა ჩვენი სერვისები ერთ დაკავებულ ადამიანად ჩათვალა და წარმოებაში 429-ებს იღებდნენ. როგორ ვიპოვეთ და გავასწორეთ.
• რატომ გადავიყვანეთ Mythex-ის სერვერები ARM-ზე — მძიმე სამუშაო სანდბოქსებში რომ გადავიტანეთ, სერვერები მეხსიერების მესამედს იყენებდა. პატარა ARM ინსტანციებმა ხარჯი დაახლოებით 30%-ით შეამცირა.
• როგორ მივიყვანეთ დეპლოიმენტები ნულოვან 502 შეცდომამდე — ვოჩდოგი, რომელიც ჩვენს დეპლოიმენტებს ეჯიბრებოდა, და დატვირთვის ბალანსერი, რომელიც ძალიან გვიან შენიშნავდა: როგორ ვიპოვეთ ორივე, გავასწორეთ და გავზომეთ 10 502-იდან ნულამდე.