Ingeniería

Ingeniería

Cómo se construye y opera Mythex, incluido lo que falló y cómo lo arreglamos.

• Una republicación fallida nunca borra un backend que funciona — Una republicación fallida podía borrar la API en vivo de una app o dejar en marcha una versión rota. Tres correcciones en cómo Mythex deshace una publicación que sale mal.
• Alertas que se disparan una vez, no una vez por servidor — Una alerta diaria nos llegó cinco veces en una tarde. Por qué la deduplicación en memoria falla con dos servidores y un despliegue, y cómo lo arregló el estado compartido.
• Cómo pasar a espacios de trabajo más grandes sin hacer esperar a nadie — Una cuarta parte de nuestros espacios se quedó en 1 GB tras pasar a 2 GB. Nuestra primera solución hizo esperar siete minutos a alguien. Qué cambiamos y qué cambiamos después.
• Cobrar las bases de datos por lo que realmente usan — Antes estimábamos el coste de la base de datos de cada app, y la estimación fallaba en los dos sentidos. Ahora cada base de datos se cobra según el uso medido, hora a hora.
• Detectar apps que se caen justo después de publicar — Tres publicaciones superaron nuestro health check mientras su API se caía segundos después de cada arranque. La causa: contar caídas en una lista limitada a cinco entradas.
• Mantener los turnos del agente con muchas imágenes dentro de la memoria — Un turno del agente que seguía revisando escaneos de catálogo se quedó sin memoria con 952 MB. Tres causas distintas retenían imágenes demasiado tiempo, y cómo las arreglamos.
• Mantener los turnos largos del agente dentro de la ventana de contexto — Los subagentes crecían hasta que el modelo los rechazaba, se paraban pronto por un falso miedo al límite o contaban mal los tokens en ruso. Tres arreglos.
• Mantener vivo el chat cuando el móvil se duerme — Los móviles se duermen, cambian de pestaña y pierden la red. Dos fallos dejaban el chat atascado o con media respuesta. Cómo los encontramos y arreglamos.
• Cómo un chat pesado podía tumbar nuestra API — El 28 de septiembre, los dos servidores de la API se quedaron sin memoria a la vez. El arreglo real fue cargar el historial por tamaño, no solo por número.
• Pulsar Publicar dos veces ahora publica una sola vez — Tres peticiones de publicación de una misma app lanzaron tres despliegues. Ahora la base de datos decide quién publica, y a los demás se les dice la verdad.
• Lecciones de SEO al corregir nuestro propio sitio — FAQ duplicadas, la miniatura equivocada en Google, plantillas sin clics y una ruta bloqueada: lo que encontramos en mythex.ai y arreglamos.
• Los sitios estáticos siguen activos mientras se vuelven a publicar — Volver a publicar un sitio estático ya no lo vacía antes de subir la nueva versión. El sitio anterior sigue activo y los cambios aparecen en segundos.
• El fallo de memoria oculto en una etiqueta de progreso — Nuestro agente de IA se quedó sin memoria al escribir un archivo grande. La causa no fue el modelo, sino una etiqueta de estado reenviada 41.000 veces.
• El archivo de intercambio que faltaba y dejó congelados nuestros servidores — Un servidor de producción dejó de responder sin fallar: thrashing de caché de páginas en una máquina sin swap. Qué pasó y qué cambiamos.
• Despertar bases de datos sin conexiones muertas — Una app publicada tardaba 10-12 segundos en su primera petición tras despertar, por conexiones de base de datos muertas. Cómo lo bajamos a 2,3 segundos.
• Estábamos limitando la tasa de nuestros propios servicios — El límite de peticiones por dirección de nuestra API trataba a nuestros servicios como a una sola persona y producción recibía 429. Cómo lo arreglamos.
• Por qué trasladamos los servidores de Mythex a ARM — Con el trabajo pesado en sandboxes, nuestros servidores usaban un tercio de su memoria. Instancias ARM más pequeñas recortaron el coste en torno a un 30 %.
• Cómo bajamos los despliegues a cero errores 502 — Un watchdog que competía con nuestros despliegues y un balanceador que se enteró tarde: cómo lo encontramos, lo arreglamos y bajamos los 502 a cero.