Аренда вычислительных мощностей окупается не всегда

Аренда выглядит дешевле, пока в таблице есть только ежемесячный счет, а покупка выглядит дешевле, пока в ней забыты люди, резерв и электричество. Честный расчет на три года часто дает неприятный для обеих сторон ответ: выбор решает не цена сервера и не процент CPU в панели мониторинга, а доля полезной мощности, которую компания действительно оплачивает непрерывно. Я считаю такие проекты через один порог. Ниже него аренда сохраняет деньги и свободу маневра, выше него своя стойка начинает отрабатывать капитальные затраты. Порог нельзя взять из чужого кейса. Его нужно получить из собственных коммерческих предложений, профиля нагрузки и правил резервирования.

Порог считает оплачиваемая загрузка, а не CPU

Нужная переменная - оплачиваемая загрузка: отношение фактически оплаченных часов эквивалентной мощности к часам всей доступной мощности за тот же период. Если из шестнадцати одинаковых виртуальных машин восемь работают весь месяц, оплачиваемая загрузка равна 50%, даже если гостевые системы показывают в среднем 18% CPU.

Это различие постоянно портит расчеты. Облако может выключить или освободить вычислительный ресурс ночью, а собственный сервер остается включенным и потребляет энергию. И наоборот, виртуальная машина может числиться остановленной, но продолжать выставляться к оплате. Документация Microsoft по FinOps отдельно различает stopped VM и deallocated VM: в первом случае вычислительные ресурсы остаются зарезервированными и оплачиваются, во втором освобождаются, хотя диски и связанные услуги по-прежнему стоят денег. Для модели важен счет, а не подпись в консоли.

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

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

Полезно посчитать две загрузки. u_bill показывает долю оплачиваемых часов и входит в денежную модель. u_work показывает выполненную работу относительно проверенной производительности и помогает искать технический запас. Большой разрыв между ними говорит не в пользу аренды или стойки, а о плохом управлении емкостью. Сначала исправьте явный простой, затем принимайте инвестиционное решение.

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

Сравнивайте одну и ту же полезную мощность

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

Я начинаю с эталонного набора, например «8 vCPU, 32 ГБ RAM, 500 ГБ быстрого хранилища, заданное число операций в секунду и восстановление после отказа одного узла». Затем проверяю его на реальной нагрузке в обеих средах. Результатом становятся не рекламные ядра, а число одновременно работающих эталонных наборов, которые проходят одинаковый тест задержки.

Тест должен длиться достаточно долго, чтобы проявились заполнение кэша, сборка мусора, контрольные точки базы и фоновые копии. Зафиксируйте версии приложения, набор данных, число запросов, 95-й и 99-й процентили задержки, потребление памяти и скорость диска. Средняя задержка легко скрывает короткие остановки, из-за которых пользователи считают систему медленной.

Не переносите коэффициент из одного класса задач в другой. Узел, который хорошо уплотняет веб-сервисы, может плохо держать базу с большим рабочим набором или обучение модели. Для GPU сравнивайте завершенные задания, время очереди, объем памяти ускорителя и допустимость разделения устройства. Цена одного часа ничего не говорит, если один вариант завершает работу вдвое дольше.

В стойке нельзя считать всю установленную мощность полезной. Если четыре узла должны пережить отказ одного, в модель попадает мощность трех. Если кластер требует свободных 20% для миграции во время обслуживания, вычтите и их. Сеть, контроллеры хранения и лицензии тоже могут поставить предел раньше CPU.

Для аренды используйте эффективную цену эталонного набора:

q = compute + RAM + mandatory_license + local_storage

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

Трехлетняя модель помещается в четыре формулы

Полная модель должна разделять фиксированные, переменные и разовые расходы. Так виден сам порог, а не одна итоговая цифра.

Для аренды с почасовым освобождением ресурсов:

Rent(u) = K * H * q * u + Rfixed + Rvariable(u)

Здесь K - число эталонных наборов при полной полезной мощности, H - 26 280 часов за три невисокосных года, q - цена набора в час, u - оплачиваемая загрузка от 0 до 1. Rfixed включает диски, копии и услуги, которые оплачиваются даже при выключленных вычислениях.

