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

MAATRIX

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

Два сценария: держать всё год или сворачивать по сезону

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

Сценарий A — круглогодичный боевой тариф. Сервер работает весь год в той же конфигурации, что и на пике сезона. Ничего не меняется, ничего не нужно переключать, риск сломать что-то при повторном развёртывании отсутствует в принципе — сервер просто никогда не выключался. Цена этой простоты — восемь месяцев переплаты за мощность, которая в межсезонье не используется даже наполовину.

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

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

Почему сезонный бизнес — не то же самое, что замороженный проект

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

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

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

Что происходит с данными в межсезонье

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

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

Если сервер сворачивается полностью, данные требуют явного плана на восемь месяцев простоя:

# 1. Дамп базы данных и архивация пользовательских файлов перед остановкой сервера
pg_dump shop_db | zstd -19 -o shop-db-pre-season-close.sql.zst
tar -I 'zstd -19' -cf uploads-pre-season-close.tar.zst /var/www/shop/uploads

# 2. Проверка целостности архива ДО того, как сервер исчезнет
zstd -t shop-db-pre-season-close.sql.zst
sha256sum shop-db-pre-season-close.sql.zst uploads-pre-season-close.tar.zst > checksums.sha256

# 3. Загрузка в недорогое объектное хранилище отдельно от самого сервера
aws s3 cp shop-db-pre-season-close.sql.zst s3://seasonal-archive/ --storage-class GLACIER

Три вещи, о которых легко забыть именно в контексте сезонного бизнеса:

• Каталог и цены меняются даже в межсезонье. Пока сервер выключен, поставщик может изменить ассортимент или закупочные цены — если архив снят в январе, а разворачивается в сентябре, часть данных о товарах успевает устареть. Это бизнес-задача, а не техническая: свериться с каталогом перед разворачиванием, а не полагаться на архив как на актуальный источник.
• Обращения клиентов после закрытия сезона не должны теряться. Если форма обратной связи или почта поддержки жили на том же сервере, который вы удаляете, заранее решите, куда будут приходить редкие обращения в межсезонье — отдельный лёгкий адрес или форма на статической странице, не зависящей от основного сервера.
• Архив без описания — это просто набор байтов через восемь месяцев. Минимальный README рядом с архивом (версия схемы БД, дата, что именно заархивировано) экономит часы при разворачивании — второпях перед закрытием сезона его легко пропустить.

Домен, TLS и почта: то, что живёт отдельно от сервера

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

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

TLS-сертификат. Здесь есть техническая тонкость, которая экономит нервы при полном сворачивании сервера. Автопродление Let's Encrypt через HTTP-01 challenge требует, чтобы веб-сервер отвечал на запросы в момент продления — если сервера физически нет, продление просто не произойдёт, и сертификат тихо истечёт где-то в межсезонье. Решение — DNS-01 challenge: подтверждение владения доменом происходит через TXT-запись в DNS, а не через ответ живого сервера, и продлить сертификат можно даже без поднятой инфраструктуры, если DNS-провайдер поддерживает API для автоматической записи TXT-записей. Если такой возможности нет, проще заложить получение свежего сертификата в сам процесс развёртывания перед сезоном, а не полагаться на автопродление во время простоя.

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

Расчёт экономики: пример на условных цифрах

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

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

В этом иллюстративном примере вариант B экономит около трети относительно круглогодичного тарифа, а вариант C — почти половину, но за счёт статьи расходов, которая не видна в счёте провайдера: рабочего времени на разворачивание и сворачивание. Именно эта статья определяет реальную экономику для конкретного бизнеса, и её легко недооценить, если считать только счета от хостинга.

Что важно учесть, подставляя свои цифры:

• Экономия варианта B зависит от того, насколько сильно можно понизить тариф без потери функциональности — реальный процент обычно в диапазоне тридцати-шестидесяти процентов и сильно зависит от тарифной линейки конкретного провайдера.
• Затраты на переключение в первый год выше, чем в последующие. Если процесса ещё нет, первое сворачивание и первое разворачивание съедят заметно больше времени, чем показано в примере — на написание регламента, скриптов и отладку процесса на живом опыте. Экономика автоматизации окупается начиная со второго цикла, а не с первого.
• Риск простоя на старте сезона стоит считать отдельной строкой, а не игнорировать. Если разворачивание перед сезоном пойдёт не по плану и магазин откроется на два-три дня позже запланированного, цена этого простоя может быть выше, чем накопленная за год экономия. Методику расчёта цены часа простоя именно на пике, а не в среднем по году, разбирали отдельно в статье про сезонный множитель цены простоя — тот же принцип применим к риску срыва даты открытия сезона.

Как выбрать вариант: критерии, а не ощущение

Универсального правильного ответа нет — есть набор вопросов, ответы на которые сдвигают выбор в ту или другую сторону.

• Нужен ли доступ к серверу в межсезонье хоть изредка? Если администратору или поддержке нужно иногда заходить в панель, проверять заказы, отвечать на редкие письма — вариант C добавляет трение на каждое такое обращение. Если доступ не нужен вообще, экономия варианта C становится более убедительной.
• Насколько предсказуема дата открытия сезона? Если сезон стартует по жёсткому календарю, разворачивание можно спланировать заранее с запасом на исправление проблем. Если старт зависит от внешних факторов с меньшей предсказуемостью, запас на тестирование стоит увеличивать, а вариант с круглогодичным сервером (A) снижает саму необходимость в этом запасе.
• Есть ли в команде опыт надёжной автоматизации разворачивания? Вариант C выгоден только тогда, когда разворачивание действительно воспроизводимо — по скрипту, а не по памяти. Если такого опыта пока нет, а строить его ради экономии в несколько тысяч рублей в месяц нецелесообразно, разумнее остаться на варианте A или B.
• Насколько велика разница между активной и минимальной конфигурацией? Если боевая конфигурация в разы мощнее минимальной, экономия от понижения тарифа или полного сворачивания заметна в деньгах. Если разница небольшая, она может не окупить риск и трудозатраты на переключение.
• Что происходит с IP-адресом при развороте заново? При удалении сервера и создании нового адрес почти всегда меняется — DNS-записи, белые списки партнёров и интеграции придётся обновлять каждый цикл. Если таких зависимостей много, это аргумент в пользу варианта B (сервер не удаляется, адрес сохраняется) вместо варианта C.

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