Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

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

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

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

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Генерация последовательностей случайных чисел с помощью DRAM — возможно ли это? Проверим с помощью RISC-V

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

Далее мы направляем данные из DRAM PUF в два подмодуля — постобработки, а также тестирования, анализа и оценки качества данных. Первый частично запускается на «железе», второй — на собранных данных на машине хоста.

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

• сырые данные,

• чистый корректор фон Неймана,

• одноканальный сигнатурный анализатор,

• чистый корректор фон Неймана + одноканальный сигнатурный анализатор,

• одноканальный сигнатурный анализатор + чистый корректор фон Неймана,

• многоканальный сигнатурный анализатор (МСА).

Зимняя школа RISC-V дала начало множеству интересных проектов. В отдельной статье мы рассказали об одном из них, где команда из БГУИР проверила гипотезу о наличии PUF в динамической памяти и создала модель одноканального источника шума. А затем реализовала постобработку и тестирование, измерила производительность генератора и оптимизировала код.

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.  

К чему готовиться на хакатоне по проектированию SoC и созданию процессоров?

Трек UVM-верификации — результат эволюции и переосмысления задач SoC Design Challenge предыдущих лет. В этом году участники работали с конфигурируемым AXI Stream маршрутизатором, который по заданным правилам распределяет транзакции с входных каналов на выходные, избегая коллизий. Для конфигурации блока предусмотрены регистры, доступные по шине APB.

Несмотря на упоминание UVM в названии трека, окружение было несколько упрощено относительно «честного» варианта методологии. Это позволило опытным участникам проявить себя, а начинающим инженерам познакомиться с основными аспектами UVM — объектно-ориентированным подходом в SystemVerilog, модульностью и абстрагированием через моделирование на уровне транзакций.

Задача хакатона охватила наиболее «творческие» этапы верификации, существующие в департаменте разработки SoC YADRO: подготовка плана верификации и разработка эталонной модели устройства. В сжатые сроки нужно было не просто усвоить спецификацию устройства, но и грамотно расставить приоритеты в разработке — чтобы успеть найти максимальное количество ошибок в дизайне.

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

Это описание лишь одного из четырех треков SoC Design Challenge — совместного хакатона YADRO и МИЭТ, который в этом году прошел в четвертый раз. Подробное описание остальных треков и знакомство с командами — в нашем репортаже.

О, сколько нам открытий чудных... готовит школа по RISC-V

Сегодня устройства на базе «молодой» архитектуры RISC-V, представленной в 2010 году, имеют ограничения по документации. Каждая инструкция в процессоре обладает двумя характеристиками исполнения, латентностью и пропускной способностью, которые зависят от реализации процессорного ядра. Латентность определяет время выполнения одной инструкции, а пропускная способность — количество инструкций, выполняемых за определенное время. Эти данные помогают разработчикам оптимизировать код и повысить эффективность выполнения алгоритмов процессором. Обычно характеристики предоставляются производителями ядер, но в настоящее время для актуальных ядер их не найти. 

Существуют стандартные инструменты для измерения латентности и пропускной способности, например llvm-exegesis. Однако из-за быстрого развития архитектуры RISC-V не все инструкции включены в эти инструменты. В рамках образовательного проекта предлагалось изучить принципы создания микробенчмарков для таких задач и измерить новые реализации недавнего векторного расширения для RISC-V (RVV) на примере плат LicheePi 4A.

Изначально мы не знали, как вычислить латентность, но знали, что на современных архитектурах скалярное сложение должно выполняться за один такт. Поэтому решили найти такой метод, который на скалярном сложении покажет латентность в один такт.

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

Так начинается лишь один из 18 интересных проектов, которые подготовили студенты в рамках Зимней школы RISC-V. О том, что это за школа и что еще разработали ее участники, читайте в нашем блоге.

Как начать практиковаться в тестировании без опыта

Если вы только что окончили курсы по тестированию, знаете теорию, но не имеете реальных кейсов — это нормально. Почти каждый начинающий QA-специалист сталкивается с вопросом: «Где набраться практики, если нет опыта?».

После тренировок в песочницах следующий шаг — попробовать себя в реальном проекте. Участие в open source — отличный способ получить настоящий опыт, поработать с командой и добавить первые кейсы в портфолио. Начать тестировать WordPress можно по простому и понятному алгоритму. Шаги для старта:

1. Установите WordPress локально.
   Самый простой способ — приложение LocalWP. Также подойдут Docker или XAMPP.

2. Разберитесь, как устроена работа.
   Загляните на make.wordpress.org — там есть разделы для разработчиков, дизайнеров, переводчиков и тестировщиков. Обратите внимание на Test Handbook — там подробно объясняется, как тестировать, искать баги и писать отчеты.

