Сколько стоит держать сайт, который никто не смотрит

MAATRIX

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

Как заводится «зомби-сайт»

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

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

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

Прямые расходы: небольшая сумма, умноженная на годы

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

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

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

Здесь же стоит учитывать не только счета за сервер, но и smtp-релеи, лицензии на закрытое ПО, платные плагины CMS с автопродлением, сторонние API с почасовой или помесячной тарификацией — всё это тоже продолжает списываться с карты, даже если сайт не открывали полгода.

Скрытая цена: заброшенный сервер как точка входа

Это самая недооценённая часть уравнения. Сайт, который никто не смотрит, — это не нейтральный «спящий» актив. Это сервер, на котором:

• давно не обновлялась операционная система и её пакеты;
• крутится CMS или фреймворк старой версии с известными к текущему моменту уязвимостями;
• никто не проверяет логи, не следит за подозрительной активностью, не получает алерты;
• часто остались открытыми порты и сервисы, нужные когда-то для отладки, а теперь просто забытые.

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

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

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

Скрытая цена номер два: время, которое утекает на неопределённость

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

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

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

Методика: регулярный аудит запущенных проектов

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

Шаг 1. Составьте полный список. Все VPS, выделенные серверы, домены, поддомены и облачные сервисы, за которые списываются деньги. Источники — панель хостинг-провайдера, история платежей по карте, DNS-зона основного домена (поддомены часто выдают забытые проекты, о которых уже никто не помнит).

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

# Быстрая проверка активности на nginx: уникальные IP за последние 30 дней
awk '{print $1}' /var/log/nginx/access.log | sort -u | wc -l

# Дата последнего запроса вообще (если лог не ротировался месяцами — это красноречиво само по себе)
tail -1 /var/log/nginx/access.log

Шаг 3. Разложите проекты по трём категориям.

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

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

Что делать с тем, что нужно сохранить, но не должно работать

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

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

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

1. Снять полный снимок сайта как набор статических html-страниц. Для многих CMS есть готовые инструменты экспорта в статику; универсальный вариант — рекурсивно скачать сайт локальным краулером:

wget --mirror --convert-links --adjust-extension \
     --page-requisites --no-parent \
     https://old-project.example.com

1. Проверить, что все внутренние ссылки, изображения и css/js подтянулись локально, поправить то, что осталось битым.

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

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

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

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

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

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