Проект умер, а серверы живы: как найти и выключить забытые машины

MAATRIX

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

Почему после смерти проекта серверы остаются живы

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

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

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

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

Шаг 1. Пройдите по всем провайдерам систематически — не по памяти

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

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

• Банковская или карточная выписка за 12-24 месяца. Отсортируйте по получателю платежа и найдите регулярные списания, связанные с хостингом, облаком, доменами, CDN, мониторингом. Регулярность — главный маркер: повторяющийся раз в месяц или раз в год платёж почти всегда означает активную подписку на ресурс.
• Почта — поиск по ключевым словам. «Invoice», «receipt», «payment successful», «your subscription», названия крупных облачных провайдеров и хостеров. Год-два переписки с биллинговыми системами дают список полнее, чем то, что вы держите в голове.
• Список активных проектов у каждого используемого провайдера. Если команда когда-либо работала с несколькими облаками или хостерами — для проекта, жившего несколько лет, это правило, а не исключение — зайдите в панель каждого по отдельности. Не полагайтесь на то, что «основной» провайдер покажет всё: у AWS, DigitalOcean, Hetzner, Vultr — свой отдельный список ресурсов, не виден из панели другого.
• Менеджер паролей и список сохранённых сессий в браузере. Часто единственное место, где остались логины от аккаунтов, о которых уже никто не помнит явно — доступ в панель сохранился, а факт существования аккаунта из памяти выпал.

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

Шаг 2. Проверьте панели управления на инстансы без привязки к проекту

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

В панели каждого облачного или VPS-провайдера ищите:

• Список всех виртуальных машин / инстансов, а не только тех, что помечены как «активные» в вашем понимании — статус в панели почти всегда «running» независимо от того, нужна ли машина кому-то.
• Теги и названия. Машины с именами вроде test, staging-old, tmp, poc, demo-2024, или с именем закрытого проекта — первые кандидаты. Но не останавливайтесь на подозрительных именах: часть забытых машин носит нейтральные имена, оставшиеся от шаблона при создании.
• Дату создания и последнего изменения конфигурации. Машина, созданная два года назад и с тех пор не менявшаяся — надёжный признак, что её никто не администрирует активно.
• Сетевой трафик и загрузку CPU за последние 30-90 дней. Машина с постоянно нулевым трафиком и загрузкой в единицы процентов почти наверняка не обслуживает реальный сервис.
• Привязанные диски, снапшоты и статические IP отдельно от машин. Даже если саму виртуалку удалили, диск или снапшот от неё нередко остаётся и тарифицируется отдельной строкой — такие «осиротевшие» ресурсы легко упустить.

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

Шаг 3. Ищите по DNS и старым доменам — там всплывают IP, о которых вы забыли

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

Порядок проверки:

• Пройдитесь по DNS-зонам всех доменов, когда-либо связанных с проектом. Не только основной домен, но и второстепенные, купленные «про запас», поддомены отделов, поддомены для отдельных фич. Команда dig быстро покажет все A/AAAA-записи для конкретного имени:

dig +short staging.example.com A
dig +short old-api.example.com A
dig +short test.example.com A

• Если доступа к панели DNS-регистратора нет, а IP всё же нужен, поможет обратный DNS и открытые базы сертификатов — например, Certificate Transparency logs (crt.sh) покажут, какие поддомены когда-либо выпускали SSL-сертификат для домена, даже те, о которых вы забыли:

curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

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

• Для каждого найденного A-записью IP проверьте, отвечает ли он вообще — простой curl или nc покажут, жив ли сервер физически:

curl -sI --max-time 5 http://<IP>
nc -zv <IP> 22 80 443

Если IP не отвечает — либо сервер давно выключен другим способом и осталась мусорная DNS-запись (её тоже стоит убрать — висящая запись на несуществующий IP это риск subdomain takeover, если IP позже займёт кто-то другой), либо сервер жив, но закрыт файрволом, и тогда его придётся искать напрямую в панели провайдера по адресу.

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

Психологический аспект: почему выключение откладывается даже после того, как машину нашли

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

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

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

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

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

Типичные скрытые зависимости, которые легко упустить:

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

Практический порядок проверки перед окончательным отключением:

1. Соберите логи доступа (веб-сервер, файрвол, API-гейтвей) минимум за последние 2-4 недели — не полагайтесь на «интуитивно кажется, что трафика нет».
2. Проверьте исходящие соединения с сервера — cron, вебхуки, синхронизации, — не только входящие запросы к нему.
3. При хоть какой-то активности сначала «притормозите» сервис мягко: закройте порт файрволом на несколько дней, оставив сервер включённым, и посмотрите, кто отреагирует. Жёсткое выключение сразу не даёт шанса откатиться.
4. Только когда логи чисты и мягкая остановка не вызвала жалоб — переходите к финальному шагу.

Финальный шаг: бэкап перед выключением, а не после

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

Минимальный набор для финального бэкапа перед выключением:

# дамп базы данных
pg_dump -Fc dbname > project_final_backup_$(date +%Y%m%d).dump

# архив файлов и конфигов
tar czf project_files_$(date +%Y%m%d).tar.gz /var/www /etc/nginx/sites-available /opt/app/config

# список установленного, на случай если понадобится восстановить окружение
dpkg -l > installed_packages.txt
docker images --format '{{.Repository}}:{{.Tag}}' > docker_images.txt

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

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

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

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