Сезонный проект, который живёт три месяца в году: схема включения и выключения

MAATRIX

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

Чем сезонный цикл отличается от разовой заморозки

Заморозка проекта — событие с неопределённым горизонтом: команда останавливает сервис, потому что деньги кончились, приоритеты сместились или проект не взлетел, и неизвестно, вернутся ли к нему вообще. Решение принимается один раз, и оптимизировать процесс отключения до автоматизма нет смысла — овчинка не стоит выделки.

Сезонный проект — принципиально другая история. Здесь заранее известно, что цикл повторится: приёмная кампания начнётся в следующем июне, новогодние заказы пойдут в следующем ноябре, туристический сезон откроется в следующем мае. Дата следующего включения известна с точностью до недель уже в момент выключения. Это меняет экономику решения: если вы потратите день на то, чтобы записать и автоматизировать процесс, в следующем году вы сэкономите не день, а несколько дней — и так каждый год, пока проект жив.

Вывод простой: заморозку можно закрывать вручную и один раз подумать головой на месте. А сезонный цикл — ровно тот случай, когда стоит один раз спроектировать процесс правильно, задокументировать и автоматизировать, а не изобретать заново каждую весну или осень.

Регламент сезонного цикла: документ, а не память команды

Главная причина, по которой сезонное включение раз за разом проходит со скрипом — процесс живёт в голове одного человека: он помнит, что перед стартом нужно поднять дополнительных воркеров, обновить сертификат и предупредить провайдера почты о всплеске рассылок. Пока этот человек в проекте — всё более-менее работает. Как только он уходит в отпуск, меняет работу или забывает деталь через год — начинаются пожары в первую неделю сезона.

Решение — завести письменный регламент сезонного цикла, который не пересказывается по памяти, а читается. Если в проекте уже есть паспорт сервера — регламент сезонного цикла логично оформить как его дополнение: паспорт описывает сервер как он есть сейчас, а сезонный регламент — как его переводят из спящего состояния в боевое и обратно. Минимальный набор пунктов, которые должны быть в этом документе:

• Триггерные даты — не «в начале лета», а конкретный ориентир вроде «за три недели до 1 июня», привязанный к внешнему событию, а не к произвольной дате.
• Список того, что поднимается — все компоненты (сервер приложения, база, кэш, очередь задач, CDN, почтовый сервис) с версиями и параметрами, а не фразой «поднять как обычно».
• Внешние зависимости, которые могли протухнуть за простой — TLS-сертификаты, API-ключи с ограниченным сроком жизни, домены на грани истечения регистрации.
• Порядок действий по шагам — в идеале со ссылкой на скрипт или playbook, а не текстовым описанием «настроить нужные сервисы».
• Критерии готовности — список конкретных smoke-тестов, а не общее ощущение «вроде работает».
• Порядок выключения, зеркальный порядку включения: что останавливается, что архивируется, что остаётся в холодном хранении до следующего сезона.
• Контакты и ответственные на текущий сезон — люди меняются, и документ обновляется на входе в каждый цикл, а не живёт с контактами трёхлетней давности.

Держать этот документ стоит там же, где и остальную операционную документацию проекта — в репозитории рядом с кодом инфраструктуры (Git), а не в чате мессенджера, где через полгода это сообщение уже не найти.

Автоматизация цикла: скрипты вместо ручных операций

Документ описывает, что нужно сделать. Но каждое ручное действие — шанс на ошибку и лишнее время исполнителя, поэтому шаги, которые повторяются из года в год без изменений, стоит переводить в скрипты, а не выполнять руками каждый раз заново. Два сценария покрывают большинство сезонных проектов.

Сценарий 1: сервер остаётся, меняется только состав сервисов. Если между сезонами сервер не удаляется (например, тарифный план позволяет держать его в минимальной конфигурации круглый год), а меняется только набор запущенных контейнеров и их ресурсы — процесс сводится к двум docker-compose файлам или профилям:

# сезонный старт: поднимаем все сервисы, включая пиковые воркеры
docker compose --profile season -f docker-compose.yml -f docker-compose.season.yml up -d

# после сезона: возвращаемся к минимальному профилю
docker compose --profile off-season -f docker-compose.yml up -d
docker compose stop worker-peak worker-peak-2 worker-peak-3

Сценарий 2: инфраструктура разворачивается и сворачивается целиком. Если на межсезонье сервер целесообразно вообще не держать (это уже ближе к консервации, но триггер плановый, а не аварийный), процесс описывается через инструмент управления инфраструктурой как кодом — например, Terraform: terraform apply -var-file=season.tfvars перед сезоном и terraform destroy -target=module.season_workers -var-file=season.tfvars после.

Ключевой момент в обоих случаях — конфигурация сезонного состояния хранится в репозитории версионированным файлом (docker-compose.season.yml, season.tfvars), а не собирается руками из головы. Тогда «поднять как в прошлом году» превращается в git log и один запуск скрипта, а не в реконструкцию по памяти.

Дату запуска процесса стоит напоминать себе заранее, а не постфактум — простейший вариант — systemd-таймер или запись в cron с уведомлением ответственному, без автоматического запуска вслепую: сезонное включение не та операция, которую стоит доверять полностью без присмотра человека, особенно в первый год.

Тестирование за две-три недели до пика, а не в день старта

Самая частая ошибка сезонного проекта — поднимать инфраструктуру и проверять её работоспособность одновременно с приходом первого реального трафика: к этому моменту время на исправление проблем уже отрицательное, пользователи видят ошибки прямо сейчас.

