Inginerie

Inginerie

Cum construim și rulăm Mythex, inclusiv ce s-a stricat și cum am reparat.

• Un republish eșuat nu șterge niciodată un backend funcțional — Un republish eșuat ar fi putut șterge API-ul live al unei aplicații sau ar fi lăsat în funcțiune versiunea nouă, defectă. Trei corecturi la anularea publicărilor eșuate.
• Alerte care se declanșează o singură dată, nu o dată pe server — O alertă zilnică ne-a ajuns de cinci ori într-o după-amiază. De ce deduplicarea din memorie eșuează cu două servere și un deploy și cum a rezolvat-o starea partajată.
• Spații de lucru mai mari, fără ca nimeni să aștepte — Un sfert din spațiile de lucru au rămas la 1 GB după trecerea la 2 GB. Prima soluție a făcut o persoană să aștepte șapte minute. Ce am schimbat, apoi am schimbat din nou.
• Baze de date facturate după ce folosesc cu adevărat — Estimam costul bazei de date pentru fiecare aplicație, iar estimarea greșea în ambele sensuri. Acum fiecare bază de date se facturează din utilizarea măsurată, oră cu oră.
• Prinderea aplicațiilor care se blochează imediat după publicare — Trei publicări au trecut verificarea de sănătate deși API-ul se prăbușea la câteva secunde după fiecare pornire. Cauza: numărarea crash-urilor într-o listă de cinci intrări.
• Menținerea turelor agentului cu multe imagini în limitele memoriei — O tură a agentului care tot analiza scanări de cataloage a rămas fără memorie la 952 MB. Trei cauze separate, fiecare ținând imaginile prea mult, și cum le-am reparat.
• Menținerea turelor lungi ale agentului în fereastra de context — Subagenții creșteau până când modelul îi refuza, se opreau ca să economisească spațiu sau numărau greșit tokenii în rusă. Trei corecții pentru munca lungă cu AI.
• Menținerea chatului activ când telefonul intră în repaus — Telefoanele intră în repaus și pierd rețeaua în timpul unei construcții. Două erori lăsau chatul blocat pe „Se conectează…” sau cu jumătate de răspuns. Cum le-am reparat.
• Un chat încărcat ar putea doborî API-ul nostru — Pe 28 septembrie, ambele servere API au rămas fără memorie în același timp. Adevărata cauză: istoricul se încărca după număr, nu după mărime.
• Apăsatul de două ori pe Publish publică acum o singură dată — Trei cereri de publicare pentru aceeași aplicație, la 84 ms distanță, porneau fiecare un deploy complet. Acum baza de date decide cine publică.
• Lecții SEO din corectarea propriului nostru site — FAQ-uri duplicate, miniatura greșită în Google, pagini de șablon fără clickuri și o cale refuzată de edge. Ce am găsit pe mythex.ai și am reparat.
• Site-urile statice rămân online în timpul republicării — Republicarea golea site-ul static înainte de încărcarea noului build. Acum cel vechi rămâne servit până ajunge cel nou, iar schimbările apar în câteva secunde.
• Blocajul de memorie ascuns într-o etichetă de progres — Agentul nostru AI a rămas fără memorie scriind un fișier mare. Cauza nu era modelul sau sub-agenții paraleli, ci o etichetă de stare retrimisă de 41.000 de ori.
• Fișierul de swap lipsă care ne-a blocat serverele — Un server de producție a înghețat fără să se prăbușească: thrashing în page cache, fără swap. Ce s-a întâmplat și ce am schimbat.
• Trezirea bazelor de date fără conexiuni moarte — O aplicație publicată, care se trezea din somn, își ținea prima cerere 10–12 secunde pe conexiuni la baza de date care muriseră cât timp dormea. Cum am ajuns la 2,3 secunde.
• Ne limitam singuri serviciile — Limita pe adresă a API-ului trata serviciile noastre ca pe un singur utilizator, iar în producție ele primeau erori 429. Cum am reparat.
• De ce am mutat serverele Mythex pe ARM — Odată ce munca grea a trecut în sandbox-uri, serverele noastre foloseau o treime din memorie. Instanțele ARM mai mici au redus costul cu ~30%.
• Cum am ajuns la zero erori 502 la deploy-uri — Un watchdog care se certa cu deploy-urile și un load balancer care a observat prea târziu: cum le-am găsit, le-am reparat și am măsurat trecerea de la 10 erori 502 la zero.