В какой момент проект дорастает до собственного железа: считаем по трём метрикам

MAATRIX

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

Почему одной метрики недостаточно

Три стороны вопроса тянут в разные стороны, и ни одна не даёт полной картины сама по себе.

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

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

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

Поэтому дальше три метрики разбираются по отдельности, а в конце — как свести их в одно решение.

Метрика 1: считаем экономику — облако против аренды дедика

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

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

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

Условный пример структуры сравнения (цифры иллюстративные, у вас в проекте они будут другими):

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

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

Метрика 2: техническая предсказуемость нагрузки

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

Практический способ проверить это — поднять графики потребления CPU, RAM и трафика за последние 3-6 месяцев (в облачной консоли эти данные обычно уже есть) и посмотреть на форму кривой:

• Растущий, но предсказуемый паттерн. Нагрузка плавно растёт месяц к месяцу, пики повторяются в одно и то же время суток/недели, всплески объяснимы (запуск фичи, сезонность, известный маркетинговый календарь). Разница между средним и пиковым потреблением стабильна и не превышает разумный множитель на протяжении всего периода наблюдения. Это хороший кандидат на переход — можно взять конфигурацию с запасом под ближайший рост и не думать об этом полгода-год.
• Скачущий непредсказуемый паттерн. Пики нерегулярны, не привязаны к понятному календарю, разница между тихим днём и пиковым может быть на порядок и заранее не видна. Здесь эластичное масштабирование облака — это не маркетинговая абстракция, а реальная защита: вы платите за пик только когда он есть, а не держите железо простаивающим 90% времени ради редких всплесков.

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

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

Метрика 3: операционная зрелость команды

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

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

Минимальный список того, что нужно закрыть своими силами (или силами подрядчика) при переходе на дедик:

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

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

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

Как свести три метрики в одно решение

По отдельности каждая метрика может дать ложно уверенный ответ. Вместе они формируют более честную картину. Условная матрица комбинаций:

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

Практический алгоритм на один вечер

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

1. Выгрузить счета за облако за последние 3-6 месяцев из биллинга провайдера, разбить по статьям (compute, storage, трафик, managed-сервисы, IP) и посчитать среднее и тренд по месяцам.
2. Получить конкретную цену дедика с конфигурацией, покрывающей текущее среднее потребление плюс разумный запас (например, ориентируясь на пиковые значения последних месяцев, а не только на среднее) — сравнить с суммой из шага 1.
3. Построить график CPU/RAM/трафика за тот же период и на глаз оценить форму: плавный рост или скачки без понятной причины. При наличии инструментов мониторинга полезно посмотреть отношение пикового значения к среднему по неделям — если оно стабильно из недели в неделю, паттерн предсказуем; если скачет от 2x до 10x без системы — нет.
4. Пройтись по чек-листу операционной готовности из предыдущего раздела и честно отметить, что уже есть, а что нужно строить с нуля.
5. Свести три ответа в матрицу из предыдущего раздела и принять решение — либо переезд, либо конкретный список того, что нужно закрыть перед переездом, либо осознанное решение остаться в облаке ещё на квартал-два.

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

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