Pavel
Tenitskiy

Инфраструктура данных · выпуск 07Інфраструктура даних · випуск 07Data infrastructure · issue 07

Четыре контура

Чотири контури

Four environments

Аренда против своего в виртуализации, резервном копировании, аналитике и нагрузках искусственного интеллекта. Четыре контура, в каждом граница проходит по-своему — и почти всегда не там, где её рисуют.

Оренда проти свого у віртуалізації, резервному копіюванні, аналітиці та навантаженнях штучного інтелекту. Чотири контури, у кожному межа проходить по-своєму — і майже завжди не там, де її малюють.

Rent versus own across virtualisation, backup, analytics and AI workloads. Four environments, and in each of them the boundary runs differently — almost never where it is drawn.

Сентябрь 2026 · 18 минут чтенияВересень 2026 · 18 хвилин читанняSeptember 2026 · 18 min read

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

Останні місяці майже в кожному проєкті спливає одна й та сама розмова. Замовник показує розрахунок на два майданчики, дивиться на підсумок і питає: а може, другий майданчик не будувати, а взяти в оренду? Іноді навпаки — приходять із готовим рішенням усе орендувати, і вже ми сідаємо рахувати, у що це виллється до кінця другого кола експлуатації.

For the last several months the same conversation has come up in nearly every project. The customer shows a two-site estimate, looks at the total and asks: what if we rent the second site instead of building it? Sometimes it runs the other way — they arrive having already decided to rent everything, and then we sit down to work out what that adds up to by the end of the second operating cycle.

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

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

The trouble with that conversation is that it is held as one question when it is really four. Core virtualisation, backup, analytics and AI workloads are built so differently that a single answer cannot cover them. Renting, which looks sensible for model training, becomes an expensive mistake for a round-the-clock production system. Owning, which is mandatory under a bank’s core, turns out to be surplus under the second tier of backup copies.

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

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

What follows is the four environments and where the boundary falls in each. Half the text is physics and arithmetic: those, not the price list, usually settle the argument. The other half is what changed during 2026 in component prices and in the legal framework.

01

Контур первый · расстояниеКонтур перший · відстаньEnvironment one · distance

Расстояние решает раньше, чем бюджет

Відстань вирішує раніше, ніж бюджет

Distance decides before the budget does

5 микросекунд на километр — цифра, которую нельзя обойти ни бюджетом, ни договором.

5 мікросекунд на кілометр — цифра, яку не обійти ні бюджетом, ні договором.

Five microseconds per kilometre — a number no budget and no contract can get around.

Начинать надо не с денег, а с километров. Разнос площадок задаёт всё остальное, и задаёт жёстко.

Починати треба не з грошей, а з кілометрів. Рознесення майданчиків задає все інше, і задає жорстко.

You start with kilometres, not with money. The separation between sites sets everything else, and it sets it rigidly.

Свет в волокне идёт примерно 200 000 км/с, это 5 микросекунд на километр. Трасса всегда длиннее прямой на 30–50% — рельеф, существующие каналы, обход. Отсюда простое правило: примерно 1 мс кругового времени на каждые 100 км трассы. 200 км по прямой дают около 4,2 мс, 400 км — 6,9 мс, 600 км — 9,6 мс.

Світло у волокні йде приблизно 200 000 км/с, це 5 мікросекунд на кілометр. Траса завжди довша за пряму на 30–50% — рельєф, наявні канали, обхід. Звідси просте правило: приблизно 1 мс кругового часу на кожні 100 км траси. 200 км по прямій дають близько 4,2 мс, 400 км — 6,9 мс, 600 км — 9,6 мс.

Light in fibre travels at roughly 200,000 km/s, which is 5 microseconds per kilometre. The route is always 30–50% longer than the straight line — terrain, existing ducts, detours. Hence a simple rule: about 1 ms of round-trip time per 100 km of route. 200 km as the crow flies gives about 4.2 ms, 400 km gives 6.9 ms, 600 km gives 9.6 ms.

Круговая задержка между площадками и предел синхронной схемыКругова затримка між майданчиками і межа синхронної схемиRound-trip latency between sites and the limit of a synchronous design

Свет в волокне — 5 микросекунд на километр, трасса длиннее прямой на 30–50%. Отсюда примерно 1 мс на каждые 100 км трассы.Світло у волокні — 5 мікросекунд на кілометр, траса довша за пряму на 30–50%. Звідси приблизно 1 мс на кожні 100 км траси.Light in fibre travels 5 microseconds per kilometre, and the route runs 30–50% longer than the straight line. That gives roughly 1 ms per 100 km of route.

50 км50 км50 kmминимум по требованию регуляторамінімум за вимогою регулятораthe regulator’s minimum separation
меньше 1 мсменше 1 мсunder 1 msсинхронная запись живёт спокойносинхронний запис живе спокійноsynchronous writes are comfortable
100 км100 км100 km
≈ 2 мс≈ 2 мс≈ 2 ms
200 км200 км200 km
≈ 4,2 мс≈ 4,2 мс≈ 4.2 msвпритык к потолкуупритул до стеліright at the ceiling
400 км400 км400 km
≈ 6,9 мс≈ 6,9 мс≈ 6.9 msтолько асинхронная репликациялише асинхронна реплікаціяasynchronous replication only
600 км600 км600 km
≈ 9,6 мс≈ 9,6 мс≈ 9.6 ms
Рис.Рис.Fig. 1 Потолок растянутого кластера и метрокластера — 5 мс кругового времени, то есть 2,5 мс в одну сторону. 400 и 600 км из синхронной схемы выпадают полностью.Стеля розтягнутого кластера і метрокластера — 5 мс кругового часу, тобто 2,5 мс в один бік. 400 і 600 км із синхронної схеми випадають повністю.The ceiling for a stretched cluster or a metro cluster is 5 ms round trip, that is 2.5 ms one way. At 400 and 600 km the synchronous design is off the table entirely.

Теперь совместим это с требованиями платформ. У растянутых кластеров ведущих платформ виртуализации потолок между площадками с данными — 5 мс кругового времени, то есть 2,5 мс в одну сторону. Требование существует не из вредности: приложение должно успеть записать данные на обе стороны. У метрокластеров на внешних массивах порядок тот же. То есть 200 км — это впритык, а 400 и 600 км из синхронной схемы выпадают полностью.

Тепер сумістимо це з вимогами платформ. У розтягнутих кластерів провідних платформ віртуалізації стеля між майданчиками з даними — 5 мс кругового часу, тобто 2,5 мс в один бік. Вимога існує не зі шкідливості: застосунок має встигнути записати дані на обидва боки. У метрокластерів на зовнішніх масивах порядок той самий. Тобто 200 км — це впритул, а 400 і 600 км із синхронної схеми випадають повністю.

Now put that against what the platforms require. Stretched clusters on the leading virtualisation platforms cap the link between data-bearing sites at 5 ms round trip, that is 2.5 ms one way. The requirement is not arbitrary: the application has to complete the write on both sides. Metro clusters on external arrays are in the same range. So 200 km is right at the edge, and 400 or 600 km falls out of the synchronous design altogether.

Вывод, который стоит проговаривать с заказчиком до того, как считать спецификацию: на 400–600 км не бывает «полной копии кластера в горячем резерве». Там бывает асинхронная репликация с точкой восстановления в минутах и с переключением, которое кто-то должен инициировать. Это другая архитектура, другой регламент и другие деньги.

Висновок, який варто проговорювати із замовником до того, як рахувати специфікацію: на 400–600 км не буває «повної копії кластера в гарячому резерві». Там буває асинхронна реплікація з точкою відновлення у хвилинах і з перемиканням, яке хтось має ініціювати. Це інша архітектура, інший регламент та інші гроші.

A conclusion worth stating to the customer before anyone prices a specification: at 400–600 km there is no such thing as “a full copy of the cluster in hot standby”. What exists there is asynchronous replication with a recovery point measured in minutes and a failover somebody has to initiate. That is a different architecture, a different runbook and different money.

Отдельно про регулятора. Положение о минимальных требованиях к информационной безопасности коммерческих банков — № 3669 от 18 августа 2025 года, вступило в силу 20 ноября — требует резервный центр обработки данных не менее чем в 50 км от основного, а сами информационные активы, средства защиты, базы данных и серверы предписывает размещать в основном и резервном центрах банка: в здании банка, его филиалах, в дата-центре Центрального банка на облачных технологиях либо в государственных дата-центрах.

Окремо про регулятора. Положення про мінімальні вимоги до інформаційної безпеки комерційних банків — № 3669 від 18 серпня 2025 року, набуло чинності 20 листопада — вимагає резервний центр обробки даних не менш ніж за 50 км від основного, а самі інформаційні активи, засоби захисту, бази даних і сервери приписує розміщувати в основному й резервному центрах банку: у будівлі банку, його філіях, у дата-центрі Центрального банку на хмарних технологіях або в державних дата-центрах.

A separate word on the regulator. The regulation on minimum information-security requirements for commercial banks — No. 3669 of 18 August 2025, in force since 20 November — requires the backup data centre to be at least 50 km from the primary one, and prescribes that information assets, security systems, databases and servers be housed in the bank’s primary and backup centres: in the bank’s own building, its branches, the Central Bank’s cloud-based data centre or state data centres.

50 км — это меньше 1 мс, синхронная запись живёт спокойно. Отсюда честная развилка, которую я предлагаю обсуждать открыто: либо 50–100 км и нулевая точка восстановления, но обе площадки в одном сейсмическом и энергетическом регионе, либо 300–600 км и настоящая защита от регионального события ценой потери синхронности. Оба варианта законны. Первый чаще выбирают те, кто боится сбоя, второй — те, кто боится события.

50 км — це менше 1 мс, синхронний запис живе спокійно. Звідси чесна розвилка, яку я пропоную обговорювати відкрито: або 50–100 км і нульова точка відновлення, але обидва майданчики в одному сейсмічному та енергетичному регіоні, або 300–600 км і справжній захист від регіональної події ціною втрати синхронності. Обидва варіанти законні. Перший частіше обирають ті, хто боїться збою, другий — ті, хто боїться події.

Fifty kilometres is under 1 ms, and synchronous writes are comfortable there. Hence an honest fork worth discussing openly: either 50–100 km with a zero recovery point, but both sites in the same seismic and power region, or 300–600 km with genuine protection against a regional event at the cost of synchronicity. Both are lawful. The first is usually chosen by those who fear a failure, the second by those who fear an event.

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

