Teknologi

Teknologi

Slik bygges og driftes Mythex, inkludert hva som gikk galt og hvordan vi fikset det.

• En mislykket republisering sletter aldri en fungerende backend — En mislykket republisering kunne slette en apps live-API, eller la en ødelagt ny versjon kjøre. Tre rettelser i hvordan Mythex angrer en publisering som går galt.
• Varsler som utløses én gang, ikke én gang per server — Et daglig varsel kom fem ganger på én ettermiddag. Hvorfor deduplisering i minnet svikter med to servere og en deploy, og hvordan delt lagring løste det.
• Å flytte til større arbeidsområder uten at noen må vente — En fjerdedel av arbeidsområdene våre satt fast på 1 GB etter at vi gikk til 2 GB. Første løsning ga én person sju minutter venting. Her er hva vi endret.
• Fakturering av databaser etter det de faktisk bruker — Vi estimerte hver apps databasekostnad, og estimatet bommet begge veier. Nå faktureres hver database etter målt bruk, time for time.
• Fange apper som krasjer rett etter publisering — Tre publiseringer besto helsesjekken vår mens API-et deres krasjet sekunder inn i hver oppstart. Årsaken: krasj ble talt i en liste med fem oppføringer.
• Holde agentturer med mange bilder innenfor minnet — En agenttur som stadig så på katalogskanninger gikk tom for minne ved 952 MB. Tre separate årsaker holdt bilder for lenge, og slik fikset vi dem.
• Holde lange agentturer innenfor kontekstvinduet — Underagentene våre vokste til modellen avviste dem, stoppet for å spare plass, eller talte tokens feil på russisk. Tre løsninger for lang AI-jobb.
• Holde chatten i live når en telefon sover — Telefoner sover, bytter faner og mister nettverk midt i en bygging. To feil fikk chatten til å stoppe eller vise halvt svar. Slik fant og fikset vi dem.
• Hvordan én tung chat kunne tatt API-et vårt ned — Den 28. september gikk minnet tomt på begge API-serverne samtidig. Den virkelige løsningen var å laste chatthistorikk etter størrelse, ikke antall.
• Å trykke Publish to ganger publiserer nå bare én gang — Tre publiseringsforespørsler for én app kom 84 ms fra hverandre og startet tre deploys. Nå avgjør databasen hvem som publiserer; de andre får klart svar.
• SEO-lærdom fra å rette opp vårt eget nettsted — Dupliserte FAQ-markeringer, feil miniatyrbilde i Google, malsider ingen klikket på og en sti vår egen kant avviste: det vi fant på mythex.ai og fikset.
• Statiske nettsteder forblir oppe under republisering — Republisering av et statisk nettsted tømte det før opplastingen. Nå viser den gamle versjonen fram til den nye er klar, og endringer vises på sekunder.
• Minnekrasjen som gjemte seg i en fremdriftsetikett — AI-agenten vår gikk tom for minne mens den skrev én stor fil. Årsaken var en statusetikett som ble sendt på nytt 41 000 ganger, ikke modellen eller underagentene.
• Den manglende swap-filen som frøs serverne våre — En produksjonsserver sluttet å svare uten å krasje: ingen minnedrap, bare sidecache-trashing på en maskin uten swap. Hva som skjedde og hva vi endret.
• Å vekke databaser uten døde forbindelser — En publisert app som våknet fra dvale, holdt første forespørsel i 10–12 sekunder på døde databaseforbindelser. Nå tar den 2,3 sekunder.
• Vi begrenset våre egne tjenester — API-ets grense per nettadresse behandlet våre egne tjenester som én travel person, og i produksjon fikk de 429-feil. Slik fant vi det og fikset det.
• Hvorfor vi flyttet Mythex sine servere til ARM — Når tung jobb flyttet over i sandkasser, brukte serverne en tredjedel av minnet. Mindre ARM-instanser kuttet kostnadene med rundt 30 %.
• Slik fikk vi deployene ned til null 502-feil — Watchdogen og lastbalanseren vår kolliderte med deployene. Slik fant og fikset vi begge, og fikk deployene fra 10 502-feil ned til null.