Ежегодный пересмотр расходов на инфраструктуру: где деньги уходят в никуда

MAATRIX

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

Почему это отдельная процедура, а не часть общего техосмотра

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

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

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

Инвентаризация: без полного списка эта работа бессмысленна

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

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

Для получения списка ресурсов у конкретного провайдера почти всегда есть CLI, который выводит больше, чем видно на первом экране панели:

# Hetzner Cloud: серверы, диски, зарезервированные IP
hcloud server list
hcloud volume list
hcloud floating-ip list

# AWS: неприкреплённые диски и статические IP без привязки
aws ec2 describe-volumes --filters Name=status,Values=available
aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"

# DigitalOcean
doctl compute droplet list
doctl compute volume list
doctl compute reserved-ip list

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

Сопоставляем цену с реальной загрузкой

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

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

# Средняя и пиковая загрузка CPU
vmstat 1 10
sar -u 1 10

# Память: реально используется, а не просто выделена
free -m

# Диск: заполненность и очередь I/O
df -h
iostat -x 1 5

Если стоит Zabbix, Prometheus/Grafana или графики из панели провайдера — используйте историю оттуда, ручной снимок точнее для серверов без мониторинга. Дальше — простое сопоставление стоимости тарифа и того, что сервер реально потребляет:

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

Ищем полностью забытые, но всё ещё оплачиваемые ресурсы

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

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

Простая проверка по каждому подозрительному ресурсу — если на все три вопроса подряд ответ «нет», это кандидат на отключение:

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

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

# Есть реальный трафик к сервису за месяц?
tail -n 100000 /var/log/nginx/access.log | awk '{print $1}' | sort -u | wc -l

Перед удалением безопаснее сначала выключить ресурс и понаблюдать одну-две недели, чем удалять сразу: если за это время никто не написал «а почему упал сервис», диск и сам сервер можно сносить с уверенностью.

Пересматриваем тарифы и оцениваем консолидацию

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

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

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

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

Сколько реально удаётся сэкономить

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

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

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