Экономика bare metal: сначала протестируйте одну нагрузку перед переездом

Почему это кажется дешевле, чем есть на самом деле

Смета на выделенный сервер рядом со счётом за облако может выглядеть подозрительно низкой. Поэтому команды часто неверно оценивают экономику bare metal на первой же встрече. Они сравнивают цену сервера со счётом за облако, видят большую разницу и называют это экономией, ещё до того как посчитают всё, что стоит вокруг этого сервера.

Счёт за железо — это только одна строка. Время команды — ещё одна, и именно оно чаще всего меняет итог. Кому-то всё равно нужно установить и обновлять ОС, настроить резервные копии, подключить мониторинг, подправить хранилище, разбирать сбои и отвечать на алерты, когда что-то ломается в 2 часа ночи.

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

Даже небольшой переезд может съедать реальные часы инженеров каждый месяц. Если один инженер тратит 8–10 часов в месяц на поддержание этой нагрузки в хорошем состоянии, дешёвый сервер перестаёт выглядеть дешёвым. А если нагрузка обслуживает платящих клиентов, у риска тоже есть цена. Более медленное восстановление, слабая избыточность или один пропущенный алерт могут стоить дороже, чем ежемесячная разница в хостинге.

Полумиграции только усугубляют ситуацию. Команды переносят одну часть на bare metal, а остальное оставляют в облаке, а потом живут с этим мостом дольше, чем планировали. Теперь они платят за две среды, две системы мониторинга, больше сетевых правил, больше секретов для управления и больше странных ошибок из-за трафика между системами.

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

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

Например, worker для отчётов, который запускается каждый час, — стабильная нагрузка. Фоновый конвертер изображений тоже часто подходит. А вот ваше основное веб-приложение обычно нет.

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

Выбирайте одну нагрузку, а не всю систему

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

Обычно это исключает то, с чем пользователи взаимодействуют напрямую. Веб-приложения, платёжные сценарии, публичные API и страницы поиска могут выглядеть дешёвыми в тихую неделю, а потом резко взлететь после кампании или бага. Фоновая задача безопаснее. Подумайте о генераторе PDF-счётов, очереди на изменение размеров изображений или ночном импорте данных. У таких задач есть понятный старт, понятный результат и меньше сюрпризов.

Чёткие границы очень важны. Вам нужна нагрузка, которую можно измерить отдельно: сколько задач она получает, сколько времени занимает каждый запуск, сколько CPU, RAM и диска она использует и что ломается, если она начнёт отставать. Если команда не может ответить на эти вопросы до теста, скорее всего, вы выбрали не то.

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

Общее состояние — это то место, где аккуратные эксперименты быстро становятся грязными. Как только один тест затрагивает основную базу данных, object storage или узел внутренних сервисов, ваш «простой» перенос превращается в отдельный проект. Это скрывает реальный результат и сжигает время команды.

Обычно вы узнаёте больше, перенеся один batch worker, чем передвинув половину стека. Это как раз тот случай частичной миграции инфраструктуры, с которого хороший fractional CTO и начнёт: одна повторяемая нагрузка, одно чистое измерение и никакой драмы, если через месяц тест придётся остановить.

Посчитайте полную ежемесячную стоимость

Железо часто оказывается самой дешёвой частью. Решение обычно зависит от труда людей и работы с отказами: именно они определяют, сработает bare metal или превратится в ложную выгоду.

Начните с самого сервера. Если вы арендуете выделенный сервер, возьмите ежемесячный счёт. Если покупаете железо, распределите покупку на фиксированный срок службы — обычно 24–36 месяцев — и добавьте гарантию или риск замены. Сервер за $4,800 — это не разовая цифра для этого теста. Это примерно $133–$200 в месяц ещё до того, как вы посчитаете что-либо ещё.

Потом добавьте расходы, о которых часто забывают: оплату трафика и риск перерасхода, резервные копии и проверку восстановления, запасные диски или RAM, резервный сервер, если он нужен, удалённые руки или поддержку на месте, а также стойку, питание или доплаты за firewall, если они применимы.

Это уже ближе к реальности, но всё ещё недостаточно. Кто-то по-прежнему должен следить за системой, обновлять её и чинить. Если ваша команда тратит по три часа в месяц на обновления ОС, настройку алертов и проверку логов, переведите это время в деньги. Если один инцидент будит инженера в 2 часа ночи раз в два месяца, это тоже нужно посчитать. Затраты bare metal и облака выглядят совсем по-разному, когда человеческое время оценено честно.

Простая оценка выглядит так:

Monthly cost = server + network + backups + spare capacity + operations time + incident time + software tools + rollback reserve

Резерв на откат важнее, чем думает большинство команд. Если тест провалится, вам потребуется время, чтобы вернуть нагрузку назад, убрать расхождение данных и удалить разовые скрипты. Оцените эту работу до старта. Даже небольшой тест часто требует 8–12 часов инженеров в резерве на уборку.

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

Вот где важен опыт оператора. Oleg Sotnikov часто работает с очень экономными production-стеками, и вывод здесь простой: маленький счёт за инфраструктуру помогает только тогда, когда модель эксплуатации тоже остаётся маленькой.