Для своей стойки:

Rack(u) = Capex + Colo + Staff + Service + Migration
          + H * PUE * Tariff * (Pidle + Pvariable * u)
          - Residual

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

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

Рост емкости редко идет гладкой линией. Аренда прибавляет один набор, а кластер иногда требует сразу новый узел, коммутатор или лицензионный пакет. В помесячной таблице округляйте мощность до реально покупаемой единицы и учитывайте дату поставки. Иначе модель приписывает стойке дробные серверы, которых поставщик не продаст.

Порог находится из равенства Rent(u*) = Rack(u*):

u* = (Rack_fixed - Rent_fixed)
     / (Rent_variable_at_100% - Rack_variable_at_100%)

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

Рабочий пример дает порог около 29%

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

Исходные строки модели:

• полезная мощность K: 12 наборов;
• цена аренды q: 980 ₸ за набор в час;
• постоянные услуги аренды за 3 года: 12 000 000 ₸;
• серверы, сеть, запас и лицензии: 50 000 000 ₸;
• размещение и каналы: 900 000 ₸ в месяц.

Работа администратора занимает 0,25 ставки при полной годовой стоимости ставки 18 000 000 ₸. Сервис и запчасти стоят 6 000 000 ₸, ввод, миграция и вывод еще 2 000 000 ₸, а остаточная стоимость равна 5 000 000 ₸. Мощность IT в простое принята за 1,4 кВт с добавкой 2,2 кВт при полной загрузке. PUE равен 1,35, тариф - 45 ₸/кВт·ч.

Арендная вычислительная часть при полной загрузке стоит 12 × 26 280 × 980 = 309 052 800 ₸. Вместе с постоянными услугами функция аренды равна 12 000 000 + 309 052 800 × u.

Фиксированная часть стойки до электричества равна 50 000 000 + 32 400 000 + 13 500 000 + 6 000 000 + 2 000 000 - 5 000 000 = 98 900 000 ₸. Электричество добавляет 26 280 × 1,35 × 45 × (1,4 + 2,2u), то есть примерно 2 235 000 + 3 512 000u. Получаем:

Rent(u) = 12 000 000 + 309 052 800u
Rack(u) = 101 135 000 + 3 512 000u
u* = 89 135 000 / 305 540 800 = 0.292

При оплачиваемой загрузке 10% аренда обойдется примерно в 42,9 млн ₸, а стойка в 101,5 млн ₸. При 25% суммы составят около 89,3 млн ₸ и 102,0 млн ₸. При 50% аренда вырастет примерно до 166,5 млн ₸, а стойка до 102,9 млн ₸. После 29% стойка дешевле в рамках этих предположений.

Эти значения можно проверить в обычной таблице без специального калькулятора. Внесите загрузку в ячейку B1, затем используйте формулы ниже. Результат при B1=0,292 должен дать близкие суммы; небольшое расхождение возникает из-за округления порога.

B2 = 12000000 + 309052800 * B1
B3 = 101135000 + 3512000 * B1
B4 = B2 - B3

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

Этот результат не говорит, что любая стойка окупается при 29%. Удвоьте цену размещения, уберите остаточную стоимость или добавьте вторую площадку, и порог сдвинется. Подставьте трехлетнее обязательство провайдеру вместо почасового тарифа, и кривая аренды станет намного более плоской. Число имеет смысл только рядом с исходными строками.

Электричество начинается с холостого хода

Сервер не потребляет электричество пропорционально CPU от нуля. У него есть базовая мощность памяти, вентиляторов, блоков питания, дисков и сетевых адаптеров. SPECpower_ssj2008 поэтому измеряет сервер на уровнях нагрузки от 100% до состояния Active Idle с нулевой производительностью. Я не переношу результат SPEC на чужую конфигурацию, но принимаю его методический вывод: одной паспортной максимальной мощности для бюджета недостаточно.

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

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

К расходу добавьте деградацию условий. Забитый фильтр, неудачные заглушки, высокая температура на входе и несбалансированные фазы увеличивают работу вентиляторов или ограничивают доступную емкость. Эти проблемы не оправдывают произвольный запас в 30%. Они требуют измерения температуры, мощности по вводам и проверки размещения перед закупкой.

