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

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

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

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

Контур первый · расстояние

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

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

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

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

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

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

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

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

Контур первый · цена дубля

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

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

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

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

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

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

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

Контур первый · цены компонентов

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

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

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

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

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

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

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

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

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

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

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

Контур первый · уровень резерва

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

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

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

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

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

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

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

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

Контур второй · арифметика канала

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

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

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

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

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

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

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

Контур второй · схема хранения

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

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

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

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

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

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

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

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

Контур третий · платформа данных

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

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

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

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

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

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

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

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

Контур четвёртый · искусственный интеллект

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

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

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

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

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

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

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

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

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

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

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

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

Выбор площадки

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

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

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

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

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

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

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

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

Чек-лист

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

Итог

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

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

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

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

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

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