Разработка программно-аппаратных комплексов (ПАК)

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

На базе ПАК строят платформы виртуализации, системы хранения и резервного копирования, комплексы информационной безопасности, видеоаналитики и инфраструктуру для искусственного интеллекта.

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

Ниже разберем состав комплекса, этапы разработки, три подхода к его созданию, архитектурные решения, актуальные в 2026 году, и типичные ошибки, которые дороже всего обходятся на внедрении.

Материал подготовлен инженерами СИНТО на основе практики проектирования и внедрения инфраструктурных решений.

Что такое программно-аппаратный комплекс

В состав ПАК могут входить:

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

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

Главный признак комплекса - заранее определенная архитектура взаимодействия компонентов. Для нее фиксируются совместимые версии ПО, требования к ресурсам, схема резервирования и критерии приемки. Если те же характеристики достигаются, когда компоненты работают порознь, перед вами не комплекс, а просто совместимый набор оборудования и лицензий.

Основные типы ПАК и что критично в каждом

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

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

Чем ПАК отличается от набора оборудования и ПО

Отдельно закупленные серверы, СХД и лицензии могут соответствовать техническому заданию, но не обеспечивать нужный результат при совместной работе.

На этапе внедрения могут обнаружиться ограничения:

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

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

Как разрабатывается ПАК

Анализ требований

Работа начинается с определения задачи и условий эксплуатации.

Недостаточно указать, что комплекс должен быть производительным или отказоустойчивым. Требования переводят в измеримые параметры:

• количество пользователей и сервисов;
• полезную емкость;
• число операций ввода-вывода;
• время отклика;
• пропускную способность;
• допустимое время простоя;
• сроки восстановления;
• планируемый рост нагрузки на 3-5 лет.

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

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

Проектирование архитектуры

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

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

Полезное правило - считать не только штатный режим, но и режим деградации. Кластер, загруженный на 85% в норме, при выходе узла из строя должен куда-то разместить его нагрузку. Если запаса нет, отказ одного узла превращается в отказ сервиса.

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

Подбор оборудования и программного обеспечения

Компоненты выбираются по расчетному профилю нагрузки, а не по максимальным паспортным характеристикам.

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

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

Испытания

Для критичной инфраструктуры комплекс желательно проверить до переноса рабочих сервисов.

Результаты фиксируются в протоколе. Формулировка «система работает стабильно» без методики, исходной нагрузки и измеренных показателей не позволяет объективно принять решение.

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

Внедрение и передача в эксплуатацию

После испытаний выполняются установка, настройка, интеграция и перенос данных.

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

Три подхода к созданию ПАК

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

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

Архитектурные решения, актуальные в 2026 году

Гиперконвергентные комплексы. Вычисление, хранение и сеть объединяются в одной платформе, масштабирование идет добавлением узлов. Это упрощает обслуживание и снимает зависимость от отдельного массива хранения. Обратная сторона - вычисление и хранение растут вместе, поэтому при перекосе нагрузки в одну сторону классическая схема с выделенной СХД может оказаться дешевле.

NVMe и NVMe over Fabrics. Перевод хранилища на NVMe и доступ к нему по NVMe-oF заметно снижает задержки по сравнению с iSCSI. Это важно для баз данных и нагрузок, чувствительных к времени отклика. Но выигрыш появляется только при соответствующей сетевой части: на перегруженной сети быстрые диски не помогут.

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

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

Реестровый и доверенный статус: что проверить в проекте

Если проект попадает под требования к импортозамещению, к техническим требованиям добавляются формальные. Здесь важно различать два независимых режима - их часто путают.

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

Доверенный ПАК - статус по постановлению № 1912 для субъектов критической информационной инфраструктуры в части принадлежащих им значимых объектов. Комплекс признается доверенным, если одновременно выполняются все три критерия приложения № 1:

• сведения о комплексе содержатся в едином реестре российской радиоэлектронной продукции;
• программное обеспечение в его составе отвечает требованиям
• постановления № 1478 к ПО для значимых объектов КИИ;
• если в комплексе реализована функция защиты информации - он
• соответствует требованиям ФСТЭК и (или) ФСБ, что подтверждается сертификатом.

Переход на значимых объектах должен быть завершен до 1 января 2030 года.

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

Типичные ошибки при разработке и выборе ПАК

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

Резервирование без проверки восстановления. Копии создаются, но время восстановления никто не измерял, и в RTO система не укладывается.
Игнорирование инженерной инфраструктуры. Мощности на стойку или охлаждения не хватает, комплекс приходится разносить или ограничивать по производительности.

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

Проверка статуса по компонентам, а не по конфигурации. Все составляющие российские, но комплекс как единое решение требуемого статуса не имеет.
 

Приемка «по общему впечатлению». Критерии не согласованы заранее, и спорить о результате уже поздно.

Как выбрать программно-аппаратный комплекс

До закупки стоит получить ответы на восемь вопросов:

• Для какой нагрузки рассчитана конфигурация?
• Какие версии оборудования и ПО проверены совместно?
• Какие отказы комплекс переносит без остановки сервисов?
• Какие фактические показатели получены на испытаниях?
• Как выполняются обновление и восстановление?
• Где находятся пределы масштабирования и что происходит со стоимостью лицензий?
• Какие требования предъявляет площадка: мощность, охлаждение, место в стойке?
• Если требуется реестровый или доверенный статус - подтвержден ли он для этой конфигурации?

Критерии приемки согласовывают заранее. Это позволяет проверить результат по измеримым параметрам, а не по общему впечатлению от работы системы.

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

Разработка и внедрение ПАК в СИНТО

Мы проводим обследование инфраструктуры, проектируем архитектуру, подбираем оборудование и программное обеспечение, организуем поставку, настройку и испытания комплекса.

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

Подробнее - об импортозамещении ИТ-оборудования, серверов, СХД и сетевых решений.

Частые вопросы

Сколько занимает разработка ПАК?

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

Можно ли создать ПАК из готовых продуктов?

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

Все ли ПАК проходят предварительные испытания?

Нет. Объем испытаний зависит от конкретного решения. До закупки стоит запросить программу проверки, протоколы и перечень протестированных конфигураций.

Обязательно ли ПАК должен быть сертифицирован?

Нет. Необходимость сертификации определяется назначением решения, требованиями законодательства, объекта и технического задания. Наличие сертификата и область его действия проверяются отдельно.

Чем ПАК отличается от гиперконвергентной платформы?

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

Чем реестровый ПАК отличается от доверенного?

Это записи в разных реестрах. Реестровый ПАК - комплекс, сведения о котором включены в единый реестр российских программ (реестр Минцифры). Доверенный ПАК - комплекс, который одновременно отвечает трем критериям приложения № 1 к постановлению № 1912: он есть в едином реестре российской радиоэлектронной продукции, его ПО соответствует требованиям постановления № 1478, а при наличии функций защиты информации есть сертификат ФСТЭК или ФСБ. Один статус не подтверждает автоматически другой.

Главное

ПАК - это не оборудование с установленной программой, а согласованная архитектура с определенным составом, проверенными версиями и измеримыми характеристиками.

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