Сверка списка сайтов с тем, за что вы платите каждый месяц

MAATRIX

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

Почему список сайтов и список платежей расходятся сами по себе

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

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

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

Два направления расхождения — и оба стоят денег

Расхождение между списком сайтов и списком платежей всегда идёт в одну из двух сторон, и они требуют разного внимания.

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

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

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

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

Список первый: все домены и сайты компании

Прежде чем сверять что-либо со счетами, нужен полный, актуальный список того, что реально существует. Не список из головы («ну у нас три сайта, кажется»), а список, собранный из проверяемых источников.

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

# Список доменов в аккаунте регистратора обычно доступен через
# личный кабинет или API — у большинства крупных регистраторов есть CLI/API,
# пример общей логики через whois для проверки статуса конкретного домена
whois example.com | grep -i "expir\|status"

# Если домены управляются через Cloudflare — список зон одной командой
curl -s -X GET "https://api.cloudflare.com/client/v4/zones" \
  -H "Authorization: Bearer $CF_API_TOKEN" | jq -r '.result[].name'

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

# nginx: список server_name из всех активных конфигов
grep -r "server_name" /etc/nginx/sites-enabled/ | awk '{print $2}' | sed 's/;//'

# Apache: аналогично через VirtualHost
grep -r "ServerName" /etc/apache2/sites-enabled/

# Если сайтов много и они на разных серверах — сверьте с DNS:
# какие A/CNAME записи вообще существуют в зоне
dig +short example.com A

Сведите оба источника в одну таблицу — простой список из четырёх колонок достаточен для начала:

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

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

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

Пройдитесь по каждому провайдеру и выпишите, за что именно идёт списание:

# Hetzner Cloud: список активных серверов с привязкой к тарифу
hcloud server list -o columns=id,name,type,status

# DigitalOcean: droplets и связанные с ними ресурсы
doctl compute droplet list --format ID,Name,Status,Region

# Отдельно проверьте домены с истекающей или продлеваемой регистрацией —
# у большинства регистраторов это отдельный раздел биллинга,
# не путайте с разделом самого хостинга

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

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

Само сопоставление: ищем расхождения в обе стороны

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

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

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

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

# Быстрая проверка: сайт реально отвечает?
curl -sI -o /dev/null -w "%{http_code}\n" https://old-project.example.com --max-time 5

# История DNS-записей домена — не всегда доступна бесплатно,
# но у большинства DNS-провайдеров есть журнал изменений зоны в панели

Как часто проводить сверку и кто за неё отвечает

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

Сигналы, что стоит сверяться чаще — например, раз в две недели хотя бы в облегчённом виде:

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

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

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

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