ПАК — это не сервер с софтом, это часть технологического процесса

Директор Главного вычислительного центра — филиала ОАО "РЖД" Виктор Аристов и руководитель Скала^р (Группа Rubytech) Виктор Урусов в интервью ТАСС обсудили, как крупные заказчики перестраивают унаследованную ИТ-инфраструктуру в условиях импортозамещения. В центре разговора — программно-аппаратные комплексы (ПАК), их роль в обеспечении операционной устойчивости, совместимости систем, миграции с устаревших платформ и экономически оправданного развития высоконагруженной инфраструктуры

— Главный вычислительный центр РЖД — это четыре основных ЦОДа в Москве и Екатеринбурге, 14 региональных вычислительных центров, более 200 тысяч единиц сетевого оборудования и свыше 20 ПБ систем хранения данных. За последние годы в любой крупной компании накопилось то, что в индустрии называют "зоопарком": десятки вендоров, поколений "железа", версий ПО. Насколько остро эта проблема стоит сегодня для РЖД?

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

У нас в реестре официально порядка 2 тысяч информационных систем. Причем речь не просто о сервере или системе хранения — речь о сложнейших программно-аппаратных комплексах, которые работают в метро- и геораспределенной конфигурации, когда каждая система резервируется на уровне города, страны, между регионами. Это ответ на первую часть вопроса — "есть ли у вас зоопарк". А дальше: что с ним делать? Это не проблема, а очень интересный вызов. Здесь нельзя поменять отдельно сервер или систему хранения данных. Нужно архитектурно смотреть на платформы, на процессы интеграции, на потоки данных и все это обязательно брать в расчет при проектировании целевой архитектуры, в том числе построенной на программно-аппаратных комплексах.

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

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

На текущий момент гигиенический минимум импортозамещения, по сути, уже пройден. Достаточно решений в реестрах Минпромторга и Минцифры, реализована ключевая функциональность, достигнуты требуемые показатели производительности. Теперь необходимо сделать решения эффективными: получить из того же объема инфраструктуры существенно более высокую производительность или меньшую стоимость за требуемые показатели. Эти задачи решаются за счет вертикальной интеграции и встречной оптимизации различных компонентов. Именно модель ПАК и кооперация производителей-вендоров, которые находятся внутри, позволяют к этим результатам приходить.

— Виктор Сергеевич, сформулируйте техническое задание для вендоров ПАК. Что обязано быть "в коробке", чтобы решение можно было ставить на критические системы РЖД: резервирование, SLA (Service Level Agreement, соглашение об уровне обслуживания — прим. ТАСС), нагрузочное тестирование, миграция?

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

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

— Виктор Александрович, один из самых сложных проектов крупных заказчиков — уход с IBM Mainframe (System Z) на x86/x64. Около 70% задач предполагают переписывание кода. Как вендор ПАК может реально снизить риски и сократить сроки при таком переходе, на каких уровнях стека?

Виктор Урусов: Что такое System Z? Это большая вертикально масштабируемая серверная система, которая позволяет практически все вычислительные задачи заказчика собрать в одно место. В итоге это приводит к упрощенной архитектуре всех бизнес-приложений, но вся современная индустрия идет по пути горизонтального масштабирования для повышения гибкости и экономической эффективности. System Z — это во многом устаревшие подходы, и точно нужно переходить на новые. И, конечно, прикладные системы придется переписывать.

Инфраструктурные решения и ПАК не могут обеспечить "непереписывание" прикладных систем. Но правильные подходы к строению инфраструктуры позволят сделать этот процесс существенно дешевле и короче по срокам.

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

— Что в реальной практике сложнее: заместить "железо", системное ПО или интегрировать все это с уже работающими прикладными системами заказчика? Или построить все заново?

Виктор Аристов: Единого ответа здесь нет. Если разложить стек: замена оборудования — самая простая задача. Дальше — системное программное обеспечение. Это, на мой взгляд, самая сложная история. Перенос данных, совместимость могут сделать процесс либо быстрым, либо максимально мучительным и долгим. Плюс требования информационной безопасности: меняя технологии, мы должны перенастраивать правила, и если меняется сама суть работы, то меняются и регламенты по ИБ, а это очень большой пласт переделок. Сетевая инфраструктура — точно так же: перенастройка сетевых правил, потоков данных. Любой процесс миграции, если это не просто "выключил одну железку и включил другую", требует достаточно серьезного инженерного проектирования. Универсального ответа нет: каждая миграция сколько-нибудь крупной системы — это процесс проектирования и подбора того решения, которое подходит.

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

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

— Виктор Сергеевич, РЖД работает по полному жизненному циклу информационных систем — от ТЗ до эксплуатации. Как меняется роль ГВЦ при переходе на платформенную модель ПАК: вы становитесь скорее эксплуатантом или соразработчиком? И чего вы ждете от вендора?

