Антипаттерн: брать сервер «с запасом на три года вперёд»

MAATRIX

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

Как это выглядит на практике

Сценарий почти всегда один и тот же. Проект запускается, нагрузка небольшая — условно, 2 CPU и 4 GB RAM с запасом закрывают текущие потребности. Но вместо того чтобы взять именно это, команда (или админ, который «отвечает за инфраструктуру») берёт конфигурацию на 8 CPU и 32 GB RAM — «чтобы через год-два не пришлось переезжать, когда трафик вырастет в десять раз».

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

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

Проблема №1: переплата за простой ресурсов месяцами и годами

Самое прямое следствие — вы платите за мощность, которая физически не используется. Если реальная нагрузка утилизирует 20-25% CPU и памяти, а оплачивается конфигурация под 100% какой-то гипотетической нагрузки через три года, то в среднем 75-80% ресурсов всё это время простаивают, но счёт выставляется за все 100%.

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

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

# средняя загрузка CPU за последние сутки (Ubuntu/Debian с sysstat)
sar -u 1 1 | tail -1

# пиковая и средняя память за неделю
free -h
vmstat 1 5

# если есть Prometheus/Grafana — смотрим p95 по cpu_usage и memory_usage
# за 2-4 недели, а не пиковый момент нагрузочного теста

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

Проблема №2: прогноз роста на три года — это гадание, а не расчёт

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

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

Ключевая проблема прогноза на три года — не в том, что он может ошибиться в цифрах (это нормально, ошибаются все), а в том, что он вообще не может учесть изменение направления. Запас мощности решает задачу «нагрузка будет расти по той же кривой», но ничего не может сделать, если через полгода выяснится, что нужен не более мощный CPU, а больше дискового I/O под аналитику, или GPU под инференс модели, или наоборот — вообще не нужен собственный сервер, потому что продукт свернули.

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

Проблема №3: деньги, замороженные сейчас, имеют цену возможности

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

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

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

Почему гибкость VPS и облака снимает саму причину для запаса

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

Практическая последовательность апгрейда VPS обычно выглядит так:

# 1. смотрим, во что реально упирается нагрузка сейчас
htop
iostat -dx 2 5
free -h

# 2. если упор в CPU/RAM — апгрейд тарифа в панели провайдера,
#    для большинства VPS это минуты простоя на перезагрузку,
#    а не часы на миграцию

# 3. если нужен рост диска без даунтайма — расширение LVM-раздела
#    после увеличения виртуального диска в панели
lsblk
growpart /dev/vda 1
resize2fs /dev/vda1   # для ext4
# или xfs_growfs /  — для xfs

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

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

Как считать правильно: текущая нагрузка плюс разумный буфер

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

1. Измерьте текущую нагрузку за представительный период — минимум 2-4 недели, включая пиковые дни (не только средний рабочий день, но и, например, распродажу или конец месяца, если для бизнеса это релевантно).
2. Возьмите пиковую (не среднюю) утилизацию как базу — если p95 по CPU за месяц составляет 60%, а не средние 20%, ориентируйтесь на 60%.
3. Добавьте буфер 30-50% сверх пика, а не кратный запас в 3-4 раза. Такой буфер закрывает органический рост на ближайшие месяцы и разовые скачки нагрузки, но не превращается в постоянно простаивающие ресурсы.
4. Зафиксируйте триггер для следующего апгрейда заранее — конкретную метрику и порог, например «при устойчивой утилизации CPU выше 70% в течение недели — заказываем апгрейд тарифа», а не «когда заметим, что тормозит».
5. Проверяйте соответствие конфигурации нагрузке раз в квартал, а не «пока само не сломается» — 15 минут на просмотр графиков раз в три месяца дешевле, чем полгода переплаты за неверно оценённый запас.

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

Когда запас всё же оправдан

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

• Известный контракт или обязательство с конкретной датой роста — например, подписан договор на подключение определённого числа пользователей к конкретной дате. Здесь запас — не гадание, а расчёт под подтверждённое событие.
• Дефицит оборудования или длинные сроки поставки — если конкретная конфигурация железа (например, определённые GPU) физически трудно достать, и следующая партия придёт через полгода, разумно взять с запасом сейчас, пока есть возможность.
• Стоимость простоя при миграции для конкретного сервиса аномально высока — например, для системы, где даже плановое окно обслуживания в несколько минут означает финансовые потери или нарушение SLA с жёсткими штрафами.
• Разница в цене между конфигурациями минимальна — если шаг между тарифами провайдера крошечный (условно, разница между «средним» и «следующим» планом не принципиальна для бюджета), спор о трёхкратном запасе теряет смысл — переплата в таком случае несущественна.

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

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