PUE тоже требует аккуратности. The Green Grid определяет его как полную энергию дата-центра, деленную на энергию ICT-оборудования. Если оператор размещения уже выставляет счет за измеренные кВт·ч с включенным охлаждением, повторное умножение на PUE задвоит расход. Если компания платит общий счет своей площадки, PUE или прямое измерение вспомогательной энергии обязательно.

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

Амортизация не заменяет денежный поток

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

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

Третья колонка нужна для времени сотрудников. Зарплата администратора не исчезает, если человек уже работает в компании. Оцените часы на проектирование, приемку, прошивки, замену компонентов, дежурства, аудит и вывод из эксплуатации. Учитывайте только дополнительную или высвобождаемую работу, но зафиксируйте владельца каждой операции. Строка «делает текущая команда» без часов скрывает ограничение, а не экономию.

IAS 16 требует оценивать срок полезного использования и остаточную стоимость с учетом ожидаемой полезности актива для самой организации, а метод и оценки пересматривать как минимум в конце каждого финансового года. Это важнее механического правила «сервер живет три года». Оборудование может физически работать дольше, но потерять экономическую пригодность из-за роста памяти, прекращения поддержки или требований приложения.

В трехлетнем сравнении остаточная стоимость обязательна, если после горизонта компания продолжит использовать или сможет продать оборудование. Но не ставьте цену нового сервера на третий год. Используйте консервативное предложение выкупа либо ноль и покажите чувствительность. Отдельно рассчитайте приведенную стоимость, если стоимость капитала заметна: ранний Capex и равномерные ежемесячные платежи нельзя честно сравнивать простой суммой.

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

Резервирование меняет обе стороны

Одинаковая доступность часто меняет результат сильнее, чем скидка на процессор. Арендная архитектура с одной виртуальной машиной не равна кластеру N+1 в стойке. И один локальный кластер не равен сервису, который переживает потерю целой площадки.

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

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

Цена простоя не должна растворяться в выдуманном проценте «риска». Возьмите конкретный бизнес-процесс, определите допустимое окно, число затронутых сотрудников или операций и прямые последствия задержки. Затем сравните архитектуры по отказам, которые они действительно закрывают. Если оценить ущерб нельзя, хотя бы покажите часы недоступности отдельно от TCO.

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

Проверьте лицензионные метрики до выбора железа. Лицензия по физическим ядрам, сокетам или виртуальным ядрам способна перевернуть расчет, особенно при резервном узле. Внесите в таблицу первичную покупку, подписку, поддержку и права переноса. Формулировка «лицензии уже есть» приемлема только после проверки договора.

Чувствительность полезнее точной итоговой суммы

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

Посчитайте минимум три сценария:

• низкая загрузка: медленный рост, почасовое освобождение ресурсов и высокая остаточная стоимость;
• базовый: наиболее вероятный профиль и подписанные коммерческие условия;
• высокая загрузка: быстрый рост, меньшая остаточная стоимость, более дорогая энергия и обслуживание.

Затем измените по одному параметру на 10% и пересчитайте u*. Если порог сильнее всего реагирует на цену аренды и Capex, сначала добивайтесь твердых предложений по этим строкам. Если его двигает работа администратора, спор о цене киловатт-часа отвлекает от главной неопределенности.

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

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

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

Аренда покупает обратимость

Аренда остается разумнее ниже порога, при резких сезонных пиках, коротком сроке проекта и высокой неопределенности конфигурации. Она также полезна, когда команда еще не знает профиль I/O или должна быстро проверить новую нагрузку. Плата сверх голого железа в этих случаях покупает возможность уменьшить ресурс и прекратить расход без продажи оборудования.

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

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

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

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

Своя стойка выигрывает предсказуемой базой

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

Перед закупкой потребуйте четыре подтверждения: нагрузочный тест эталонного набора, почасовой профиль оплачиваемой мощности, два сопоставимых предложения на аренду и полный расчет стойки с N+1. Этого достаточно, чтобы убрать самые дорогие фантазии из обеих колонок.

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

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

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

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