Правильный порядок обратный: инфраструктура разворачивается за две-три недели до ожидаемого пика, чтобы оставить запас на то, что неизбежно пойдёт не так. За девять-десять месяцев простоя успевает устареть больше, чем кажется — стоит явно свериться с тем, что может протухнуть за время простоя (о том, как спланировать патчи так, чтобы они не свалились на голову в разгар сезона — правило двух недель для обновлений):

• Операционная система и пакеты. За межсезонье накапливается пакет патчей безопасности, часть из которых требует перезагрузки — разворачивать их нужно в тестовом окне, а не в первую неделю сезона, когда перезагрузка означает простой на боевом трафике.
• TLS-сертификаты и домены. Автопродление Let's Encrypt рассчитано на постоянно работающий сервер с cron-задачей; если сервер был выключен, сертификат мог не обновиться и истечь без предупреждения.
• Версии внешних API и зависимостей. Платёжный шлюз, картографический сервис, SMS-провайдер за несколько месяцев могли изменить формат ответа или требования к TLS — это проверяется только реальным тестовым запуском, а не чтением changelog.
• Данные и миграции. Изменения схемы базы или структуры файлов, накопленные между сезонами, накатываются на копии данных заранее, а не на боевой базе в момент первого наплыва пользователей.

Практический план тестового окна: поднять инфраструктуру по сезонному регламенту на отдельном контуре или на боевом до открытия сезона для пользователей; прогнать smoke-тесты — логин, ключевой сценарий (заказ, заявка, бронирование) от начала до конца, доставка писем, тестовые платежи; дать нагрузочный тест, приближенный именно к ожидаемому пику сезона, а не к обычной для проекта нагрузке; зафиксировать результат в том же документе, где живёт регламент — что прошло гладко, что потребовало вмешательства, сколько заняло по времени.

Три недели — не магическое число, а разумный минимум: неделя на обнаружение проблем, неделя на исправление и повторную проверку, неделя запаса на непредвиденное. Если сезон стартует резким скачком спроса, запас стоит увеличивать — обратный отсчёт в этом случае идёт не по календарю, а по факту первого всплеска трафика.

Масштабирование именно на сезон

Отдельная ошибка — либо держать инфраструктуру круглый год в конфигурации, рассчитанной на сезонный пик (переплата большую часть года), либо оставлять её в межсезонной конфигурации и надеяться, что она выдержит момент, когда трафик вырастет в разы. Обе крайности решаются одним приёмом: сезонное масштабирование — отдельный, спланированный заранее шаг, а не побочный эффект общей конфигурации сервера.

Прежде чем масштабироваться, стоит понять порядок величины разницы между фоновой и пиковой нагрузкой — это тот случай, когда цена простоя именно на пике считается иначе, чем цена простоя в обычный день (цена простоя на пике распродажи: сезонный множитель разбирает эту методику подробно). Практический пример такого разрыва между фоновым и сезонным трафиком — каталог питомника растений, где почти вся годовая выручка проходит за несколько весенних недель, а остальное время каталог живёт на минимальной нагрузке.

Практические варианты организации сезонного масштабирования:

• Вертикальное масштабирование на период сезона — держать минимальную конфигурацию весь год и переключаться на более мощный тариф на время сезона, если провайдер это позволяет без пересоздания сервера. Плюс — простота, минус — конечный потолок мощности одной машины.
• Горизонтальное масштабирование только на пиковые недели — дополнительные воркеры поднимаются перед сезоном и снимаются после, тот самый профиль --profile season или terraform apply с увеличенным числом реплик. Хорошо работает, когда узкое место — обработка запросов, а не единая база данных.
• Автомасштабирование внутри сезонного окна — если нагрузка нестабильна даже внутри сезона, автомасштабирование стоит включать именно на его период, а не круглый год, где оно просто не нужно и добавляет сложности без пользы.

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

После цикла: ретроспектива, которая делает систему лучше

Последний и чаще всего пропускаемый шаг — зафиксировать, что пошло не так, сразу после того, как сезон закончился и инфраструктура свёрнута. Пока детали свежи в памяти, разбор занимает двадцать минут; через полгода их придётся вспоминать заново — или наступать на те же грабли во второй раз.

Практический формат — короткая ретроспектива, добавляемая как раздел в тот же документ сезонного регламента, а не отдельным файлом, который потеряется:

Итоги сезона 2026

• Что сломалось: сертификат истёк за неделю до старта, автопродление

не сработало из-за выключенного cron в межсезонье.

• Что заняло больше времени, чем ожидалось: миграция базы —

вместо 20 минут заняла почти 3 часа из-за отсутствующего индекса.

• Что стоит изменить в регламенте: добавить пункт "проверить

автопродление сертификата" в чек-лист за 3 недели до старта.

• Что сработало хорошо и трогать не нужно: сценарий с

docker-compose.season.yml — поднялся с первого раза.

Три вещи стоит удерживать в фокусе: разделять симптом и причину («сайт лежал два часа» — симптом, «сертификат истёк, потому что cron был выключен вместе с сервером» — причина, которую можно исправить в регламенте); превращать каждый пункт в конкретное изменение процесса, а не общее пожелание («добавить проверку срока сертификата в скрипт тестирования», а не «быть внимательнее»); обновлять регламент сразу, пока команда помнит контекст, а не откладывать до следующего сезона.

За несколько циклов такой подход превращает сезонное включение из ежегодного стресса в рутинную операцию, где основные грабли собраны в первые один-два года, а дальше регламент только уточняется в мелочах — не единоразовая экономия времени, а сложный процент, который год от года снижает и трудозатраты, и риск ошибки в момент, когда цена этой ошибки максимальна.

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