3. Найдите первую задачу.
   В баг-трекере Trac ищите задачи с меткой good-first-bug — они идеально подходят для старта. Прочитайте описание, повторите шаги и проверьте, воспроизводится ли баг.

4. Включайтесь в сообщество.
   Присоединяйтесь к чату #core-test в Slack (ссылка на подключение — в make.wordpress.org/test). Там обсуждают приоритетные задачи и проводят регулярные митинги. Новичкам всегда рады!

   

В статье, Юлия Ковшова, руководитель группы компонентного тестирования в YADRO, делится опытом, где найти первые реальные задачи без трудоустройства. Если вы только начинаете карьеру в тестировании и застряли на этапе теории, это руководство поможет сделать уверенный шаг к практике.

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

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

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

Мы увеличили размер словаря для русского языка до 40 тысяч слов и использовали модель Char CNN + RNN. Так удалось добиться прироста метрики KSS (количество сэкономленных нажатий) на 60%. 

Читайте в статье ИИ-инженера Вадима Воеводкина из YADRO, как его команда улучшила предиктивный ввод на планшетах KVADRA_T и с какими сложностями столкнулась. 

Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками

Представим, что вы звоните семье со смартфона в 4G-сети. В вашей сети нет (или временно недоступна) поддержка голосового звонка через сеть 4G. Не имеет значения, в какой сети находится второе устройство.

Что происходит в сети оператора при таком звонке:

• Телефон отправляет на базовую станцию (eNB) вызов.

• Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.

• После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.

• После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.

• Голосовой вызов осуществляется через 2G-сеть.

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

Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.

Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.

Android-приложение «Контакты»: работает — не трогай

У многих полей контакта есть типы. Например, у номеров телефонов или адресов электронной почты по умолчанию есть типы «рабочий» и «домашний». Аналитики сказали, что нужно реализовать дополнительные типы и дать пользователю возможность создавать свои. Звучит легко, но на деле оказалось совсем непросто.

Чтобы заменить стандартные типы полей, нужно добавить новую базу данных с доступными типами полей, а также реализовать отображение и возможность выбора поля. Для этого пришлось во многом переписать код редактирования полей контакта, где и без этого логика была непростой. Теперь стало совсем сложно: при добавлении или обновлении поля в contentProvider нужно указывать тип поля, так что мы начали указывать «custom».

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

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

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

Пришлось опять добавлять костыль: в отдельной корутине ожидать инициализации БД и только потом начинать рисовать экран...

Дмитрий Бражник, старший инженер-программист в департаменте разработки мобильных приложений YADRO, рассказал в статье, как его команда пыталась допилить стандартное AOSP-приложение «Контакты» и к чему они в итоге пришли.

Собеседование инженера: взгляд со стороны нанимающих специалистов

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

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

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

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

Проверка знаний в эпоху LLM: опыт преподавателя из Политеха

Сегодня преподаватели сталкиваются с новой реальностью: даже уникальные задания и ежегодное обновление вариантов не гарантируют защиту от списывания. Студенты могут принести работающий код, созданный с помощью LLM-моделей, но совершенно не понимать, как он устроен. Устные собеседования могли бы помочь, но они требуют много времени и экспертности — до 15 минут на одного студента, что превращается в колоссальную нагрузку.

На курсах «Введение в язык программирования Go» и «Технологии параллельного программирования на C++» в Политехе лабораторные работы проверяются с использованием системы контроля версий GitLab. Это позволяет упорядочить процесс сдачи и проверки заданий.

Каждый студент работает в личном fork-репозитории, созданном на базе основного, предоставленного преподавателем. Решения оформляются строго по структуре: каждая задача и подзадача — в своей директории, обязательное наличие модуля go.mod, а точка входа программы размещается в cmd/. Сдача работы происходит через создание Merge Request в основной репозиторий, где автоматически запускаются все проверки.

Система GitLab CI/CD выполняет серию автоматических тестов, включая проверку структуры проекта, сборку и выполнение юнит-тестов. Если хотя бы один из этапов не пройден, работа не допускается к оценке. Это дисциплинирует студентов и делает процесс проверки прозрачным и объективным.

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

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

От картотеки Лумана к современным графам: учим языки программирования с методом Цеттелькастен

В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.

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

Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.

Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки. 

Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →

Работаем со свертками в PyTorch с помощью библиотеки CUTLASS и алгоритма Implicit GEMM

