Инженерия

Инженерия

Как устроен и работает Mythex — включая то, что ломалось, и как мы это чинили.

• Неудачная повторная публикация никогда не удаляет работающий бэкенд — Неудачная повторная публикация могла удалить живой API приложения или оставить сломанную новую версию работать. Три исправления в откате Mythex.
• Оповещения, которые срабатывают один раз, а не по разу на каждый сервер — Ежедневное оповещение пришло нам пять раз за один день. Почему дедупликация в памяти ломается при двух серверах и деплое и как общее хранилище это исправило.
• Переход на более крупные рабочие пространства без ожидания для кого-либо — Четверть рабочих пространств осталась на 1 ГБ после перехода на 2 ГБ. Первое исправление заставило одного человека ждать семь минут. Что мы меняли.
• Оплата баз данных по тому, что они реально используют — Раньше мы оценивали стоимость базы данных каждого приложения, и оценка ошибалась в обе стороны. Теперь каждая база оплачивается по измеренному использованию, час за часом.
• Как поймать приложения, которые падают сразу после публикации — Три публикации прошли проверку, хотя API падал через секунды после каждого запуска. Причина: падения считались в списке из пяти записей.
• Как уложить ходы агента с большим количеством изображений в память — Ход агента, рассматривавший сканы каталога, упал с нехваткой памяти на 952 МБ. Три причины держали изображения слишком долго, и как мы их устранили.
• Как уместить длинные ходы агента в контекстное окно — Субагенты росли, пока модель их не отклоняла, и неверно считали токены для русского. Три исправления, благодаря которым длинная работа ИИ доходит до конца.
• Как сохранить чат живым, когда телефон спит — Телефоны засыпают, переключают вкладки и теряют сеть во время сборки. Две ошибки заставляли чат зависать или показывать половину ответа. Как мы их нашли и исправили.
• Как один тяжёлый чат мог уронить наш API — 28 сентября оба наших API-сервера одновременно исчерпали память. Настоящей причиной оказалась загрузка истории чата по количеству, а не по размеру сообщений.
• Двойное нажатие «Опубликовать» теперь публикует один раз — Три запроса на публикацию одного приложения пришли с разницей 84 мс и запустили три деплоя. Теперь база данных решает, кто публикует, а остальным честно сообщает.
• Уроки SEO, которые мы вынесли из исправления собственного сайта — Дублирующая разметка FAQ, не та миниатюра в Google, шаблонные страницы без кликов и путь, который отклонял наш edge: что мы нашли на mythex.ai и исправили.
• Статические сайты теперь работают во время повторной публикации — Раньше повторная публикация статического сайта очищала его перед загрузкой. Теперь старый сайт работает, пока новый не на месте, а изменения видны за секунды.
• Нехватка памяти, спрятанная в подписи прогресса — Наш AI-агент закончил память, записывая один большой файл. Причиной была не модель и не параллельные субагенты, а строка статуса, отправленная 41 000 раз.
• Отсутствующий файл подкачки, из-за которого зависли наши серверы — Продакшен-сервер перестал отвечать, но не упал: ни убийства из-за нехватки памяти, ни ошибки, просто трэш page-cache на машине без swap. Что случилось и что мы изменили.
• Пробуждение баз данных без мёртвых соединений — Опубликованное приложение, пробуждаясь от сна, держало первый запрос 10–12 секунд из-за соединений с базой, которые умерли, пока оно спало. Как мы довели это до 2,3 секунды.
• Мы ограничивали собственные сервисы по частоте запросов — Лимит запросов с одного адреса в нашем API считал наши собственные сервисы одним занятым человеком, и в продакшене они начали получать 429. Как мы нашли и исправили.
• Почему мы перенесли серверы Mythex на ARM — Когда тяжёлая работа переехала в песочницы отдельных проектов, наши серверы использовали треть памяти. Меньшие ARM-инстансы сократили расходы примерно на 30%. Как это было.
• Как мы добились нуля ошибок 502 при деплоях — Сторожевой процесс, который конкурировал с деплоями, и балансировщик, который заметил проблему поздно: как мы нашли обе, исправили и сократили 502 при деплое с 10 до нуля.