І друга частина того самого пункту: перелік допустимих майданчиків у положенні закритий. Отже, орендну схему для банку треба звіряти спершу з ним, а вже потім із калькулятором. Це не заборона оренди, це вимога дивитися, у кого орендуєш.

And the second half of the same point: the list of permitted locations in the regulation is closed. So for a bank, a rental arrangement has to be checked against that list first and against the calculator second. This is not a ban on renting; it is a requirement to look at whom you are renting from.

02

Контур первый · цена дубляКонтур перший · ціна дубляEnvironment one · the price of a duplicate

Во что обходится вторая копия

У що обходиться друга копія

What the second copy really costs

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

Резервний майданчик платить не лише залізом: ядра ліцензуються з обох боків, а безстрокових ліцензій більше не продають.

The standby site pays in more than hardware: cores are licensed on both sides, and perpetual licences are no longer sold.

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

Далі починається арифметика, і саме тут замовники регулярно недораховують половину.

Then the arithmetic starts, and this is where customers routinely miss half of it.

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

Візьмемо звичні сьогодні платформи. У провідного вендора гіперконвергентної інфраструктури в ліцензійній політиці написано прямо: майданчики аварійного відновлення потребують окремого ліцензування, а ліцензії на файлові та об’єктні сервіси потрібні і на джерелі, і на цілі, в обсязі спожитої ємності з кожного боку. Тобто резервний майданчик платить майже стільки ж, скільки основний, і платить не лише залізом.

Take the platforms that are common today. The leading hyperconverged vendor states it plainly in its licensing policy: disaster-recovery sites require separate licensing, and file and object service licences are needed on both the source and the target, sized by the capacity consumed on each side. So the standby site pays nearly as much as the primary one, and not only in hardware.

На классическом трёхуровневом стеке история не лучше, а после смены владельца платформы в 2024 году стала заметно хуже. Лицензирование теперь подписочное и считается по физическим ядрам, с минимумом 16 ядер на процессор — процессор на 8 или 12 ядер всё равно оплачивается как 16. Считаются все ядра всех хостов. Резервная площадка на классическом стеке — это ещё один комплект серверов со своими ядрами, ещё один массив, ещё одна фабрика хранения и ещё одна подписка сверху.

На класичному трирівневому стеку історія не краща, а після зміни власника платформи у 2024 році стала помітно гіршою. Ліцензування тепер передплатне і рахується за фізичними ядрами, з мінімумом 16 ядер на процесор — процесор на 8 або 12 ядер однаково оплачується як 16. Рахуються всі ядра всіх хостів. Резервний майданчик на класичному стеку — це ще один комплект серверів зі своїми ядрами, ще один масив, ще одна фабрика зберігання і ще одна підписка згори.

On a classic three-tier stack the story is no better, and after the platform changed hands in 2024 it became markedly worse. Licensing is now subscription-based and counted by physical cores, with a minimum of 16 cores per processor — an 8- or 12-core processor is still billed as 16. Every core of every host counts. A standby site on a classic stack means another set of servers with their own cores, another array, another storage fabric and another subscription on top.

Что придётся оплатить на резервной площадкеЩо доведеться оплатити на резервному майданчикуWhat the standby site actually costs you

Три способа построить вторую площадку и то, какие строки сметы каждый из них оставляет.Три способи побудувати другий майданчик і те, які рядки кошторису кожен із них залишає.Three ways to build the second site, and which cost lines each of them leaves in place.

Полный дубльПовний дубльFull duplicateЧастичный резервЧастковий резервPartial standbyАрендаОрендаRented
Серверы и их физические ядраСервери та їхні фізичні ядраServers and their physical cores
Подписка на платформу виртуализацииПідписка на платформу віртуалізаціїVirtualisation platform subscription
Массив и фабрика храненияМасив і фабрика зберіганняArray and storage fabric
Лицензии файловых и объектных сервисов на обеих сторонахЛіцензії файлових і об’єктних сервісів з обох боківFile and object service licences on both sides
Поддержка и продленияПідтримка і продовженняSupport and renewals
Место, питание, охлаждениеМісце, живлення, охолодженняSpace, power, cooling
Ежемесячный платёж без конца срокаЩомісячний платіж без кінця строкуA monthly bill with no end date
Своё оборудование на стыке: межсетевой экран, коммутаторСвоє обладнання на стику: міжмережевий екран, комутаторYour own kit at the boundary: firewall, switch
платим полностьюплатимо повністюpaid in full платим частичноплатимо частковоpaid in part не платимне платимоnot paid
Рис.Рис.Fig. 2 Лицензии на файловые и объектные сервисы у ведущего вендора гиперконвергенции нужны и на источнике, и на цели — в объёме потреблённой ёмкости на каждой стороне.Ліцензії на файлові та об’єктні сервіси в провідного вендора гіперконвергенції потрібні і на джерелі, і на цілі — в обсязі спожитої ємності з кожного боку.With the leading hyperconverged vendor, file and object service licences are required on both the source and the target, sized by the capacity consumed on each side.

Здесь же спрятана вещь, которую я считаю главной новостью последних двух лет для темы «аренда или своё». Раньше покупка работала так: купил железо, купил бессрочную лицензию, зафиксировал стоимость платформы на весь срок службы и дальше платил только за поддержку. Сегодня бессрочных лицензий на новые контракты нет. Железо ты покупаешь, а платформу — арендуешь в любом случае. По оценкам консультантов, переход с чистого гипервизора на полный бандл поднимал годовые расходы в 2–5 раз, и минимумы по ядрам добавляли к этому свою долю.

Тут же захована річ, яку я вважаю головною новиною останніх двох років для теми «оренда чи своє». Раніше купівля працювала так: купив залізо, купив безстрокову ліцензію, зафіксував вартість платформи на весь строк служби і далі платив лише за підтримку. Сьогодні безстрокових ліцензій на нові контракти немає. Залізо ти купуєш, а платформу — орендуєш у будь-якому разі. За оцінками консультантів, перехід із чистого гіпервізора на повний бандл піднімав річні витрати у 2–5 разів, і мінімуми за ядрами додавали до цього свою частку.

Hidden in here is what I consider the biggest news of the past two years for the rent-or-own question. Buying used to work like this: you bought the hardware, bought a perpetual licence, fixed the platform cost for the whole service life and paid only for support afterwards. Today there are no perpetual licences on new contracts. You buy the hardware, and you rent the platform either way. Consultants estimate that moving from a bare hypervisor to the full bundle raised annual spend by a factor of 2 to 5, with core minimums adding their own share.

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

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

Which leads to a conclusion few people like: buying hardware no longer protects you from software price increases. The argument worth having is not buy-versus-rent, but which part of the stack you are willing to keep on subscription and for how long you have fixed it.

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

Але за останній рік до цього додалася друга обставина, яка перевернула структуру кошторису назад.

Over the past year, though, a second factor has flipped the structure of the estimate back again.

03

Контур первый · цены компонентовКонтур перший · ціни компонентівEnvironment one · component prices

Железо снова стало главной статьёй

Залізо знову стало головною статтею

Hardware is the main cost line again

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

Поки всі рахували ліцензійний периметр, кошторис переїхав в обладнання — і винна в цьому пам’ять.

While everyone was counting the licensing perimeter, the budget moved into hardware — and memory is the reason.

Ещё в 2024 году в типовом проекте на гиперконвергенции софт и железо делились примерно поровну. Сегодня в тех же по смыслу проектах я вижу совсем другую пропорцию — около 20% на лицензии и около 80% на оборудование. Особенно там, где в решении много оперативной памяти и флеша в любом виде: NVMe, SSD, кэш-ярусы, полки под резервные копии.

Ще у 2024 році в типовому проєкті на гіперконвергенції софт і залізо ділилися приблизно порівну. Сьогодні в тих самих за змістом проєктах я бачу зовсім іншу пропорцію — близько 20% на ліцензії і близько 80% на обладнання. Особливо там, де в рішенні багато оперативної пам’яті та флешу в будь-якому вигляді: NVMe, SSD, кеш-яруси, полиці під резервні копії.

As recently as 2024, a typical hyperconverged project split software and hardware roughly evenly. In projects of the same kind today I see a completely different ratio — about 20% licences and about 80% hardware. Especially where the design carries a lot of RAM and flash in any form: NVMe, SSD, cache tiers, shelves for backup copies.

Причина не в лицензиях, а в памяти. Gartner в апреле 2026 года дал прогноз: средние цены DRAM за 2026 год вырастут примерно на 125%, NAND — примерно на 234%, и заметного облегчения не будет раньше конца 2027 года. Квартальная динамика по данным TrendForce ещё нагляднее: в 1 квартале 2026 контрактные цены на обычный DRAM выросли на 90–95% квартал к кварталу, во 2 квартале — ещё на 58–63%, в 3 квартале рост замедлился до 13–18%, но замедлился он на уже раздутой базе.

Причина не в ліцензіях, а в пам’яті. Gartner у квітні 2026 року дав прогноз: середні ціни DRAM за 2026 рік зростуть приблизно на 125%, NAND — приблизно на 234%, і помітного полегшення не буде раніше кінця 2027 року. Квартальна динаміка за даними TrendForce ще наочніша: у 1 кварталі 2026 контрактні ціни на звичайний DRAM зросли на 90–95% квартал до кварталу, у 2 кварталі — ще на 58–63%, у 3 кварталі зростання сповільнилося до 13–18%, але сповільнилося воно на вже роздутій базі.

The cause is not licensing, it is memory. In April 2026 Gartner forecast that average DRAM prices would rise about 125% over 2026 and NAND about 234%, with no meaningful relief before the end of 2027. TrendForce’s quarterly figures make it plainer still: in Q1 2026 contract prices for conventional DRAM rose 90–95% quarter on quarter, in Q2 another 58–63%, and in Q3 growth slowed to 13–18% — but it slowed on an already inflated base.

Индекс контрактных цен на память и накопителиІндекс контрактних цін на пам’ять і накопичувачіContract price index for memory and storage media

За 100 приняты цены 4 квартала 2025 года. Замедление 3 квартала 2026 считается уже от новой базы.За 100 прийняті ціни 4 кварталу 2025 року. Уповільнення 3 кварталу 2026 рахується вже від нової бази.Q4 2025 prices are taken as 100. The Q3 2026 slowdown is measured against the new base, not the old one.

