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

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

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

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

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

Поехали!

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

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

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

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

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

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