Вывод сервиса из эксплуатации: чтобы через год он не всплыл в счёте

MAATRIX

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

Почему «выключили» не значит «вывели из эксплуатации»

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

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

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

Инвентаризация: соберите полный список, прежде чем трогать хоть что-то

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

Собирайте инвентаризацию по источникам, а не по памяти:

• Инфраструктура как код / панель провайдера. Пройдитесь по всем серверам, VPS и контейнерам в аккаунте провайдера — не по тем, что «вроде помните», а по полному списку в панели. Отдельно выпишите выделенные серверы: их часто заводят под один тяжёлый проект и потом забывают, что он давно не тяжёлый, а мёртвый.
• DNS-зона. Откройте зону домена целиком и посмотрите на все A/AAAA/CNAME записи, а не только на основную. Тестовые поддомены, staging-окружения, старые версии API часто живут годами именно потому, что их не видно на главной странице. Похожая история разобрана в статье про забытый поддомен со сломанной CMS — те же поддомены, которые не удалили при выводе сервиса, потом становятся точкой входа для атаки.
• Базы данных. Отдельные инстансы, managed-базы, реплики для аналитики. Если база была managed-услугой у облачного провайдера — это отдельная строка в счёте, которая не исчезает при остановке приложения.
• Платные интеграции и SaaS. Почтовые шлюзы, SMS, платёжные провайдеры, системы мониторинга, CDN, лицензии на ПО, привязанные к проекту. Проверяйте не только «активные» подписки, но и те, что переведены в бесплатный тариф — они тоже иногда содержат скрытые лимиты, за превышение которых включается оплата.
• Домены и сертификаты. Домен сам по себе — это годовая подписка, которая продлевается независимо от того, работает ли сайт. Проверьте автопродление в панели регистратора отдельно от всего остального.
• Учётные записи и API-ключи. Отдельные сервисные аккаунты (например, у облачного провайдера для CI/CD) могут иметь собственную тарификацию за хранение логов или трафик, даже если основное приложение уже не работает.

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

Пример реальной инвентаризации

Для наглядности — как может выглядеть список для среднего внутреннего сервиса (например, закрытый MVP или отработавшая маркетинговая акция):

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

Поэтапное отключение вместо мгновенного удаления

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

Правильная последовательность — поэтапное отключение с периодом наблюдения между шагами:

1. Остановите, не удаляйте. Первым шагом остановите сервисы (docker compose stop, а не down -v; выключение VPS, а не его удаление), закройте внешний доступ на файрволе, отключите интеграции на уровне API-ключей (отозвать ключ проще и обратимее, чем удалить аккаунт). Ничего физически не удаляется — просто перестаёт отвечать на запросы.
2. Наблюдайте 2–4 недели. Это ключевой этап, который чаще всего пропускают. За этот период проверьте логи файрвола и веб-сервера на входящие запросы к остановленным адресам, посмотрите, не приходят ли алерты о недоступности от систем, которые вы не учли, спросите смежные команды напрямую — «кто-то ещё использует X?». Если за это время ничего не сломалось и никто не хватился — можно двигаться дальше.
3. Снимите бэкап перед необратимыми действиями. Даже если сервис точно не нужен, финальный дамп базы данных и архив файлового хранилища стоит сохранить в холодном хранилище на разумный срок (например, 90 дней). Это дешевле, чем поднимать всё заново, если через месяц выяснится, что данные всё же нужны для отчётности или разбирательства.
4. Удаляйте по одному ресурсу, с паузой. Сначала одна категория ресурсов, проверка, что всё по-прежнему в порядке, потом следующая. Домены удаляйте или переводите в статус «не продлевать» отдельным, последним шагом — обратно домен восстановить сложнее и дороже всего остального в списке.
5. Фиксируйте каждый шаг в том же тикете. Дата остановки, дата удаления, кто подтвердил, что ресурс точно не нужен. Через полгода, когда кто-то спросит «а где делся сервер X», у вас будет ответ за тридцать секунд, а не новое расследование.

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

Технические команды: что реально проверить перед отключением

Чек-лист — это хорошо, но проверка должна опираться на факты, а не на память. Несколько конкретных команд и мест, куда стоит заглянуть.

Активные подключения к базе данных перед её остановкой (PostgreSQL):

SELECT datname, usename, client_addr, state, query_start
FROM pg_stat_activity
WHERE datname = 'project_mvp_db'
ORDER BY query_start DESC;

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

Проверка, какие DNS-записи реально существуют в зоне (полезно свериться с тем, что вы вспомнили в инвентаризации):

dig +noall +answer project-mvp.example ANY
dig +noall +answer api.project-mvp.example A

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

ss -tulnp

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

Проверка последних запросов к веб-серверу за период наблюдения — если после остановки приложения продолжают идти обращения, это может быть бот, а может быть забытый клиент API:

awk '{print $1, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30

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

crontab -l
systemctl list-timers --all

Финальная проверка: нигде больше не идут платежи

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

Порядок действий:

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

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

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