Engineering

Engineering

Come costruiamo e gestiamo Mythex, compreso cosa si è rotto e come l'abbiamo sistemato.

• Un republish fallito non cancella mai un backend funzionante — Un republish fallito poteva cancellare l'API live di un'app. Tre correzioni a come Mythex annulla una pubblicazione andata storta.
• Avvisi che scattano una volta sola, non una volta per server — Un avviso giornaliero è arrivato cinque volte in un pomeriggio. Perché la deduplica in memoria fallisce con due server, e come l'abbiamo corretta.
• Passare a spazi di lavoro più grandi senza far aspettare nessuno — Un quarto degli spazi era rimasto a 1 GB dopo il passaggio a 2 GB. La prima correzione ha fatto aspettare una persona sette minuti. Cosa abbiamo cambiato.
• Fatturare i database in base a ciò che usano davvero — Stimavamo il costo del database di ogni app, e la stima sbagliava in entrambe le direzioni. Ora ogni database viene fatturato dall'uso misurato.
• Individuare le app che vanno in crash subito dopo la pubblicazione — Tre pubblicazioni hanno superato l'health check mentre l'API andava in crash a ogni avvio. La causa: contare i crash in una lista limitata a cinque voci.
• Mantenere entro la memoria i turni dell'agente ricchi di immagini — Un turno dell'agente che analizzava scansioni di cataloghi ha esaurito la memoria a 952 MB. Tre cause separate, e come le abbiamo risolte.
• Tenere i turni lunghi dell'agente dentro la finestra di contesto — I sotto-agenti crescevano fino a essere rifiutati dal modello, si fermavano per risparmiare spazio e contavano male i token in russo. Tre correzioni.
• Tenere viva la chat quando il telefono si mette in pausa — I telefoni vanno in standby e cambiano rete durante una build. Due bug bloccavano la chat o mostravano metà risposta. Come li abbiamo risolti.
• Come una chat pesante avrebbe potuto mandare giù la nostra API — Il 28 settembre entrambi i server API sono rimasti senza memoria insieme. La causa: la cronologia caricata per numero di messaggi, non per dimensione.
• Premere Publish due volte ora pubblica una sola volta — Tre richieste di pubblicazione della stessa app, arrivate a 84 ms di distanza, avviavano tre deploy. Ora il database decide chi pubblica.
• Lezioni SEO da una correzione del nostro sito — FAQ doppie, miniatura sbagliata su Google, pagine modello senza clic e un percorso bloccato dal nostro edge: cosa abbiamo risolto su mythex.ai.
• I siti statici restano online mentre vengono ripubblicati — Ripubblicare un sito statico lo svuotava prima. Ora la versione vecchia resta online finché la nuova è pronta, e le modifiche compaiono in pochi secondi.
• Il crash per esaurimento di memoria nascosto in un'etichetta di avanzamento — Il nostro agente IA ha esaurito la memoria scrivendo un file grande. Non era il modello né i sotto-agenti: un'etichetta di stato rispedita 41.000 volte.
• Il file di swap mancante che ha bloccato i nostri server — Un server di produzione ha smesso di rispondere senza crash: nessun kill per memoria, solo thrashing su una macchina senza swap. Cosa abbiamo cambiato.
• Risvegliare i database senza connessioni morte — Un'app pubblicata che si risvegliava teneva la prima richiesta per 10-12 secondi su connessioni al database morte. Ora siamo a 2,3 secondi.
• Stavamo limitando i nostri stessi servizi — Il limite di frequenza per indirizzo trattava i nostri servizi come un'unica persona, e in produzione ricevevano 429. Come l'abbiamo scoperto e risolto.
• Perché abbiamo spostato i server di Mythex su ARM — Dopo aver spostato il lavoro pesante nelle sandbox, i nostri server usavano un terzo della memoria. Istanze ARM più piccole: costi giù del 30%.
• Come siamo arrivati a zero errori 502 nei deploy — Un watchdog che lottava contro i deploy e un load balancer che se ne accorgeva tardi: come li abbiamo trovati e corretti, fino a zero errori 502.