Публикация | 23 Октября 2026

Данные как актив: почему цена терабайта перестала быть аргументом

Летом 2026 года опрос 200 руководителей российских ИТ-подразделений показал: 10% компаний уже полностью перешли на отечественные системы хранения, 35% в процессе, еще 15% начнут в течение года. Вопрос «есть ли замена?» снимается с повестки. Теперь задача другая: выбирать следует по экономике. А привычный показатель — цена полезного терабайта — для такой оценки не подходит. Почему так и как теперь выбирать платформу, рассказывает Илья Гусев, руководитель направления интеллектуального хранения данных Скала^р (Группа Rubytech).

Хранилище перестало быть складом

Классическая система хранения решала одну задачу: сохранить данные и выдать их по запросу с предсказуемой скоростью. Сейчас идет сдвиг в сторону программно-определяемых хранилищ: они иначе масштабируются и обрастают слоями управления и интеграции — единый мониторинг разнородного парка, мультипротокольность (блочный, файловый доступ и S3 в одном контуре), связь с прикладными сервисами. Это и есть платформа данных.

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

Честная цена: не терабайт, а единица производительности в год

Еще несколько лет назад совокупную стоимость владения (TCO) сводили к одному параметру: полезный терабайт стоит столько-то. Сегодня ее считают в комплексе — TCO с видением на три-пять лет, куда входят стоимость обеспечения производительности и отдельной транзакции, энергопотребление и обслуживание. Учитывают и простой при обновлении: сколько система будет недоступна, пока устанавливается новая версия.

Честнее смотреть, во что обходится единица производительности и единица объема за год. Сравнение «у меня терабайт стоит 7 рублей, а у соседа 10» ничего не говорит о том, сколько компания потратит на самом деле. Первый пример — системы без внутреннего охлаждения. Они дороже в капитальных затратах, но за срок эксплуатации выходят дешевле. Пока электроэнергию в экономику хранения закладывают немногие, но считать ее придется всем.

Второй пример — избыточность. При тройной репликации хранятся три копии каждого объекта: из 300 ТБ физической емкости под данные остается около 100 ТБ. Широкие схемы избыточного кодирования (erasure coding) позволяют использовать под данные до 95% дискового пространства; они есть и в российских продуктах, в том числе в программно-аппаратных комплексах (ПАК) Скала^р, разработчиком которых является Группа Rubytech. Из тех же 300 ТБ полезными становятся около 285 ТБ вместо 100. Для TCO это прямая экономия: на той же инфраструктуре можно хранить почти втрое больше данных.

Начинать нужно не с железа, а со своих данных

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

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

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

Где менять уже можно, а где нужна подготовка

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

Слой, который уже можно менять безопасно, — S3. Разработчикам с ним удобно взаимодействовать — поэтому протокол и стал отраслевым стандартом, а базовая функциональность гарантированно работает во всех продуктах. Он хорош там, где нужно хранить большие объемы без POSIX-семантики. Продукты различаются производительностью и набором возможностей, но не работоспособностью. Обратная сторона: S3 подходит не для любой нагрузки. OLTP (Online Transaction Processing) на объектном хранилище будет работать неоптимально или не заработает вовсе.

Главный практический риск при переходе — не протоколы, а совместимость: по опросу зрителей эфира AM Live именно она оказалась ключевым критерием выбора платформы (38%). Два типичных примера.

- Привычный файловый доступ. Бухгалтер годами заходит в сетевую папку, где лежат файлы. Замените файловый ресурс на S3 — и папка просто пропадет: Windows штатно не подключает объектное хранилище как сетевой диск, нужен коннектор или отдельная прослойка.

- Модель доступа. Западное решение подключалось к Active Directory напрямую. Многие S3-хранилища, в том числе российские, нативной интеграции с AD или LDAP не имеют: им нужен собственный слой управления доступом (IAM), например Keycloak. Подключить новую систему к каталогу «как было» не получится, ролевые модели и списки доступа придется перестроить.

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

Миграция вместо второй стойки рядом

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

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

Что компании забывают проверить на пилоте

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

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

Глубокого погружения в стек от бизнеса при этом не требуется. ИТ-директору нужно понимать не уровень блоков и железа, а последствия для компании: если в пиковую нагрузку выключится один сервер, производительность просядет, условно, на 10% (которые для бизнеса критичны, но несравнимы с 90% или полным отказом). Такой ответ и должен дать пилот.

Еще два критерия выбора — эксплуатационная зрелость (как администратор в ЦОД узнает о нештатной ситуации) и единое окно поддержки. Разбирательство в духе «здесь тормозит хранилище, а у нас все хорошо» бизнесу ничего не дает: нужен один ответственный — интегратор или производитель инфраструктуры, — который разберется с проблемой на уровне всей системы.

ИИ меняет требования к хранению

Искусственный интеллект, скорее всего, станет основным драйвером изменений — и по объемам, и по архитектуре. Привычное разделение на вычисления (compute) и хранение (storage) размывается: хранилище перестает быть пассивным слоем и непрерывно подает данные в сторону вычислений.

Практический вывод для тех, кто проектирует платформу сейчас: S3 под ИИ-нагрузку — отдельная архитектура, и прорабатывать ее нужно на старте. Решения под такие задачи на российском рынке есть, но выбирать нужно продукт, изначально рассчитанный на ИИ, а не просто поддерживающий S3 API. Важны задержки, с которыми хранилище отвечает вычислительным серверам, нативная поддержка форматов вроде Iceberg, скорость операций с мелкими объектами, работа с метаданными. Если ИИ-сценариев не предвидится, закладывать все это необязательно: ошибка в обе стороны стоит денег.

Как обосновать бюджет, не продавая страх

Разговор ИТ-директора с бизнесом о новой платформе хранения часто сводится к «все устарело, пора менять» или «а если завтра все выключится». Оба аргумента слабые.

Убеждает проектный подход с декомпозицией затрат до конкретных цифр. Что мы потеряем, если ничего не менять. Насколько выросла стоимость эксплуатации текущего оборудования. Не наступили ли сроки окончания жизненного цикла (end of life) и прекращения поддержки (end of support). Как изменится экономика после замены: если восстановление занимает не два часа, а десять минут, сэкономленные 1 час 50 минут можно потратить на обработку данных и получить больше выгоды. Такой расчет дает честный ответ — новая система дешевле или дороже, а если дороже, то через какое время затраты сравняются.

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