Выкатка падала трижды: четыре причины в одном симптоме | AI-Mrkt
AI
AI Marketing Community
Вступить бесплатно
Главная/Кейсы/Инфраструктура
Инфраструктура

Выкатка падала трижды подряд. Внутри было четыре разные поломки

«Оборвалось соединение» — это симптом, а не причина. Разбор по слоям: лишние 5,4 ГБ в передаче, удаление рабочего кэша при каждом деплое, самоубийственный таймаут и тысячи заведомо пустых страниц в сборке.

8,1 → 2,7 ГБобъём одной выкатки
−5 300страниц из сборки
4причины у одного симптома

Задача

Выкатка обновлений большого портала перестала доходить до сервера. Три попытки подряд оборвались, каждая занимала около сорока минут, в логе — «соединение разорвано» и «таймаут». Внешне это одна поломка сети.

Самое дорогое решение здесь — то, которое напрашивается: увеличить таймаут и перезапустить. Оно иногда срабатывает, ничего не объясняет и возвращается через неделю.

Решение

Вместо перезапуска — измерить три вещи по отдельности: сколько данных мы вообще отправляем, что при этом удаляем на сервере и сколько страниц собираем. Один симптом «выкатка оборвалась» распался на четыре независимые причины, и три из них к сети отношения не имели.

Внедрение

1. Отправляли втрое больше нужного

Папка сборки весила 8,1 ГБ, из которых серверу нужны 2,7 ГБ. Остальное — 4,3 ГБ служебных артефактов режима разработки, которые на боевом сервере не используются вообще, и 1,1 ГБ локального кэша сборки. Оба каталога исключены из передачи.

2. Каждый деплой сносил рабочий кэш сайта

Это оказалось хуже медленной выкатки. Синхронизация шла с режимом «удалить на сервере всё лишнее», и под «лишнее» попадал кэш уже готовых страниц, который живёт в том же каталоге. То есть сайт после каждого обновления заново прогревался с нуля — а списывали это на «ну, после деплоя всегда тормозит». Каталог кэша теперь нельзя ни заливать, ни удалять.

3. Таймаут убивал передачу сам

Ограничение в 120 секунд стояло на всю операцию, включая сверку файлов. На 127 000 файлов сверка молчит дольше двух минут — и процесс убивал себя, не передав ни байта. Таймаут поднят до 600 секунд, добавлены докачка оборванных файлов и удержание соединения, чтобы длинная передача не рвалась посередине.

4. Собирали тысячи заведомо пустых страниц

Четыре раздела каталога строились как полное сочетание всех признаков со всеми — регион с типом, станция метро с типом и так далее. Большинство сочетаний пустые: объектов такого типа в этом месте просто нет. Теперь заранее собираются только непустые комбинации: 3 611 → 996, 2 394 → 220, 550 → 135, 189 → 73. Остальные никуда не делись — они открываются по первому запросу и после этого работают как обычные.

Результат

Вывод, который переносится на любой проект: «всё тормозит и падает» — это не диагноз, а список симптомов. Час на разбор дал четыре разные причины, две из которых портили сайт незаметно и не имели отношения к тому, на что жаловались.

Дмитрий Коновалов

Дмитрий Коновалов

CMO · AI-маркетинг

10 лет в маркетинге. Строю комьюнити AI-маркетологов и вайбкодеров в России. Каждый кейс сначала проверяю на своих проектах и бюджетах, потом разбираю в Telegram @dima_konovalov_edtech.

Хочешь делать так же?

В канале @dima_konovalov_edtech — реальные кейсы, рабочие промпты и разборы того, как AI меняет маркетинг и продажи. Без воды, только практика.

Вступить бесплатно

Частые вопросы

Почему нельзя было просто увеличить таймаут?

Это убрало бы одну причину из четырёх — и то не главную. Остались бы лишние 5,4 ГБ в каждой передаче, снос рабочего кэша при каждом деплое и тысячи пустых страниц в сборке. Симптом бы ушёл, а сайт продолжил бы тормозить после каждого обновления.

Пропали ли страницы, убранные из предварительной сборки?

Нет. Они просто не готовятся заранее: адрес открывается по первому обращению и дальше работает как обычная страница. Из поиска ничего не выпадает, а сборка перестаёт тратить время на тысячи заведомо пустых сочетаний.

Как понять, что деплой втихую выкатывает старую версию?

Проверять код возврата каждого шага, а не только финального. У нас ошибка обновления кода на сервере гасилась внутри конвейера, скрипт бодро рапортовал об успехе и заливал старое. Правило простое: любой шаг, который может не сработать, должен уметь остановить весь деплой.

Читать дальше