Как понять, что подрядчик завышает счёт за серверы и обслуживание

MAATRIX

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

Чем это отличается от завышения по часам

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

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

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

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

Избыточные мощности: платите за то, что не используете

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

Базовый набор команд для быстрой оценки:

# Средняя загрузка процессора за последние минуту/5 минут/15 минут
uptime

# Текущая загрузка CPU и памяти по процессам
top

# Использование оперативной памяти
free -h

# Использование дисков
df -h

# Использование диска и памяти внутри контейнеров, если инфраструктура на Docker
docker stats --no-stream

Если uptime месяцами показывает load average в разы ниже числа ядер, а free -h — постоянно больше половины памяти свободно, это повод спросить, почему тариф именно такой. Важная оговорка: низкая средняя загрузка сама по себе не доказывает переплату — это может быть осознанный запас на пиковую нагрузку или сезонность. Мы подробно разбирали, когда такой запас оправдан, а когда это просто забытая переплата, в статье «Средняя загрузка CPU 4%: сколько стоит ваш запас прочности». Здесь важно другое: сам факт запаса — не проблема, проблема — если подрядчик никогда не объяснял вам, зачем этот запас нужен именно в таком размере, и не пересматривал его по мере того, как реальная нагрузка становится понятна.

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

Задвоенные услуги: платите дважды за одно и то же

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

Типичные пары, которые стоит проверить в вашем счёте:

• Резервное копирование дважды. Провайдер хостинга часто включает снапшоты сервера в тариф или предлагает их за небольшую доплату, но в счёте отдельной строкой стоит ещё и «управляемый бэкап» от подрядчика — с похожей ценой. Спросите прямо: это разные механизмы (например, снапшот диска и логический дамп базы данных на отдельное хранилище) или буквально одна и та же услуга, оформленная как своя.
• Мониторинг дважды. На сервере может быть развёрнут собственный стек мониторинга (Zabbix, Prometheus с Grafana) — и параллельно оплачиваться внешний SaaS-сервис мониторинга с похожим функционалом. Иногда это оправдано (внешний мониторинг видит сервер снаружи, если он упал целиком), но чаще это просто забытая после миграции подписка.
• SSL-сертификат на платной основе, когда фактически используется бесплатный Let's Encrypt. Проверяется одной командой:

echo | openssl s_client -connect ваш-домен:443 -servername ваш-домен 2>/dev/null | openssl x509 -noout -issuer

Если в выводе issuer фигурирует Let's Encrypt (ISRG) или другой бесплатный центр сертификации, а в счёте стоит отдельная платная строка за «SSL-сертификат», — это прямой повод для разговора.

• Защита от DDoS и WAF дважды — на уровне провайдера (многие хостинги включают базовую защиту в тариф) и отдельно как платная услуга подрядчика поверх того же самого.
• Лицензии на ПО, которое давно заменено на open-source аналог — например, продолжающаяся оплата панели управления, от которой фактически отказались в пользу ручного администрирования или бесплатной альтернативы.

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

Устаревшие тарифы: цена, которая не пересматривалась годами

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

Как это проверить:

1. Узнайте у подрядчика точное название провайдера, у которого арендован сервер, и конкретный тарифный план (не просто «VPS», а конкретное название линейки и конфигурации).
2. Откройте актуальный публичный прайс-лист этого же провайдера на сайте и найдите эквивалентную по CPU/RAM/диску конфигурацию.
3. Сравните текущую рыночную цену с той суммой, которая указана в вашем счёте как «стоимость хостинга» (без учёта наценки подрядчика за администрирование — о ней отдельно ниже).

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

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

Апгрейды без обоснования

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

Прежде чем соглашаться на апгрейд, попросите подрядчика показать:

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

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

Как провести собственный аудит счёта: пошагово

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

1. Запросите построчный счёт за последние 3-6 месяцев с разбивкой по серверам и услугам, а не общей суммой. Посмотрите на динамику — растут ли отдельные строки, и если да, есть ли этому объяснение в переписке того периода.
2. Получите собственный доступ к панели управления хостинг-провайдером, если его до сих пор нет — не только к серверу по SSH, но и к личному кабинету, где видна фактическая история платежей провайдеру. Это разделяет «сколько вы платите подрядчику» и «сколько подрядчик платит провайдеру», и именно эта разница — источник наценки, которую стоит понимать.
3. Проверьте утилизацию ресурсов командами из раздела про избыточные мощности — на каждом сервере, который вы арендуете.
4. Пройдитесь по списку услуг на предмет дублирования — бэкапы, мониторинг, SSL, защита от DDoS, лицензии — по чек-листу из раздела выше.
5. Сравните тариф хостинга с актуальным прайсом провайдера за эквивалентную конфигурацию.
6. Зафиксируйте вопросы письменно и отправьте подрядчику одним списком, а не серией сообщений в течение недели — так проще получить последовательные ответы и сложнее уйти от неудобного пункта.

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

Как говорить с подрядчиком, если завышение подтвердилось

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

Несколько практических принципов:

• Приходите с конкретными цифрами, а не с общим недовольством. «Мне кажется, вы много берёте» — приглашение к спору о мнениях. «На сервере X загрузка CPU за три месяца не поднималась выше 12%, при этом мы платим за конфигурацию на 8 ядер — расскажите, чем обоснован такой запас» — конкретный вопрос, на который есть конкретный ответ.
• Разделяйте добросовестное объяснение и уклонение. Хороший подрядчик, столкнувшись с прямым вопросом, либо объясняет обоснование по существу, либо признаёт, что конфигурацию давно пора пересмотреть, и предлагает план. Плохой признак — раздражение на сам факт вопроса, смена темы или обещание «разберёмся» без конкретики и сроков.
• Договоритесь о формате отчётности на будущее, а не только разбирайте прошлое. Попросите ежемесячный построчный счёт с разбивкой на стоимость ресурсов и стоимость обслуживания — это снимает необходимость проводить такой аудит вручную каждый раз.
• Если доверие уже подорвано системно, а не в рамках одного недопонимания, стоит заранее понимать, как выглядит процесс смены подрядчика без простоя и что нужно успеть забрать до разрыва отношений — это отдельно разобрано в статье «Меняем подрядчика: как забрать инфраструктуру».

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

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