Проект заморозили на год: что выключить, а что обязано остаться включённым

MAATRIX

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

Что реально экономит заморозка, а что нет

Прежде чем нажимать кнопки выключения, стоит понять структуру расходов проекта. Обычно она делится на две неравные части.

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

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

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

Отключаем: вычислительные ресурсы и живой трафик

Это самая понятная часть, но и здесь есть нюансы, которые стоят реальных денег.

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

# снять итоговый бэкап перед остановкой — обязательно, не после
docker compose down
systemctl stop nginx

Дальше — развилка, которую многие упускают: просто выключенный сервер и уничтоженный (terminated) — разные вещи для счёта. У большинства провайдеров VPS «выключенный» (stopped) инстанс продолжает занимать выделенные диск и IP, и вы платите почти полную цену — экономится обычно только процессорное время. Чтобы реально сэкономить, нужно:

1. Снять финальный снапшот диска или полный бэкап данных.
2. Выгрузить снапшот или архив в дешёвое объектное хранилище (оно стоит на порядок меньше, чем блочный диск активного сервера).
3. Уничтожить сам инстанс — освободить и диск, и выделенный IP.

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

База данных. Managed-БД (PostgreSQL, MySQL, Redis, Elasticsearch как сервис) отключается по тому же принципу: снять дамп, положить в хранилище, снести инстанс. Держать managed-базу «просто на паузе» ради удобства — самая дорогая иллюзия экономии в этом списке, потому что тарификация managed-БД обычно завязана на выделенные CPU/RAM вне зависимости от реальной нагрузки.

CDN и балансировщики с фиксированной платой. Если CDN, WAF или балансировщик оплачивались абонентской платой (а не только за трафик), их стоит отключить или понизить до бесплатного тарифа — трафика без работающего сайта всё равно не будет.

Отключаем: managed-услуги и лишние окружения

Вторая категория — сервисы, которые были нужны не для хранения актива, а для процесса разработки и эксплуатации живого продукта.

Staging и тестовые окружения. Почти всегда это первая цель для отключения, и это правильно: staging существует для тестирования изменений перед продакшеном, а если изменений не будет год, тестировать нечего. Снимите с него финальный дамп конфигурации (docker-compose файлы, .env без секретов в открытом виде, схему БД) в архив — пригодится при возобновлении — и удалите сам сервер целиком. Держать staging «на всякий случай» весь год — это платить полную цену VPS ради нуля пользы.

Мониторинг и APM-подписки. Datadog, платный тариф Sentry, New Relic и подобные сервисы обычно тарифицируются по объёму событий или числу хостов. Без работающего продакшена метрик и ошибок не будет — переводите на бесплатный тариф или отменяйте подписку полностью, оставляя только базовый аптайм-мониторинг для того, что осталось включённым (см. следующий раздел).

CI/CD раннеры и билд-агенты. Если сборки не идут, платные раннеры (в облаке или self-hosted VPS под CI) можно выключить полностью — конфигурация пайплайна (.gitlab-ci.yml, .github/workflows/*) хранится в самом репозитории и никуда не денется.

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

Таблица ниже — ориентир, что обычно можно смело гасить, а что требует индивидуальной оценки:

Домен: почему это неприкосновенный актив

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

При заморозке на год домен должен оставаться:

• Зарегистрированным и оплаченным вперёд. Если есть уверенность в сроке заморозки — год, — разумно продлить регистрацию сразу на этот период или на два, чтобы не зависеть от списания карты в процессе. Многие регистраторы позволяют продлевать на несколько лет вперёд одной операцией.
• С включённым автопродлением и актуальной картой на регистраторе. Замороженный проект — не тот случай, где стоит полагаться на ручное продление раз в год: именно за время паузы про такие вещи забывают быстрее всего.
• С сохранённым WHOIS-доступом и контактным email, который вы реально проверяете (см. следующий раздел) — регистратор присылает уведомления о продлении именно туда.
• Залоченным (registrar lock), если такая опция включена — это отдельная защита от угона домена, не связанная напрямую с продлением, но тоже критичная на длительный необслуживаемый период.

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

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

Что ещё должно остаться: почта, DNS, SSL и бэкапы

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

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

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

• Финальный полный бэкап снимается перед, а не после отключения основных серверов.
• Бэкап переносится в отдельное объектное или архивное хранилище — не остаётся на том же сервере, который потом уничтожается (это частая и фатальная ошибка).
• Хранилище остаётся оплаченным на весь срок заморозки без перерывов.
• Раз в несколько месяцев — а не только в момент возобновления — стоит выполнять тестовое восстановление или хотя бы проверку контрольных сумм, потому что архив, который никто не трогал год, может незаметно испортиться, а обнаружится это обычно в худший момент. Это подробно разобрано в статье про холодный архив, который не трогали три года.

SSL-сертификаты. Здесь у многих ложное ожидание: кажется, что нужно «продлевать» сертификат весь год простоя. На практике для Let's Encrypt и аналогичных бесплатных ACME-сертификатов это не так — они выпускаются на 90 дней, и продлевать неиспользуемый сертификат бессмысленно: он всё равно истечёт до возобновления. Важен не файл сертификата, а сохранённый контроль над доменом и DNS-зоной: если он на месте, повторный выпуск при запуске занимает минуты и полностью автоматизируется через тот же ACME-протокол. Исключение — платный коммерческий или EV-сертификат с длительным сроком: тут стоит посчитать, дешевле ли доплатить за оставшийся срок или заново пройти бесплатный выпуск при перезапуске. Для большинства проектов на VPS выгоднее второй вариант.

Экономика заморозки: считаем по цифрам, а не на глаз

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

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

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

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

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