Принцип пазла: от лоскутного стека к ПАК

После масштабной трансформации российский корпоративный сектор столкнулся с необходимостью поиска новых моделей построения ИТ-инфраструктуры. Форсированный переход на отечественные решения часто сопровождался лоскутной интеграцией: компании были вынуждены собирать стек из десятков разрозненных продуктов от разных вендоров. Однако попытка воспроизвести прежний ландшафт в новом форм-факторе показала свою экономическую и технологическую неэффективность, отметил руководитель Скала^р (группа Rubytech) Виктор Урусов в своем выступлении на сессии «Эволюция ИТ-инфраструктуры» форума «Цифровые решения» 8 октября. По его словам, сегодня корпоративный заказчик смещает фокус с «точечного импортозамещения» на платформизацию и использование программно-аппаратных комплексов (ПАК).

После 2022 года крупнейшие российские предприятия оказались перед дилеммой: собирать ИТ-инфраструктуру из готовых отечественных ИТ-решений или инвестировать в собственные R&D-подразделения, адаптируя открытое программное обеспечение под свои жесткие требования. Практика показала, что самостоятельное исследование и глубокая доработка инфраструктурных технологий силами одной компании превращаются в колоссальную финансовую нагрузку.

Разработка и тестирование сложных высоконагруженных систем требуют постоянных капиталовложений. Ежегодные расходы специализированного вендора на исследования, разработку и доводку инфраструктурных решений составляют порядка 4–5 млрд руб., рассказал Виктор Урусов. Если разложить эту сумму на пул из 10 крупнейших заказчиков, то затраты в расчете на одного клиента составляют около 500 млн руб., продолжает он. В случае же, когда крупный заказчик пытается реализовать аналогичный объем R&D внутри собственного ИТ-контура, весь этот бюджет неизбежно ложится на плечи одной компании, так как без внешнего пула клиентов подобные инвестиции просто не способны окупаться, объяснил господин Урусов.

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

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

Задача современной ИТ-службы крупнейших предприятий — стать бизнес-партнером для топ-менеджмента, погрузиться в реализацию отраслевой логики и ускорение вывода новых продуктов на рынок, переложив базовый технологический R&D на специализированных игроков, считает Урусов.

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

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

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

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

Сегодня российские технологические решения массово внедряются в критическую информационную инфраструктуру (КИИ) — от банковского сектора и ТЭК до транспортной отрасли и госуправления. В этих условиях к системам предъявляются бескомпромиссные требования по операционной устойчивости. Во-первых, это сквозное резервирование и восстановление после сбоев (Disaster Recovery, DR) на уровне приложений, данных и аналитики. Во-вторых, это жесткие требования к максимально допустимому периоду потери данных (Recovery Point Objective, RPO). В-третьих, это концепция безопасности Secure by Design, перечисляет господин Урусов. Безопасность не должна быть внешним «обвесом», устанавливаемым поверх готовой системы, подчеркивает он: элементы защиты, изоляции и контроля доступа должны закладываться в архитектуру ПАК и платформ сразу, на этапе фундаментального проектирования.

«Сегодня отечественные ИТ-решения работают в самом сердце крупнейших корпораций страны, где минута простоя обходится в десятки миллионов рублей, — говорит Виктор Урусов. — Обеспечить операционную устойчивость КИИ можно только тогда, когда требования к катастрофоустойчивости, восстановлению данных и защищенности по концепции Secure by Design заложены в саму природу платформы, а не дописываются в виде заплаток в процессе эксплуатации».

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

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