Как считать ROI переезда на свой сервер

MAATRIX

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

Формула целиком и почему она не сводится к одной цифре

Базовая идея простая:

Чистая выгода за 1-й год =
  Годовая экономия на инфраструктуре
  − Единоразовые затраты на миграцию
  − Дополнительные затраты на поддержку своего сервера (за год)

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

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

Считаем годовую экономию: сравниваем не тарифы, а сценарии использования

Первая ошибка — сравнивать цену тарифа облачного провайдера с ценой VPS «в лоб». Реальная экономия считается по фактическому потреблению, а не по прайс-листу.

Шаги:

1. Возьмите реальные счета за 3-6 месяцев — не один месяц (он может быть нетипичным), а несколько, чтобы увидеть тренд и пиковую нагрузку. Выпишите отдельно: compute (виртуальные машины/инстансы), хранилище, трафик (особенно исходящий — у облаков он часто оплачивается отдельно и не всегда очевиден на первый взгляд), managed-надстройки (managed БД, managed Kubernetes, CDN, балансировщик), лицензии SaaS, если мигрируете с готового сервиса на self-hosted аналог.
2. Спроецируйте нагрузку на характеристики своего сервера. Если сейчас арендуете 3 отдельных инстанса под веб, БД и очередь, на своём сервере это может быть один сервер с нужным объёмом RAM и CPU — экономия не только в аренде, но и в количестве единиц инфраструктуры. Если же нагрузка растёт скачками (сезонность, рекламные кампании), у своего сервера нет автоскейлинга «из коробки» — придётся либо резервировать мощность под пик, либо строить масштабирование самостоятельно.
3. Учтите резерв и отказоустойчивость отдельно. Если сейчас реплика в другом регионе или managed-бэкапы включены в тариф, при переезде это отдельная статья расходов, которую нельзя списывать в ноль — иначе экономия окажется дутой.
4. Не забывайте трафик между локациями. Пока часть инфраструктуры остаётся в старом облаке, а часть переезжает, трафик между ними может стоить неожиданно много.

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

Считаем единоразовые затраты на миграцию

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

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

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

Обучение команды новому стеку. Если команда раньше жала кнопки в панели managed-провайдера, а теперь администрирует Linux-сервер напрямую — это не бесплатно. Оцените реалистично: сколько нужно времени, чтобы человек уверенно настраивал firewall, systemd-юниты, резервное копирование, обновления безопасности, мониторинг. Если такого опыта в команде нет вообще, честная оценка — недели, а не дни, и в первые месяцы производительность на новом стеке будет ниже, чем на привычном managed-решении. Это тоже часть стоимости, даже если не проходит отдельной строкой в бюджете.

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

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

Считаем продолжающиеся затраты на поддержку своего сервера

Managed-решение включает в тариф то, что при переезде на свой сервер становится вашей задачей: обновления безопасности, резервное копирование, мониторинг, реакцию на инциденты ночью, замену оборудования при выходе из строя (для выделенных серверов) или просто время на администрирование (для VPS).

Разложите это на составляющие:

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

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

Пример структуры расчёта (без готовых цифр)

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

Годовая экономия на инфраструктуре:
  compute: было ___ / станет ___ = экономия ___/мес
  хранилище: было ___ / станет ___ = экономия ___/мес
  трафик: было ___ / станет ___ = экономия ___/мес
  managed-надстройки: было ___ / станет ___ = экономия ___/мес
  итого в год: (сумма экономии в месяц) × 12 = ___

Единоразовые затраты на миграцию:
  перенос данных и конфигурации: ___ часов × ставка = ___
  тестирование: ___ часов × ставка = ___
  риск простоя: вероятность × стоимость часа простоя = ___
  обучение команды: ___ часов × ставка = ___
  параллельная оплата: ___ месяцев × старый тариф = ___
  итого: ___

Дополнительные затраты на поддержку (за год):
  время администратора: ___ часов/мес × 12 × ставка = ___
  мониторинг и бэкапы: ___
  резерв на рост: ___
  итого: ___

Чистая выгода за 1-й год = экономия − миграция − поддержка = ___
Срок окупаемости = миграция / (экономия − поддержка за год) = ___ лет

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

Нефинансовые факторы, которые формула не показывает

ROI даёт число, но решение не должно приниматься только по числу — особенно если оно близко к нулю или горизонт окупаемости больше пары лет.

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

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

Скорость реакции на инциденты. У managed-провайдера обычно есть SLA с гарантированным временем ответа. На своём сервере время реакции обеспечивает команда сама, и ночью оно часто хуже, чем днём. Если дежурств нет, честно заложите это в риски, а не в экономию.

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

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

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

Как снизить единоразовые затраты и ускорить окупаемость

Часть слагаемых в формуле не фиксирована — ей можно управлять ещё на этапе планирования.

• Мигрируйте поэтапно, а не всё разом. Перенесите сначала наименее критичный компонент (например, статический сайт или тестовое окружение), обкатайте процесс, только потом — продакшен с базой данных. Это снижает и риск простоя, и требования к квалификации команды на старте.
• Держите старую инфраструктуру как fallback на переходный период. Дороже по деньгам (двойная оплата), но резко снижает риск простоя — можно откатиться за минуты вместо часов разбора проблемы на новом сервере.
• Автоматизируйте настройку через Ansible/Terraform ещё до переезда, а не вручную. Это увеличивает время подготовки, но многократно снижает время на повторную настройку, если что-то пойдёт не так, и упрощает последующее масштабирование — второй сервер поднимается за минуты, а не переписывается вручную заново.
• Выберите готовые компоненты вместо самописных там, где это уместно — панель управления, готовый образ с преднастроенным стеком, managed-подобные инструменты поверх своего сервера (например, автоматический TLS через Let's Encrypt вместо ручной настройки сертификатов). Это снижает как единоразовые затраты на настройку, так и постоянные затраты на поддержку.
• Сравнивайте TCO не за один год, а за три, если решение стратегическое, а не тактическое — единоразовые затраты размазываются на больший срок, и экономия за счёт масштаба обычно растёт быстрее, чем расходы на поддержку. Подробный разбор такого расчёта — в статье про TCO выделенного сервера против облака на три года.

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