Мифы вокруг ПАК: что мешает технологической независимости

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

Миф 1. ПАК — это просто сервер в красивой коробке

Путаница возникает из-за определения, что такое ПАК. Здесь нужно четко разделять, имеется в виду специализированное программно-аппаратное решение или полноценный ПАК. В первом случае — это, действительно, один сервер с предустановленным ПО. Он предназначен для узких, строго сегментированных задач, чаще всего в сфере информационной безопасности (например, NGFW от Positive Technologies или от "Континент").

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

За счёт этого ПАК закрывает широкий спектр общеинфраструктурных задач, таких как: платформа для построение частных и гибридных облаков, виртуализация серверов и рабочих мест (VDI), работа высоконагруженных СУБД и платформ обработки данных, контейнерные среды, системы резервного копирования и катастрофоустойчивости, платформы для аналитики, ИИ и машинного обучения, а также консолидация критичных бизнес-приложений уровня ERP и биллинга. По сути, ПАК становится фундаментом, на котором предприятие строит и развивает свои цифровые сервисы.

Пока жёсткого ГОСТа на этот класс решений нет, но отрасль уже пришла к общему пониманию: ПАК — это сложная инфраструктурная платформа, а не "сервер в красивой коробке" и не набор железа со скриптами поверх.

Миф 2. Проекты с использованием ПАК — это долго и сложно

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

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

Миф 3. ПАК — это дорого

Корректно сравнивать совокупную стоимость владения (TCO), а не только начальные инвестиции. Как показывает практика, в перспективе 3–5 лет ПАК оказывается выгоднее других решений. В стоимость ПАК уже включены техническая поддержка, обновления и гарантийное обслуживание. Существенная экономия достигается за счет отсутствия затрат на интеграцию компонентов и снижения рисков простоя из-за проблем совместимости.

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

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

Миф 4. Отечественные ПАК не тянут критичные нагрузки старых систем на Oracle/IBM

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

ПАК Oracle соединяет в себе три типа нагрузки: транзакционную, аналитическую, гибридную. Соответственно, есть возможность правильно скомбинировать отечественные ПАК и сделать архитектурное проектирование. Тогда эти задачи можно решить даже с большей эффективностью. Яркий пример — перевод АБС Газпромбанка с импортного технологического стека на отечественные ПАК Скала^р. Скорость подготовки отчетности (в том числе годовой) выросла более чем в три раза. Производительность не просто не упала — она кратно выросла.

Миф 5. На рынке может появиться полный отечественный аналог Oracle/IBM, поэтому лучше подождать

Ждать полного аналога западных решений — это путь в никуда. R&D-бюджет Oracle за год, пожалуй, больше, чем суммарно все российские вендоры ПАК выделяют на R&D. Oracle разрабатывают ПАК с начала 90-х, и в их продукты вложены не только огромные суммы, но и сотни тысяч человеко-часов. Мировые лидеры уже сейчас переделывают свои продукты под новую логику для работы с искусственным интеллектом, нейросетями, предиктивной аналитикой. Догонять, пытаясь сделать копию — значит всегда плестись в хвосте. Поэтому задача российских разработчиков — не повторить их путь в 35 лет, а сразу разрабатывать продукты, которые соответствуют требованиям времени.

Миф 6. Российские ПАК — это только название, внутри — все импортное

"Российский ПАК" — это юридический термин, закрепленный Постановлением Правительства № 719. В нем четко прописаны требования к интеллектуальной собственности (она должна быть у российского юрлица без иностранных бенефициаров) и к локализации производства. Сейчас требования по проценту компонентов, произведенных в РФ, не 100%. Но государство держит жесткий вектор: каждые 2–2,5 года планка локализации повышается.

При этом "российскость" ПАК — это не только сборка корпусов на территории страны. Современный отечественный ПАК сегодня уже включает целый ряд ключевых ИТ-элементов российской разработки и производства: серверные и СХД-платформы на материнских платах из реестра Минпромторга, отечественные процессоры там, где это применимо для конкретного класса нагрузок, российские операционные системы (Astra Linux, "Альт", РЕД ОС и др.), отечественные платформы виртуализации и контейнеризации, СУБД из реестра российского ПО (Postgres Pro, Tantor и аналоги), собственные средства управления, мониторинга и оркестрации, а также сертифицированные решения по информационной безопасности. Всё это объединяется единым стеком инженерной поддержки и обновлений со стороны российского вендора — а значит, заказчик получает не "шильдик", а реально управляемый из России жизненный цикл платформы.

Дойдет ли локализация до 100%? Вопрос открытый. Но путь к технологической независимости уже прописан законодательно и подкреплен реальным наполнением ПАК отечественными аппаратными и программными компонентами.

Миф 7. Концепция ПАК быстро устаревает, а в будущем все перейдут на облака

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

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

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

Миф 8. ПАК нужен только корпоративным гигантам

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

Мотивы выбора у сегментов разные. Крупные организации обладают достаточными ресурсами, чтобы держать в штате ИТ-команды, иметь собственную разработку, проводить исследования и так далее. Они могут проектировать собственные ПАК.

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

Миф 9. ПАК сложно масштабировать

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

Миф 10. ПАК — это "черный ящик", и никто не знает, что там внутри и как его обслуживать

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

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

Заключение

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