Роман Бычков: ПАК — это не сервер с софтом, а ответственность за все решение целиком

Еще несколько лет назад заказчик преимущественно самостоятельно выстраивал высоконагруженную инфраструктуру — собирая ее из разрозненных серверов, систем хранения данных и программного обеспечения. Сегодня рынок смещается в сторону готовых программно‑аппаратных комплексов (ПАК) и модульных платформ, где предусмотрена единая точка ответственности. В интервью CNews Роман Бычков, руководитель продуктового департамента Скала^р (Группа Rubytech), рассказал, почему сборка решений только на базе open source — не оптимальный вариант, в чем принципиальное отличие модульной платформы от разнородного набора совместимых устройств («зоопарка»).

«По прогнозам к 2031 году продажи коммерческих ПАК вырастут до 265 млрд рублей»

CNews: Еще недавно заказчик собирал высоконагруженную инфраструктуру сам. Каким был путь рынка за это время — с чего он начинался и где находится сейчас?

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

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

Поэтому заказчики начали смотреть в сторону готовых продуктов — и, главное, в сторону тех, кто может гарантировать производительность и взять на себя ответственность за результат целиком. Этот разворот виден и в цифрах: по прогнозам группы компаний «Б1», доля отечественных среди установленных готовых решений вырастет с 25% в 2025 году до 74% к 2031-му, а продажи коммерческих ПАК — почти втрое, с 89 до 265 млрд руб. Это уже не эффект импортозамещения, а смена самой модели построения ИТ-инфраструктуры.

CNews: Готовые комплексы с ответственностью за весь жизненный цикл — кто на рынке оказался готов их предложить?

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

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

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

CNews: Отдельные ПАК — под СУБД, под виртуализацию — какое-то время закрывали спрос. В какой момент стало понятно, что этого уже недостаточно?

Роман Бычков: Эта задача в первую очередь встает перед крупными заказчиками. По оценке «Б1», спрос на инфраструктуру для высоконагруженных систем растет примерно на 15% в год — это в 1,3 раза быстрее, чем ИТ-бюджеты госсектора и крупнейших корпораций. Драйверы понятны: искусственный интеллект, необходимость управления данными, надежность и масштабируемость, законодательные требования к критической инфраструктуре. Когда ресурсов много, управлять ими и распределять нагрузку нужно по единому принципу.

Мы прошли этот путь на собственной продуктовой линейке. Отдельные машины — под виртуализацию, транзакционные СУБД, большие данные, искусственный интеллект — остаются самостоятельными продуктами. При этом все они совместимы между собой и собираются в модульную платформу Скала^р. 

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

CNews: В чем принципиальная разница между набором совместимых устройств и по-настоящему модульной платформой, если объяснять с инженерной точки зрения?

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

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

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

«Последние несколько лет наш рынок находился в стадии бурного роста»

CNews: Одно из самых устойчивых мнений относительно ПАК — что это «сервер с предустановленным софтом». Почему это упрощение и что оно упускает в самом главном?

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

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

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

В ПАК Скала^р эта работа заранее сделана на стороне вендора, то есть на нашей: комплекс собирается, настраивается и тестируется в нашей лаборатории еще до поставки, и заказчик получает готовое к работе, проверенное решение, а не набор ИТ-компонентов, который предстоит сводить самому.

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

Для собственной службы эксплуатации заказчика это становится проблемой; интегратор такую функцию выполнять, но вопрос, насколько это является профильной деятельностью для него. Вендорский ПАК как раз закрывает этот разрыв: у заказчика появляется единое окно ответственности.

CNews: На чем реально экономит компания, когда уходит от покомпонентной сборки к готовому комплексу?

Роман Бычков: Экономия складывается из нескольких слоев, и первоначальная цена железа — далеко не главный из них. Первый слой — эксплуатация. Разрозненная инфраструктура обходится примерно в 5% от своей стоимости в год на поддержку, а интегрированный комплекс — около 2%; это соотношение в 2–2,5 раза сохраняется на разных масштабах. 

Второй слой — внедрение: за счет преднастройки и автоматизированного развертывания запуск ПАК обходится в те же 2–2,5 раза дешевле, чем самостоятельный проект. Третий — единое окно ответственности вместо одновременной коммуникации с десятком вендоров по технически сложным вопросам. В сумме по совокупной стоимости владения на горизонте пяти лет разница достигает порядка 40% в пользу готового комплекса.

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

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

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

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

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

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

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

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

«Спрос смещается к специализированным комплексам, где каждый ПАК спроектирован и сбалансирован под свой класс нагрузки»

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

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

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

CNews: Все чаще говорят о связке «вычисления + данные + ИИ» в едином периметре, а не о наборе отдельных компонентов. Почему эта интеграция становится нормой и где здесь настоящая инженерная сложность?

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

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

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

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

CNews: Рынок движется от проектной сборки к промышленным продуктам с предсказуемым жизненным циклом. Что будет определять конкурентоспособность вендоров ИВНС в ближайшие два-три года и что стоит за словами «единая точка ответственности»?

Роман Бычков: Зрелого вендора отличает способность обеспечивать не разовую поставку, а весь жизненный цикл продукта: серийное производство, единый контур поддержки, предсказуемое развитие на годы вперед. «Единая точка ответственности» — не маркетинговая формула. 

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

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

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