Виктор Аристов: Если есть зрелое решение, которое в состоянии снять с нас большой нетипичный пласт работы и каких-либо несвойственных нам активностей, то мы с удовольствием эту активность доверим партнеру, поставившему решение.

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

— Виктор Александрович, какой обратной связи вы ждете от крупных заказчиков, чтобы продукт стал лучше — и для всей отрасли?

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

— С 1 января 2025 года значимым объектам критической информационной инфраструктуры запрещено использовать иностранное ПО. Где сегодня самые большие риски?

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

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

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

Виктор Урусов: Основной риск, на мой взгляд, — экономический. Как построить инфраструктуру так, чтобы это было экономически оправдано — при соблюдении требований регуляторики, требований критической информационной инфраструктуры (КИИ) и значимых объектов КИИ? Накопленный технологический опыт из промышленности и других отраслей дает возможность для создания экономически эффективных решений. При построении новых ИТ-инфраструктур перспективным подходом является использование промышленных решений с заложенными сценариями эксплуатации, развития, масштабирования и адаптации к изменениям. Такой подход позволит внедрять более эффективные и при необходимости более быстрые решения.

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

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

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

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

Именно здесь на помощь приходит подход построения ИТ-ландшафта на базе программно‑аппаратных комплексов (ПАК). Он позволяет достичь той самой монолитности нового типа за счет двух ключевых принципов: интеграции компонентов на этапе проектирования (когда все компоненты — от "железа" до софта — подбираются и тестируются совместно, что исключает конфликты и гарантирует стабильную работу) и принципа конструктивной информационной безопасности (Secure by Design). Это когда безопасность закладывается не как дополнительная надстройка, а как фундаментальное свойство архитектуры. Это снижает риски и избавляет от необходимости "латания дыр" в будущем.

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

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

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

Классические транзакционные системы: продажа билетов, управление перевозочным процессом, ERP-контур (интеграционный комплекс, представляющий собой набор решений для организации защищенного электронного документооборота и проверки юридических и физических лиц — прим. ТАСС), финансовые операции — требуют прежде всего предсказуемости, отказоустойчивости и минимальных задержек. Для них критичны стабильность, резервирование, соглашение об уровне обслуживания (Service Level Agreement, SLA) и гарантированная целостность данных. Здесь приоритет — консервативная архитектура и максимально проверенные решения.

Аналитика и ИИ работают по совершенно другой модели. Там важны горизонтальное масштабирование, обработка больших массивов данных, GPU-ускорение (GPU — графический процессор — прим. ТАСС), гибкость вычислительной среды и высокая скорость экспериментов. Нагрузки могут быть нерегулярными — например, модель прогнозирования может несколько часов потреблять огромный объем ресурсов, а затем простаивать. Поэтому инфраструктура для AI/ML (искусственный интеллект и машинное обучение — прим. ТАСС) почти всегда строится по отдельным принципам и использует другой стек технологий.

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

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

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

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

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

По оценкам отрасли, в крупных ИТ-инфраструктурах до 30–40% времени системных администраторов и эксплуатационных команд до сих пор уходит на рутинные операции: обновления, ручное переключение сервисов, контроль резервного копирования, диагностику типовых инцидентов, управление конфигурациями. Именно эти задачи современные платформенные решения автоматизируют в первую очередь. В результате инженер начинает заниматься не поддержанием жизни инфраструктуры, а ее развитием и оптимизацией.

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

Поэтому для крупных компаний критически важна собственная система подготовки кадров. Отдельно меняется и сам профиль инженера. Если раньше востребован был специалист по конкретному продукту или платформе, то сейчас все больше нужны инженеры с архитектурным мышлением: пониманием интеграции, автоматизации, контейнеризации, сетевых взаимодействий и DevOps/SRE-подходов (DevOps — подход к разработке и эксплуатации ПО, основанный на культуре сотрудничества, автоматизации и непрерывной интеграции; SRE — подход к эксплуатации и поддержке программных систем, основанный на применении инженерных практик к задачам обеспечения надежности — прим. ТАСС).

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

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

— Виктор Сергеевич, если посмотреть на горизонт 3–5 лет, какой вы видите ИТ-инфраструктуру крупной российской компании? Это будет монолитный ПАК, гибридная модель или что-то принципиально новое?

Виктор Аристов: Если смотреть на горизонт 3–5 лет, то в крупных российских компаниях вряд ли появится монолитный ПАК, который закрывает все. Реалистичная картина — это многослойная гибридная архитектура, где под едиными стандартами управления живет разнородный технологический ландшафт. ИТ-инфраструктура становится не набором одинаковых платформ, а системой согласованных платформенных слоев.

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

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

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

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

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