Есть сюжет, который мы видим в проектах чаще любого другого. Заказчик выбирает прикладную систему: антифрод, платформу отчётности, управление каналами обслуживания, ядро для нового направления. Выбирает долго и всерьёз — сравнивает функциональность, ездит на референсы, считает лицензии на пользователей и рабочие места. К моменту, когда решение принято и защищено, в бюджете стоит одна строка: стоимость самой системы.
А потом наступает день, когда эту систему надо где-то запустить.
И выясняется, что строк на самом деле четыре: прикладной софт, оборудование, системные лицензии и поддержка. Заказчик видел первую. Заплатит за все четыре. Причём самая недооценённая из трёх оставшихся — не оборудование, как принято думать, а лицензии на системное программное обеспечение. Оборудование хотя бы видно глазами, его можно потрогать и списать через шесть лет. Лицензионная подписка не видна вообще и пересчитывается ровно тогда, когда вы решаете, сколько ядер купить.
Дальше — разбор на сквозном примере. Случай редкий тем, что замкнулся: расчёт делался в январе 2025 года, спор шёл о методике, а через полтора года появились фактические метрики с той самой инфраструктуры. Обычно история про сайзинг заканчивается словами «мы рекомендовали», и читателю остаётся поверить на слово. Здесь есть проверка практикой.
Заказчика и страну не называем: Средняя Азия, сервис с массовой розничной клиентской базой. Абсолютные цифры по клиентам и ёмкости заменили на кратности — логика расчёта от этого не меняется.
Постановка задачи
Требования, которые ничего не значат
Раздел с требованиями к инфраструктуре в документации на прикладную систему описывает не нагрузку, а страховку её разработчика.
Раздел с требованиями к инфраструктуре в документации на прикладную систему обычно есть. Проблема в том, что читать там нечего.
Типичная формулировка выглядит так: сервер, не менее 32 ядер, не менее 256 GB оперативной памяти, дисковая подсистема на SSD. Иногда добавляют «или эквивалент» — и это единственное честное слово во всём абзаце. Ни поколения процессора, ни частоты, ни профиля нагрузки, ни главного: идёт речь о физическом сервере или о виртуальной машине.
Разница здесь не косметическая. Между 32 ядрами 2018 года и 32 ядрами сегодняшними разрыв в производительности кратный. Между 32 физическими ядрами и 32 vCPU разрыв ещё больше, и он в другую сторону. Купив по такой строчке физический сервер, вы почти наверняка переплатите. Выделив по ней виртуальную машину, можете недодать.
Важно понимать, кто и зачем это пишет. Требования формулирует разработчик прикладной системы, и формулирует их с запасом, чтобы к нему не было претензий по производительности ни при каком сценарии. Это его законный интерес, и обижаться тут не на что. Но использовать такой текст как основание для закупки нельзя: он описывает не нагрузку, он описывает страховку поставщика софта.
Реальный профиль всегда задаётся прикладными величинами, а не техническими. Для системы транзакционного антифрода это число операций в секунду в пике, доля операций, уходящих на модельную проверку, и глубина хранения истории для обучения. Для платформы самостоятельной обработки данных — число одновременно работающих аналитиков, объём витрин и то, считается ли агрегация заранее по расписанию или на лету по запросу. Ни одна из этих величин из строчки «не менее 32 ядер» не выводится и вывестись не может.
Бывает и обратная ошибка, о ней говорят реже. Требования занижены, потому что разработчик указал конфигурацию, на которой система разворачивается и показывается — демонстрационную. Она честно работает на десяти пользователях и разваливается на трёхстах. Опознаётся такая строчка по подозрительной скромности: если под систему, обслуживающую весь фронт банка, просят два сервера средней конфигурации, это не экономия, это стенд.
Отсюда правило, с которого начинается любой наш разговор о сайзинге. Требования к инфраструктуре берутся не из документации на систему, а из замера. Если система уже где-то работает — снимаем метрики с работающей. Если она новая и мерить нечего — получаем от разработчика письменный нагрузочный профиль в операциях, объёмах и сроках хранения. Устно такие вещи не обсуждаются: через год выяснять, кто что имел в виду, будет некому.
Переподписка
Спор о методике
Требование задано в виртуальных ресурсах, а спор пошёл о том, сколько физических ядер под ними должно лежать.
В нашем случае формулировка была лучше средней. Требование задали в виртуальных ресурсах: 1000 vCPU на площадку. Прикладная часть — контейнерная платформа, реляционная и документная базы, сопутствующие сервисы. Две площадки, коммерческая виртуализация.
Мы посчитали и предложили 5 узлов на площадку, по 2 процессора на 24 ядра. Это 48 ядер на узел и 240 физических ядер на площадку. При коэффициенте 4:1 получается 960 vCPU, при 5:1 — 1200. Требование закрывается.
И тут возникло несогласие. Позиция другой стороны звучала так: магии не бывает, вычислительный поток может выполняться только в одном потоке ядра, потоков в ядре два, а не четыре, значит коэффициент 4:1 — маркетинговый ход. Считать надо один к одному. Тысяча vCPU — тысяча физических ядер.
Позиция искренняя и по-своему логичная. Она просто описывает не ту систему.
Расчёт по схеме «одна к одной» не делает систему надёжнее. Он делает её дороже, а часть купленного ресурса — незанятой навсегда.
Переподписка существует не потому, что кто-то хочет сэкономить на железе, а потому что виртуальные машины не потребляют выделенные ресурсы одновременно. Машина с 8 vCPU не держит 8 ядер занятыми круглосуточно — она занимает их в моменты работы, а между ними отдаёт планировщику гипервизора. Вся конструкция виртуализации построена ровно на этом. Если бы каждая vCPU требовала выделенного ядра, виртуализация не давала бы вообще ничего, кроме удобства управления.
Отдельно заметим: методики расчёта, применимые к bare metal, где ресурс действительно раздаётся потоками, на виртуализацию не переносятся. Это разные модели распределения, и подстановка одной вместо другой — самая частая ошибка в спорах о сайзинге. Причём ошибка добросовестная: человек не пытается сэкономить или завысить, он просто считает по знакомой ему схеме.
Рекомендуемый коэффициент зависит от типа нагрузки и лежит в диапазоне примерно от 3:1 до 6-8:1. Для смешанного профиля из баз данных и контейнеров разумный ориентир — 4-5:1. Для тяжёлых баз с жёсткими требованиями по задержке его снижают, иногда до 2:1 или до выделенных узлов без переподписки вообще. Контейнерная платформа, которая сама умеет упаковывать нагрузку, спокойно живёт выше.
Расчёт по схеме 1:1 не делает систему надёжнее. Он делает её дороже, а часть купленного ресурса — незанятой навсегда. И это ещё не самое неприятное следствие.
Лицензионный периметр
Ядра превращаются в лицензии
Виртуализация лицензируется по физическим ядрам. Отсюда следует всё остальное, включая цену методической ошибки.
Теперь про то, из-за чего этот спор стоил существенно дороже, чем выглядел.
Коммерческая виртуализация лицензируется по физическим ядрам. Не по виртуальным машинам, не по vCPU, не по сокетам и не по серверам — по ядрам процессоров, физически установленных в узлах кластера. В нашем расчёте это 240 ядер на площадку, 480 на две, и подписка бралась с поддержкой на 3 года.
Считаем второй вариант. Если идти по схеме 1:1, нужно 1000 физических ядер на площадку. При 48 ядрах на узел это примерно 21 сервер на площадку вместо 5 и около 2000 лицензий вместо 480. Вчетверо. Не на четверть, не в полтора раза — вчетверо, и на трёхлетнем горизонте подписки.
Спор шёл о методике расчёта производительности. А цена ошибки лежала в лицензионном хвосте на три года.
Здесь обычно возникает встречная идея, и её стоит разобрать отдельно, потому что она выглядит убедительно. Мысль такая: возьмём процессоры с бо́льшим числом ядер, тогда серверов понадобится вдвое меньше, и мы сэкономим.
Не сработает. Лицензия следует за ядрами, а не за серверами. Процессор на 48 ядер вместо 24 действительно сокращает число узлов примерно вдвое, но число лицензируемых ядер оставляет тем же — их по-прежнему около тысячи на площадку. При этом сам процессор в тот момент стоил примерно в 2,3 раза дороже за штуку, чем выбранный нами. То есть экономии не возникает ни в одной из четырёх строк: железо дороже, лицензий столько же, поддержка считается от стоимости железа.
Вот это и есть главный вывод выпуска. Спор шёл о методике расчёта производительности — вещи сугубо технической. А цена ошибки лежала не в железе. Она лежала в лицензионном хвосте, который тянется три года и растёт строго пропорционально числу ядер, которое вы однажды решили купить.
Причём заметьте: сторона, настаивавшая на схеме 1:1, защищала позицию, которая утроила бы её собственную смету. Из лучших побуждений и из желания посчитать честнее. Так это обычно и выглядит — не как чей-то злой умысел, а как техническое разногласие с финансовыми последствиями, которые в тот момент никто не считает.
Замер
Проверка практикой
Полтора года спустя появились фактические метрики. Спор, который решался на словах, закрылся числами.
Прошло полтора года. Инфраструктура работает в продуктиве, клиентская база за это время выросла примерно вдвое. Провели аудит: сняли фактические метрики с обеих площадок.
Загрузка процессоров на основной площадке — около 45%. Виртуальные ресурсы розданы в объёме, близком к исходному требованию. Физика при этом занята меньше чем наполовину. Узлов на основной площадке в итоге стало 6, а не 5, но на выводе это не сказывается.
Это и есть ответ на вопрос, который в январе 2025 года решался на словах. Коэффициент 4-5:1 не был оптимистичным допущением — по факту он оказался консервативным. Реальное потребление легло примерно в 2,5 ядра на каждую розданную виртуальную.
Теперь посчитаем альтернативу. При схеме 1:1 та же самая прикладная нагрузка сегодня жила бы на вчетверо большем парке с загрузкой процессоров около 13%. Плюс лицензионная подписка, оплаченная на три года вперёд под ресурс, который не будет использован никогда. Плюс электричество, место в стойках и охлаждение на этот парк.
Резервная площадка в аудите показала единицы процентов, и это нормально: она в режиме горячего резерва и ждёт своего часа, а не обслуживает пользователей. Её мощность считается не по загрузке, а по способности принять контур основной площадки целиком. Это отдельный разговор, но упомянуть стоит — цифру загрузки резервной площадки регулярно приносят как аргумент «у нас всё простаивает».
Из этой истории мы вынесли практику, которую теперь предлагаем всем. В момент согласования сайзинга фиксируем точку контроля: через 6–12 месяцев после ввода снимаем фактические метрики и сравниваем с расчётом. Если расчёт был неверен, это будет видно, и виноватого искать не придётся — будут числа. А следующее расширение вы посчитаете уже по своим показателям, а не по чужим рекомендациям и не по спору двух инженеров.
Расширение
Новое поколение и как не заплатить за него дважды
Через два года прежний процессор уже не заказать. Что при этом происходит с числом лицензий и как этим управлять.
Сейчас эта же инфраструктура расширяется под дальнейший рост: по плану клиентская база должна вырасти примерно впятеро от исходной. Добавляются узлы, добавляется ёмкость. И здесь возникает развилка, о которой стоит знать заранее — она проявляется в любом проекте, где расширение идёт через полтора-два года после первой поставки.
Процессор того поколения, что стоял в исходной поставке, к моменту расширения уже не заказать. Придётся брать текущее. А в новом поколении соблазн простой и почти неизбежный: раз всё равно меняем, возьмём модель посильнее, она же новее.
Если пойти по этому пути, произойдёт следующее. Число ядер на процессор вырастет — в новых линейках базовые модели начинаются с бо́льшего числа ядер, чем два поколения назад. Лицензионный периметр вырастет вслед за ним автоматически. А прикладная нагрузка останется прежней. Вы заплатите за производительность, которая не нужна, и будете доплачивать за неё все годы подписки.
Мы сделали иначе. Взяли текущее поколение с тем же числом ядер на процессор — 24, как и было. Лицензий требуется ровно столько же, сколько потребовалось бы на старом поколении: 48 на узел. А производительность при этом выросла, потому что в новом поколении выше базовая частота, больше кэша на ядро и заметно шире канал к памяти. Прирост достался бесплатно с точки зрения лицензий.
Правило простое и работает почти всегда. В кластере под виртуализацию, лицензируемую по ядрам, модель процессора выбирается по числу ядер, а не по позиции в линейке. Внутри одного и того же числа ядер новое поколение почти наверняка быстрее старого — вот этим приростом и надо пользоваться. Позиция в линейке важна там, где лицензий нет вообще: на узлах баз данных с лицензией по пользователям, на выделенном железе, в файловых и объектных системах.
У расширения на новом поколении есть и второй эффект, менее очевидный. Кластер становится разнородным: часть узлов на прежних процессорах, часть на новых. Живая миграция машин между узлами при этом продолжает работать, но обычно требует включить режим совместимости, который выравнивает доступный машинам набор инструкций по старшему общему знаменателю. То есть новые узлы отдают часть своих возможностей ради того, чтобы кластер оставался единым.
Пугаться этого не стоит: выравнивается набор инструкций, а не частота, объём кэша и пропускная способность памяти. Основной прирост нового поколения лежит именно в них и сохраняется полностью. Но решение надо принять заранее и осознанно — либо единый кластер с режимом совместимости, либо два кластера по поколениям с раздельным планированием отказоустойчивости. Выясняться это должно на этапе расчёта, а не на этапе внедрения, когда сроки уже подписаны.
Попутно про память, раз уж речь о конфигурации узла. В этих серверах по 16 модулей на сервер при 32 доступных слотах, то есть один модуль на канал. Тот же объём можно набрать вдвое более дешёвыми модулями, заняв все слоты, но тогда память работает на пониженной частоте. Для баз данных это ощутимо, и экономия на модулях возвращается замедлением, за которое потом попросят добавить ядер. И лицензий.
Горизонт 3 плюс 3
Четвёртая строка
Поддержка не попадает в первую смету, потому что первые три года закрыты гарантией. На четвёртом году она возвращается.
Остаётся поддержка. Она почти никогда не попадает в первую смету, и причина понятная: первые три года закрыты гарантией, а горизонт планирования у прикладного проекта редко бывает длиннее трёх лет.
Мы считаем горизонт не одним сроком, как принято в презентациях, а как 3 года первичной эксплуатации плюс 3 года второго круга. Первые три года оборудование новое, риск отказа лежит на производителе, поддержка входит в поставку. На втором круге появляется продление вендорской поддержки, и это уже отдельные деньги. Ориентир — порядка 10-15% стоимости нового аналогичного оборудования в год.
Ровно на этой границе заканчивается и трёхлетняя подписка на виртуализацию, и продлевается она по числу ядер. По тому самому числу, которое вы зафиксировали в момент первой закупки и с тех пор не меняли. Если в первый год вы взяли вчетверо больше ядер, чем нужно, вы заплатите вчетверо и на продлении.
Отсюда неочевидное следствие: решение о числе ядер — единственное в проекте, которое вы принимаете один раз, а оплачиваете шесть лет. Оборудование можно частично перераспределить, ёмкость нарастить позже, поддержку по части парка не продлевать. Лицензионный периметр кластера привязан к железу, которое в нём стоит, и уменьшить его, не выведя узлы из эксплуатации, не получится.
Из этого же следует, как читать предложения, где лицензии показаны отдельной строкой без срока. Строка «лицензии на виртуализацию» без указания длительности подписки и метрики не значит ничего: за ней может стоять и год, и три года, и разное число ядер. Спрашивать нужно три вещи сразу — метрику, количество и срок.
Что делать, если периметр уже завышен и деньги потрачены? Честный ответ — немного. Вывести часть узлов из кластера и не продлевать на них подписку можно, но это решение принимается на границе срока, а не в середине, и требует пересборки отказоустойчивости. Гораздо дешевле обходится один разговор до закупки.
Чек-лист
Что спросить до подписания
Восемь вопросов, которые стоит пройти раньше, чем прикладная система попадёт в бюджет.
Список вопросов, который стоит пройти раньше, чем строка с прикладной системой попадёт в бюджет. Ни один из них не требует технической подготовки, чтобы его задать.
Итог
Вместо вывода
Ни в одной из этих историй никто не действует недобросовестно. Разработчик прикладной системы пишет требования с запасом, потому что отвечает за производительность. Инженер заказчика считает по схеме 1:1, потому что она кажется честнее и осторожнее. Закупка смотрит на цену процессора и выбирает тот, что дешевле за штуку. Каждый на своём месте прав.
Проблема в том, что никто из них не видит все четыре строки сразу. А смету собирают именно из них.
Если у вас на столе лежит выбранная прикладная система и вопрос «во что нам это обойдётся» — давайте посчитаем вместе. Не по строчке из документации, а по нагрузочному профилю, с разложением на четыре строки и с горизонтом 3 плюс 3. Разговор занимает пару встреч, а расхождение с первой сметой обычно измеряется не процентами.