Ingénierie

Ingénierie

Comment Mythex est conçu et exploité, y compris ce qui a cassé et comment nous l’avons réparé.

• Une republication ratée ne supprime jamais un backend fonctionnel — Une republication ratée pouvait supprimer l'API en production d'une application. Trois correctifs pour la façon dont Mythex annule une publication qui tourne mal.
• Des alertes qui se déclenchent une seule fois, et non une fois par serveur — Une alerte quotidienne nous est parvenue cinq fois en un après-midi. Pourquoi la déduplication en mémoire échoue avec deux serveurs, et comment un état partagé la corrige.
• Passer à des espaces de travail plus grands sans faire attendre qui que ce soit — Un quart de nos espaces étaient restés à 1 Go après le passage à 2 Go. Notre première correction a fait attendre une personne sept minutes. Ce que nous avons changé.
• Facturer les bases de données selon leur utilisation réelle — Nous estimions le coût des bases de données, et l'estimation se trompait dans les deux sens. Chaque base est maintenant facturée selon son usage mesuré, heure par heure.
• Repérer les applications qui plantent juste après la publication — Trois publications ont réussi le contrôle de santé alors que leur API plantait à chaque démarrage. La cause : compter les plantages dans une liste limitée à cinq entrées.
• Garder les tours d'agent riches en images dans la mémoire — Un tour d'agent a manqué de mémoire à 952 Mo en analysant des catalogues. Trois causes qui gardaient les images trop longtemps, et leurs corrections.
• Garder les longs tours d'agent dans la fenêtre de contexte — Nos sous-agents pouvaient grossir jusqu'au refus du modèle ou mal compter les jetons en russe. Trois corrections pour mener le long travail à terme.
• Garder le clavardage actif quand un téléphone se met en veille — Les téléphones se mettent en veille et changent de réseau. Deux bogues bloquaient le clavardage ou affichaient une réponse incomplète. Voici les corrections.
• Un clavardage trop lourd pouvait faire tomber notre API — Le 28 septembre, nos deux serveurs d'API ont manqué de mémoire en même temps. La vraie correction : charger l'historique selon la taille, pas le nombre.
• Appuyer deux fois sur Publish ne publie plus qu'une fois — Trois demandes de publication pour une même app lançaient trois déploiements. La base de données décide maintenant qui publie, et les autres sont informées.
• Leçons de référencement tirées de la correction de notre propre site — Balisage FAQ en double, mauvaise miniature Google, pages de modèles sans clics, chemin bloqué par notre edge : ce que nous avons corrigé sur mythex.ai.
• Les sites statiques restent en ligne pendant leur republication — Republier un site statique le vidait avant le téléversement. Désormais, l'ancienne version reste en ligne jusqu'à ce que la nouvelle soit prête.
• La fuite de mémoire cachée dans une étiquette de progression — L'agent IA a manqué de mémoire en écrivant un gros fichier. Le coupable : une étiquette d'état renvoyée 41 000 fois, pas le modèle ni les sous-agents.
• Le fichier d'échange manquant qui a figé nos serveurs — Un serveur de production a cessé de répondre sans planter, faute de swap : un emballement du cache de pages. Ce qui s'est passé et ce qui a changé.
• Réveiller des bases de données sans connexions mortes — Au réveil, une application publiée retenait sa première requête 10 à 12 secondes à cause de connexions mortes. Nous sommes passés à 2,3 secondes.
• Nous limitions nos propres services — Notre limite par adresse bloquait nos propres services internes, qui recevaient des 429 en production. Comment nous l'avons corrigé.
• Pourquoi nous avons migré nos serveurs vers ARM — Nos serveurs n'utilisaient plus qu'un tiers de leur mémoire. Des instances ARM plus petites ont réduit la facture d'environ 30 %.
• Comment nous avons ramené les déploiements à zéro erreur 502 — Un chien de garde en conflit avec nos déploiements, et un répartiteur trop lent à réagir : comment nous sommes passés de 10 erreurs 502 à zéro.