DRAMDRAMDRAM
4 квартал 20254 квартал 2025Q4 2025
100100100
2 квартал 20262 квартал 2026Q2 2026
309309309×3,1 за два квартала×3,1 за два квартали×3.1 in two quarters
NANDNANDNAND
4 квартал 20254 квартал 2025Q4 2025
100100100
2 квартал 20262 квартал 2026Q2 2026
272272272×2,7 за два квартала×2,7 за два квартали×2.7 in two quarters
Доля в смете типового проектаЧастка в кошторисі типового проєктуShare of a typical project budget
2024: лицензии2024: ліцензії2024: licences
≈ 50%≈ 50%≈ 50%
2024: оборудование2024: обладнання2024: hardware
≈ 50%≈ 50%≈ 50%
2026: лицензии2026: ліцензії2026: licences
≈ 20%≈ 20%≈ 20%потолок экономии на периметрестеля економії на периметріthe ceiling on licence savings
2026: оборудование2026: обладнання2026: hardware
≈ 80%≈ 80%≈ 80%
Рис.Рис.Fig. 3 Пока доля железа держится около 80%, спор об экономии на лицензиях идёт о пятой части бюджета.Поки частка заліза тримається близько 80%, суперечка про економію на ліцензіях іде про п’яту частину бюджету.While hardware holds at about 80%, an argument about saving on licences is an argument about a fifth of the budget.

Важно понимать природу этого роста, иначе легко ждать отката. Это не ковидный дефицит поставок, который рассасывается за квартал. Это структурное перераспределение производственных мощностей: пластины уходят под память для ускорителей и под корпоративные NVMe-накопители для центров обработки данных, а гиперскейлеры выкупают доступный объём долгосрочными контрактами. По оценке IDC, прирост предложения DRAM в 2026 году составит всего 16%, NAND — 17%, при исторической норме 20–30%. Новые заводы не выходят на объём раньше конца 2027 года.

Важливо розуміти природу цього зростання, інакше легко чекати відкату. Це не ковідний дефіцит постачань, який розсмоктується за квартал. Це структурний перерозподіл виробничих потужностей: пластини йдуть під пам’ять для прискорювачів і під корпоративні NVMe-накопичувачі для центрів обробки даних, а гіперскейлери викуповують доступний обсяг довгостроковими контрактами. За оцінкою IDC, приріст пропозиції DRAM у 2026 році становитиме лише 16%, NAND — 17%, за історичної норми 20–30%. Нові заводи не виходять на обсяг раніше кінця 2027 року.

It matters to understand the nature of this rise, or it is easy to sit waiting for a rollback. This is not a covid-era supply shortage that clears in a quarter. It is a structural reallocation of manufacturing capacity: wafers are going into memory for accelerators and into enterprise NVMe drives for data centres, while hyperscalers lock up the available volume with long-term contracts. IDC puts 2026 supply growth at just 16% for DRAM and 17% for NAND, against a historical norm of 20–30%. New fabs do not reach volume before the end of 2027.

Проценты квартал к кварталу скрывают главное, поэтому смотреть надо на накопленный индекс. Если принять цены 4 квартала 2025 года за 100, то к концу 2 квартала 2026 DRAM стоит 309, а NAND — 272. То есть за 2 квартала память подорожала в 3,1 раза, накопители — в 2,7. Замедление 3 квартала считается от этой базы, а не от той, по которой верстался ваш прошлогодний бюджет.

Відсотки квартал до кварталу приховують головне, тому дивитися треба на накопичений індекс. Якщо прийняти ціни 4 кварталу 2025 року за 100, то до кінця 2 кварталу 2026 DRAM коштує 309, а NAND — 272. Тобто за 2 квартали пам’ять подорожчала у 3,1 раза, накопичувачі — у 2,7. Уповільнення 3 кварталу рахується від цієї бази, а не від тієї, за якою верстався ваш торішній бюджет.

Quarter-on-quarter percentages hide the point, so look at the cumulative index instead. Take Q4 2025 prices as 100, and by the end of Q2 2026 DRAM stands at 309 and NAND at 272. In two quarters memory became 3.1 times dearer and storage media 2.7 times. The Q3 slowdown is measured from that base, not from the one your last year’s budget was drawn against.

Для нашего разговора отсюда следуют три вещи, и они не сводятся к «покупать дороже».

Для нашої розмови звідси випливають три речі, і вони не зводяться до «купувати дорожче».

Three things follow for our purposes, and none of them is simply “buying costs more”.

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

Перше: точка порівняння зсунулася, але в обидва боки одразу. Купівля подорожчала — це очевидно. Але провайдер закуповує те саме залізо в тих самих постачальників, тому орендні ставки поїдуть слідом, із затримкою на строк чинних контрактів. Розрахунок за торішніми ставками оренди і сьогоднішніми цінами купівлі бреше на користь оренди.

First: the point of comparison has moved, but it has moved both ways at once. Buying became more expensive — that much is obvious. But the provider buys the same hardware from the same suppliers, so rental rates will follow, lagging by the term of their current contracts. A comparison built on last year’s rental rates and today’s purchase prices lies in favour of renting.

За 2 квартала память подорожала в 3,1 раза, накопители — в 2,7. Замедление считается от этой базы, а не от той, по которой верстался ваш прошлогодний бюджет.

За 2 квартали пам’ять подорожчала у 3,1 раза, накопичувачі — у 2,7. Уповільнення рахується від цієї бази, а не від тієї, за якою верстався ваш торішній бюджет.

In two quarters memory became 3.1 times dearer and storage media 2.7 times. The slowdown is measured from that base, not from the one your last year’s budget was drawn against.

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

Друге, і воно важливіше за ціну: строки постачання за великими партіями пам’яті розтягнулися за 40 тижнів. Ризик тепер не в тому, що конфігурація подорожчає, а в тому, що потрібних модулів і накопичувачів може не виявитися вчасно ні за які гроші. Це окремий рядок ризику, і обговорювати його треба до підписання, а не після.

Second, and this matters more than price: lead times on large memory orders have stretched past 40 weeks. The risk is no longer that the configuration gets dearer, but that the modules and drives you need may not arrive in time at any price. That is a risk line of its own, and it belongs in the conversation before signature, not after.

Третье: рост цен бьёт по резервной площадке сильнее, чем по основной. Основная обычно уже куплена, а резерв только предстоит купить — по новым ценам. Это самый практичный аргумент за неполный резерв, о котором дальше.

Третє: зростання цін б’є по резервному майданчику сильніше, ніж по основному. Основний зазвичай уже куплений, а резерв тільки належить купити — за новими цінами. Це найпрактичніший аргумент за неповний резерв, про який далі.

Third: the price rise hits the standby site harder than the primary one. The primary has usually been bought already; the standby is still to be bought, at the new prices. That is the most practical argument for a partial standby, which comes next.

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

І висновок за розділом. Раз частка заліза в кошторисі зросла до 80%, стеля економії на ліцензійному периметрі — п’ята частина бюджету. Решта чотири п’ятих визначаються конфігурацією пам’яті та флешу.

And the conclusion for this section. With hardware now at 80% of the estimate, the ceiling on any licensing-perimeter saving is a fifth of the budget. The other four fifths are decided by the memory and flash configuration.

04

Контур первый · уровень резерваКонтур перший · рівень резервуEnvironment one · the level of standby

Резерв не обязан быть полным

Резерв не зобов’язаний бути повним

A standby site does not have to be complete

Уровень обслуживания на резерве — это решение, которое принимают и записывают, а не то, что получается само.

Рівень обслуговування на резерві — це рішення, яке ухвалюють і записують, а не те, що виходить само.

The service level on the standby site is a decision you make and write down, not something that emerges by itself.

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

Це найбільша економія в усій розмові, більша за будь-яку оренду, і чомусь вона обговорюється найрідше.

This is the single largest saving in the whole conversation, larger than any rental arrangement — and somehow the least discussed.

Если заранее описать деградацию — на резервной площадке поднимаем системы первой категории, вторую и третью не поднимаем до восстановления основной, — то резерв спокойно живёт на 50–60% мощности. Это не халтура, это осознанный уровень обслуживания, зафиксированный в регламенте и проверенный на учениях. Халтура — это когда 100-процентный резерв нарисован в спецификации, а на учениях выясняется, что половина систем на нём не стартует.

Якщо заздалегідь описати деградацію — на резервному майданчику піднімаємо системи першої категорії, другу і третю не піднімаємо до відновлення основного, — то резерв спокійно живе на 50–60% потужності. Це не халтура, це усвідомлений рівень обслуговування, зафіксований у регламенті й перевірений на навчаннях. Халтура — це коли 100-відсотковий резерв намальований у специфікації, а на навчаннях з’ясовується, що половина систем на ньому не стартує.

If you describe the degradation in advance — on the standby site we bring up category-one systems, and categories two and three stay down until the primary is restored — then the standby lives comfortably on 50–60% of the capacity. That is not cutting corners; it is a deliberate service level, written into the runbook and verified in a drill. Cutting corners is when a 100% standby is drawn in the specification and the drill reveals that half the systems will not start on it.

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

Тут же треба закрити спокусу, яка виникає у всіх, хто побачив ціни на компоненти: поставити на резерв техніку, що відпрацювала перше коло на основному майданчику. Обладнання ми рахуємо на 3 роки первинної експлуатації під гарантією плюс 3 роки другого кола на постгарантійній підтримці, і арифметика виглядає спокусливо.

And here we should close off a temptation that occurs to everyone who has seen component prices: putting hardware that has served its first cycle on the primary site into the standby. We plan equipment as 3 years of primary operation under warranty plus 3 years of a second cycle on post-warranty support, and the arithmetic looks tempting.

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

Для продуктивного навантаження я проти, і причин дві. Перша організаційна: майданчик зі старого заліза перестає сприйматися серйозно, і за півроку на нього тихо забивають — не оновлюють прошивки, не ганяють навчання, не стежать за деградацією дисків. Друга технічна: техніка другого кола має помітно більший шанс відмовити саме тоді, коли на неї піде навантаження, тобто в момент аварії на основному майданчику або прямо перед ним. Резерв, який ламається під час приймання навантаження, гірший за відсутність резерву — на нього розраховували.

For production workloads I am against it, for two reasons. The first is organisational: a site built from old hardware stops being taken seriously, and within six months it is quietly neglected — firmware not updated, drills not run, disk degradation not watched. The second is technical: second-cycle hardware has a markedly higher chance of failing exactly when load arrives on it, that is during or just before an outage on the primary site. A standby that breaks while taking the load is worse than no standby at all — people were counting on it.

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

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

