MAATRIX / Блог / Проект на паузе, а счета идут: за что вы платите и что можно отключить сегодня

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

MAATRIX

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

Почему счета идут сами, даже когда проект стоит

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

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

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

Шаг 1. Составьте полный список — не только сервер

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

Соберите список по категориям — так проще не забыть половину:

  • Вычислительные ресурсы. Основной сервер, staging-окружение, тестовый стенд, отдельная машина под CI/CD, снапшоты и образы, за хранение которых часто берут отдельную плату сверх самого сервера.
  • Хранилища и бэкапы. Резервные копии баз данных, объектное хранилище для файлов пользователей, архивные снапшоты дисков — их легко забыть, потому что они не отвечают на запросы и никак не сигнализируют о себе.
  • Мониторинг и алертинг. Сервисы вроде Uptime-мониторов, систем сбора логов, дашбордов метрик — они продолжают опрашивать давно неактивные эндпоинты и слать отчёты, которые никто не читает.
  • Аналитика. Платные тарифы веб-аналитики, сервисы A/B-тестирования, инструменты для воронок — часто тарифицируются по числу отслеживаемых событий или сессий, которых у остановленного проекта давно ноль, но сам тариф не снижается автоматически.
  • Сторонние API. Платёжные шлюзы, SMS- и email-рассылки, геокодирование, распознавание, LLM-провайдеры — многие берут не только за использование, но и за факт подключённого аккаунта или минимальный ежемесячный платёж.
  • Домен и сертификаты. Регистрация домена, платный SSL, если он не автоматический через Let's Encrypt, DNS-хостинг у стороннего провайдера.
  • Вспомогательные SaaS-сервисы. Таск-трекер под команду проекта, канал уведомлений, CRM для лидов, которых больше не поступает — они редко ассоциируются с «инфраструктурой», но списываются с того же счёта.

Источники для сборки списка — банковская выписка за 6-12 месяцев (в ней видны все регулярные списания, включая то, что вы сами могли забыть), панели управления облачных провайдеров (там ресурсы видно даже без прямого списания, если тариф postpaid), и, отдельно, почта — просто найдите все письма с темой «invoice» или «receipt» за последний год. Пока список не полный, любая экономия будет только частичной: выключить два самых заметных сервиса и почувствовать облегчение — это не аудит, а иллюзия аудита.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать VPS

Шаг 3. Разделите список на «нельзя трогать» и «можно отключать»

После двух вопросов сортировка становится почти механической. Практика показывает, что типичный список из 10-15 позиций у остановленного проекта распадается примерно так: 2-4 позиции критичны, 3-5 — под вопросом и требуют одного уточняющего действия, а половина или больше — можно отключать сразу.

Critical must-stay — трогать нельзя:

  • Домен. Пока домен зарегистрирован на вас, репутация и история остаются вашими; истечёт регистрация — домен уйдёт в свободную продажу, и вернуть его будет либо дорого, либо невозможно.
  • Минимальное хранилище последнего рабочего бэкапа. Не весь архив снапшотов за два года, а именно последняя рабочая копия базы и конфигов — то, с чего можно поднять проект заново, если он оживёт. Экономика такого «спящего» состояния подробно разобрана в статье про минимальный ценник замороженного проекта: держать данные в архивном хранилище на порядок дешевле, чем платить за работающий сервер, который просто простаивает.
  • Сертификат или как минимум DNS-запись, если восстановление домена с нуля означает простой при следующем запуске дольше, чем вы готовы терпеть.
  • Юридически обязательные хранения — если для проекта есть требования по сроку хранения данных (бухгалтерские документы, договоры, персональные данные клиентов с активными обязательствами) — здесь решение диктует не техника, а закон.

Можно отключать без сожаления:

  • Staging и тестовые окружения, если разработка не ведётся — их пересоздание из репозитория занимает часы, а не дни.
  • Мониторинг и алертинг для неактивных эндпоинтов — оставьте разве что один простой uptime-чек на домен, если для вас важно узнать о его компрометации раньше, чем через полгода.
  • Платные тарифы аналитики — если событий нет, платить за тариф с лимитом в миллион событий бессмысленно; при необходимости легко подключить заново.
  • Сторонние API без активного трафика — особенно те, что берут минимальную ежемесячную плату за сам факт подключения.
  • Дополнительные учётные места в SaaS для людей, которые больше не работают над проектом — эта проблема настолько типична, что заслуживает отдельного разбора в статье про оплаченные, но не используемые места в подписках.
  • Резервные копии старше срока, который реально нужен — если для восстановления нужна последняя копия, а не архив за три года, лишние снапшоты просто занимают оплаченное место.

Психологическая ловушка: «руки не доходят»

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

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

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

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

Что конкретно экономит час аудита

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

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать VPS

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

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

С чего начать, если список подписок нигде не собран и в голове нет полной картины?

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

Как быть, если непонятно, за что конкретно списывается платёж — название в выписке ничего не говорит?

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

Что если не уверен, оживёт ли проект — не жалко ли будет потом жалеть об отключённом?

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

Стоит ли отключать сразу или сначала предупредить всех, кто мог пользоваться сервисом?

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

Нужно ли делать этот аудит регулярно, или разового прохода достаточно?

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

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →