Інженерія

Інженерія

Як ми створюємо й підтримуємо Mythex — зокрема що ламалося і як ми це виправили.

• Невдала повторна публікація ніколи не видаляє робочий бекенд — Невдала повторна публікація могла видалити живий API застосунку або залишити зламану нову версію. Три виправлення відкату публікації.
• Сповіщення, які спрацьовують один раз, а не раз на сервер — Щоденне сповіщення прийшло до нас п'ять разів за один день. Чому дедуплікація в пам'яті ламається з двома серверами і деплоєм, і як спільний стан це виправив.
• Переїзд на більші робочі простори без очікування для кого б то не було — Чверть наших робочих просторів застрягла на 1 ГБ після переходу на 2 ГБ. Наше перше виправлення змусило одну людину чекати сім хвилин. Що ми змінили і змінили знову.
• Оплата баз даних за тим, що вони справді використовують — Раніше ми оцінювали вартість бази даних кожного застосунку, і оцінка була хибною. Тепер кожна база оплачується за виміряним використанням.
• Ловимо застосунки, які падають одразу після публікації — Три публікації пройшли перевірку працездатності, хоча їхній API падав за кілька секунд після кожного запуску. Причина: підрахунок збоїв у списку, обмеженому п'ятьма записами.
• Як утримати ходи агента з великою кількістю зображень у межах пам'яті — Хід агента, який постійно переглядав скани каталогу, вичерпав пам'ять на 952 МБ. Три окремі причини, кожна з яких тримала зображення надто довго, і як ми їх виправили.
• Як утримати довгі ходи агента в межах контекстного вікна — Субагенти росли, доки модель не відхиляла запити, зупинялися, щоб заощадити місце, і хибно рахували токени в російській. Три виправлення, щоб довга робота завершувалася.
• Як зберегти чат живим, коли телефон засинає — Телефони засинають і перемикають вкладки. Дві помилки змушували чат зависати на «Підключення…» або показувати половину відповіді. Як ми їх знайшли й виправили.
• Як один важкий чат міг би покласти наш API — 28 вересня обидва наші API-сервери одночасно вичерпали пам'ять. Перше виправлення — більше пам'яті; справжнє — завантаження історії чату за розміром, а не за кількістю.
• Натискання «Опублікувати» двічі тепер публікує один раз — Три запити на публікацію одного застосунку прийшли за 84 мс, і кожен запустив деплой. Як база даних тепер вирішує, хто публікує, і чесно повідомляє інших.
• Уроки SEO з виправлення власного сайту — Дубльована розмітка FAQ, невірна мініатюра в Google, шаблони без кліків і шлях, який наш край відхиляв: що ми знайшли на mythex.ai і виправили.
• Статичні сайти тепер не зупиняються під час повторної публікації — Раніше повторна публікація статичного сайту спершу стирала його. Тепер старий сайт працює, доки не буде готовий новий, а зміни з'являються за секунди.
• Збій через брак пам'яті, захований у мітці прогресу — Наш агент ШІ вичерпав пам'ять під час запису великого файлу. Причиною була не модель і не паралельні субагенти, а мітка статусу, надіслана 41 000 разів.
• Відсутній файл підкачки, через який зависали наші сервери — Виробничий сервер перестав відповідати, але не впав: без swap ядро постійно перекидало код програм з кешу. Що сталося і що ми змінили.
• Пробудження баз даних без мертвих з'єднань — Опублікований застосунок після сну тримав перший запит 10–12 секунд на з'єднаннях з базою, які вмерли, поки він спав. Як ми скоротили це до 2,3 секунди.
• Ми обмежували самі себе: наші сервіси під власним лімітом — Ліміт запитів на адресу сприймав наші власні сервіси як одного користувача, і в продакшені вони почали отримувати 429. Як ми знайшли і виправили.
• Чому ми перенесли сервери Mythex на ARM — Коли важка робота перейшла в пісочниці, наші сервери використовували третину пам'яті. Менші ARM-інстанси зменшили витрати приблизно на 30%. Як це сталося.
• Як ми досягли нуля помилок 502 під час розгортань — Вотчдог, що змагався з нашими розгортаннями, і балансувальник, який помітив це занадто пізно: як ми знайшли обидві проблеми, виправили їх і зменшили 502 з 10 до нуля.