Besides, the norm in banks today is identical hardware on both sites, and that is a requirement from the risk function, usually written down explicitly. Arguing with it on technical grounds is futile and pointless.

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

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

For test environments, development and workloads whose downtime the business can absorb, second-cycle hardware is a perfectly sound choice. That is precisely where it should be moved, freeing budget for the production standby.

Третий приём — вынести из резерва то, что физически не обязано там стоять. Об этом следующие два раздела.

Третій прийом — винести з резерву те, що фізично не зобов’язане там стояти. Про це наступні два розділи.

A third technique is to take out of the standby whatever does not physically have to be there. The next two sections are about that.

05

Контур второй · арифметика каналаКонтур другий · арифметика каналуEnvironment two · link arithmetic

Арифметика канала

Арифметика каналу

The arithmetic of the link

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

Каналом між майданчиками іде не повний обсяг, а унікальні блоки. Вузьких місць рівно два, і обидва варто винести в окремий рядок.

What crosses the link between sites is unique blocks, not the full volume. There are exactly two bottlenecks, and both deserve their own line in the project.

Про резервное копирование существует стойкое заблуждение, которое я и сам какое-то время повторял: что репликация между площадками упирается в канал, потому что «терабайты в сутки не передать». Давайте посчитаем, потому что цифры получаются неожиданные в обе стороны.

Про резервне копіювання існує стійка хибна думка, яку я і сам якийсь час повторював: що реплікація між майданчиками впирається в канал, бо «терабайти на добу не передати». Порахуймо, бо цифри виходять несподівані в обидва боки.

There is a persistent misconception about backup, one I repeated myself for a while: that replication between sites is limited by the link, because “you cannot move terabytes a day”. Let us count, because the numbers turn out surprising in both directions.

Сначала верхняя граница. При реалистичных 85% полезной утилизации канал 100 Гбит/с переносит около 300 ТБ за 8 часов и около 900 ТБ за сутки. Канал 10 Гбит/с — 31 ТБ за 8 часов, 92 ТБ за сутки. Отсюда сразу видно, что фраза «передать 1000 ТБ за ночь по сотке» неверна: 1000 ТБ по 100 Гбит/с — это 26 часов, в ночное окно они не влезают.

Спочатку верхня межа. За реалістичних 85% корисної утилізації канал 100 Гбіт/с переносить близько 300 ТБ за 8 годин і близько 900 ТБ за добу. Канал 10 Гбіт/с — 31 ТБ за 8 годин, 92 ТБ за добу. Звідси одразу видно, що фраза «передати 1000 ТБ за ніч по сотці» невірна: 1000 ТБ по 100 Гбіт/с — це 26 годин, у нічне вікно вони не влазять.

Start with the upper bound. At a realistic 85% usable utilisation, a 100 Gbit/s link moves about 300 TB in 8 hours and about 900 TB in a day. A 10 Gbit/s link moves 31 TB in 8 hours and 92 TB in a day. Which immediately shows that “we will push 1000 TB overnight on the hundred-gig” is wrong: 1000 TB at 100 Gbit/s is 26 hours, and that does not fit into a night window.

Время передачи объёма между площадкамиЧас передавання обсягу між майданчикамиTransfer time between sites

При реалистичной полезной утилизации канала 85%.За реалістичної корисної утилізації каналу 85%.At a realistic 85% usable link utilisation.

ОбъёмОбсягVolumeКанал 10 Гбит/сКанал 10 Гбіт/с10 Gbit/s linkКанал 100 Гбит/сКанал 100 Гбіт/с100 Gbit/s linkНочное окно 8 часовНічне вікно 8 годинAn 8-hour night window
9 ТБ — суточная дельта, нижняя оценка9 ТБ — добова дельта, нижня оцінка9 TB — daily delta, low estimate≈ 2 ч≈ 2 год≈ 2 hминутыхвилиниminutesзакрывается с запасомзакривається із запасомfits with room to spare
38 ТБ — суточная дельта, верхняя оценка38 ТБ — добова дельта, верхня оцінка38 TB — daily delta, high estimate≈ 10 ч≈ 10 год≈ 10 hменьше часаменше годиниunder an hourна 10 Гбит/с уже не закрываетсяна 10 Гбіт/с уже не закриваєтьсяno longer fits on 10 Gbit/s
92 ТБ92 ТБ92 TBсуткидобаa full day≈ 2,5 ч≈ 2,5 год≈ 2.5 hпредел суток на 10 Гбит/смежа доби на 10 Гбіт/сthe daily ceiling of a 10 Gbit/s link
300 ТБ300 ТБ300 TBне переноситсяне переноситьсяnot feasible8 ч8 год8 hровно окно на 100 Гбит/срівно вікно на 100 Гбіт/сexactly the window on 100 Gbit/s
1000 ТБ — первичная заливка1000 ТБ — первинне заливання1000 TB — initial seedingне переноситсяне переноситьсяnot feasible≈ 26 ч≈ 26 год≈ 26 hв ночь не влезаету ніч не влазитьdoes not fit into a night
Рис.Рис.Fig. 4 По каналу идёт не полный объём, а уникальные блоки после дедупликации: 1500 ТБ защищаемых данных при изменяемости 2–5% и уплотнении 3–5 раз дают от 9 до 38 ТБ в сутки.Каналом іде не повний обсяг, а унікальні блоки після дедуплікації: 1500 ТБ даних, що захищаються, за змінюваності 2–5% і ущільнення 3–5 разів дають від 9 до 38 ТБ на добу.What crosses the link is not the full volume but unique blocks after deduplication: 1500 TB of protected data at a 2–5% daily change rate and a 3–5× reduction on the wire gives 9 to 38 TB per day.

Но главное не это. По каналу между площадками никто не гонит полный объём. Идут изменения, а после дедупликации — только уникальные блоки. Возьмите комплекс с 1500 ТБ защищаемых данных, суточную изменяемость 2–5% и коэффициент уплотнения на проводе от 3 до 5 раз. Получится от 9 до 38 ТБ в сутки. Это 2–10 часов на 10 Гбит/с и меньше часа на 100 Гбит/с.

Але головне не це. Каналом між майданчиками ніхто не жене повний обсяг. Ідуть зміни, а після дедуплікації — лише унікальні блоки. Візьміть комплекс із 1500 ТБ даних, що захищаються, добову змінюваність 2–5% і коефіцієнт ущільнення на проводі від 3 до 5 разів. Вийде від 9 до 38 ТБ на добу. Це 2–10 годин на 10 Гбіт/с і менше години на 100 Гбіт/с.

But that is not the main point. Nobody pushes the full volume across the link between sites. What travels is the changes, and after deduplication only the unique blocks. Take a complex with 1500 TB of protected data, a daily change rate of 2–5% and a 3–5× reduction on the wire. That gives 9 to 38 TB a day: 2–10 hours on 10 Gbit/s and under an hour on 100 Gbit/s.

То есть для ежедневной работы канал узким местом не является — при условии, что дедупликация действительно работает и на второй площадке стоит приёмник, умеющий принимать уникальные блоки, а не полный поток.

Тобто для щоденної роботи канал вузьким місцем не є — за умови, що дедуплікація справді працює і на другому майданчику стоїть приймач, який уміє приймати унікальні блоки, а не повний потік.

So for day-to-day operation the link is not the bottleneck — provided deduplication genuinely works and the second site has a target able to receive unique blocks rather than the full stream.

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

Але в цієї картини є важливе застереження, і його треба перевіряти за вашим регламентом, а не за середнім по ринку. Дельта залишається маленькою, поки йдуть інкрементальні завдання. Щойно за нормативом знімається регулярна повна копія — а в багатьох регламентах вона обов’язкова щотижня або щомісяця, — добовий обсяг вистрибує на порядок і впирається рівно в ті години з таблиці вище. Тож рахувати треба не середню добу, а найважчу: ніч після повного бекапу за одночасної роботи решти завдань. Якщо цього дня вікно не закривається, воно не закривається взагалі.

There is an important caveat to this picture, and it has to be checked against your own runbook rather than a market average. The delta stays small while incremental jobs are running. The moment the policy calls for a regular full copy — and in many runbooks that is mandatory weekly or monthly — the daily volume jumps by an order of magnitude and runs straight into the hours in the table above. So the figure to plan against is not an average day but the heaviest one: the night after a full backup, with every other job running alongside. If the window does not close on that day, it does not close at all.

Канал становится узким местом ровно в двух точках, и обе стоит выносить в отдельную строку проекта. Первая — первичная заливка, когда копию надо создать с нуля. Вторая — массовое восстановление, когда данные надо тащить обратно. Про первую все помнят, про вторую вспоминают в момент аварии.

Канал стає вузьким місцем рівно у двох точках, і обидві варто виносити в окремий рядок проєкту. Перша — первинне заливання, коли копію треба створити з нуля. Друга — масове відновлення, коли дані треба тягнути назад. Про першу всі пам’ятають, про другу згадують у момент аварії.

The link becomes the bottleneck at exactly two points, and both belong in a separate line of the project. The first is the initial seeding, when the copy has to be created from scratch. The second is a mass restore, when the data has to be dragged back. Everyone remembers the first; the second is remembered during the outage.

06

Контур второй · схема храненияКонтур другий · схема зберіганняEnvironment two · the storage design

Вторая площадка без второго комплекта

Другий майданчик без другого комплекту

A second site without a second set of everything

Полный трёхъярусный комплекс на основной площадке, медиа-серверы и арендованное хранилище — на резервной.

Повний триярусний комплекс на основному майданчику, медіа-сервери та орендоване сховище — на резервному.

A full three-tier stack on the primary site; media servers and rented storage on the standby one.

Схема, к которой я прихожу, когда считаю такую вторую площадку, выглядит так.

Схема, до якої я приходжу, коли рахую такий другий майданчик, виглядає так.

The design I arrive at when costing a second site of this kind looks like this.

На основной площадке строим полноценный трёхъярусный комплекс: быстрый ярус на NVMe под оперативное восстановление, дисковый ярус под основную глубину, ленточный ярус под долговременное хранение и неизменяемые копии. Всё своё, всё под контролем, восстановление из первого яруса измеряется минутами.