Если после всего этого ежемесячная сумма всё ещё заметно ниже облака, тест стоит запускать. Если экономия исчезает после учёта труда и отката, на этом и остановитесь, оставив нагрузку там, где она уже живёт.

Задайте правило стоп/го до начала теста

Тест без правила принятия решения превращается в надежду на лучшее. Ещё до того, как вы переведёте хотя бы одну нагрузку, решите, что считается успехом. Если команде нужна минимум 25% ежемесячной экономии, чтобы оправдать дополнительную операционную работу, запишите это. Если лучший сценарий даёт только 8%, тест, скорее всего, не проходит даже на бумаге.

Для bare metal это особенно важно, потому что дешёвое железо может скрывать дорогую работу людей. Более низкий счёт за сервер не помогает, если команда ночами разбирает вышедшие из строя диски, ручные обновления или проблемы с бэкапами. Считайте нужную вам экономию после всех этих затрат, а не до них.

Но стоимость — это только одна сторона правила. Задайте лимиты для uptime, задержки в очереди и времени ответа. Стабильный worker может терпеть некоторую задержку, но ему всё равно нужен предел. Например, вы можете разрешить рост среднего времени выполнения задач на 10%, но не больше. Или потребовать ежемесячную доступность выше 99.9%. Выбирайте числа, которые команда уже отслеживает.

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

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

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

Как провести тест

Начните с чистой базы. Возьмите 30 дней данных из текущей системы для той же нагрузки, которую хотите проверить. Используйте одну стабильную задачу или небольшой кусок трафика, а не смесь несвязанных сервисов. Если спрос скачет каждые несколько дней, тест размоет результат.

Затем соберите ту же нагрузку на bare metal, не меняя само приложение. Оставьте ту же версию приложения, runtime, зависимости и расписание. Если вы меняете код и хостинг одновременно, вы не поймёте, что именно дало улучшение или создало проблему.

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

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

Не ждите 30-го дня, чтобы посмотреть на данные. Просматривайте цифры каждую неделю. Система, которая на бумаге выглядит дешёвой, всё равно может проигрывать, если команда тратит на неё по шесть лишних часов в неделю.

Именно здесь команды обманывают себя. Они считают счёт за сервер, но игнорируют время, которое уходит на мониторинг, резервные копии, патчи и отработку восстановления. Fractional CTO должен заставить всё это попасть в scorecard. Иначе тест превращается в проверку цены железа, а не в проверку эксплуатации.

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

Простой пример с worker для отчётов

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

Представьте SaaS-продукт, который каждую ночь создаёт PDF-отчёты и днём экспортирует CSV-файлы. Worker берёт задачу из очереди, читает данные, формирует файл, сохраняет его и помечает задачу как выполненную. Это скучная работа, а именно поэтому она и подходит для чистого теста.

Ровная загрузка CPU делает сравнение проще. Если этот worker почти весь день сжимает данные, строит графики или собирает PDF, вы можете сравнивать облако и bare metal на простых цифрах: средняя загрузка CPU, время выполнения задач, число сбоев и месячная стоимость. Вам не придётся гадать, насколько помогали всплески трафика или autoscaling.

Для такого worker обычно нужно совсем немного зависимостей: доступ к очереди задач, доступ на чтение к базе данных или к replica, object storage для готовых отчётов и общие шаблоны или шрифты.

Именно этот небольшой набор зависимостей и важен. Вы переносите не весь продукт, не стек авторизации и не все фоновые сервисы. Вы переносите один worker с коротким чек-листом.

Откат тоже должен помещаться в короткий чек-лист. Оставьте облачный worker живым во время теста, но уменьшите его мощность. Затем направьте на сервер bare metal только часть задач по отчётам. Если что-то выглядит не так, откатите в один шаг: отправьте все новые задачи обратно в облачный consumer очереди и остановите worker на bare metal. Без миграции данных, без смены DNS, без переключения для пользователей.

Именно такой тест опытный fractional CTO выберет первым, потому что он быстро даёт честные цифры. Если один worker для отчётов не может обойти облако после учёта железа, платы за стойку, мониторинга, резервных копий и времени инженеров, более крупная полумиграция обычно становится не проще, а сложнее. Если же он действительно обходит облако, у вас есть реальная база, а не обнадёживающая таблица.

Ошибки, из-за которых появляются фальшивые savings

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

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

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

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

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

Сторонняя проверка здесь часто помогает. Тот, кто уже работал с экономной инфраструктурой, обычно заставляет команду считать часы, сбои и перекрытия, а не только железо. Если после этого bare metal всё ещё выглядит выгодно, экономия с большей вероятностью реальна.

Быстрые проверки перед тем, как что-то двигать

Короткая пауза может сэкономить месяц уборки. Команды часто тратят время на серверы, образы и бенчмарки, прежде чем ответят на четыре базовых вопроса.

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

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

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

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

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

Что делать после того, как придут цифры

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

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

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

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

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

Если перед окончательным решением вам нужен второй взгляд, на oleg.is Oleg Sotnikov предлагает услуги Fractional CTO и консультации по инфраструктуре для стартапов и небольших команд. Быстрый внешний разбор модели затрат, плана эксплуатации и шагов отката может уберечь от дорогого переезда, основанного на таблице, которая выглядит лучше реальной работы.