Inženierija

Inženierija

Kā Mythex tiek veidots un darbināts, arī tas, kas salūza un kā to salabojām.

• Neveiksmīga atkārtota publicēšana nekad neizdzēš darbīgu aizmugurējo daļu — Neveiksmīga atkārtota publicēšana varētu izdzēst lietotnes dzīvo API vai atstāt darbībā tās bojāto jauno versiju. Trīs labojumi tam, kā Mythex atsauc neizdevušos publicēšanu.
• Brīdinājumi, kas skan vienreiz, nevis reizi katrā serverī — Viens brīdinājums sasniedza mūs piecas reizes vienā pēcpusdienā. Kāpēc atmiņas dublēšana neiztur divus serverus un izvietošanu un kā kopīgs stāvoklis to novērsa.
• Pāreja uz lielākām darbvidēm bez gaidīšanas ikvienam — Ceturtdaļa mūsu darbvidu pēc pārejas uz 2 GB palika iestrēgusi 1 GB. Mūsu pirmais labojums vienam cilvēkam lika gaidīt septiņas minūtes. Ko mainījām un ko mainījām vēlreiz.
• Datu bāzu norēķini pēc tā, ko tās patiesi izmanto — Agrāk datu bāzes izmaksas aplēsām, un aplēse bija nepareiza abos virzienos. Tagad katra datu bāze tiek norēķināta pēc izmērītas lietošanas, stundu pa stundai.
• Lietotņu avāriju noķeršana tieši pēc publicēšanas — Trīs publicēšanas izturēja veselības pārbaudi, kamēr to API avarēja pēc katras palaišanas. Iemesls: avāriju skaitīšana sarakstā, kas aprobežots ar pieciem ierakstiem.
• Ar attēliem bagātus aģenta gājienus saglabājam atmiņas robežās — Aģenta gājiens, kas pastāvīgi skatījās katalogu skenējumus, ražošanā beidzās ar atmiņu 952 MB. Trīs atsevišķi cēloņi, katrs turēja attēlus pārāk ilgi, un kā mēs tos novērsām.
• Garus aģenta gājienus saglabājam kontekstu logā — Apakšaģenti auga, līdz modelis tos noraidīja, apstājās, lai taupītu vietu, vai nepareizi skaitīja krievu žetonus. Trīs labojumi, kas ļāva garam darbam pabeigties.
• Tērzēšanas uzturēšana, kad tālrunis guļ — Tālruņi iet gulēt un maina tīklu veidošanas laikā. Divas kļūdas lika Mythex tērzēšanai iestrēgt vai parādīt pusi atbildes. Kā mēs tās atradām un novērsām.
• Kā viena smaga tērzēšana varēja nogāzt mūsu API — 28. septembrī abi mūsu API serveri vienlaikus beidzās atmiņa. Pirmais labojums bija vairāk atmiņas; īstais bija vēstures ielāde pēc izmēra, nevis skaita.
• Nospiežot Publish divreiz, tagad publicē vienreiz — Trīs publicēšanas pieprasījumi vienai lietotnei ieradās ar 84 ms starpību un katrs palaida pilnu izvietošanu. Datubāze tagad izlemj, kurš publicē, pārējiem pasakot patiesību.
• SEO mācības no mūsu pašu vietnes labošanas — Dublēts FAQ marķējums, nepareizs attēls Google rezultātos un veidņu lapas, ko neviens neklikšķināja. Ko atradām mythex.ai un ko salabojām.
• Statiskās vietnes paliek tiešraidē arī pārpublicēšanas laikā — Statiskā vietne pārpublicēšanas laikā vairs netiek iztukšota. Vecā versija darbojas, līdz jaunā ir gatava, un izmaiņas redzamas sekundēs.
• Atmiņas pārpildes avārija, kas slēpās progresa uzrakstā — Mūsu AI aģents izbeidza atmiņu, rakstot lielu failu. Cēlonis nebija modelis vai paralēli apakšaģenti, bet statusa uzraksts, kas nosūtīts 41 000 reižu.
• Trūkstošais swap fails, kas iesaldēja mūsu serverus — Ražošanas serveris pārstāja atbildēt, bet nenokrita: nebija swap, un lapu kešatmiņa pastāvīgi tika pārlādēta. Kas notika un ko mainījām.
• Datubāzes pamošana bez mirušiem savienojumiem — Publicēta lietotne, pamostoties no miega, pirmo pieprasījumu turēja 10–12 sekundes mirušos datubāzes savienojumos. Kā to panācām līdz 2,3 sekundēm.
• Mēs ierobežojām paši savus pakalpojumus — Mūsu API ierobežojums uz adresi uzskatīja mūsu pašu pakalpojumus par vienu aktīvu lietotāju, un ražošanā tie sāka saņemt 429. Kā to atradām un salabojām.
• Kāpēc mēs pārcēlām Mythex serverus uz ARM — Kad smagais darbs pārcēlās uz projektu smilškastēm, mūsu serveri izmantoja trešdaļu atmiņas. Mazāki ARM serveri samazināja izmaksas par aptuveni 30%. Kā.
• Kā panācām izvietošanu līdz nullei 502 kļūdu — Uzraudzība sacentās ar mūsu izvietošanām, un slodzes sadalītājs pamanīja pārāk vēlu. Kā atradām abas problēmas un 10 502 kļūdas samazinājām līdz nullei.