На основному майданчику будуємо повноцінний триярусний комплекс: швидкий ярус на NVMe під оперативне відновлення, дисковий ярус під основну глибину, стрічковий ярус під довготривале зберігання і незмінні копії. Усе своє, усе під контролем, відновлення з першого ярусу вимірюється хвилинами.

On the primary site we build a full three-tier stack: a fast NVMe tier for operational restores, a disk tier for the bulk of the retention depth, and a tape tier for long-term retention and immutable copies. All owned, all under control, and restores from the first tier are measured in minutes.

На второй площадке полный дубль этого хозяйства не строим. Ставим медиа-серверы и объектное хранилище в аренде, а рядом — небольшой массив на NVMe как зону приземления. Аргумент здесь не сетевой, и это важно: в объектное хранилище данные тоже уходят по сети, тот же трафик. Аргумент капитальный — не нужен второй комплект дисковых полок и вторая ленточная библиотека, а это самая скучная и самая дорогая часть второй площадки. С учётом того, что творится с ценами на накопители, экономия здесь выросла за год заметно.

На другому майданчику повний дубль цього господарства не будуємо. Ставимо медіа-сервери та об’єктне сховище в оренді, а поруч — невеликий масив на NVMe як зону приземлення. Аргумент тут не мережевий, і це важливо: в об’єктне сховище дані теж ідуть мережею, той самий трафік. Аргумент капітальний — не потрібен другий комплект дискових полиць і друга стрічкова бібліотека, а це найнудніша і найдорожча частина другого майданчика. З огляду на те, що коїться з цінами на накопичувачі, економія тут зросла за рік помітно.

On the second site we do not build a duplicate of all that. We put in media servers and rented object storage, with a small NVMe array alongside as a landing zone. The argument here is not about networking, and that matters: data goes to object storage over the network too, the same traffic. The argument is capital — you do not need a second set of disk shelves and a second tape library, and those are the dullest and most expensive part of a second site. Given what is happening to media prices, that saving has grown noticeably over the year.

Гибридная схема резервного копирования на двух площадкахГібридна схема резервного копіювання на двох майданчикахA hybrid backup design across two sites

Полный комплекс на основной площадке, аренда и зона приземления на резервной.Повний комплекс на основному майданчику, оренда і зона приземлення на резервному.A complete stack on the primary site; rented capacity and a landing zone on the standby one.

Основная площадка — своё, три ярусаОсновний майданчик — своє, три ярусиPrimary site — owned, three tiers

  • Быстрый ярус на NVMe — оперативное восстановление за минутыШвидкий ярус на NVMe — оперативне відновлення за хвилиниA fast NVMe tier — operational restores in minutes
  • Дисковый ярус — основная глубина храненияДисковий ярус — основна глибина зберіганняA disk tier — the bulk of the retention depth
  • Ленточный ярус — долговременное хранение и неизменяемые копииСтрічковий ярус — довготривале зберігання і незмінні копіїA tape tier — long-term retention and immutable copies

Резервная площадка — аренда плюс минимум своегоРезервний майданчик — оренда плюс мінімум свогоStandby site — rented, plus a minimum of your own

  • Медиа-серверы свои — они дёшевы и держат логикуМедіа-сервери свої — вони дешеві й тримають логікуYour own media servers — they are cheap and hold the logic
  • Объектное хранилище в аренде вместо второго комплекта полокОб’єктне сховище в оренді замість другого комплекту полицьRented object storage instead of a second set of shelves
  • Небольшой массив на NVMe как зона приземленияНевеликий масив на NVMe як зона приземленняA small NVMe array as the landing zone

Не нужны второй комплект дисковых полок и вторая ленточная библиотека — самая дорогая часть дубля.Не потрібні другий комплект дискових полиць і друга стрічкова бібліотека — найдорожча частина дубля.No second set of disk shelves and no second tape library — the most expensive part of a duplicate.

Чем за это платимЧим за це платимоWhat it costs

  • Нисходящий трафик при массовом восстановлении — отдельная статьяНизхідний трафік при масовому відновленні — окрема статтяEgress traffic on a mass restore is a line item of its own
  • Минимальный оплачиваемый срок в холодных классах храненияМінімальний оплачуваний строк у холодних класах зберіганняMinimum billable retention in cold storage classes
  • Глубину раскладываем по классам: 7–14 суток горячими, остальное в архивГлибину розкладаємо за класами: 7–14 діб гарячими, решта в архівRetention is split by class: 7–14 days hot, the rest archival
  • Для банков — сверка площадки арендодателя с перечнем регулятораДля банків — звірка майданчика орендодавця з переліком регулятораFor banks, the provider’s site must be checked against the regulator’s list
Рис.Рис.Fig. 5 Зона приземления — не роскошь. Без неё время восстановления определяется каналом до арендованного хранилища в обратную сторону.Зона приземлення — не розкіш. Без неї час відновлення визначається каналом до орендованого сховища у зворотний бік.The landing zone is not a luxury. Without it, restore time is dictated by the link back from the rented storage.

Дальше — честно про минусы, потому что схема их имеет.

Далі — чесно про мінуси, бо схема їх має.

Now honestly about the downsides, because the design has them.

Обратный путь стоит денег и времени. Восходящий трафик в облако обычно бесплатен, нисходящий — нет, и при массовом восстановлении счёт за исходящий трафик становится отдельной статьёй. У холодных классов хранения есть минимальный оплачиваемый срок: удалили объект раньше — заплатили как за полный срок. Для короткого срока хранения это ломает экономику полностью, поэтому глубину надо раскладывать по классам: горячие 7–14 суток в быстром классе или локально, всё остальное — в архивном.

Зворотний шлях коштує грошей і часу. Висхідний трафік у хмару зазвичай безкоштовний, низхідний — ні, і при масовому відновленні рахунок за вихідний трафік стає окремою статтею. У холодних класів зберігання є мінімальний оплачуваний строк: видалили об’єкт раніше — заплатили як за повний строк. Для короткого строку зберігання це ламає економіку повністю, тому глибину треба розкладати за класами: гарячі 7–14 діб у швидкому класі або локально, усе інше — в архівному.

The way back costs money and time. Ingress to the cloud is usually free, egress is not, and on a mass restore the egress bill becomes a line item of its own. Cold storage classes carry a minimum billable retention: delete an object early and you pay as if for the full term. For short retention that breaks the economics entirely, so depth has to be split by class: a hot 7–14 days in a fast class or locally, everything else in the archive class.

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

Зона приземлення на NVMe — не розкіш, а обов’язкова частина схеми. Без неї час відновлення визначається каналом до хмари у зворотний бік, а ми вже порахували, скільки це годин. З нею ви викачуєте потрібне заздалегідь або порціями і відновлюєте вже з локального швидкого сховища.

The NVMe landing zone is not a luxury but a mandatory part of the design. Without it, restore time is set by the link back from the cloud, and we have already counted those hours. With it, you pull down what you need in advance or in batches and restore from local fast storage.

И для банков — сверка с положением № 3669 по перечню допустимых площадок. Резервная копия ядра содержит сведения, составляющие банковскую тайну, и вопрос «у кого арендован объектный слой» здесь не коммерческий, а регуляторный.

І для банків — звірка з положенням № 3669 щодо переліку допустимих майданчиків. Резервна копія ядра містить відомості, що становлять банківську таємницю, і питання «у кого орендований об’єктний шар» тут не комерційне, а регуляторне.

And for banks, a check against regulation No. 3669 and its list of permitted locations. A backup copy of the core contains information covered by banking secrecy, so the question of whose object storage you are renting is a regulatory one, not a commercial one.

07

Контур третий · платформа данныхКонтур третій · платформа данихEnvironment three · the data platform

У аналитики четыре слоя, а не один

В аналітики чотири шари, а не один

Analytics has four layers, not one

Требование «реплицировать озеро целиком» почти всегда избыточно. А самый критичный слой при этом самый маленький.

Вимога «реплікувати озеро цілком» майже завжди надмірна. А найкритичніший шар при цьому найменший.

“Replicate the whole lake” is almost always excessive. And the most critical layer is the smallest one.

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

З платформами даних ситуація зворотна: там зазвичай перестраховуються. Надходить вимога «реплікувати озеро даних на другий майданчик», і ніхто не питає навіщо.

With data platforms it is the other way round: people over-insure. A requirement arrives to “replicate the data lake to the second site”, and nobody asks what for.

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

Теза, з якої я зазвичай починаю: сирий шар дублювати не треба. Він відновлюваний із джерел. Якщо у вас налагоджене захоплення змін із промислових баз, історію можна перелити заново, це довго, але не смертельно, і коштує незіставно дешевше за другий кластер зберігання. За нинішніх цін на флеш різниця особливо помітна.

The proposition I usually start from: the raw layer does not need duplicating. It is recoverable from the sources. If change capture from the production databases is working, the history can be reloaded — slow, but not fatal, and incomparably cheaper than a second storage cluster. At current flash prices the difference is especially visible.

Но общим правилом это делать нельзя, потому что платформа состоит из слоёв с очень разной ценой потери.

Але загальним правилом це робити не можна, бо платформа складається з шарів із дуже різною ціною втрати.

But it cannot be turned into a blanket rule, because the platform consists of layers whose loss costs very different amounts.

Слои платформы данных и политика резервированияШари платформи даних і політика резервуванняThe layers of a data platform and the protection policy for each

Самый большой слой резервировать не надо. Самый критичный — самый маленький.Найбільший шар резервувати не треба. Найкритичніший — найменший.The largest layer does not need protection. The most critical one is the smallest.

