Fejlesztés

Fejlesztés

Hogyan épül és működik a Mythex – azzal együtt, mi romlott el és hogyan javítottuk.

• Egy sikertelen újrapublikálás soha nem töröl működő backendet — Egy sikertelen újrapublikálás törölhette volna egy app élő API-ját, vagy futva hagyhatta volna a hibás verziót. Három javítás a Mythex visszavonásához.
• Riasztások, amelyek egyszer szólnak, nem szerverenként egyszer — Egy napi riasztás egy délután öt alkalommal jött meg. Miért nem működik a memóriabeli deduplikáció két szerverrel és deployokkal, és mit javított a közös állapot.
• Nagyobb munkaterületekre váltás úgy, hogy senki ne várjon — A munkaterületek negyede 1 GB-on ragadt, miután 2 GB-ra váltottunk. Az első javításunk egy embert hét percig várakoztatott. Mit változtattunk, és mit változtattunk újra.
• Adatbázisok számlázása a valódi használat szerint — Korábban minden app adatbázisköltségét becsültük, és a becslés mindkét irányban téved. Most minden adatbázist mért használat alapján számlázunk, óránként.
• Az összeomló appok elkapása közvetlenül a publikálás után — Három publikálás átment az állapotellenőrzésen, miközben az API minden indítás után pár másodperccel összeomlott. Az ok: az összeomlásokat egy ötelemű listában számolták.
• Képekkel teli ügynöki körök a memórián belül — Egy ügynöki kör katalógusszkennelésekkel 952 MB-nál kifutott a memóriából. Három külön ok tartotta túl sokáig a képeket, és mindhármat javítottuk.
• Hosszú ügynöki körök a kontextusablakon belül — Az al-ügynökeink addig nőttek, amíg a modell el nem utasította őket, vagy rosszul számoltak oroszul. Három javítás, amely a hosszú AI-munkát végigviszi.
• A chat életben tartása, amikor a telefon elalszik — A telefonok elalszanak és hálózatot cserélnek építés közben. Két hiba miatt a chat megakadt, vagy félig mutatta a választ. Így javítottuk ki.
• Hogyan tudott egy nehéz chat leállítani az API-nkat — Szeptember 28-án mindkét API-szerverünk egyszerre fogyott ki a memóriából. Az igazi javítás: az előzményeket mérettel, nem darabszámmal töltjük be.
• A Közzététel kétszeri megnyomása most egyszer közzéteszi — Három közzétételi kérés 84 ms-on belül ugyanarra az appra három deployt indított. Így az adatbázis dönt, ki publikál, a többiek pedig az igazat kapják.
• SEO-tanulságok a saját oldalunk javításából — Dupla FAQ-jelölés, rossz bélyegkép a Google-ben, kattintás nélküli sablonoldalak és egy blokkolt útvonal: mit találtunk a mythex.ai-on, és mit javítottunk.
• A statikus oldalak újrapublikálás közben is elérhetők maradnak — Statikus oldal újrapublikálásakor nem üres a live oldal: a régi verzió marad, amíg az új fel nem kerül, a változások pedig másodpercek alatt látszanak.
• A memóriakimerülési összeomlás, amely egy folyamatjelzőben lapult — Az AI-ügynökünk memóriahiba miatt állt le egy nagy fájl írása közben. Nem a modell volt az ok, hanem egy állapotcímke, amelyet 41 000-szer küldtünk újra.
• A hiányzó swap-fájl, amely lefagyasztotta a szervereinket — Egy éles szerver nem omlott össze, mégsem válaszolt: lapgyorsítótár-csörtetés volt swap nélkül. Mi történt, és mit változtattunk.
• Adatbázisok felébresztése halott kapcsolatok nélkül — Az alvásból ébredő publikált app első kérése 10–12 másodpercig tartott, mert alvás alatt elhalt adatbázis-kapcsolatokat próbált újrahasználni. Most 2,3 másodperc.
• Saját szolgáltatásainkat korlátoztuk sebességben — Az API címenkénti sebességkorlátja a saját szolgáltatásainkat is korlátozta, így az éles környezetben 429-es válaszokat kaptak. Hogyan javítottuk ki.
• Miért költöztettük a Mythex szervereit ARM-re — A munka sandboxokba költözése után szervereink memóriájuk harmadát használták. A kisebb ARM-példányok körülbelül 30%-kal csökkentették a szerverköltséget.
• Hogyan jutottunk nulla 502-es hibához a deployoknál — Egy watchdog, amely a deployjainkkal versenyzett, és egy terheléselosztó, amely későn vette észre a változást: hogyan lett a 10 db 502-es hibából nulla.