Библиотека CUTLASS — это набор C++ шаблонов для реализации высокопроизводительного GEMM в коде. Она предоставляет структурные блоки, из которых можно собрать или просто вызвать операцию GEMM. Поддерживает вычисление смешанной точности, использование TensorCores и других примитивов, доступных для быстрого вычисления. В отличие от cuBLAS, это open source-библиотека. Ее относительно просто интегрироватьь и модифицировать под свои задачи. 

Подход основан на тайлинге — разбиении задачи на мелкие подзадачи и распараллеливании. Как устроен процесс работы:

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

• Затем используются примитивы для переноса этих данных в shared-память, где происходит тайлинг на этом уровне.

• После выполняется работа на уровне варпов и регистров с использованием TensorCores или CUDA Cores. 

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

Библиотека предоставляет различные уровни специализации и конфигурирования: Device-level, Kernel-level, Block-level, warp, Instruction. Весь API представлен в виде шаблонов, из которых можно набирать те типы, которые потом инстанцируются для реализации нужного тайлинга. 

Какие еще инструменты могут расширить функциональность PyTorch для работы с большими свертками? Как выбрать алгоритм, подходящий для обучения моделей? Узнаете из статьи →

На пределе железа: протестировали резервное копирование 32 виртуальных машин с дедупликацией «на лету»

Один из сценариев тестирования СХД TATLIN.BACKUP и СРК Кибер Бэкап, в котором резервное копирование производилось с inline-дедупликацией внутри каждой ВМ.

В каждую из 32 виртуальных машин установлены агенты Кибер Бэкапа, а также агенты Tboost, протокола дедупликации в TATLIN.BACKUP. Каждый агент сохраняет резервную копию в локальную папку, подключенную к целевому хранилищу через протокол T‑BOOST (точка монтирования /mnt/esxboost)​. В качестве хранилища резервных копий в Кибер Бэкапе указано 32 хранилища — по числу ВМ.

График показывает, что мы достигли ограничений оборудования: пропускной способности четырех портов Ethernet по 25 Гбит/с, через которые подключен диск TATLIN.UNIFIED к хостам виртуализации. 

Совокупный объем данных, переданных Кибер Бэкапом для полного резервного копирования всех ВМ, составил ~ 4 192 ГБ (32 × 131 ГБ). Параллельно выполнялись 32 операции резервного копирования. Время выполнения операций — от 8 до 11 минут.

Про совместное использование TATLIN.BACKUP и Кибер Бэкапа читайте в статье с результатами тестирования трех сценариев резервного копирования 32 виртуальных машин.

Проверяй, пока не поздно: функциональная верификация в жизненном цикле СнК

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

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

Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (tape-out) раз в полгода. Это говорит о том, что процессы налажены и команда работает с высокой скоростью.

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

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

Верните мой 2007-й: превращаем старые фотки в снимки с зеркалок с помощью ИИ

Однажды группе ИИ-энтузиастов пришла идея: а что если обучить искусственный интеллект улучшать смартфонные снимки до профессиональных с помощью парных фотографий? Задумка понравилась. Для сбора датасета выбрали актуальные в то время Sony Xperia Z, iPhone 3GS, BlackBerry Passport и цифровую зеркалку Canon EOS 70D в качестве эталона. Модель обучили улучшать фотографии, сделанные на смартфонах, в соответствии с такими же изображениями, полученными с камеры. Проект реализовали, исходный код опубликовали на GitHub, а подробное описание — на arXiv.org. Но что же в нем интересного сейчас, почти десять лет спустя?

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

Открытый исходный код и доступность датасета DPED позволяют легко адаптировать, изменять и дорабатывать модель. Это дает большие возможности исследовательскому сообществу и разработчикам мобильных приложений. Именно гибкость и понятность архитектуры делают DPED хорошим кандидатом для дальнейших экспериментов и улучшений.

В своей статье команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева запустила DPED на свежих версиях софта, преодолев все проблемы совместимости, и попробовала через него улучшить фото с современного планшета.

Как оптимизировать расходы на резервное копирование

10 апреля в 13:00 подключайтесь к вебинару, где специалисты YADRO и Киберпротект расскажут об эффективном использовании системы резервного копирования (СРК) в связке с системой хранения данных (СХД). СРК занимается резервным копированием и восстановлением данных, а СХД — их надежным хранением, компрессией и дедупликацией. 

В прямом эфире вы сможете:

• узнать о возможностях СРК Кибер Бэкап и СХД TATLIN.BACKUP,

• выбрать подходящий сценарий их совместного использования,

• посмотреть в реальном времени, как происходит резервное копирование средствами Кибер Бэкапа на TATLIN.BACKUP с помощью T-BOOST,

• задать вопросы экспертам.