СлойШарLayerОбъёмОбсягVolumeЦена потериЦіна втратиCost of lossПолитикаПолітикаPolicy
Сырой слой и историческая глубинаСирий шар та історична глибинаRaw layer and historical depthнаибольшийнайбільшийthe largestвремя на перезаливкучас на перезаливанняthe time to reload itне реплицируем, восстанавливаем из источниковне реплікуємо, відновлюємо з джерелnot replicated — reloaded from the sources
Витрины, датасеты, выборки по клиентамВітрини, датасети, вибірки за клієнтамиMarts, datasets, customer extractsумеренныйпомірнийmoderateдолгий пересчётдовгий перерахунокa long recomputationвыгружаем в объектное хранилищевивантажуємо в об’єктне сховищеexported to object storage
Онлайновый слой признаковОнлайновий шар ознакOnline feature layerдесятки, редко сотни ГБдесятки, рідко сотні ГБtens, rarely hundreds of GBостанавливается бизнес-процессзупиняється бізнес-процесthe business process stopsрезервируем полноценно — это дёшеворезервуємо повноцінно — це дешевоfully protected — and it is cheap
Метаданные, каталог, схемы, код конвейеровМетадані, каталог, схеми, код конвеєрівMetadata, catalogue, schemas, pipeline codeничтожныймізернийnegligibleдатасеты становятся набором безымянных файловдатасети стають набором безіменних файлівdatasets become a pile of nameless filesрезервируем обязательнорезервуємо обов’язковоalways protected
Модели и журнал принятых решенийМоделі та журнал ухвалених рішеньModels and the decision logнебольшойневеликийsmallнечем подтвердить, как было принято решениенічим підтвердити, як було ухвалено рішенняno way to show how a decision was madeрезервируем обязательно — уже по правовой причинерезервуємо обов’язково — уже з правової причиниalways protected — for a legal reason now
Рис.Рис.Fig. 6 Требование «реплицировать озеро целиком» почти всегда избыточно, но общим правилом «не реплицировать ничего» это делать нельзя.Вимога «реплікувати озеро цілком» майже завжди надмірна, але загальним правилом «не реплікувати нічого» це робити не можна.“Replicate the whole lake” is almost always excessive — but that does not turn into a blanket rule of replicating nothing.

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

Сирий шар та історична глибина — не реплікуємо, відновлюємо з джерел. Вітрини, готові датасети і вибірки за клієнтами — вивантажуємо в об’єктне сховище, обсяг помірний, цінність висока, перераховувати їх з нуля довго.

The raw layer and the historical depth: not replicated, reloaded from the sources. Marts, finished datasets and customer extracts: exported to object storage — moderate volume, high value, and slow to recompute from scratch.

Онлайновый слой признаков — а вот здесь распространённая ошибка. Если на аналитике построен скоринг или антифрод, работающий в реальном времени, то хранилище признаков для онлайнового обращения имеет типовые требования порядка 30 мс на чтение в 95-м перцентиле и доступность от 99,95%, потому что его недоступность останавливает бизнес-процесс целиком. Объём при этом небольшой — десятки, редко сотни гигабайт. Его надо резервировать полноценно, и это дёшево.

Онлайновий шар ознак — а ось тут поширена помилка. Якщо на аналітиці побудований скоринг або антифрод, що працює в реальному часі, то сховище ознак для онлайнового звернення має типові вимоги порядку 30 мс на читання в 95-му перцентилі й доступність від 99,95%, бо його недоступність зупиняє бізнес-процес цілком. Обсяг при цьому невеликий — десятки, рідко сотні гігабайтів. Його треба резервувати повноцінно, і це дешево.

The online feature layer — and here is a common mistake. If scoring or real-time fraud detection is built on the analytics, the feature store serving online lookups typically requires around 30 ms read latency at the 95th percentile and availability from 99.95%, because its unavailability halts the business process entirely. The volume, meanwhile, is small — tens, rarely hundreds of gigabytes. It has to be fully protected, and that is cheap.

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

Метадані, каталог, схеми і код конвеєрів — обсяг узагалі мізерний, а без них відновлені датасети перетворюються на набір файлів, про які ніхто не пам’ятає, що в них лежить. Резервуємо обов’язково.

Metadata, the catalogue, schemas and pipeline code: the volume is negligible, yet without them restored datasets turn into a pile of files nobody remembers the contents of. Always protected.

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

Моделі та журнал ухвалених рішень — резервуємо обов’язково, і вже не з технічної причини. До цього повернемося в наступному розділі.

Models and the decision log: always protected, and no longer for a technical reason. We come back to that in the next section.

08

Контур четвёртый · искусственный интеллектКонтур четвертий · штучний інтелектEnvironment four · artificial intelligence

Между арендой и локальностью

Між орендою і локальністю

Between renting and staying local

Одна граница экономическая и считается по утилизации. Вторая — временная, и её деньгами не сдвинуть.

Одна межа економічна і рахується за утилізацією. Друга — часова, і її грошима не зсунути.

One boundary is economic and follows utilisation. The other is temporal, and money will not move it.

Здесь спор про аренду острее всего, потому что ускорители дороги, дефицитны и стареют быстрее, чем успевает пройти тендер.

Тут суперечка про оренду найгостріша, бо прискорювачі дорогі, дефіцитні й старіють швидше, ніж встигає пройти тендер.

This is where the rent-or-own argument is sharpest, because accelerators are expensive, scarce, and age faster than a tender takes to complete.

Начну с экономики, и она сводится к одному числу — устойчивой утилизации. Правило, которое сейчас повторяет рынок: ниже примерно 40% загрузки выгоднее арендовать, выше — владеть, а круглосуточный инференс делает владение безальтернативным. Разброс арендных ставок при этом чудовищный: обзор 25 провайдеров показал разницу почти в 14 раз за одну и ту же карту. То есть тезисы «аренда дешевле» и «аренда дороже» одинаково доказуемы, всё решает выбор поставщика и профиль загрузки.

Почну з економіки, і вона зводиться до одного числа — стійкої утилізації. Правило, яке зараз повторює ринок: нижче приблизно 40% завантаження вигідніше орендувати, вище — володіти, а цілодобовий інференс робить володіння безальтернативним. Розкид орендних ставок при цьому жахливий: огляд 25 провайдерів показав різницю майже в 14 разів за одну й ту саму карту. Тобто тези «оренда дешевша» і «оренда дорожча» однаково доказові, усе вирішує вибір постачальника і профіль завантаження.

I start with the economics, and they come down to one number — sustained utilisation. The rule the market currently repeats: below roughly 40% load renting wins, above it owning wins, and round-the-clock inference makes owning the only option. The spread in rental rates, meanwhile, is monstrous: a survey of 25 providers found an almost 14-fold difference for the same card. So “renting is cheaper” and “renting is dearer” are equally provable; what decides it is the choice of provider and the load profile.

Две границы для нагрузок искусственного интеллектаДві межі для навантажень штучного інтелектуTwo boundaries for AI workloads

Первая граница экономическая и считается по утилизации. Вторая временная, и её деньгами не сдвинуть.Перша межа економічна і рахується за утилізацією. Друга часова, і її грошима не зсунути.The first boundary is economic and follows utilisation. The second is temporal, and money does not move it.

Граница по утилизацииМежа за утилізацієюThe utilisation boundary

Ниже 40% устойчивой загрузкиНижче 40% стійкого завантаженняBelow 40% sustained load
выгоднее арендоватьвигідніше орендуватиrenting wins
Выше 40%Вище 40%Above 40%
выгоднее владетьвигідніше володітиowning wins
Круглосуточный инференсЦілодобовий інференсRound-the-clock inference
владение безальтернативноволодіння безальтернативнеowning is the only option

Обзор 25 провайдеров показал разницу почти в 14 раз за одну и ту же карту, так что «аренда дешевле» и «аренда дороже» одинаково доказуемы.Огляд 25 провайдерів показав різницю майже в 14 разів за одну й ту саму карту, тож «оренда дешевша» і «оренда дорожча» однаково доказові.A survey of 25 providers found an almost 14-fold spread for the same card, so “renting is cheaper” and “renting is dearer” are equally provable.

Граница по времени ответаМежа за часом відповідіThe response-time boundary

Медианная пауза в живой речиМедіанна пауза в живій мовіMedian pause in live speech
≈ 200 мс≈ 200 мс≈ 200 ms
Терпимый ответ роботаТерпима відповідь роботаA tolerable bot response
до ≈ 800 мсдо ≈ 800 мсup to ≈ 800 ms
Свыше 1,5 секундыПонад 1,5 секундиOver 1.5 seconds
собеседник считает, что связь оборваласьспіврозмовник вважає, що зв’язок обірвавсяthe caller assumes the line dropped

В 800 мс должны уложиться детекция конца фразы, распознавание, первый токен, синтез первого куска звука и сеть в обе стороны.У 800 мс мають вкластися детекція кінця фрази, розпізнавання, перший токен, синтез першого шматка звуку і мережа в обидва боки.Those 800 ms have to cover end-of-speech detection, recognition, the first token, synthesis of the first chunk of audio, and the network both ways.

Разделение, которое из этого следуетРозділення, що з цього випливаєThe split that follows

  • Обучение и переобучение — аренда: нагрузка эпизодическая, с пикамиНавчання і перенавчання — оренда: навантаження епізодичне, з пікамиTraining and retraining — rented: episodic, peaky load
  • Промышленный инференс круглые сутки — своё железоПромисловий інференс цілодобово — своє залізоProduction inference around the clock — your own hardware
  • Эксперименты и боковые проекты — аренда почти всегдаЕксперименти і бічні проєкти — оренда майже завждиExperiments and side projects — rented, almost always
  • Всё голосовое — локально, из-за бюджета времени ответаУсе голосове — локально, через бюджет часу відповідіAnything voice — local, because of the response-time budget
Рис.Рис.Fig. 7 Внешнее облако съедает бюджет времени раньше, чем модель начнёт говорить.Зовнішня хмара з’їдає бюджет часу раніше, ніж модель почне говорити.An external cloud eats the time budget before the model starts speaking.

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

Із цього випливає природне розділення. Навчання і перенавчання моделей — епізодичне навантаження з піками, його беремо в оренду. Промисловий інференс, що працює цілодобово рівним потоком, — своє залізо. Експериментальні та бічні проєкти — оренда майже завжди, бо їхній горизонт коротший навіть за перше коло експлуатації, не кажучи про друге.

A natural split follows. Training and retraining are episodic, peaky loads — rent them. Production inference running around the clock at a steady rate — your own hardware. Experimental and side projects — rented almost always, because their horizon is shorter than even the first operating cycle, let alone the second.

Теперь правовая часть, и за 2026 год она поменялась дважды в разные стороны.

Тепер правова частина, і за 2026 рік вона змінилася двічі в різні боки.

Now the legal side, which changed twice during 2026, in opposite directions.

Стало легче с локализацией. Закон № ЗРУ-1125 от 26 марта 2026 года изложил статью 27-1 в новой редакции и отменил прежнее сплошное требование хранить все персональные данные внутри страны. Обязательной локализации теперь подлежат 3 категории: биометрические данные, генетические данные и данные пользователей операторов телекоммуникаций. Для остальных персональных данных обработка за пределами страны допустима при выполнении одного из трёх условий той же статьи.

