Фокус на совместимости. Как отечественные ПАК изменили подход к построению ИТ-инфраструктуры

Отказ оборудования, срыв сроков проекта, многомиллионные простои — риски, которые несет точечная замена ИТ-решений. IT-World разбирается, как переход на программно-аппаратные комплексы меняет правила игры.

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

Точечный KPI — точечные решения

В период с 2016 по 2022–2023 годы среди заказчиков ПО и аппаратного оборудования была широко распространена практика точечной замены. При таком подходе задача — не перестроить архитектуру, а выполнить KPI, поэтому выбирались наименее критичные элементы инфраструктуры и заменялись без оглядки на общую концепцию. Это часто приводило к «зоопарку решений» и сопутствующим ему проблемам совместимости между ИТ-продуктами.

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

Вторая проблема — масштабирование. Система, которая отлично работает на 5–10 серверах, начинает рассыпаться при расширении до 70–80 серверов. В итоге разрозненные продукты, каждый со своей логикой обновлений, сертификатами и сроками поддержки, рано или поздно начинают выдавать ошибки и перестают работать как единое целое.

Курс на системность

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

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

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

Камень преткновения: ответственность за совместимость

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

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

ПАК как новая норма

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

Первый — создание собственного тестового контура. Крупнейшие мировые корпорации, включая Google, Amazon, Boeing и Airbus, именно так и поступают: сначала прогоняют все обновления на тестовой среде, выявляют проблемы, и только потом делают релиз. Этот подход требует серьезных ресурсов, экспертизы и денег, но он гарантирует максимальный контроль.

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

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

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

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