Одной из тем вебинара станет технология T-BOOST. Она позволяет выполнять дедупликацию данных на источнике: защищенном хосте или узле хранения Кибер Бэкапа. После дедупликации в хранилище передаются только уникальные данные. Это позволяет минимизировать объем передаваемых данных (снизить нагрузку на сеть) и ускорить резервное копирование.

Принять участие в вебинаре →

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

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

Bi-Encoder — состоит из двух трансформеров encoder-only. С помощью passage-encoder получаются эмбеддинги для всех чанков в базе знаний. Запрос от пользователя кодируется с помощью query-encoder. На этапе поиска высчитывается косинусное расстояние между query-embedding и passage-embedding. Мы получаем поисковую выдачу после ранжирования всех пассажей по убыванию косинусного расстояния. В отличие от следующей архитектуры Cross-Encoder, можно заранее сохранить эмбеддинги для пассажей и использовать их для подсчета расстояния.

Cross-Encoder — трансформер с архитектурой encoder-only и ранжирующим слоем. Этот слой выдает оценку релевантности запроса к пассажу. На вход подается двойка: запрос и пассаж. Cross-Encoder лучше понимает семантическую связь между пассажем и запросом, но для каждого пользовательского запроса он работает медленнее, так как для оценки релевантности запроса и пассажей, cross-encoder нужно запустить N раз, где N — количество пассажей.

Мы будем использовать Bi-Encoder, так как у нас много пассажей в базе знаний.

Для выбора модели удобно использовать открытый бенчмарк MTEB с рейтингом по различным моделям в зависимости от вашей задачи. Для нас лучшей оказалась модель multilingual-e5-large, Bi-Encoder c 560M параметров и размером эмбеддингов в 1024 элемента.

Инженер по разработке ПО искусственного интеллекта Павел Яковлев максимально подробно рассказал в статье, как его команда разрабатывает и оптимизирует семантический поиск по сложным документам: PDF, HTML и DOCX.

Какие проблемы решает алгоритм FastCDC при дедупликации данных

FastCDC — это алгоритм разбиения данных на блоки переменной длины (Content Defined Chunking, CDC). В отличие от нарезки с фиксированной длиной блока, FastCDC решает проблему смещения границ (boundary-shift problem), которая возникает при вставке новых данных в файл. Например, если в начало файла добавить байт, то при использовании разбиения с фиксированной длиной все последующие блоки изменятся.

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

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

Основная идея FastCDC заключается в следующем: среди всех возможных последовательностей байтов (множество A) выделяется подмножество B. Когда в файле обнаруживается последовательность из множества B, алгоритм устанавливает границу блока (anchor) сразу после этой последовательности.

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

После нахождения опорного байта (anchor) алгоритм проверяет, удовлетворяет ли он дополнительным условиям. Например, FastCDC не создаст новый блок, если точка находится слишком близко к границе предыдущего блока и минимальный размер блока еще не достигнут. Если опорные байты не найдены, система отрежет блок по его максимально допустимому размеру. 

Добавление всего одного нового байта 0 сдвигает все предыдущие байты вправо, что приводит к изменению содержимого каждого блока:

Эксперт по разработке ПО отдела систем обработки данных в YADRO Ростислав Ефремов в статье подробно объяснил, что такое дедупликация данных, какую роль она играет в системах резервного копирования и как работает в СХД TATLIN.BACKUP

Тест на тестировщика: что в коробке?

Ответ: Это Shield box — экранированная коробка, внутри которой размещаются сотовые телефоны. Ее используют тестировщики телеком-оборудования. Коробка обеспечивает изоляцию сигнала и предотвращает возможность подключения сторонних абонентов к «тестовой» сети.

Если вы знакомы с этим оборудованием или хотите с ним познакомиться, вас могут заинтересовать несколько вакансий в команде Телекома в YADRO. 

→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE. 

Test Engineer (LTE/GSM Radio Subsystem)

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

Field Test Engineer (LTE/GSM) 

Команда готовит тестовые сценарии для драйв-тестов, проводит их по подготовленным тест-планам и измеряет ключевые показатели производительности базовых станций LTE/GSM с помощью измерительных комплексов. Здесь также от кандидата требуются знания принципов и законов радиосвязи, базовое понимание теории антенн и их характеристик.

→ А вот несколько вакансий, где глубокое знание телеком-технологий не является решающим фактором при отборе кандидатов. 

Test Engineer (Performance Test)

Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом. 

QA Automation Engineer 

Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.

Test Engineer Manual 

Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.

О направлении 

Команда Телеком с нуля создает телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Инженеры разрабатывают первые в России базовые станции стандартов GSM/LTE, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.

А как тестируют функции базовой станции, читайте по ссылке →