Вячеслав Шипилов, OpenYard: Команда разработки должна учитывать весь жизненный цикл серверной платформы
В 2026 году OpenYard развивает линейку серверных платформ, поддерживая разные процессорные архитектуры, классы нагрузок и сценарии эксплуатации. Одно из новых направлений связано с платформой на базе AMD, рассчитанной на задачи, где важны производительность, масштабируемость, энергоэффективность и гибкость конфигураций. О том, как команда, занимающаяся исследованиями и разработкой (R&D) принимает решения о запуске новых платформ, какие этапы проектирования и валидации наиболее критичны и как эксплуатационный опыт влияет на следующие поколения решений, рассказал Вячеслав Шипилов, директор департамента исследований и разработок OpenYard.
«Серверная платформа, которая одинаково эффективно закрывает все сценарии, практически невозможна»
CNews: Вячеслав, сегодня серверные платформы должны поддерживать широкий спектр нагрузок: от корпоративных систем и баз данных до высокопроизводительных вычислений и ИИ-сценариев. Какие архитектурные требования это предъявляет к разработке новых решений?
Вячеслав Шипилов: Серверная платформа, которая одинаково эффективно закрывает базы данных, корпоративные приложения, обучение больших языковых моделей (LLM) и высокопроизводительные вычисления, практически невозможна. Поэтому одно из ключевых архитектурных требований сегодня заключается в модульности и возможности конфигурировать платформу под конкретный сценарий.
В линейке OpenYard есть как OCP-совместимые решения, так и традиционные 19-дюймовые серверы. В OCP-сегменте модульный принцип особенно важен: он позволяет менять отдельные элементы системы без полного перепроектирования платформы. В классических 19-дюймовых серверах гибкость тоже остается базовым требованием, потому что заказчикам нужны разные конфигурации под разные задачи.
Еще один важный слой связан с управляемостью и мониторингом. Современный BMC уже не ограничивается удаленным включением сервера. Он контролирует энергопотребление, собирает телеметрию, поддерживает удаленное обновление встроенного ПО и дает эксплуатационным командам больше данных о состоянии системы. Поэтому развитие собственных BIOS и BMC для нас связано не только с внутренней экспертизой, но и с возможностью интегрировать серверы в инфраструктуры с нестандартными требованиями к мониторингу и управлению.
Надежность также закладывается не в конце разработки, а с первых этапов: от моделирования целостности сигналов и питания до теплофизических расчетов. Затем идут натурные испытания, в том числе при предельных температурах окружающей среды и максимальной нагрузке. Отдельное значение имеет качество массового производства, и здесь важную роль играет наш завод в Рязани.
«Чаще всего заказчик покупает не один сервер, а решение на десятки или сотни узлов»
CNews: Какие параметры сегодня становятся определяющими при проектировании серверных платформ: производительность, плотность размещения, энергоэффективность, масштабируемость, совместимость с компонентами и ПО? Как R&D-команда находит баланс между этими требованиями?
Вячеслав Шипилов: Все перечисленные параметры важны, но, если их ранжировать, я бы выделил три группы: масштабируемость, совместимость с компонентами и ПО, а также плотность размещения вместе с энергоэффективностью. Производительность в этом смысле не единственная цель, а результат грамотного баланса архитектурных решений.
Чаще всего заказчик покупает не один сервер, а решение на десятки или сотни узлов. Поэтому платформа должна масштабироваться без потери предсказуемости. Если при росте инфраструктуры появляются проблемы с охлаждением, питанием, совместимостью или обслуживанием, высокая производительность отдельного сервера уже не решает задачу.
Плотность размещения и энергоэффективность особенно важны для современных дата-центров, где идет борьба за каждый ватт и каждый юнит пространства. В наших решениях большое внимание уделяется тому, чтобы эффективно использовать внутренний объем 1U и при этом сохранять стабильную работу системы без принудительного снижения производительности (троттлинга).
Совместимость с компонентами и ПО сегодня фактически становится ответственностью производителя серверной платформы. Заказчик не будет переписывать свой софт под новое железо. Поэтому OpenYard формирует внутренний список одобренных вендоров и перечень совместимых компонентов и ПО. Этот список появляется по итогам валидации силами команды исследований и разработок и продолжает обновляться уже после релиза платформы, потому что рынок компонентов меняется, а заказчикам важны сроки поставки, цена и качество конечного решения.
CNews: Как в R&D принимается решение о развитии новой платформы? Какие технологические, архитектурные и эксплуатационные факторы оцениваются на предварительном этапе?
Вячеслав Шипилов: Решение о запуске новой платформы принимает не только R&D. Обычно идея формируется на стыке продуктовой команды, исследований и разработок, производства и сервиса. Продуктовый отдел собирает требования, оценивает запросы рынка, конкурентную среду и экономику проекта. После этого начинается техническая проработка, где R&D оценивает реализуемость будущего решения.
Один из первых вопросов на этом этапе касается доступности документации по ключевым компонентам. Без нее даже сильная инженерная команда будет ограничена в разработке и сопровождении продукта. Не менее важна доступность самих компонентов: нет смысла проектировать платформу, если затем невозможно стабильно собрать спецификацию компонентов (BOM) в нужном объеме и с приемлемыми сроками поставки.
Отдельно оценивается доступность исходных кодов и инструментов, необходимых для разработки встроенного ПО. Для серверной платформы это критично, потому что базовая система ввода-вывода (BIOS) и контроллер управления материнской платы (BMC) напрямую влияют на управляемость, поддержку и дальнейшую модернизацию продукта.
Еще один важный фактор связан с собственной экспертизой. Нужно понимать, есть ли внутри компании инженеры, работавшие с подобной архитектурой, доступны ли специалисты для проекта, потребуется ли найм или привлечение внешней экспертизы. После этого формируется верхнеуровневая архитектура, проверяется реализуемость требований и оцениваются эксплуатационные аспекты: как платформа будет производиться, тестироваться, ремонтироваться и сопровождаться. Только после такого анализа проект может переходить в активную фазу разработки.
«Серверный рынок меняется, и производитель не может развивать линейку, ориентируясь только на привычные архитектуры»
CNews: В портфеле OpenYard появилась новая серверная платформа на базе AMD. Чем обусловлен выбор этой архитектуры и какую задачу новая платформа закрывает в линейке компании?
Вячеслав Шипилов: Компания OpenYard представила новую платформу RS202A на базе процессоров AMD EPYC 9005. Для компании это важный шаг, потому что исторически значительная часть нашей экспертизы и базы встроенного ПО формировалась вокруг архитектуры Intel. Кроме того, на российском рынке больше специалистов с практическим опытом работы именно с платформами Intel.
Но серверный рынок меняется, и производитель не может развивать линейку, ориентируясь только на привычные архитектуры. AMD заметно усилила позиции в корпоративных и высокопроизводительных системах, поэтому наличие такой платформы в портфеле становится для нас закономерным этапом развития.
Выбор AMD обусловлен несколькими факторами. С технической точки зрения архитектура EPYC дает большое количество линий PCIe, что важно для конфигураций с развитым вводом-выводом, сетевыми адаптерами, накопителями и ускорителями. Кроме того, платформа предлагает сбалансированное сочетание числа ядер и тактовой частоты, а поддержка большого количества каналов памяти интересна для ресурсоемких задач.
Есть и экономический аспект. Для многих сценариев важна стоимость в пересчете на ядро, линию PCIe и общую конфигурацию платформы. Наконец, для OpenYard значимы доступность процессоров и диверсификация продуктовой линейки в условиях меняющихся внешних факторов.
CNews: На какие классы нагрузок ориентирована новая AMD-платформа? Можно ли говорить о фокусе на виртуализацию, облачные среды, высоконагруженные системы, аналитику или другие сценарии?
Вячеслав Шипилов: Платформа достаточно универсальна, но ее сильные стороны лучше всего раскрываются в задачах, где важны параллельные вычисления, развитый ввод-вывод и эффективная работа с памятью. В первую очередь это облачные среды, виртуализация, аналитика, транзакционные нагрузки и высоконагруженные корпоративные сервисы.
Конфигурации с большим количеством физических ядер и высокой тактовой частотой делают платформу интересной для виртуализации и облачных сценариев. В таких задачах важно не только количество ресурсов, но и то, сколько рабочих нагрузок можно стабильно разместить на одном узле и как система ведет себя при высокой утилизации.
Объем кэш-памяти процессора может быть важен для транзакционных сценариев, где большое значение имеют задержки и скорость обработки обращений. Поддержка большого количества линий PCIe актуального поколения открывает возможности для аналитических задач, конфигураций с быстрыми накопителями, сетевыми адаптерами и дополнительными устройствами.
При этом я бы не сводил платформу к одному классу применений. Ее задача в линейке OpenYard заключается в том, чтобы дать заказчику возможность собрать технически обоснованную конфигурацию с понятной экономикой под конкретный профиль нагрузки.
CNews: Какие технологические особенности новой платформы наиболее важны с точки зрения производительности, масштабируемости, энергоэффективности и гибкости конфигураций?
Вячеслав Шипилов: Любое решение о выводе новой платформы должно начинаться с понимания целевого заказчика и его задач. Универсальный сервер, который одинаково хорошо закрывает все возможные сценарии, невозможен. Поэтому еще до старта основных работ важно сформировать техническое задание и определить, какие характеристики будут приоритетными.
Есть параметры, на которые R&D смотрит всегда. Один из них касается производительности, но не только в смысле количества ядер или тактовой частоты. Важны пропускная способность и задержки на ключевых магистралях, поддержка PCIe Gen5, работа с памятью DDR5, а также оптимизация топологии для минимизации потерь и задержек внутри платформы.
Производительность должна сочетаться с устойчивой тепловой моделью, надежным питанием, корректной работой памяти, возможностями ввода-вывода и удобством обслуживания. Если один из этих элементов не сбалансирован, платформа может хорошо выглядеть в спецификации, но создавать проблемы в реальной эксплуатации.
Еще один важный слой связан с масштабируемостью и гибкостью конфигураций. Наша цель состоит в том, чтобы платформа могла расти вместе с задачами заказчика без замены шасси или материнской платы. Здесь помогает модульный подход и поддержка необходимой периферии. Отдельно я бы выделил энергоэффективность: для ЦОД важно не только получить высокую производительность, но и понимать, сколько полезной работы выполняется на единицу потребляемой энергии.
CNews: Что означает поддержка разных процессорных архитектур внутри серверной линейки с точки зрения разработки? Насколько сильно меняются подходы к проектированию, тестированию, валидации и дальнейшему сопровождению таких платформ?
Вячеслав Шипилов: Внешне два сервера на разных процессорных архитектурах могут выглядеть почти одинаково. Но с инженерной точки зрения различия начинаются уже на уровне схемотехники и топологии. Меняется не только сокет процессора, но и система питания, интерфейсы, логика взаимодействия ключевых компонентов, требования к разводке и даже количество слоев в материнской плате.
Особенно заметны отличия во встроенном ПО, прежде всего в BIOS. Нельзя взять BIOS, разработанный под одну архитектуру, и просто перекомпилировать его под другую. Для R&D это означает разные кодовые базы, разные наборы инструментов и необходимость иметь инженеров, которые специализируются на конкретной архитектуре.
Меняются и подходы к тестированию. Отличаются утилиты, методики, часть стендов для квалификационных испытаний, производственного тестирования и валидации. То, что корректно для одной платформы, нельзя автоматически переносить на другую без дополнительной проверки.
Сопровождение таких решений тоже требует отдельной экспертизы. Сервисной команде нужно понимать архитектурные особенности платформы и специфику встроенного ПО, иначе сложные инциденты будет трудно анализировать. Кроме того, в текущих условиях приходится отдельно оценивать доступность документации и внешние ограничения для каждого производителя CPU.
CNews: Что стоит за выводом новой серверной платформы на рынок со стороны R&D: проектирование, тестирование, валидация, совместимость с компонентами, операционными системами и прикладным ПО?
Вячеслав Шипилов: В целом у производителя есть два подхода к появлению новой серверной платформы в портфеле. Первый — разработка с нуля, когда команда сама формирует архитектуру, проектирует аппаратную часть, механику, встроенное ПО и контур тестирования. Второй — локализация уже существующего решения под требования конкретного рынка. Но в обоих случаях задача R&D одна: сделать продукт надежным, воспроизводимым и готовым к промышленной эксплуатации.
Работа начинается задолго до релиза. Сначала определяется, какие задачи должна закрывать платформа, какие конфигурации будут базовыми, какие требования есть к питанию, охлаждению, сервисному доступу, удаленному управлению и дальнейшему сопровождению. Затем начинается инженерная проработка: компонентная база, BIOS, BMC, операционные системы, прикладное ПО и совместимость всех этих уровней между собой.
Отдельный большой блок — тестирование и валидация. Мы проверяем не только факт запуска системы, но и устойчивость под длительной нагрузкой, температурные режимы, работу питания, поведение при ошибках, обновление встроенного ПО, мониторинг и удаленное управление. Для заказчика сервер должен быть не набором отдельных совместимых элементов, а предсказуемой промышленной платформой.
Не менее важен переход от инженерного образца к серийному продукту. Платформа должна быть воспроизводимой в производстве, понятной для сервиса, ремонтопригодной и готовой к сопровождению. Именно в этой невидимой части работы проявляется зрелость R&D: качество сервера во многом определяется тем, насколько глубоко команда проработала архитектуру, валидацию, производство и сервисные сценарии еще до вывода продукта на рынок.
«Способность собирать обратную связь и превращать ее в инженерные изменения показывает зрелость производителя»
CNews: Как эксплуатационный опыт уже поставленных платформ возвращается в R&D? Какие данные, инциденты или наблюдения помогают дорабатывать архитектуру и учитывать реальные сценарии использования в следующих поколениях решений?
Вячеслав Шипилов: Способность собирать обратную связь и превращать ее в инженерные изменения показывает зрелость производителя. В OpenYard такие данные приходят в R&D из нескольких источников: от сервиса, производства и технических пресейлов.
Сервисный отдел собирает информацию по инцидентам на уже поставленных платформах. Особое внимание уделяется повторяемым отказам, сбоям и поведенческим аномалиям. Если проблема связана с архитектурой или встроенным ПО, она передается в R&D для анализа и последующей доработки.
Производство дает другой, не менее важный тип обратной связи. Эти данные помогают оптимизировать конструкцию, схемотехнику и производственные тесты. Если потенциальную проблему можно выявить еще на раннем этапе производства, это напрямую повышает качество конечного продукта.
Еще один источник обратной связи связан с тестированием демо-образцов у заказчиков. У крупных клиентов часто есть собственные методики проверки платформ и опыт работы с оборудованием разных производителей. Такая обратная связь особенно ценна, потому что показывает, как продукт ведет себя не в лаборатории, а в условиях, близких к реальной эксплуатации. Часто именно такие наблюдения ложатся в основу планов по доработке текущих и будущих решений.
CNews: Какие технологические направления для R&D OpenYard будут приоритетными в ближайшей перспективе: новые платформы, развитие архитектур, повышение плотности и энергоэффективности, валидация компонентов, поддержка специализированных нагрузок?
Вячеслав Шипилов: Приоритеты R&D на ближайшие один-два года связаны не только с выпуском новых платформ, но и с повышением качества на всех этапах жизненного цикла изделия. Эта работа не всегда заметна конечному заказчику, но без нее невозможно масштабировать продуктовую линейку и выстраивать репутацию надежного производителя.
В фокусе находятся улучшение производственных тестовых стендов, развитие автоматизированного тестирования, оптимизация тестовых сценариев, развитие процесса валидации аппаратных компонентов и ПО, а также участие R&D в разработке методик входного контроля новых типов компонентов. Для нас качество означает не только снижение количества дефектов, но и контроль себестоимости, устойчивость поставок и доверие заказчиков к бренду.
Параллельно развивается продуктовая линейка. Мы видим рост интереса к системам для обучения нейронных сетей, инференса и высокопроизводительных расчетов. Поэтому OpenYard работает над расширением портфеля в направлении платформ с плотной упаковкой GPU, JBOG-решений (систем с несколькими GPU) и новых подходов к охлаждению. Также продолжается развитие стандартных 19-дюймовых решений и OCP-линейки.
При этом наша цель не в том, чтобы вывести на рынок как можно больше новых продуктов. Приоритетом остаются качество и закрытие конкретных ниш. Если у заказчика появляется понятный спрос, а в текущем портфеле нет подходящего решения, OpenYard готова запускать новые платформы вне первоначальной дорожной карты. Такой подход позволяет развивать линейку не формально, а исходя из реальных технологических задач рынка.
■ Рекламаerid:2W5zFJt1rwKРекламодатель: ООО «Центр открытых разработок»ИНН/ОГРН: 9705156518/1217700263340Сайт: https://openyard.ru/



