Ежемесячная сверка счёта хостера с тем, что у вас реально работает

MAATRIX

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

Зачем сверять счёт каждый месяц, а не раз в год

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

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

Есть два симметричных сценария, которые ловит эта сверка, и оба одинаково реальны:

• Платите за то, что давно не используется. Тестовый сервер подняли под спринт и забыли выключить после релиза. Сотрудник, который завёл отдельный VPS под свой проект, уволился три месяца назад. Резервный IP зарезервировали под миграцию, которая случилась и закончилась.
• Используете больше, чем предусматривает тариф. Трафик вырос втрое из-за нового источника нагрузки, и вы платите за перерасход сверх лимита каждый месяц, хотя апгрейд тарифа с большим включённым трафиком обошёлся бы дешевле. База данных разрослась и упирается в диск, для которого приходится докупать место отдельными платными блоками вместо перехода на план с большим хранилищем изначально.

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

Два списка, которые нужны для сверки

Сверка построена на сопоставлении двух источников, и оба должны быть актуальными на момент проверки, а не месячной давности.

Список первый — счёт от провайдера. Не итоговая сумма, а детализация по позициям: раздел billing/invoices в панели, а не письмо с одной цифрой. У большинства хостеров детализация доступна либо в веб-панели, либо через API/CLI:

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

# DigitalOcean: то же самое одной командой на категорию
doctl compute droplet list --format ID,Name,Status,Memory,Disk
doctl compute volume list --format ID,Name,SizeGigaBytes,DropletIDs

# AWS: отдельно ищем то, что тарифицируется, но ни к чему не привязано
aws ec2 describe-volumes --filters Name=status,Values=available
aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"

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

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

# Кто-то заходил на сервер за последний месяц?
last -n 30

# Есть активные подключения помимо системных проверок мониторинга?
ss -tn state established | wc -l

# Реальный трафик к сервису за последние недели
tail -n 50000 /var/log/nginx/access.log | awk '{print $1}' | sort -u | wc -l

# Когда последний раз менялись файлы проекта
find /var/www -maxdepth 2 -mtime -30

Если в компании уже есть учёт ресурсов — CMDB, таблица в Notion, теги в облачной панели с владельцем каждого сервера, — используйте его вместо ручного обхода, а не собирайте список заново каждый раз.

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

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

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

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

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

Найденные при сверке отклонения делятся на две группы с разными действиями, и путать их не стоит.

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

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

Текущий перерасход по трафику: +40% к включённому лимиту,
цена за перерасход: $0.01/GB сверх лимита
→ за месяц: ~800GB перерасхода × $0.01 = $8/мес переплаты за перерасход

План на ступень выше: +$5/мес к базовой цене,
включённый трафик покрывает текущее потребление с запасом
→ экономия ~$3/мес и запас на дальнейший рост

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

Периодичность: ежемесячно, ежеквартально или чаще

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

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

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

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

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

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

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