Стало легше з локалізацією. Закон № ЗРУ-1125 від 26 березня 2026 року виклав статтю 27-1 у новій редакції та скасував колишню суцільну вимогу зберігати всі персональні дані всередині країни. Обов’язковій локалізації тепер підлягають 3 категорії: біометричні дані, генетичні дані та дані користувачів операторів телекомунікацій. Для решти персональних даних обробка за межами країни допустима за виконання однієї з трьох умов тієї самої статті.

Localisation became easier. Law No. ZRU-1125 of 26 March 2026 restated article 27-1 and repealed the previous blanket requirement to keep all personal data inside the country. Three categories are now subject to mandatory localisation: biometric data, genetic data, and the data of telecom operators’ subscribers. For other personal data, processing outside the country is permitted if one of three conditions in the same article is met.

Держите в голове важное следствие: голос — это биометрия. Записи разговоров колл-центра и голосовые слепки попадают под обязательную локализацию, и никакое маскирование этого не отменяет.

Тримайте в голові важливий наслідок: голос — це біометрія. Записи розмов колл-центру і голосові зліпки підпадають під обов’язкову локалізацію, і жодне маскування цього не скасовує.

Keep an important consequence in mind: voice is biometric data. Call-centre recordings and voiceprints fall under mandatory localisation, and no amount of masking changes that.

Голос — это биометрия. Никакое маскирование этого не отменяет.

Голос — це біометрія. Жодне маскування цього не скасовує.

Voice is biometric data. No amount of masking changes that.

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

Стало жорсткіше із самим застосуванням моделей. Закон від 21 січня 2026 року встановив, що при ухваленні юридично значущих рішень, які зачіпають права і свободи людини, неприпустимо спиратися виключно на висновки систем на основі штучного інтелекту. За незаконну обробку персональних даних із застосуванням таких технологій запроваджено штраф від 50 до 100 базових розрахункових величин із конфіскацією засобів вчинення правопорушення.

The use of the models themselves became stricter. A law of 21 January 2026 established that legally significant decisions affecting a person’s rights and freedoms may not rest solely on the output of AI-based systems. Unlawful processing of personal data using such technologies now carries a fine of 50 to 100 base accounting units, with confiscation of the equipment used to commit the offence.

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

Для скорингу це пряма архітектурна вимога, а не юридична формальність. Потрібна людина в контурі ухвалення рішення, потрібна пояснюваність, потрібен журнал: які ознаки були на вході, яка версія моделі відпрацювала, хто зі співробітників підтвердив результат. Усе це зберігається у вас, а не в провайдера потужностей. Що зручно збігається з правильною інженерною практикою.

For scoring this is a direct architectural requirement, not a legal formality. You need a human in the decision loop, you need explainability, and you need a log: which features went in, which model version ran, and which member of staff confirmed the outcome. All of it is stored by you, not by the provider of the compute. Which conveniently coincides with sound engineering practice.

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

Про маскування даних перед відправленням у зовнішній контур — прийом робочий, але межі в нього вузькі. Для табличних ознак детермінована токенізація працює добре: зв’язки між таблицями зберігаються, якість моделі практично не страждає. Для вільного тексту і тим паче для голосу надійного маскування немає: розпізнавач сутностей помиляється, а за комбінацією решти ознак людина відновлюється. Тож «маскуємо і відправляємо» працює лише для структурованих ознак.

On masking data before sending it outside: the technique works, but its limits are narrow. For tabular features, deterministic tokenisation does well — relationships between tables are preserved and model quality barely suffers. For free text, and all the more for voice, there is no reliable masking: the entity recogniser makes mistakes, and the person is re-identifiable from the combination of remaining attributes. So “mask it and send it” holds only for structured features.

И последнее по этому контуру. Своё локальное железо под генеративные нагрузки нужно там, где важна скорость ответа. Голосовой робот в колл-центре — ровно такой случай: человек в разговоре ждёт ответа в пределах примерно 800 мс, медианная пауза между репликами в живой речи около 200 мс, а свыше 1,5 секунды собеседник считает, что связь оборвалась. В эти 800 мс должны уложиться детекция конца фразы, финальное распознавание, генерация первого токена, синтез первого куска звука и сеть в обе стороны. Внешнее облако съедает бюджет раньше, чем модель начнёт говорить.

І останнє за цим контуром. Своє локальне залізо під генеративні навантаження потрібне там, де важлива швидкість відповіді. Голосовий робот у колл-центрі — саме такий випадок: людина в розмові чекає відповіді в межах приблизно 800 мс, медіанна пауза між репліками в живій мові близько 200 мс, а понад 1,5 секунди співрозмовник вважає, що зв’язок обірвався. У ці 800 мс мають вкластися детекція кінця фрази, фінальне розпізнавання, генерація першого токена, синтез першого шматка звуку і мережа в обидва боки. Зовнішня хмара з’їдає бюджет раніше, ніж модель почне говорити.

And the last point on this environment. Local hardware for generative workloads is needed wherever response speed matters. A voice bot in a call centre is exactly that case: in conversation a person expects a reply within roughly 800 ms, the median pause between turns in live speech is about 200 ms, and beyond 1.5 seconds the caller assumes the line has dropped. Those 800 ms have to accommodate end-of-speech detection, final recognition, generation of the first token, synthesis of the first chunk of audio, and the network in both directions. An external cloud eats the budget before the model starts speaking.

09

Выбор площадкиВибір майданчикаChoosing the site

Куда именно арендовать: рядом или далеко

Куди саме орендувати: поруч чи далеко

Where exactly to rent: near or far

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

Вибір давно не зводиться до «своє залізо чи глобальний гіперскейлер». Локальний варіант закриває більше сценаріїв, ніж прийнято думати.

The choice stopped being “own hardware or a global hyperscaler” long ago. The local option covers more scenarios than people assume.

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

Розмова про оренду зазвичай ведеться так, ніби вибір стоїть між своїм залізом і глобальним гіперскейлером. На нашому ринку це давно не так, і локальний варіант заслуговує на окремий погляд.

The rental conversation is usually held as if the choice were between your own hardware and a global hyperscaler. In our market that stopped being true some time ago, and the local option deserves a separate look.

Внутри страны есть операторы с собственными дата-центрами уровня Tier III, инфраструктурой как услугой, объектным хранилищем и резервным копированием как услугой. Что они дают по сравнению с глобальным облаком: задержку в единицы миллисекунд вместо десятков, юрисдикцию внутри страны, договор и счёт в местной валюте, живого инженера, до которого можно доехать. Для трёх категорий данных под обязательной локализацией это не преимущество, а единственный законный вариант аренды.

Усередині країни є оператори з власними дата-центрами рівня Tier III, інфраструктурою як послугою, об’єктним сховищем і резервним копіюванням як послугою. Що вони дають порівняно з глобальною хмарою: затримку в одиниці мілісекунд замість десятків, юрисдикцію всередині країни, договір і рахунок у місцевій валюті, живого інженера, до якого можна доїхати. Для трьох категорій даних під обов’язковою локалізацією це не перевага, а єдиний законний варіант оренди.

Inside the country there are operators with their own Tier III data centres, infrastructure as a service, object storage and backup as a service. What they offer against a global cloud: latency in single-digit milliseconds instead of tens, jurisdiction inside the country, a contract and an invoice in local currency, and a live engineer you can drive to. For the three categories of data under mandatory localisation this is not an advantage but the only lawful way to rent.

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

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

With accelerators the situation has changed faster than people assume. Several operators now rent them inside the country, the cards were bought together with the servers, and at some providers that capacity sits noticeably under-loaded. The shortage written about in the global market transfers poorly to local rental right now: domestic demand simply has not caught up with supply. What to look at, accordingly, is not availability as such but the generation of the cards, the memory per card and the contract terms.

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

Чого в локального ринку поки зазвичай немає: глибини каталогу сервісів і зрілих керованих баз даних та черг. Це рідко критично для чотирьох контурів із цієї статті, але помітно, якщо ви розраховували перекласти експлуатацію платформи на провайдера.

What the local market usually still lacks: depth of service catalogue, and mature managed databases and queues. That is rarely critical for the four environments in this article, but it shows if you were counting on handing platform operations to the provider.

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

Окремо про те, що в розрахунку оренди забувають майже завжди: чистої оренди не буває. На стик з орендованим майданчиком вам майже напевно знадобиться свій міжмережевий екран — магістральний або класу NGFW, — бо дані ходять в обидва боки, тунелі треба десь термінувати, а політику на периметрі ніхто за вас не напише. Потрібного комутатора в каталозі провайдера може не виявитися, і його теж доведеться поставити свого. Це капітальні витрати, вони виникають першого ж місяця, і в моделі порівняння оренди з купівлею вони зобов’язані стояти в стовпці оренди.

And separately, the thing almost always left out of a rental calculation: there is no such thing as pure rental. At the boundary with the rented site you will almost certainly need your own firewall — a high-throughput or NGFW-class one — because data flows both ways, tunnels have to be terminated somewhere, and nobody will write your perimeter policy for you. The switch you need may not be in the provider’s catalogue either, so that will be yours too. These are capital costs, they appear in the very first month, and in any rent-versus-buy model they belong in the rental column.

Глобальные облака выигрывают там, где нужна редкая услуга, эластичность на порядок или мощности, которых в стране физически нет. И проигрывают всё остальное: задержку, трансграничную передачу, стоимость исходящего трафика, поддержку в вашем часовом поясе. Но главное для нас — канал наружу. Внешняя связность Узбекистана ограничена и по толщине, и по числу независимых маршрутов, поэтому при выносе чего-либо значимого в глобальное облако отказоустойчивость внешнего канала становится частью модели рисков всей системы, а не строкой в договоре с провайдером связи. Считать её надо там же, где вы считаете отказ площадки.

Глобальні хмари виграють там, де потрібна рідкісна послуга, еластичність на порядок або потужності, яких у країні фізично немає. І програють усе інше: затримку, транскордонну передачу, вартість вихідного трафіку, підтримку у вашому часовому поясі. Але головне для нас — канал назовні. Зовнішня зв’язність Узбекистану обмежена і за товщиною, і за кількістю незалежних маршрутів, тому при винесенні чогось значущого в глобальну хмару відмовостійкість зовнішнього каналу стає частиною моделі ризиків усієї системи, а не рядком у договорі з провайдером зв’язку. Рахувати її треба там само, де ви рахуєте відмову майданчика.

