Есть сюжет, который я вижу в проектах чаще любого другого. Заказчик выбирает прикладную систему: антифрод, платформу отчётности, управление каналами обслуживания, ядро для нового направления. Выбирает долго и всерьёз — сравнивает функциональность, ездит на референсы, считает лицензии на пользователей и рабочие места. К моменту, когда решение принято и защищено, в бюджете стоит одна строка: стоимость самой системы.
Є сюжет, який я бачу в проєктах частіше за будь-який інший. Замовник обирає прикладну систему: антифрод, платформу звітності, управління каналами обслуговування, ядро для нового напряму. Обирає довго і серйозно — порівнює функціональність, їздить на референси, рахує ліцензії на користувачів і робочі місця. До моменту, коли рішення ухвалене й захищене, у бюджеті стоїть один рядок: вартість самої системи.
There is one storyline I see in projects more often than any other. A customer is choosing an application system: fraud detection, a reporting platform, service-channel management, the core for a new line of business. The choice is long and serious — comparing functionality, visiting reference sites, counting user and workstation licences. By the time the decision is made and defended, the budget holds a single line: the cost of the system itself.
А потом наступает день, когда эту систему надо где-то запустить.
А потім настає день, коли цю систему треба десь запустити.
And then comes the day when the system has to run somewhere.
И выясняется, что строк на самом деле четыре: прикладной софт, оборудование, системные лицензии и поддержка. Заказчик видел первую. Заплатит за все четыре. Причём самая недооценённая из трёх оставшихся — не оборудование, как принято думать, а лицензии на системное программное обеспечение. Оборудование хотя бы видно глазами, его можно потрогать и списать через шесть лет. Лицензионная подписка не видна вообще и пересчитывается ровно тогда, когда вы решаете, сколько ядер купить.
І з’ясовується, що рядків насправді чотири: прикладний софт, обладнання, системні ліцензії та підтримка. Замовник бачив перший. Заплатить за всі чотири. Причому найбільш недооцінений із трьох, що лишилися, — не обладнання, як прийнято думати, а ліцензії на системне програмне забезпечення. Обладнання хоча б видно очима, його можна торкнутися і списати через шість років. Ліцензійна підписка не видна взагалі й перераховується рівно тоді, коли ви вирішуєте, скільки ядер купити.
And it turns out there are in fact four lines: the application software, the hardware, the system licences and the support. The customer saw the first one. They will pay for all four. And the most underestimated of the remaining three is not the hardware, as people assume, but the system-software licences. Hardware at least is visible — you can touch it and write it off after six years. A licence subscription is not visible at all, and it is recalculated at exactly the moment you decide how many cores to buy.
Дальше — разбор на сквозном примере. Случай редкий тем, что замкнулся: расчёт делался в январе 2025 года, спор шёл о методике, а через полтора года появились фактические метрики с той самой инфраструктуры. Обычно история про сайзинг заканчивается словами «мы рекомендовали», и читателю остаётся поверить на слово. Здесь есть проверка практикой.
Далі — розбір на наскрізному прикладі. Випадок рідкісний тим, що замкнувся: розрахунок робився в січні 2025 року, суперечка йшла про методику, а через півтора року з’явилися фактичні метрики з тієї самої інфраструктури. Зазвичай історія про сайзинг закінчується словами «ми рекомендували», і читачеві лишається повірити на слово. Тут є перевірка практикою.
What follows is a single worked example. It is a rare case in that it closed: the calculation was done in January 2025, the argument was about methodology, and a year and a half later actual metrics arrived from that very infrastructure. Usually a sizing story ends with “we recommended”, and the reader is left to take it on trust. This one has a check against practice.
Заказчика и страну не называю: Средняя Азия, сервис с массовой розничной клиентской базой. Абсолютные цифры по клиентам и ёмкости заменил на кратности — логика расчёта от этого не меняется.
Замовника і країну не називаю: Середня Азія, сервіс із масовою роздрібною клієнтською базою. Абсолютні цифри за клієнтами та ємністю замінив на кратності — логіка розрахунку від цього не змінюється.
I am not naming the customer or the country: Central Asia, a service with a mass retail customer base. Absolute figures for customers and capacity have been replaced with multiples — the logic of the calculation is unaffected.
Четыре строки сметы и момент, когда каждая появляетсяЧотири рядки кошторису і момент, коли кожен з’являєтьсяThe four cost lines and the moment each one appears
Решение о прикладной системе принимается по первой строке. Остальные три приходят следом и никуда не деваются.Рішення про прикладну систему ухвалюється за першим рядком. Решта три приходять слідом і нікуди не діваються.The decision on the application system is made on the first line. The other three follow it and do not go away.
| Выбор системыВибір системиChoosing the system | Закупка инфраструктурыЗакупівля інфраструктуриBuying the infrastructure | Годы 1–3Роки 1–3Years 1–3 | Годы 4–6Роки 4–6Years 4–6 | |
|---|---|---|---|---|
| Прикладной софт: лицензии и внедрениеПрикладний софт: ліцензії та впровадженняApplication software: licences and rollout | ||||
| Оборудование: серверы, хранение, сетьОбладнання: сервери, зберігання, мережаHardware: servers, storage, network | ||||
| Системные лицензии: виртуализация, СУБД, копированиеСистемні ліцензії: віртуалізація, СУБД, копіюванняSystem licences: virtualisation, database, backup | ||||
| Поддержка оборудования и продленияПідтримка обладнання і продовженняHardware support and renewals |
01
Постановка задачиПостановка задачіFraming the problem
Требования, которые ничего не значат
Вимоги, які нічого не значать
Requirements that mean nothing
Раздел с требованиями к инфраструктуре в документации на прикладную систему описывает не нагрузку, а страховку её разработчика.
Розділ із вимогами до інфраструктури в документації на прикладну систему описує не навантаження, а страховку її розробника.
The infrastructure-requirements section in an application system’s documentation describes not the workload but the developer’s insurance policy.
Раздел с требованиями к инфраструктуре в документации на прикладную систему обычно есть. Проблема в том, что читать там нечего.
Розділ із вимогами до інфраструктури в документації на прикладну систему зазвичай є. Проблема в тому, що читати там нічого.
The infrastructure-requirements section usually exists in an application system’s documentation. The problem is that there is nothing in it to read.
Типичная формулировка выглядит так: сервер, не менее 32 ядер, не менее 256 GB оперативной памяти, дисковая подсистема на SSD. Иногда добавляют «или эквивалент» — и это единственное честное слово во всём абзаце. Ни поколения процессора, ни частоты, ни профиля нагрузки, ни главного: идёт речь о физическом сервере или о виртуальной машине.
Типове формулювання виглядає так: сервер, не менш як 32 ядра, не менш як 256 GB оперативної пам’яті, дискова підсистема на SSD. Іноді додають «або еквівалент» — і це єдине чесне слово в усьому абзаці. Ні покоління процесора, ні частоти, ні профілю навантаження, ні головного: ідеться про фізичний сервер чи про віртуальну машину.
A typical wording reads: a server, no fewer than 32 cores, no less than 256 GB of RAM, an SSD-based disk subsystem. Sometimes “or equivalent” is added — the only honest word in the whole paragraph. No processor generation, no clock speed, no load profile, and above all no answer to the main question: is this a physical server or a virtual machine?
Разница здесь не косметическая. Между 32 ядрами 2018 года и 32 ядрами сегодняшними разрыв в производительности кратный. Между 32 физическими ядрами и 32 vCPU разрыв ещё больше, и он в другую сторону. Купив по такой строчке физический сервер, вы почти наверняка переплатите. Выделив по ней виртуальную машину, можете недодать.
Різниця тут не косметична. Між 32 ядрами 2018 року і 32 ядрами сьогоднішніми розрив у продуктивності кратний. Між 32 фізичними ядрами і 32 vCPU розрив ще більший, і він в інший бік. Купивши за таким рядком фізичний сервер, ви майже напевно переплатите. Виділивши за ним віртуальну машину, можете недодати.
The difference is not cosmetic. Between 32 cores from 2018 and 32 cores today the performance gap is a multiple. Between 32 physical cores and 32 vCPUs the gap is larger still, and it runs the other way. Buy a physical server against that line and you will almost certainly overpay. Provision a virtual machine against it and you may underdeliver.
Важно понимать, кто и зачем это пишет. Требования формулирует разработчик прикладной системы, и формулирует их с запасом, чтобы к нему не было претензий по производительности ни при каком сценарии. Это его законный интерес, и обижаться тут не на что. Но использовать такой текст как основание для закупки нельзя: он описывает не нагрузку, он описывает страховку поставщика софта.
Важливо розуміти, хто і навіщо це пише. Вимоги формулює розробник прикладної системи, і формулює їх із запасом, щоб до нього не було претензій щодо продуктивності за жодного сценарію. Це його законний інтерес, і ображатися тут немає на що. Але використовувати такий текст як підставу для закупівлі не можна: він описує не навантаження, він описує страховку постачальника софту.
It matters to understand who writes this and why. The requirements are written by the application vendor, and written with headroom so that nobody can blame them for performance under any scenario. That is their legitimate interest and there is nothing to resent. But such a text cannot be used as the basis for a purchase: it describes not the workload but the software supplier’s insurance.
Реальный профиль всегда задаётся прикладными величинами, а не техническими. Для системы транзакционного антифрода это число операций в секунду в пике, доля операций, уходящих на модельную проверку, и глубина хранения истории для обучения. Для платформы самостоятельной обработки данных — число одновременно работающих аналитиков, объём витрин и то, считается ли агрегация заранее по расписанию или на лету по запросу. Ни одна из этих величин из строчки «не менее 32 ядер» не выводится и вывестись не может.
Реальний профіль завжди задається прикладними величинами, а не технічними. Для системи транзакційного антифроду це кількість операцій на секунду в піку, частка операцій, що йдуть на модельну перевірку, і глибина зберігання історії для навчання. Для платформи самостійної обробки даних — кількість одночасно працюючих аналітиків, обсяг вітрин і те, чи рахується агрегація заздалегідь за розкладом, чи на льоту за запитом. Жодна з цих величин із рядка «не менш як 32 ядра» не виводиться і вивестися не може.
The real profile is always defined in application terms, not technical ones. For a transaction fraud-detection system it is peak operations per second, the share of operations routed to a model check, and the depth of history retained for training. For a self-service data platform it is the number of analysts working at once, the size of the marts, and whether aggregation is precomputed on a schedule or done on the fly on request. Not one of these can be derived from the line “no fewer than 32 cores”, and it never will be.
Бывает и обратная ошибка, о ней говорят реже. Требования занижены, потому что разработчик указал конфигурацию, на которой система разворачивается и показывается — демонстрационную. Она честно работает на десяти пользователях и разваливается на трёхстах. Опознаётся такая строчка по подозрительной скромности: если под систему, обслуживающую весь фронт банка, просят два сервера средней конфигурации, это не экономия, это стенд.
Буває й зворотна помилка, про неї говорять рідше. Вимоги занижені, бо розробник вказав конфігурацію, на якій система розгортається і показується — демонстраційну. Вона чесно працює на десяти користувачах і розвалюється на трьохстах. Розпізнається такий рядок за підозрілою скромністю: якщо під систему, що обслуговує весь фронт банку, просять два сервери середньої конфігурації, це не економія, це стенд.
The opposite mistake happens too, and gets discussed less. The requirements are understated because the vendor quoted the configuration the system is deployed and demonstrated on — the demo one. It honestly works for ten users and falls apart at three hundred. You spot such a line by its suspicious modesty: if a system serving a bank’s entire front office is said to need two mid-range servers, that is not thrift, that is a lab setup.
Отсюда правило, с которого начинается любой мой разговор о сайзинге. Требования к инфраструктуре берутся не из документации на систему, а из замера. Если система уже где-то работает — снимаем метрики с работающей. Если она новая и мерить нечего — получаем от разработчика письменный нагрузочный профиль в операциях, объёмах и сроках хранения. Устно такие вещи не обсуждаются: через год выяснять, кто что имел в виду, будет некому.
Звідси правило, з якого починається будь-яка моя розмова про сайзинг. Вимоги до інфраструктури беруться не з документації на систему, а із заміру. Якщо система вже десь працює — знімаємо метрики з працюючої. Якщо вона нова і міряти нічого — отримуємо від розробника письмовий навантажувальний профіль в операціях, обсягах і строках зберігання. Усно такі речі не обговорюються: через рік з’ясовувати, хто що мав на увазі, буде нікому.
Hence the rule every sizing conversation of mine starts from. Infrastructure requirements come from a measurement, not from the system’s documentation. If the system already runs somewhere, take metrics from the running instance. If it is new and there is nothing to measure, get a written load profile from the vendor in operations, volumes and retention periods. These things are not agreed verbally: a year later there will be nobody left to ask what anyone meant.
02
ПереподпискаПерепідпискаOversubscription
Спор о методике
Суперечка про методику
An argument about methodology
Требование задано в виртуальных ресурсах, а спор пошёл о том, сколько физических ядер под ними должно лежать.
Вимога задана у віртуальних ресурсах, а суперечка пішла про те, скільки фізичних ядер під ними має лежати.
The requirement was stated in virtual resources, and the argument became about how many physical cores should sit under them.
В нашем случае формулировка была лучше средней. Требование задали в виртуальных ресурсах: 1000 vCPU на площадку. Прикладная часть — контейнерная платформа, реляционная и документная базы, сопутствующие сервисы. Две площадки, коммерческая виртуализация.
У нашому випадку формулювання було краще за середнє. Вимогу задали у віртуальних ресурсах: 1000 vCPU на майданчик. Прикладна частина — контейнерна платформа, реляційна і документна бази, супутні сервіси. Два майданчики, комерційна віртуалізація.
In our case the wording was better than average. The requirement was stated in virtual resources: 1000 vCPUs per site. The application side was a container platform, a relational and a document database, and supporting services. Two sites, on commercial virtualisation.
Мы посчитали и предложили 5 узлов на площадку, по 2 процессора на 24 ядра. Это 48 ядер на узел и 240 физических ядер на площадку. При коэффициенте 4:1 получается 960 vCPU, при 5:1 — 1200. Требование закрывается.
Ми порахували і запропонували 5 вузлів на майданчик, по 2 процесори на 24 ядра. Це 48 ядер на вузол і 240 фізичних ядер на майданчик. За коефіцієнта 4:1 виходить 960 vCPU, за 5:1 — 1200. Вимога закривається.
We did the arithmetic and proposed 5 nodes per site, two 24-core processors each. That is 48 cores per node and 240 physical cores per site. At a 4:1 ratio that yields 960 vCPUs, at 5:1 it yields 1200. The requirement is met.
И тут возникло несогласие. Позиция другой стороны звучала так: магии не бывает, вычислительный поток может выполняться только в одном потоке ядра, потоков в ядре два, а не четыре, значит коэффициент 4:1 — маркетинговый ход. Считать надо один к одному. Тысяча vCPU — тысяча физических ядер.
І тут виникла незгода. Позиція іншої сторони звучала так: магії не буває, обчислювальний потік може виконуватися лише в одному потоці ядра, потоків у ядрі два, а не чотири, отже коефіцієнт 4:1 — маркетинговий хід. Рахувати треба один до одного. Тисяча vCPU — тисяча фізичних ядер.
And then came the disagreement. The other side’s position ran like this: there is no magic, a compute thread can only run on one hardware thread, a core has two threads and not four, therefore the 4:1 ratio is a marketing device. It must be counted one to one. A thousand vCPUs means a thousand physical cores.
Позиция искренняя и по-своему логичная. Она просто описывает не ту систему.
Позиція щира і по-своєму логічна. Вона просто описує не ту систему.
The position is sincere and logical in its own way. It simply describes a different system.
Расчёт по схеме «одна к одной» не делает систему надёжнее. Он делает её дороже, а часть купленного ресурса — незанятой навсегда.
Розрахунок за схемою «одна до однієї» не робить систему надійнішою. Він робить її дорожчою, а частину купленого ресурсу — незайнятою назавжди.
A one-to-one calculation does not make the system more reliable. It makes it more expensive, and leaves part of the purchased resource idle for good.
Переподписка существует не потому, что кто-то хочет сэкономить на железе, а потому что виртуальные машины не потребляют выделенные ресурсы одновременно. Машина с 8 vCPU не держит 8 ядер занятыми круглосуточно — она занимает их в моменты работы, а между ними отдаёт планировщику гипервизора. Вся конструкция виртуализации построена ровно на этом. Если бы каждая vCPU требовала выделенного ядра, виртуализация не давала бы вообще ничего, кроме удобства управления.
Перепідписка існує не тому, що хтось хоче зекономити на залізі, а тому що віртуальні машини не споживають виділені ресурси одночасно. Машина з 8 vCPU не тримає 8 ядер зайнятими цілодобово — вона займає їх у моменти роботи, а між ними віддає планувальнику гіпервізора. Уся конструкція віртуалізації побудована саме на цьому. Якби кожна vCPU вимагала виділеного ядра, віртуалізація не давала б узагалі нічого, крім зручності управління.
Oversubscription exists not because somebody wants to save on hardware, but because virtual machines do not consume their allocated resources simultaneously. A machine with 8 vCPUs does not hold 8 cores busy around the clock — it occupies them while it works and hands them back to the hypervisor scheduler in between. The entire construct of virtualisation rests on exactly this. If every vCPU required a dedicated core, virtualisation would deliver nothing at all beyond management convenience.
Отдельно замечу: методики расчёта, применимые к bare metal, где ресурс действительно раздаётся потоками, на виртуализацию не переносятся. Это разные модели распределения, и подстановка одной вместо другой — самая частая ошибка в спорах о сайзинге. Причём ошибка добросовестная: человек не пытается сэкономить или завысить, он просто считает по знакомой ему схеме.
Окремо зауважу: методики розрахунку, застосовні до bare metal, де ресурс справді роздається потоками, на віртуалізацію не переносяться. Це різні моделі розподілу, і підстановка однієї замість іншої — найчастіша помилка в суперечках про сайзинг. Причому помилка добросовісна: людина не намагається зекономити чи завищити, вона просто рахує за знайомою їй схемою.
A separate note: calculation methods that apply to bare metal, where the resource really is handed out in threads, do not carry over to virtualisation. These are different allocation models, and substituting one for the other is the commonest error in sizing arguments. And it is an honest error: the person is not trying to cut corners or pad the figure, they are simply counting the way they know.
Рекомендуемый коэффициент зависит от типа нагрузки и лежит в диапазоне примерно от 3:1 до 6–8:1. Для смешанного профиля из баз данных и контейнеров разумный ориентир — 4–5:1. Для тяжёлых баз с жёсткими требованиями по задержке его снижают, иногда до 2:1 или до выделенных узлов без переподписки вообще. Контейнерная платформа, которая сама умеет упаковывать нагрузку, спокойно живёт выше.
Рекомендований коефіцієнт залежить від типу навантаження і лежить у діапазоні приблизно від 3:1 до 6–8:1. Для змішаного профілю з баз даних і контейнерів розумний орієнтир — 4–5:1. Для важких баз із жорсткими вимогами щодо затримки його знижують, іноді до 2:1 або до виділених вузлів без перепідписки взагалі. Контейнерна платформа, яка сама вміє пакувати навантаження, спокійно живе вище.
The recommended ratio depends on the workload type and sits roughly between 3:1 and 6–8:1. For a mixed profile of databases and containers, 4–5:1 is a sensible mark. For heavy databases with strict latency requirements it is lowered, sometimes to 2:1 or to dedicated nodes with no oversubscription at all. A container platform that packs its own workloads lives comfortably above the range.
Сколько vCPU приходится на физическое ядроСкільки vCPU припадає на фізичне ядроHow many vCPUs sit on one physical core
Коэффициент задаётся типом нагрузки, а не осторожностью. Схема «одна к одной» — это отказ от виртуализации, оплаченный полностью.Коефіцієнт задається типом навантаження, а не обережністю. Схема «одна до однієї» — це відмова від віртуалізації, оплачена повністю.The ratio is set by the workload type, not by caution. A one-to-one design is a refusal of virtualisation, paid for in full.
Расчёт по схеме 1:1 не делает систему надёжнее. Он делает её дороже, а часть купленного ресурса — незанятой навсегда. И это ещё не самое неприятное следствие.
Розрахунок за схемою 1:1 не робить систему надійнішою. Він робить її дорожчою, а частину купленого ресурсу — незайнятою назавжди. І це ще не найнеприємніший наслідок.
A 1:1 calculation does not make the system more reliable. It makes it more expensive and leaves part of the purchased resource idle for good. And that is not even the worst consequence.
03
Лицензионный периметрЛіцензійний периметрThe licensing perimeter
Ядра превращаются в лицензии
Ядра перетворюються на ліцензії
Cores turn into licences
Виртуализация лицензируется по физическим ядрам. Отсюда следует всё остальное, включая цену методической ошибки.
Віртуалізація ліцензується за фізичними ядрами. Звідси випливає все інше, включно з ціною методичної помилки.
Virtualisation is licensed by physical cores. Everything else follows from that, including the price of a methodological error.
Теперь про то, из-за чего этот спор стоил существенно дороже, чем выглядел.
Тепер про те, через що ця суперечка коштувала суттєво дорожче, ніж виглядала.
Now about why this argument cost substantially more than it looked.
Коммерческая виртуализация лицензируется по физическим ядрам. Не по виртуальным машинам, не по vCPU, не по сокетам и не по серверам — по ядрам процессоров, физически установленных в узлах кластера. В нашем расчёте это 240 ядер на площадку, 480 на две, и подписка бралась с поддержкой на 3 года.
Комерційна віртуалізація ліцензується за фізичними ядрами. Не за віртуальними машинами, не за vCPU, не за сокетами і не за серверами — за ядрами процесорів, фізично встановлених у вузлах кластера. У нашому розрахунку це 240 ядер на майданчик, 480 на два, і підписка бралася з підтримкою на 3 роки.
Commercial virtualisation is licensed by physical cores. Not by virtual machines, not by vCPUs, not by sockets and not by servers — by the cores of the processors physically installed in the cluster’s nodes. In our calculation that is 240 cores per site, 480 for both, with a three-year subscription including support.
Считаем второй вариант. Если идти по схеме 1:1, нужно 1000 физических ядер на площадку. При 48 ядрах на узел это примерно 21 сервер на площадку вместо 5 и около 2000 лицензий вместо 480. Вчетверо. Не на четверть, не в полтора раза — вчетверо, и на трёхлетнем горизонте подписки.
Рахуємо другий варіант. Якщо йти за схемою 1:1, потрібно 1000 фізичних ядер на майданчик. За 48 ядер на вузол це приблизно 21 сервер на майданчик замість 5 і близько 2000 ліцензій замість 480. Учетверо. Не на чверть, не в півтора раза — учетверо, і на трирічному горизонті підписки.
Now the second option. Going one to one requires 1000 physical cores per site. At 48 cores per node that is roughly 21 servers per site instead of 5, and about 2000 licences instead of 480. Fourfold. Not a quarter more, not half as much again — fourfold, and across a three-year subscription horizon.
Спор шёл о методике расчёта производительности. А цена ошибки лежала в лицензионном хвосте на три года.
Суперечка йшла про методику розрахунку продуктивності. А ціна помилки лежала в ліцензійному хвості на три роки.
The argument was about a performance calculation method. The cost of getting it wrong sat in a three-year licensing tail.
Здесь обычно возникает встречная идея, и её стоит разобрать отдельно, потому что она выглядит убедительно. Мысль такая: возьмём процессоры с бо́льшим числом ядер, тогда серверов понадобится вдвое меньше, и мы сэкономим.
Тут зазвичай виникає зустрічна ідея, і її варто розібрати окремо, бо вона виглядає переконливо. Думка така: візьмемо процесори з більшою кількістю ядер, тоді серверів знадобиться вдвічі менше, і ми зекономимо.
At this point a counter-idea usually appears, and it deserves separate treatment because it sounds convincing. It goes: let us take processors with more cores, then we need half as many servers, and we save money.
Не сработает. Лицензия следует за ядрами, а не за серверами. Процессор на 48 ядер вместо 24 действительно сокращает число узлов примерно вдвое, но число лицензируемых ядер оставляет тем же — их по-прежнему около тысячи на площадку. При этом сам процессор в тот момент стоил примерно в 2,3 раза дороже за штуку, чем выбранный нами. То есть экономии не возникает ни в одной из четырёх строк: железо дороже, лицензий столько же, поддержка считается от стоимости железа.
Не спрацює. Ліцензія слідує за ядрами, а не за серверами. Процесор на 48 ядер замість 24 справді скорочує кількість вузлів приблизно вдвічі, але кількість ліцензованих ядер залишає тією самою — їх, як і раніше, близько тисячі на майданчик. При цьому сам процесор у той момент коштував приблизно у 2,3 раза дорожче за штуку, ніж обраний нами. Тобто економії не виникає в жодному з чотирьох рядків: залізо дорожче, ліцензій стільки ж, підтримка рахується від вартості заліза.
It will not work. The licence follows the cores, not the servers. A 48-core processor instead of a 24-core one does halve the node count, but it leaves the number of licensed cores unchanged — still about a thousand per site. Meanwhile that processor cost roughly 2.3 times more per unit at the time than the one we chose. So no saving appears in any of the four lines: the hardware costs more, the licence count is the same, and support is calculated from the hardware price.
Три способа закрыть одно и то же требованиеТри способи закрити одну й ту саму вимогуThree ways to satisfy the same requirement
Требование — 1000 vCPU на площадку. Разница между вариантами не в производительности, а в числе ядер, которое придётся лицензировать.Вимога — 1000 vCPU на майданчик. Різниця між варіантами не в продуктивності, а в кількості ядер, яку доведеться ліцензувати.The requirement is 1000 vCPUs per site. The difference between the options is not performance but the number of cores you will have to license.
Расчёт 4–5 : 1 — принятый вариантРозрахунок 4–5 : 1 — прийнятий варіантA 4–5 : 1 calculation — the option taken
- ПроцессорПроцесорProcessor
- 24 ядра24 ядра24 cores
- Узлов на площадкуВузлів на майданчикNodes per site
- 555
- Ядер на площадкуЯдер на майданчикCores per site
- 240240240
- Лицензий на две площадкиЛіцензій на два майданчикиLicences for both sites
- 480480480
- vCPU в пределеvCPU у межіvCPU ceiling
- 960 — 1200960 — 1200960 — 1200
Требование закрыто, лицензионный периметр минимальный из возможных.Вимога закрита, ліцензійний периметр мінімальний із можливих.The requirement is met, and the licensing perimeter is the smallest available.
Схема 1 : 1 на тех же процессорахСхема 1 : 1 на тих самих процесорахA 1 : 1 design on the same processors
- ПроцессорПроцесорProcessor
- 24 ядра24 ядра24 cores
- Узлов на площадкуВузлів на майданчикNodes per site
- около 21близько 21about 21
- Ядер на площадкуЯдер на майданчикCores per site
- около 1000близько 1000about 1000
- Лицензий на две площадкиЛіцензій на два майданчикиLicences for both sites
- около 2000близько 2000about 2000
- vCPU в пределеvCPU у межіvCPU ceiling
- 100010001000
Вчетверо больше лицензий и вчетверо больше парка под ту же нагрузку.Учетверо більше ліцензій і вчетверо більший парк під те саме навантаження.Four times the licences and four times the estate for the same workload.
Схема 1 : 1 на процессорах вдвое плотнееСхема 1 : 1 на процесорах удвічі щільнішихA 1 : 1 design on twice-denser processors
- ПроцессорПроцесорProcessor
- 48 ядер48 ядер48 cores
- Узлов на площадкуВузлів на майданчикNodes per site
- около 11близько 11about 11
- Ядер на площадкуЯдер на майданчикCores per site
- около 1050близько 1050about 1050
- Лицензий на две площадкиЛіцензій на два майданчикиLicences for both sites
- около 2100близько 2100about 2100
- vCPU в пределеvCPU у межіvCPU ceiling
- 105010501050
Узлов вдвое меньше, лицензий столько же, процессор дороже за штуку.Вузлів удвічі менше, ліцензій стільки ж, процесор дорожчий за штуку.Half the nodes, the same licence count, and a more expensive processor per unit.
Вот это и есть главный вывод выпуска. Спор шёл о методике расчёта производительности — вещи сугубо технической. А цена ошибки лежала не в железе. Она лежала в лицензионном хвосте, который тянется три года и растёт строго пропорционально числу ядер, которое вы однажды решили купить.
Ось це і є головний висновок випуску. Суперечка йшла про методику розрахунку продуктивності — річ суто технічну. А ціна помилки лежала не в залізі. Вона лежала в ліцензійному хвості, який тягнеться три роки і зростає строго пропорційно кількості ядер, яку ви одного разу вирішили купити.
And that is the main conclusion of this issue. The argument was about a performance calculation method — a purely technical matter. But the cost of getting it wrong did not sit in the hardware. It sat in a licensing tail that runs for three years and grows in strict proportion to the number of cores you once decided to buy.
Причём заметьте: сторона, настаивавшая на схеме 1:1, защищала позицию, которая утроила бы её собственную смету. Из лучших побуждений и из желания посчитать честнее. Так это обычно и выглядит — не как чей-то злой умысел, а как техническое разногласие с финансовыми последствиями, которые в тот момент никто не считает.
Причому зверніть увагу: сторона, що наполягала на схемі 1:1, захищала позицію, яка потроїла б її власний кошторис. З найкращих спонукань і з бажання порахувати чесніше. Так це зазвичай і виглядає — не як чийсь злий намір, а як технічна незгода з фінансовими наслідками, які в той момент ніхто не рахує.
And note this: the side insisting on 1:1 was defending a position that would have tripled its own budget. Out of good intentions and a wish to count more honestly. That is what this usually looks like — not somebody’s bad faith, but a technical disagreement with financial consequences nobody is counting at the time.
04
ЗамерЗамірThe measurement
Проверка практикой
Перевірка практикою
A check against practice
Полтора года спустя появились фактические метрики. Спор, который решался на словах, закрылся числами.
Півтора року по тому з’явилися фактичні метрики. Суперечка, яка вирішувалася на словах, закрилася числами.
A year and a half later the actual metrics arrived. An argument settled in words closed with numbers.
Прошло полтора года. Инфраструктура работает в продуктиве, клиентская база за это время выросла примерно вдвое. Провели аудит: сняли фактические метрики с обеих площадок.
Минуло півтора року. Інфраструктура працює в продуктиві, клієнтська база за цей час зросла приблизно вдвічі. Провели аудит: зняли фактичні метрики з обох майданчиків.
Eighteen months passed. The infrastructure is in production and the customer base has roughly doubled in that time. We ran an audit and took the actual metrics from both sites.
Загрузка процессоров на основной площадке — около 45%. Виртуальные ресурсы розданы в объёме, близком к исходному требованию. Физика при этом занята меньше чем наполовину. Узлов на основной площадке в итоге стало 6, а не 5, но на выводе это не сказывается.
Завантаження процесорів на основному майданчику — близько 45%. Віртуальні ресурси роздані в обсязі, близькому до вихідної вимоги. Фізика при цьому зайнята менше ніж наполовину. Вузлів на основному майданчику зрештою стало 6, а не 5, але на висновку це не позначається.
Processor utilisation on the primary site is around 45%. Virtual resources have been issued at a level close to the original requirement. The physical cores, meanwhile, are less than half busy. The primary site ended up with 6 nodes rather than 5, but that does not change the conclusion.
Что показал замер через полтора годаЩо показав замір через півтора рокуWhat the measurement showed a year and a half later
Клиентская база за это время выросла примерно вдвое. Коэффициент 4–5 : 1 оказался не оптимистичным, а консервативным.Клієнтська база за цей час зросла приблизно вдвічі. Коефіцієнт 4–5 : 1 виявився не оптимістичним, а консервативним.The customer base roughly doubled in that time. The 4–5 : 1 ratio turned out not optimistic but conservative.
Это и есть ответ на вопрос, который в январе 2025 года решался на словах. Коэффициент 4–5:1 не был оптимистичным допущением — по факту он оказался консервативным. Реальное потребление легло примерно в 2,5 ядра на каждую розданную виртуальную.
Це і є відповідь на питання, яке в січні 2025 року вирішувалося на словах. Коефіцієнт 4–5:1 не був оптимістичним припущенням — за фактом він виявився консервативним. Реальне споживання лягло приблизно в 2,5 ядра на кожну роздану віртуальну.
And that is the answer to the question settled in words back in January 2025. The 4–5:1 ratio was not an optimistic assumption — in fact it proved conservative. Real consumption came out at roughly 2.5 physical cores per issued virtual one.
Теперь посчитаем альтернативу. При схеме 1:1 та же самая прикладная нагрузка сегодня жила бы на вчетверо большем парке с загрузкой процессоров около 13%. Плюс лицензионная подписка, оплаченная на три года вперёд под ресурс, который не будет использован никогда. Плюс электричество, место в стойках и охлаждение на этот парк.
Тепер порахуємо альтернативу. За схеми 1:1 те саме прикладне навантаження сьогодні жило б на вчетверо більшому парку із завантаженням процесорів близько 13%. Плюс ліцензійна підписка, оплачена на три роки вперед під ресурс, який не буде використаний ніколи. Плюс електрика, місце в стійках і охолодження на цей парк.
Now the alternative. Under a 1:1 design the same application workload would today sit on four times the estate at around 13% processor utilisation. Plus a licence subscription paid three years ahead for a resource that will never be used. Plus power, rack space and cooling for that estate.
Резервная площадка в аудите показала единицы процентов, и это нормально: она в режиме горячего резерва и ждёт своего часа, а не обслуживает пользователей. Её мощность считается не по загрузке, а по способности принять контур основной площадки целиком. Это отдельный разговор, но упомянуть стоит — цифру загрузки резервной площадки регулярно приносят как аргумент «у нас всё простаивает».
Резервний майданчик в аудиті показав одиниці відсотків, і це нормально: він у режимі гарячого резерву і чекає свого часу, а не обслуговує користувачів. Його потужність рахується не за завантаженням, а за здатністю прийняти контур основного майданчика цілком. Це окрема розмова, але згадати варто — цифру завантаження резервного майданчика регулярно приносять як аргумент «у нас усе простоює».
In the audit the standby site showed single-digit percentages, and that is normal: it is in hot standby waiting its turn, not serving users. Its capacity is measured not by utilisation but by its ability to take on the primary site’s entire environment. That is a separate conversation, but worth mentioning — the standby site’s utilisation figure is regularly produced as evidence that “everything here sits idle”.
Из этой истории я вынес практику, которую теперь предлагаю всем. В момент согласования сайзинга фиксируем точку контроля: через 6–12 месяцев после ввода снимаем фактические метрики и сравниваем с расчётом. Если расчёт был неверен, это будет видно, и виноватого искать не придётся — будут числа. А следующее расширение вы посчитаете уже по своим показателям, а не по чужим рекомендациям и не по спору двух инженеров.
Із цієї історії я виніс практику, яку тепер пропоную всім. У момент погодження сайзингу фіксуємо точку контролю: через 6–12 місяців після введення знімаємо фактичні метрики і порівнюємо з розрахунком. Якщо розрахунок був невірний, це буде видно, і винного шукати не доведеться — будуть числа. А наступне розширення ви порахуєте вже за своїми показниками, а не за чужими рекомендаціями і не за суперечкою двох інженерів.
From this story I took away a practice I now propose to everyone. At the moment the sizing is agreed, fix a control point: 6–12 months after go-live, take the actual metrics and compare them with the calculation. If the calculation was wrong, it will show, and nobody will need to look for someone to blame — there will be numbers. And you will size the next expansion on your own figures rather than on somebody’s recommendation or two engineers’ argument.
05
РасширениеРозширенняExpansion
Новое поколение и как не заплатить за него дважды
Нове покоління і як не заплатити за нього двічі
A new generation, and how not to pay for it twice
Через два года прежний процессор уже не заказать. Что при этом происходит с числом лицензий и как этим управлять.
Через два роки колишній процесор уже не замовити. Що при цьому відбувається з кількістю ліцензій і як цим керувати.
Two years on, the old processor can no longer be ordered. What that does to the licence count, and how to manage it.
Сейчас эта же инфраструктура расширяется под дальнейший рост: по плану клиентская база должна вырасти примерно впятеро от исходной. Добавляются узлы, добавляется ёмкость. И здесь возникает развилка, о которой стоит знать заранее — она проявляется в любом проекте, где расширение идёт через полтора-два года после первой поставки.
Зараз ця сама інфраструктура розширюється під подальше зростання: за планом клієнтська база має зрости приблизно вп’ятеро від вихідної. Додаються вузли, додається ємність. І тут виникає розвилка, про яку варто знати заздалегідь — вона проявляється в будь-якому проєкті, де розширення йде через півтора-два роки після першої поставки.
That same infrastructure is now being expanded for further growth: the plan has the customer base growing roughly fivefold from the original. Nodes are being added, capacity is being added. And here a fork appears that is worth knowing about in advance — it shows up in any project where expansion comes eighteen months to two years after the first delivery.
Процессор того поколения, что стоял в исходной поставке, к моменту расширения уже не заказать. Придётся брать текущее. А в новом поколении соблазн простой и почти неизбежный: раз всё равно меняем, возьмём модель посильнее, она же новее.
Процесор того покоління, що стояв у вихідній поставці, до моменту розширення вже не замовити. Доведеться брати поточне. А в новому поколінні спокуса проста і майже неминуча: раз однаково змінюємо, візьмемо модель сильнішу, вона ж новіша.
The processor generation from the original delivery can no longer be ordered by the time you expand. You will have to take the current one. And with a new generation the temptation is simple and almost inevitable: since we are changing anyway, let us take a stronger model — it is newer, after all.
Если пойти по этому пути, произойдёт следующее. Число ядер на процессор вырастет — в новых линейках базовые модели начинаются с бо́льшего числа ядер, чем два поколения назад. Лицензионный периметр вырастет вслед за ним автоматически. А прикладная нагрузка останется прежней. Вы заплатите за производительность, которая не нужна, и будете доплачивать за неё все годы подписки.
Якщо піти цим шляхом, відбудеться таке. Кількість ядер на процесор зросте — у нових лінійках базові моделі починаються з більшої кількості ядер, ніж два покоління тому. Ліцензійний периметр зросте слідом за ним автоматично. А прикладне навантаження залишиться колишнім. Ви заплатите за продуктивність, яка не потрібна, і будете доплачувати за неї всі роки підписки.
Take that path and here is what happens. The core count per processor rises — in new lines the base models start from more cores than two generations ago. The licensing perimeter rises automatically behind it. And the application workload stays the same. You pay for performance you do not need, and keep paying for it through every year of the subscription.
Мы сделали иначе. Взяли текущее поколение с тем же числом ядер на процессор — 24, как и было. Лицензий требуется ровно столько же, сколько потребовалось бы на старом поколении: 48 на узел. А производительность при этом выросла, потому что в новом поколении выше базовая частота, больше кэша на ядро и заметно шире канал к памяти. Прирост достался бесплатно с точки зрения лицензий.
Ми зробили інакше. Взяли поточне покоління з тією самою кількістю ядер на процесор — 24, як і було. Ліцензій потрібно рівно стільки ж, скільки знадобилося б на старому поколінні: 48 на вузол. А продуктивність при цьому зросла, бо в новому поколінні вища базова частота, більше кешу на ядро і помітно ширший канал до пам’яті. Приріст дістався безкоштовно з погляду ліцензій.
We did it differently. We took the current generation with the same core count per processor — 24, as before. The licence requirement is exactly what it would have been on the old generation: 48 per node. Performance nonetheless went up, because the new generation has a higher base clock, more cache per core and a noticeably wider path to memory. The gain came free in licensing terms.
Правило простое и работает почти всегда. В кластере под виртуализацию, лицензируемую по ядрам, модель процессора выбирается по числу ядер, а не по позиции в линейке. Внутри одного и того же числа ядер новое поколение почти наверняка быстрее старого — вот этим приростом и надо пользоваться. Позиция в линейке важна там, где лицензий нет вообще: на узлах баз данных с лицензией по пользователям, на выделенном железе, в файловых и объектных системах.
Правило просте і працює майже завжди. У кластері під віртуалізацію, що ліцензується за ядрами, модель процесора обирається за кількістю ядер, а не за позицією в лінійці. Усередині однієї й тієї самої кількості ядер нове покоління майже напевно швидше за старе — саме цим приростом і треба користуватися. Позиція в лінійці важлива там, де ліцензій немає взагалі: на вузлах баз даних із ліцензією за користувачами, на виділеному залізі, у файлових та об’єктних системах.
The rule is simple and holds almost always. In a cluster running virtualisation licensed by cores, the processor model is chosen by core count, not by its position in the line-up. Within the same core count, a new generation is almost certainly faster than an old one — that is the gain to take. Position in the line-up matters where there are no core licences at all: on database nodes licensed by users, on dedicated hardware, in file and object systems.
У расширения на новом поколении есть и второй эффект, менее очевидный. Кластер становится разнородным: часть узлов на прежних процессорах, часть на новых. Живая миграция машин между узлами при этом продолжает работать, но обычно требует включить режим совместимости, который выравнивает доступный машинам набор инструкций по старшему общему знаменателю. То есть новые узлы отдают часть своих возможностей ради того, чтобы кластер оставался единым.
У розширення на новому поколінні є і другий ефект, менш очевидний. Кластер стає різнорідним: частина вузлів на колишніх процесорах, частина на нових. Жива міграція машин між вузлами при цьому продовжує працювати, але зазвичай вимагає увімкнути режим сумісності, який вирівнює доступний машинам набір інструкцій за старшим спільним знаменником. Тобто нові вузли віддають частину своїх можливостей заради того, щоб кластер залишався єдиним.
Expanding onto a new generation has a second, less obvious effect. The cluster becomes heterogeneous: some nodes on the old processors, some on the new ones. Live migration between nodes keeps working, but it usually requires enabling a compatibility mode that levels the instruction set available to the machines down to the highest common denominator. In other words, the new nodes give up part of their capability so the cluster can stay whole.
Пугаться этого не стоит: выравнивается набор инструкций, а не частота, объём кэша и пропускная способность памяти. Основной прирост нового поколения лежит именно в них и сохраняется полностью. Но решение надо принять заранее и осознанно — либо единый кластер с режимом совместимости, либо два кластера по поколениям с раздельным планированием отказоустойчивости. Выясняться это должно на этапе расчёта, а не на этапе внедрения, когда сроки уже подписаны.
Лякатися цього не варто: вирівнюється набір інструкцій, а не частота, обсяг кешу і пропускна здатність пам’яті. Основний приріст нового покоління лежить саме в них і зберігається повністю. Але рішення треба ухвалити заздалегідь і усвідомлено — або єдиний кластер із режимом сумісності, або два кластери за поколіннями з роздільним плануванням відмовостійкості. З’ясовуватися це має на етапі розрахунку, а не на етапі впровадження, коли строки вже підписані.
There is no need to be alarmed: what is levelled is the instruction set, not the clock speed, the cache size or the memory bandwidth. The bulk of the new generation’s gain lies in those and is preserved in full. But the decision has to be taken in advance and deliberately — either one cluster with compatibility mode, or two clusters split by generation with separately planned resilience. That belongs to the design stage, not to deployment when the dates have already been signed.
Попутно про память, раз уж речь о конфигурации узла. В этих серверах по 16 модулей на сервер при 32 доступных слотах, то есть один модуль на канал. Тот же объём можно набрать вдвое более дешёвыми модулями, заняв все слоты, но тогда память работает на пониженной частоте. Для баз данных это ощутимо, и экономия на модулях возвращается замедлением, за которое потом попросят добавить ядер. И лицензий.
Принагідно про пам’ять, раз уже мова про конфігурацію вузла. У цих серверах по 16 модулів на сервер за 32 доступних слотів, тобто один модуль на канал. Той самий обсяг можна набрати вдвічі дешевшими модулями, зайнявши всі слоти, але тоді пам’ять працює на зниженій частоті. Для баз даних це відчутно, і економія на модулях повертається уповільненням, за яке потім попросять додати ядер. І ліцензій.
While we are on node configuration, a word about memory. These servers carry 16 modules each against 32 available slots, that is one module per channel. The same capacity can be assembled from modules half the price by filling every slot, but then the memory runs at a reduced speed. For databases that is noticeable, and the saving on modules comes back as a slowdown for which somebody will later ask to add cores. And licences.
06
Горизонт 3 плюс 3Горизонт 3 плюс 3The 3-plus-3 horizon
Четвёртая строка
Четвертий рядок
The fourth line
Поддержка не попадает в первую смету, потому что первые три года закрыты гарантией. На четвёртом году она возвращается.
Підтримка не потрапляє в перший кошторис, бо перші три роки закриті гарантією. На четвертому році вона повертається.
Support misses the first estimate because the first three years are under warranty. In year four it comes back.
Остаётся поддержка. Она почти никогда не попадает в первую смету, и причина понятная: первые три года закрыты гарантией, а горизонт планирования у прикладного проекта редко бывает длиннее трёх лет.
Залишається підтримка. Вона майже ніколи не потрапляє в перший кошторис, і причина зрозуміла: перші три роки закриті гарантією, а горизонт планування у прикладного проєкту рідко буває довшим за три роки.
That leaves support. It almost never makes the first estimate, and the reason is plain: the first three years are covered by warranty, and an application project’s planning horizon is rarely longer than three years.
Я считаю горизонт не одним сроком, как принято в презентациях, а как 3 года первичной эксплуатации плюс 3 года второго круга. Первые три года оборудование новое, риск отказа лежит на производителе, поддержка входит в поставку. На втором круге появляется продление вендорской поддержки, и это уже отдельные деньги. Ориентир — порядка 10–15% стоимости нового аналогичного оборудования в год.
Я рахую горизонт не одним строком, як прийнято в презентаціях, а як 3 роки первинної експлуатації плюс 3 роки другого кола. Перші три роки обладнання нове, ризик відмови лежить на виробнику, підтримка входить у поставку. На другому колі з’являється продовження вендорської підтримки, і це вже окремі гроші. Орієнтир — порядку 10–15% вартості нового аналогічного обладнання на рік.
I count the horizon not as a single term, as presentations tend to, but as 3 years of first-cycle operation plus 3 years of a second cycle. For the first three years the hardware is new, failure risk sits with the manufacturer, and support is included in the delivery. In the second cycle vendor support renewal appears, and that is money of its own — on the order of 10–15% of the price of equivalent new hardware per year.
Ровно на этой границе заканчивается и трёхлетняя подписка на виртуализацию, и продлевается она по числу ядер. По тому самому числу, которое вы зафиксировали в момент первой закупки и с тех пор не меняли. Если в первый год вы взяли вчетверо больше ядер, чем нужно, вы заплатите вчетверо и на продлении.
Рівно на цій межі закінчується і трирічна підписка на віртуалізацію, і продовжується вона за кількістю ядер. За тією самою кількістю, яку ви зафіксували в момент першої закупівлі й відтоді не міняли. Якщо в перший рік ви взяли вчетверо більше ядер, ніж потрібно, ви заплатите вчетверо і на продовженні.
The three-year virtualisation subscription ends at exactly that boundary, and it renews on the core count. On the very number you fixed at the first purchase and have not changed since. If in year one you bought four times more cores than you needed, you will pay four times more at renewal too.
Как четыре строки ведут себя на горизонте 3 плюс 3Як чотири рядки поводяться на горизонті 3 плюс 3How the four lines behave over a 3-plus-3 horizon
Первые три года закрыты гарантией и оплаченной подпиской. На четвёртом всё возвращается — по тем числам, что зафиксированы в первый год.Перші три роки закриті гарантією та оплаченою підпискою. На четвертому все повертається — за тими числами, що зафіксовані в перший рік.The first three years are covered by warranty and a paid subscription. In year four it all comes back — at the numbers fixed in year one.
| Год 1Рік 1Year 1 | Год 2Рік 2Year 2 | Год 3Рік 3Year 3 | Год 4Рік 4Year 4 | Год 5Рік 5Year 5 | Год 6Рік 6Year 6 | |
|---|---|---|---|---|---|---|
| Первичная эксплуатация, гарантияПервинна експлуатація, гарантіяFirst cycle, under warranty | ||||||
| Прикладной софтПрикладний софтApplication software | ||||||
| ОборудованиеОбладнанняHardware | ||||||
| Второй круг: продления и расширениеДруге коло: продовження і розширенняSecond cycle: renewals and expansion | ||||||
| Системные лицензииСистемні ліцензіїSystem licences | ||||||
| Поддержка и продленияПідтримка і продовженняSupport and renewals | ||||||
Отсюда неочевидное следствие: решение о числе ядер — единственное в проекте, которое вы принимаете один раз, а оплачиваете шесть лет. Оборудование можно частично перераспределить, ёмкость нарастить позже, поддержку по части парка не продлевать. Лицензионный периметр кластера привязан к железу, которое в нём стоит, и уменьшить его, не выведя узлы из эксплуатации, не получится.
Звідси неочевидний наслідок: рішення про кількість ядер — єдине в проєкті, яке ви ухвалюєте один раз, а оплачуєте шість років. Обладнання можна частково перерозподілити, ємність наростити пізніше, підтримку за частиною парку не продовжувати. Ліцензійний периметр кластера прив’язаний до заліза, яке в ньому стоїть, і зменшити його, не вивівши вузли з експлуатації, не вийде.
Which leads to a non-obvious consequence: the decision about the core count is the only one in the project you take once and pay for over six years. Hardware can be partly redeployed, capacity can be grown later, support on part of the estate can be left unrenewed. The cluster’s licensing perimeter is tied to the hardware standing in it, and you cannot shrink it without taking nodes out of service.
Из этого же следует, как читать предложения, где лицензии показаны отдельной строкой без срока. Строка «лицензии на виртуализацию» без указания длительности подписки и метрики не значит ничего: за ней может стоять и год, и три года, и разное число ядер. Спрашивать нужно три вещи сразу — метрику, количество и срок.
Із цього ж випливає, як читати пропозиції, де ліцензії показані окремим рядком без строку. Рядок «ліцензії на віртуалізацію» без зазначення тривалості підписки і метрики не значить нічого: за ним може стояти і рік, і три роки, і різна кількість ядер. Питати потрібно три речі одразу — метрику, кількість і строк.
The same tells you how to read proposals where licences appear as a separate line with no term. A line reading “virtualisation licences”, with no subscription length and no metric, means nothing: behind it could be one year or three, and any number of cores. Ask three things at once — the metric, the quantity and the term.
Что делать, если периметр уже завышен и деньги потрачены? Честный ответ — немного. Вывести часть узлов из кластера и не продлевать на них подписку можно, но это решение принимается на границе срока, а не в середине, и требует пересборки отказоустойчивости. Гораздо дешевле обходится один разговор до закупки.
Що робити, якщо периметр уже завищений і гроші витрачені? Чесна відповідь — небагато. Вивести частину вузлів із кластера і не продовжувати на них підписку можна, але це рішення ухвалюється на межі строку, а не в середині, і вимагає перезбирання відмовостійкості. Значно дешевше обходиться одна розмова до закупівлі.
What can be done if the perimeter is already oversized and the money is spent? The honest answer is: not much. You can take some nodes out of the cluster and not renew their subscription, but that decision is taken at the term boundary rather than mid-term, and it requires rebuilding the resilience design. One conversation before the purchase costs far less.
07
Чек-листЧек-листChecklist
Что спросить до подписания
Що запитати до підписання
What to ask before signing
Восемь вопросов, которые стоит пройти раньше, чем прикладная система попадёт в бюджет. Ни один из них не требует технической подготовки, чтобы его задать.
Вісім питань, які варто пройти раніше, ніж прикладна система потрапить у бюджет. Жодне з них не вимагає технічної підготовки, щоб його поставити.
Eight questions worth going through before the application system reaches the budget. None of them requires technical training to ask.
- Поставщику прикладной системы: какой нагрузочный профиль в прикладных величинах — операции в секунду, объёмы, сроки хранения, число одновременных пользователей? Не в ядрах и гигабайтах.
- Ему же: требования к серверу указаны для физической машины или для виртуальной? Ответ обязательно письменный.
- Ему же: есть ли компоненты, чувствительные к задержке, для которых переподписка ресурсов недопустима или ограничена?
- Себе: по какой метрике лицензируется каждый слой — виртуализация, СУБД, резервное копирование? Ядра, сокеты, виртуальные машины, терабайты?
- Себе: что произойдёт с числом лицензий, если через два года понадобится расширение на текущем поколении процессоров?
- Интегратору: показать смету по четырём строкам отдельно, а не одной суммой. И отдельно — что происходит с каждой из них на горизонте 3 плюс 3 года.
- Интегратору: зафиксировать точку контроля через 6–12 месяцев после ввода — снять фактические метрики и сравнить с расчётом.
- Интегратору: что произойдёт с кластером, если через два года понадобится добрать узлы, а прежнего процессора уже не будет в продаже?
- Постачальнику прикладної системи: який навантажувальний профіль у прикладних величинах — операції на секунду, обсяги, строки зберігання, кількість одночасних користувачів? Не в ядрах і гігабайтах.
- Йому ж: вимоги до сервера вказані для фізичної машини чи для віртуальної? Відповідь обов’язково письмова.
- Йому ж: чи є компоненти, чутливі до затримки, для яких переплідписка ресурсів неприпустима або обмежена?
- Собі: за якою метрикою ліцензується кожен шар — віртуалізація, СУБД, резервне копіювання? Ядра, сокети, віртуальні машини, терабайти?
- Собі: що станеться з кількістю ліцензій, якщо через два роки знадобиться розширення на поточному поколінні процесорів?
- Інтегратору: показати кошторис за чотирма рядками окремо, а не однією сумою. І окремо — що відбувається з кожним із них на горизонті 3 плюс 3 роки.
- Інтегратору: зафіксувати точку контролю через 6–12 місяців після введення — зняти фактичні метрики і порівняти з розрахунком.
- Інтегратору: що станеться з кластером, якщо через два роки знадобиться добрати вузли, а колишнього процесора вже не буде в продажу?
- To the application vendor: what is the load profile in application terms — operations per second, volumes, retention periods, concurrent users? Not in cores and gigabytes.
- To the same vendor: are the server requirements stated for a physical machine or a virtual one? The answer must be in writing.
- To the same vendor: are there latency-sensitive components for which resource oversubscription is unacceptable or limited?
- To yourself: by what metric is each layer licensed — virtualisation, database, backup? Cores, sockets, virtual machines, terabytes?
- To yourself: what happens to the licence count if in two years you need to expand on the then-current processor generation?
- To the integrator: show the estimate as four separate lines rather than one total. And separately, what happens to each of them over a 3-plus-3-year horizon.
- To the integrator: fix a control point 6–12 months after go-live — take the actual metrics and compare them with the calculation.
- To the integrator: what happens to the cluster if in two years you need to add nodes and the original processor is no longer on sale?
08
ИтогПідсумокWrap-up
Вместо вывода
Замість висновку
In place of a conclusion
Ни в одной из этих историй никто не действует недобросовестно. Разработчик прикладной системы пишет требования с запасом, потому что отвечает за производительность. Инженер заказчика считает по схеме 1:1, потому что она кажется честнее и осторожнее. Закупка смотрит на цену процессора и выбирает тот, что дешевле за штуку. Каждый на своём месте прав.
У жодній із цих історій ніхто не діє недобросовісно. Розробник прикладної системи пише вимоги із запасом, бо відповідає за продуктивність. Інженер замовника рахує за схемою 1:1, бо вона здається чеснішою й обережнішою. Закупівля дивиться на ціну процесора і обирає той, що дешевший за штуку. Кожен на своєму місці має рацію.
In none of these stories is anyone acting in bad faith. The application vendor writes requirements with headroom because they are answerable for performance. The customer’s engineer counts one to one because it seems more honest and more cautious. Procurement looks at the processor price and picks the cheaper unit. Each of them is right in their own place.
Проблема в том, что никто из них не видит все четыре строки сразу. А смету собирают именно из них.
Проблема в тому, що ніхто з них не бачить усі чотири рядки одразу. А кошторис збирають саме з них.
The problem is that none of them sees all four lines at once. And the estimate is assembled from exactly those four.
Если на столе лежит выбранная прикладная система и вопрос «во что нам это обойдётся», считать нужно не по строчке из документации, а по нагрузочному профилю, с разложением на четыре строки и с горизонтом 3 плюс 3. Расхождение с первой сметой обычно измеряется не процентами.
Якщо на столі лежить обрана прикладна система і питання «у що нам це обійдеться», рахувати потрібно не за рядком із документації, а за навантажувальним профілем, із розкладанням на чотири рядки і з горизонтом 3 плюс 3. Розходження з першим кошторисом зазвичай вимірюється не відсотками.
If an application system has been chosen and the question is “what will this cost us”, the calculation has to start from the load profile rather than a line in the documentation, broken into four cost lines and carried across a 3-plus-3 horizon. The gap against the first estimate is usually not measured in percentages.