Engenharia

Engenharia

Como o Mythex é construído e operado, incluindo o que falhou e como o corrigimos.

• Uma Republicação Falhada Nunca Apaga um Backend que Funciona — Uma republicação falhada podia apagar a API ativa de uma app ou deixar uma versão avariada a correr. Três correções ao modo como a Mythex desfaz uma publicação falhada.
• Alertas que Disparam Uma Vez, Não Uma Vez por Servidor — Um alerta diário chegou-nos cinco vezes numa só tarde. Porque é que a deduplicação em memória falha com dois servidores e um deploy, e como a partilha de estado a resolveu.
• Passar para Espaços de Trabalho Maiores Sem Fazer Ninguém Esperar — Um quarto dos espaços de trabalho ficou em 1 GB depois de passarmos para 2 GB. A primeira correção fez uma pessoa esperar sete minutos. O que mudámos e o que voltámos a mudar.
• Faturar as Bases de Dados Pelo Que Realmente Usam — Estimávamos o custo da base de dados de cada app, e a estimativa estava errada para os dois lados. Agora cada base de dados é faturada pela utilização medida, hora a hora.
• Apanhar Apps que se Avariam Logo Após a Publicação — Três publicações passaram o nosso health check enquanto a sua API se avariava segundos após cada arranque. A causa: contar as falhas numa lista limitada a cinco entradas.
• Manter os turnos do agente com muitas imagens dentro da memória — Um turno do agente ficou sem memória aos 952 MB ao analisar digitalizações de catálogos. Três causas, cada uma a reter imagens tempo demais, e como as corrigimos.
• Manter os turnos longos do agente dentro da janela de contexto — Os sub-agentes podiam crescer até o modelo os recusar, parar cedo por falsa falta de espaço, ou contar mal os tokens em russo. Três correções para o trabalho longo terminar.
• Manter o chat ativo quando o telemóvel adormece — Telemóveis adormecem e mudam de rede a meio de uma criação. Dois erros faziam o chat bloquear ou mostrar meia resposta. Como os encontrámos e corrigimos.
• Como um chat pesado podia derrubar a nossa API — A 28 de setembro, os dois servidores da API ficaram sem memória ao mesmo tempo. A causa real: o histórico do chat era carregado por número, não por tamanho.
• Carregar duas vezes em Publicar agora publica apenas uma vez — Três pedidos de publicação da mesma app chegaram com 84 ms de diferença e cada um lançou um deploy. Agora a base de dados decide quem publica.
• Lições de SEO ao Corrigir o Nosso Próprio Site — FAQ duplicada, a miniatura errada no Google, páginas de modelos sem cliques e uma rota bloqueada pela nossa borda: o que encontrámos no mythex.ai e corrigimos.
• Os Sites Estáticos Continuam no Ar Enquanto Republicam — Republicar um site estático apagava o conteúdo antes do envio. Agora o site antigo continua no ar até a nova versão estar pronta, e as alterações aparecem em segundos.
• O Crash por Falta de Memória Escondido numa Etiqueta de Progresso — O agente de IA ficou sem memória ao escrever um ficheiro grande. A causa não foi o modelo: foi uma etiqueta de estado reenviada 41.000 vezes.
• O Ficheiro de Swap em Falta Que Congelou os Nossos Servidores — Um servidor de produção deixou de responder sem bloquear: thrashing da cache numa máquina sem swap, sem kill por memória. O que aconteceu e o que mudámos.
• Acordar Bases de Dados Sem Ligações Mortas — Uma app publicada que acordava mantinha o primeiro pedido 10–12 segundos à espera de ligações mortas. Como baixámos isso para 2,3 segundos.
• Estávamos a Limitar a Taxa dos Nossos Próprios Serviços — O limite por endereço da API tratava os nossos próprios serviços como uma pessoa ocupada, e começaram a receber 429. Como o encontrámos e corrigimos.
• Porque Mudámos os Servidores do Mythex para ARM — Depois de o trabalho pesado passar para sandboxes, os servidores usavam um terço da memória. Instâncias ARM mais pequenas cortaram cerca de 30% dos custos. Eis como.
• Como Chegámos a Zero Erros 502 nos Deploys — Um watchdog em corrida com os deploys e um balanceador que notou tarde demais: como encontrámos os dois problemas e passámos de 10 erros 502 para zero.