Global clouds win where you need a rare service, an order-of-magnitude elasticity, or capacity that physically does not exist in the country. And they lose everything else: latency, cross-border transfer, egress cost, support in your time zone. But the decisive factor for us is the link out. Uzbekistan’s external connectivity is limited both in capacity and in the number of independent routes, so once anything significant moves to a global cloud, the resilience of that external link becomes part of the risk model for the whole system rather than a clause in a telecom contract. It has to be counted where you count a site failure.

Для четырёх контуров из этой статьи локальная аренда закрывает больше сценариев, чем принято думать: объектный слой под копии, зона приземления, боковые проекты, тестовые контуры.

Для чотирьох контурів із цієї статті локальна оренда закриває більше сценаріїв, ніж прийнято думати: об’єктний шар під копії, зона приземлення, бічні проєкти, тестові контури.

For the four environments in this article, local rental covers more scenarios than people assume: the object tier for copies, the landing zone, side projects, test environments.

10

Чек-листЧек-листChecklist

Что спросить до того, как считать спецификацию

Що запитати до того, як рахувати специфікацію

What to ask before anyone prices a specification

11 вопросов, после которых спор про аренду перестаёт быть спором про вкусы.

11 питань, після яких суперечка про оренду перестає бути суперечкою про смаки.

Eleven questions that turn the rental argument from a matter of taste into a matter of numbers.

  1. Какое расстояние между площадками и какое круговое время задержки измерено, а не обещано? От этого зависит, синхронная схема или асинхронная, и весь остальной расчёт.
  2. Какая точка восстановления и какое время восстановления зафиксированы письменно по каждой системе? Без этих двух чисел спор про аренду беспредметен.
  3. Резерв полный или частичный, и если частичный — какие системы на нём не поднимаются, кто это подписал и когда это проверялось на учениях?
  4. Сколько ядер придётся лицензировать на резервной площадке и входит ли она в тот же договор подписки, что и основная?
  5. Какая доля сметы приходится на память и накопители, и на цены какого квартала опирается расчёт? Прошлогодняя цифра сегодня не бьётся.
  6. Какие сроки поставки подтверждены письменно по модулям памяти и накопителям, и что происходит с проектом, если они уедут на 2 квартала?
  7. Какая суточная изменяемость данных измерена и какой коэффициент уплотнения получается на проводе — и что происходит в ночь после регулярной полной копии, если она есть в регламенте?
  8. Что при аренде придётся поставить своего на стыке — межсетевой экран, коммутатор, каналообразующее оборудование — и учтено ли это в столбце аренды?
  9. Сколько стоит и сколько занимает обратный путь: полное восстановление из арендованного объектного хранилища, с трафиком и временем?
  10. Какая устойчивая утилизация ожидается по ускорителям — не пиковая и не проектная, а средняя за квартал? Ниже 40% покупка почти всегда проигрывает.
  11. Попадают ли данные под обязательную локализацию, есть ли среди них голос, изображение лица или другая биометрия, и входит ли площадка арендодателя в перечень, допустимый для вашей отрасли?
  1. Яка відстань між майданчиками і який круговий час затримки виміряний, а не обіцяний? Від цього залежить, синхронна схема чи асинхронна, і весь інший розрахунок.
  2. Яка точка відновлення і який час відновлення зафіксовані письмово за кожною системою? Без цих двох чисел суперечка про оренду безпредметна.
  3. Резерв повний чи частковий, і якщо частковий — які системи на ньому не піднімаються, хто це підписав і коли це перевірялося на навчаннях?
  4. Скільки ядер доведеться ліцензувати на резервному майданчику і чи входить він у той самий договір підписки, що й основний?
  5. Яка частка кошторису припадає на пам’ять і накопичувачі, і на ціни якого кварталу спирається розрахунок? Торішня цифра сьогодні не б’ється.
  6. Які строки постачання підтверджені письмово за модулями пам’яті й накопичувачами, і що відбувається з проєктом, якщо вони поїдуть на 2 квартали?
  7. Яка добова змінюваність даних виміряна і який коефіцієнт ущільнення виходить на проводі — і що відбувається в ніч після регулярної повної копії, якщо вона є в регламенті?
  8. Що при оренді доведеться поставити свого на стику — міжмережевий екран, комутатор, каналоутворювальне обладнання — і чи враховано це в стовпці оренди?
  9. Скільки коштує і скільки займає зворотний шлях: повне відновлення з орендованого об’єктного сховища, з трафіком і часом?
  10. Яка стійка утилізація очікується за прискорювачами — не пікова і не проєктна, а середня за квартал? Нижче 40% купівля майже завжди програє.
  11. Чи підпадають дані під обов’язкову локалізацію, чи є серед них голос, зображення обличчя або інша біометрія, і чи входить майданчик орендодавця в перелік, допустимий для вашої галузі?
  1. What is the distance between the sites, and what round-trip latency has been measured rather than promised? Everything else — synchronous or asynchronous, and the whole calculation — follows from it.
  2. What recovery point and recovery time are fixed in writing for each system? Without those two numbers the rental argument has no subject.
  3. Is the standby full or partial, and if partial — which systems do not come up on it, who signed that off, and when was it last tested in a drill?
  4. How many cores will have to be licensed on the standby site, and is it inside the same subscription agreement as the primary one?
  5. What share of the estimate is memory and storage media, and which quarter’s prices does the calculation rest on? Last year’s figure does not reconcile today.
  6. Which lead times for memory modules and drives are confirmed in writing, and what happens to the project if they slip by two quarters?
  7. What daily change rate has been measured, what reduction ratio is achieved on the wire — and what happens on the night after a scheduled full copy, if the runbook calls for one?
  8. What will you have to install of your own at the boundary when renting — firewall, switch, transmission equipment — and is it counted in the rental column?
  9. What does the way back cost and how long does it take: a full restore out of the rented object storage, traffic and hours included?
  10. What sustained utilisation is expected on the accelerators — not peak, not design, but the quarterly average? Below 40% buying almost always loses.
  11. Does the data fall under mandatory localisation, does it include voice, facial images or other biometrics, and is the provider’s site on the list permitted for your sector?

11

ИтогПідсумокWrap-up

Вместо вывода

Замість висновку

In place of a conclusion

Спор «аренда или своё» почти всегда сводится к трём числам: расстоянию между площадками, устойчивой утилизации и горизонту проекта относительно 3 лет первого круга и 3 лет второго. Всё остальное — детали реализации.

Суперечка «оренда чи своє» майже завжди зводиться до трьох чисел: відстані між майданчиками, стійкої утилізації та горизонту проєкту відносно 3 років першого кола і 3 років другого. Усе інше — деталі реалізації.

The rent-or-own argument almost always comes down to three numbers: the distance between the sites, sustained utilisation, and the project horizon against 3 years of the first cycle plus 3 of the second. Everything else is implementation detail.

Расстояние определяет, возможна ли синхронная схема, и его нельзя купить за деньги. Утилизация определяет, на чьей стороне экономика: ниже 40% почти всегда выигрывает аренда, при круглосуточной ровной нагрузке — почти всегда владение. Горизонт определяет, успеет ли покупка окупиться до того, как оборудование или лицензионная модель поменяются под вами.

Відстань визначає, чи можлива синхронна схема, і її не можна купити за гроші. Утилізація визначає, на чиєму боці економіка: нижче 40% майже завжди виграє оренда, за цілодобового рівного навантаження — майже завжди володіння. Горизонт визначає, чи встигне купівля окупитися до того, як обладнання або ліцензійна модель зміняться під вами.

Distance decides whether a synchronous design is possible at all, and it cannot be bought. Utilisation decides which side the economics fall on: below 40% renting nearly always wins, and under a steady round-the-clock load owning nearly always does. The horizon decides whether a purchase pays back before the hardware or the licensing model changes under you.

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

І поверх цих трьох чисел тепер лежить четверте — ціна пам’яті. Поки частка заліза в кошторисі тримається близько 80%, будь-які міркування про економію на ліцензіях стосуються однієї п’ятої бюджету. Рахувати треба там, де гроші.

And on top of those three numbers there is now a fourth — the price of memory. While hardware holds at around 80% of the estimate, any reasoning about licence savings concerns a fifth of the budget. Count where the money is.

Мой рабочий ответ по четырём контурам такой. Ядро виртуализации — своё, минимум 2 площадки, но резерв не обязательно полный и не обязательно одного поколения с основной площадкой. Резервное копирование — полный комплекс на первой площадке, медиа-серверы, арендованное объектное хранилище и зона приземления на второй. Аналитика — своё железо в одном центре, выводы и датасеты в объектном хранилище, а онлайновый слой признаков и метаданные резервируем полноценно, они маленькие. Искусственный интеллект — обучение в аренде, промышленный инференс и всё, что связано с голосом, локально.

Моя робоча відповідь за чотирма контурами така. Ядро віртуалізації — своє, мінімум 2 майданчики, але резерв не обов’язково повний і не обов’язково одного покоління з основним майданчиком. Резервне копіювання — повний комплекс на першому майданчику, медіа-сервери, орендоване об’єктне сховище і зона приземлення на другому. Аналітика — своє залізо в одному центрі, висновки й датасети в об’єктному сховищі, а онлайновий шар ознак і метадані резервуємо повноцінно, вони маленькі. Штучний інтелект — навчання в оренді, промисловий інференс і все, що пов’язане з голосом, локально.

My working answer across the four environments is this. The virtualisation core — owned, at least two sites, but the standby need not be complete and need not be the same generation as the primary. Backup — a full stack on the first site; media servers, rented object storage and a landing zone on the second. Analytics — owned hardware in a single centre, outputs and datasets in object storage, and full protection for the online feature layer and the metadata, which are small. AI — training rented, production inference and anything involving voice kept local.

Материал написан по собственной практике. Цифры в тексте — расчётные иллюстрации порядка величин: всё, что влияет на закупку или на норматив, проверяется на конкретной конфигурации. Названия заказчиков и коммерческие условия не приводятся.

Матеріал написаний на основі власної практики. Цифри в тексті — розрахункові ілюстрації порядку величин: усе, що впливає на закупівлю або на норматив, перевіряється на конкретній конфігурації. Назви замовників і комерційні умови не наводяться.

Written from my own practice. The numbers in the text are order-of-magnitude illustrations: anything that affects a purchase or a service-level target has to be verified against the actual configuration. Customer names and commercial terms are not disclosed.