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

Сегодня же — про сеть.

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

Покажем, как мы проектировали сетевую архитектуру «Скала^р МИИ» и какие вопросы пришлось решить заранее, чтобы заказчик с ними не столкнулся. Про ограничения InfiniBand, его сравнение с RoCEv2 и многое другое — под катом.

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

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

Как вы поняли, сегодня поговорим о безопасности конвейера. Меня зовут Владимир Ковтунов, я начальник отдела безопасности разработки и автоматизации в департаменте ИБ Группы Rubytech.

Под катом — четыре столпа, на которых мы строим ИБ своих конвейеров для B2G-проектов, и общие советы, которые пригодятся вам, если вы занимаетесь аналогичными вещами.

Привет, Хабр!

Меня зовут Владислав Шершульский, я советник генерального директора Группы Rubytech по инновационным проектам и ИИ.

Отвечая на вопрос, заявленный в заголовке, напрашивается короткий ответ — «всё». Но попробуем немного его детализировать...

Привет, Хабр!

Меня зовут Илья, я работаю в Группе Rubytech в департаменте информационной безопасности, и в этой статье расскажу, как мы сильно упростили себе жизнь, сделав сброс пароля мультиплатформенным. Если вы вдруг в вашей компании планируете что-то подобное — вам пригодится. А если просто интересно, как все это устроено — добро пожаловать под кат.

Всем привет! Меня зовут Артём, я продуктовый лидер с опытом управления линейкой высоконагруженных продуктов информационной безопасности и клиентского сервиса — IDM, PAM, PKI, SSO, FAM — в крупнейших банках России и коммерческих организациях. На мне в этом плане всегда были стратегия и операционное управление бэклогом, координация 30+ разработчиков, DevOps, архитекторов, аналитиков и инженеров. Причем не в самой дружелюбной среде — с высочайшими требованиями к надежности, безопасности и соблюдению регуляторных стандартов.

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

Как мы автоматизировали выдачу ключей от демозала через бот в Telegram, обрадовались, потом вынужденно переехали в eXpress и настроили все по новой (но путь был тернист).

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

Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разбирали стратегический вопрос: что проще и выгоднее — собирать самостоятельно или брать готовый ПАК (на примере ПАК Скала^р)? Поговорили и о том, что именно заказчик узнает о самосборе — не на этапе закупки, а через полгода эксплуатации. 

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

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

Поехали!

Привет, Хабр! Это снова Евгений Шилкин и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. В прошлой статье мы разобрали подходы к миграции, посмотрели, какие есть альтернативные решения, и обмолвились парой фраз про MIND Migrate Guest. 

В этой статье — практическая часть, проверим MIND в деле и протестируем его. Что из себя представляет процесс миграции с точки зрения алгоритма и чем он отличается от простого переноса между серверами? В процессе обнаружили несколько интересных находок. Давайте разбираться.

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

Статья носит обзщепознавательный характер и будет полезна тем, кому в целом интересны механизмы миграции ИТ-систем — и их ключевые отличия у разных вендоров в разных странах. В следующих статьях цикла мы разберем типы миграции, их алгоритмы и посмотрим на результаты тестирования, чтобы оценить их работу в реальных условиях. А пока…

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

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