Razvoj

Razvoj

Kako je Mythex zgrajen in kako deluje, vključno s tem, kaj se je pokvarilo in kako smo popravili.

• Neuspešna ponovna objava nikoli ne izbriše delujočega zaledja — Neuspešna ponovna objava bi lahko izbrisala živ API aplikacije ali pustila pokvarjeno novo različico. Trije popravki pri razveljavitvi objave.
• Opozorila, ki se sprožijo enkrat, ne enkrat na strežnik — Opozorilo, ki naj pride enkrat na dan, je prišlo petkrat. Zakaj deduplikacija v pomnilniku pri dveh strežnikih odpove in kako jo popravi deljeno stanje.
• Selitev na večje delovne prostore brez čakanja — Po povečanju na 2 GB jih je četrtina ostala pri 1 GB. Prvi popravek je nekega uporabnika prisilil v sedem minut čakanja. Kaj smo spremenili in spremenili še enkrat.
• Zaračunavanje baz po dejanski porabi — Strošek baze vsake aplikacije smo prej ocenjevali, ocena pa je bila napačna v obe smeri. Zdaj se vsaka baza zaračunava po izmerjeni porabi, uro za uro.
• Odkrivanje aplikacij, ki se zrušijo takoj po objavi — Trije objavi so prestali preverbo zdravja, čeprav se je API vsakič sekundo po zagonu zrušil. Vzrok: zrušitve smo šteli v seznamu, omejenem na pet vnosov.
• Agentove poteze s številnimi slikami znotraj pomnilnika — Agentova poteza, ki je ves čas gledala skenirane kataloge, je pri 952 MB ostala brez pomnilnika. Trije ločeni vzroki, vsak je slike hranil predolgo, in kako smo jih odpravili.
• Dolge agentove poteze znotraj kontekstnega okna — Podagenti so rasli, dokler jih model ni zavrnil, se ustavili zaradi prostora ali napačno šteli žetone. Kako smo popravili dolgo delo z AI.
• Ohranjanje klepeta, ko telefon spi — Telefoni se uspavajo, preklapljajo zavihke in izgubijo omrežje med gradnjo. Dve napaki sta klepet pustili obtičati ali pokazati pol odgovora. Kako smo ju našli in odpravili.
• Kako bi en težak klepet lahko podrl naš API — 28. septembra sta obe naši API strežniški vrstici hkrati zmanjkali pomnilnika. Prvi popravek je bil več pomnilnika, pravi pa nalaganje zgodovine po velikosti, ne številu.
• Dvakratni pritisk na Publish zdaj objavi samo enkrat — Trije zahtevki za objavo ene aplikacije so prispeli 84 ms narazen in vsak je sprožil celotno izdajo. Kako smo prepustili odločitev bazi in ostalim povedali resnico.
• SEO lekcije iz popravljanja lastne spletne strani — Podvojena oznaka FAQ, napačna sličica v Googlu, predloge strani, ki jih nihče ni kliknil, in pot, ki jo je naš robni del zavrnil: kaj smo našli na mythex.ai in popravili.
• Statična spletna mesta zdaj ostanejo na voljo med ponovnim objavljanjem — Ponovna objava statičnega mesta ne izbriše več datotek najprej. Stara stran ostane na voljo, dokler nova ni na mestu, spremembe pa se pokažejo v nekaj sekundah.
• Pomanjkanje pomnilnika, skrito v oznaki napredka — Naš AI agent je med pisanjem ene velike datoteke zmanjkal pomnilnika. Vzrok ni bil model ali vzporedni podagenti, temveč oznaka stanja, poslana 41.000-krat.
• Manjkajoča swap datoteka, ki je zamrznila naše strežnike — Produkcijski strežnik je nehal odgovarjati, ne da bi se zrušil: brez swapa je jedro neprestano prebiralo predpomnilnik. Kaj se je zgodilo in kaj smo spremenili.
• Prebujanje baz brez mrtvih povezav — Aplikacija, ki se je prebudila iz spanja, je prvo zahtevo držala 10–12 sekund zaradi povezav do baze, ki so med spanjem odmrle. Zdaj je 2,3 sekunde.
• Omejevali smo lastne storitve — Omejitev API-ja na naslov je obravnavala naše lastne storitve kot enega zasedenega uporabnika, zato so v produkciji dobivale napake 429. Kako smo to popravili.
• Zakaj smo strežnike preselili na ARM — Ko je težko delo preselilo v peskovnike za projekte, so naši strežniki porabljali le tretjino pomnilnika. Manjši ARM strežniki so znižali stroške za približno 30 %.
• Kako smo spravili napake 502 pri objavah na nič — Watchdog je tekmoval z objavami, load balancer pa je prepozno opazil odhod strežnika. Kako smo oboje popravili in prišli od 10 napak 502 do nič.