Vývoj

Vývoj

Jak Mythex vyvíjíme a provozujeme – včetně toho, co se rozbilo a jak jsme to opravili.

• Neúspěšné opětovné publikování nikdy nesmaže fungující backend — Neúspěšné opětovné publikování mohlo smazat živé API aplikace nebo nechat běžet rozbitou novou verzi. Tři opravy v tom, jak Mythex vrací zpět nezdařené publikování.
• Upozornění, která se spustí jednou, ne jednou na každý server — Upozornění, které mělo přijít jednou denně, dorazilo odpoledne pětkrát. Proč deduplikace v paměti selhává u dvou serverů a nasazení a jak to opravilo sdílené úložiště.
• Přechod na větší pracovní prostory bez čekání pro kohokoli — Čtvrtina našich pracovních prostorů zůstala po přechodu na 2 GB na 1 GB. Naše první oprava donutila jednoho člověka čekat sedm minut. Co jsme změnili a potom ještě jednou.
• Fakturace databází podle toho, co skutečně používají — Dřív jsme odhadovali náklady na databázi každé aplikace a odhad byl špatný oběma směry. Teď se každá databáze účtuje podle změřeného využití, hodinu po hodině.
• Odchytávání aplikací, které se hroutí hned po publikování — Tři publikování prošla naším health checkem, zatímco jejich API se sekundy po každém startu zhroutilo. Příčina: pády se počítaly v seznamu omezeném na pět položek.
• Jak udržet běhy agenta s mnoha obrázky v paměti — Běh agenta, který kontroloval skeny katalogů, došel na 952 MB paměti. Tři oddělené příčiny držely obrázky příliš dlouho a takto jsme je opravili.
• Jak udržet dlouhé běhy agenta v kontextovém okně — Subagenti rostli, až je model odmítl, zastavovali se kvůli místu nebo špatně počítali ruské tokeny. Tři opravy, aby dlouhá práce dokončila.
• Jak udržet chat živý, když telefon usne — Telefony usínají, přepínají karty a ztrácejí síť. Dvě chyby způsobovaly, že chat zamrzl nebo ukázal jen půl odpovědi. Jak jsme je našli a opravili.
• Jeden těžký chat by mohl položit naše API — 28. září oba naše API servery najednou došly paměti. Skutečná oprava: historie chatu se načítá podle velikosti, ne jen počtu zpráv.
• Dvojí stisk Publikovat teď publikuje jen jednou — Tři žádosti o publikaci jedné aplikace dorazily po 84 ms a každá spustila celé nasazení. Jak databáze rozhoduje o tom, kdo publikuje.
• Ponaučení z SEO, když opravujete vlastní web — Duplicitní značky FAQ, špatný náhled v Googlu, šablonové stránky, na které nikdo neklikal, a cesta, kterou náš edge odmítl. Co jsme na mythex.ai našli a opravili.
• Statické weby zůstávají online, i když se znovu publikují — Republikace statického webu dřív smazala živý web před nahráním nového buildu. Teď zůstává starý web online, dokud není nový na místě, a změny se projeví do pár sekund.
• Chyba nedostatku paměti skrytá v popisku průběhu — Náš AI agent došel paměť při zápisu jednoho velkého souboru. Příčinou nebyl model ani paralelní subagenti – byl to stavový popisek, který se odeslal 41 000krát.
• Chybějící swapový soubor, který zamrazil naše servery — Produkční server přestal odpovídat, aniž by spadl – žádné zabití kvůli nedostatku paměti, jen thrashing page cache na stroji bez swapu. Co se stalo a co jsme změnili.
• Probouzení databází bez mrtvých spojení — Probuzená publikovaná aplikace držela první požadavek 10–12 s kvůli mrtvým databázovým spojením z doby spánku. Zkrátili jsme to na 2,3 sekundy.
• Omezovali jsme vlastní služby — Limit požadavků na API podle adresy zacházel s našimi vlastními službami jako s jedním vytíženým člověkem, a v produkci začaly dostávat 429. Jak jsme to našli a opravili.
• Proč jsme přesunuli servery Mythexu na ARM — Když se těžká práce přesunula do sandboxů jednotlivých projektů, naše servery využívaly třetinu paměti. Menší ARM instance snížily náklady zhruba o 30 %. Jak to proběhlo.
• Jak jsme se dostali při nasazení na nula chyb 502 — Watchdog, který závodil s nasazeními, a load balancer, který si všiml pozdě: jak jsme oba problémy našli, opravili a změřili nasazení z 10 chyb 502 na nula.