Vývoj

Vývoj

Ako sa Mythex vyvíja a prevádzkuje – vrátane toho, čo sa pokazilo a ako sme to opravili.

• Neúspešné opätovné publikovanie nikdy nevymaže fungujúci backend — Neúspešné opätovné publikovanie mohlo vymazať živé API aplikácie alebo nechať bežať jej pokazenú novú verziu. Tri opravy vrátenia zlyhaného publikovania.
• Upozornenia, ktoré sa spustia raz, nie raz na každý server — Denné upozornenie k nám prišlo päťkrát za jedno popoludnie. Prečo deduplikácia v pamäti zlyháva pri dvoch serveroch a nasadeniach a čo to opravilo.
• Prechod na väčšie pracovné priestory bez čakania pre niekoho — Štvrtina pracovných priestorov zostala po prechode na 2 GB na 1 GB. Naša prvá oprava spôsobila jednému človeku sedem minút čakania. Čo sme zmenili a zmenili znova.
• Databázy účtované podľa toho, čo skutočne využívajú — Náklady na databázu sme kedysi odhadovali a odhad bol zlý oboma smermi. Teraz sa každá databáza účtuje podľa nameraného využitia, hodinu po hodine.
• Zachytávanie aplikácií, ktoré spadnú hneď po publikovaní — Tri publikovania prešli kontrolou stavu, hoci ich API pri každom štarte spadlo po sekundách. Príčina: pády sa počítali v zozname s limitom päť položiek.
• Ako udržať obrazovo náročné kroky agenta v pamäti — Jeden krok agenta, ktorý pozeral skeny katalógu, minul pamäť pri 952 MB. Tri samostatné príčiny, každá držala obrázky príliš dlho, a ako sme ich opravili.
• Ako udržať dlhé kroky agenta v kontextovom okne — Subagenti rástli, až ich model odmietol, zastavili sa kvôli miestu alebo zle počítali ruské tokeny. Tri opravy, vďaka ktorým dlhá práca AI dokončí úlohu.
• Ako udržať chat živý, keď telefón zaspí — Telefóny zaspávajú, prepínajú karty a strácajú sieť počas stavby. Dve chyby zasekli chat alebo ukázali polovicu odpovede. Ako sme ich našli a opravili.
• Jeden ťažký chat mohol zhodiť naše API — 28. septembra obe naše API servery naraz minuli pamäť. Prvá oprava bola viac pamäte; skutočná bola načítavať históriu chatu podľa veľkosti, nie počtu.
• Dvojité stlačenie Publish teraz publikuje iba raz — Tri žiadosti o publikovanie jednej aplikácie prišli s odstupom 84 ms a spustili tri deploye. Databáza rozhodne, kto publikuje, a ostatným povie pravdu.
• SEO lekcie z opravy vlastnej stránky — Duplicitné FAQ značky, zlý náhľad v Google, šablóny, na ktoré nikto neklikal, a cesta, ktorú náš edge odmietal: čo sme našli na mythex.ai a opravili.
• Statické stránky zostávajú online aj počas opätovného publikovania — Opätovné publikovanie statickej stránky ju už nevyprázdni. Stará verzia ostáva online, kým nová nie je na mieste, a zmeny sa ukážu za pár sekúnd.
• Chyba out-of-memory skrytá v popisku priebehu — Náš AI agent došiel na pamäť pri zápise jedného veľkého súboru. Príčinou nebol model ani paralelní subagenti, ale štítok stavu odoslaný 41 000-krát.
• Chýbajúci swap súbor, ktorý zamrazil naše servery — Produkčný server prestal odpovedať bez pádu — žiadne zabitie pre pamäť, len thrashing page cache na stroji bez swapu. Čo sa stalo a čo sme zmenili.
• Prebúdzanie databáz bez mŕtvych spojení — Publikovaná aplikácia po prebudení držala prvú požiadavku 10–12 sekúnd na databázových spojeniach, ktoré počas spánku odumreli. Ako sme to skrátili na 2,3 sekundy.
• Obmedzovali sme vlastné služby — Limit požiadaviek na adresu v našom API bral vlastné služby ako jedného zaneprázdneného človeka a v produkcii začali dostávať 429. Ako sme to našli a opravili.
• Prečo sme presunuli servery Mythex na ARM — Keď ťažká práca prešla do sandboxov projektov, servery využívali tretinu pamäte. Menšie ARM inštancie znížili náklady asi o 30 %. Ako to fungovalo.
• Ako sme dostali nasadenia na nula chýb 502 — Watchdog, ktorý súťažil s nasadeniami, a load balancer, ktorý reagoval neskoro: ako sme znížili chyby 502 pri nasadení z 10 na nulu.