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

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

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

Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (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, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.

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

Петля времени в пайплайне для уменьшения числа галлюцинаций в LLM

Это — грубая схема работа RAG-пайплайна, который использует одна из ML-команд в YADRO.

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

Что сделали инженеры?

Решили дообучить базовую модель при помощи LoRA на специально собранном датасете для ситуаций, когда в контексте нет ответа на вопрос пользователя. На тот момент в качестве базовой модели LLM использовали saiga_mistral_7b, которая нетребовательна к ресурсам и долгое время была в топе на Russian SuperGLUE. Есть модели лучше, но, как правило, они либо огромные, либо имеют проблемы с лицензией в России, в том числе все, что основаны на LLaMa.

Самое главное: в этом RAG-пайплайне ML-инженеры решили сделать опциональную петлю, в которой проверяли бы каждый найденный фрагмент контекста на релевантность вопросу пользователя. Только те куски контекста, которые пройдут проверку, будут попадать в финальный вопрос для LLM.

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

Что это и за маркер? И к каким результатам привела оптимизация работы модели, читайте по ссылке → 

Спойлер: Модель DeepSeek-R1-Distill-Qwen-7B уступила saiga_mistral_7b по качеству, несмотря на то, что первая намного новее и вооружена механизмом reasoning.

Конкурентность в Go: просто запустить — сложнее управлять

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

Полезные материалы о конкурентности в Go можно найти в блоге Дейва Чени. Он рассматривает различные решения в Go, объясняя их происхождение и способы использования. В своих статьях он также подробно разбирает тему конкурентности.

Например, в статье Curious Channels Дейв Чени описывает два важных свойства каналов в Go:

1. Закрытый канал не блокируется. После закрытия в него нельзя отправлять данные, но можно читать. Если данных нет, возвращается нулевое значение. Это удобно при использовании range, который автоматически завершает цикл.

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

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

Владислав Белогрудов, эксперт по разработке ПО в YADRO, собрал полезные материалы про конкурентность в Go. В статье — блоги, выступления и книги, которые помогут разобраться, как в Go работать с горутинами и каналами без хаоса и дедлоков.

Готовим прошивки для BIOS. Нужно всего лишь...

В YADRO есть команда, которая разрабатывает и отлаживает UEFI для самых разных продуктов компании. Подробнее о ней — в видеоролике → .

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

Системы, для которых разрабатывают прошивки в YADRO, делятся на два типа: с BMC и без него.

Больше о работе команды и, в целом, об истории BIOS/UEFI читайте в статье → 

А если тоже хотите стать «поваром» UEFI, присмотритесь к одной из вакансий:

→ Старший/ ведущий разработчик на C++ (Linux/OpenBMC)

→ Старший разработчик на С (BIOS/UEFI)

→ Тимлид разработки в OpenBMC

SystemVerilog отжил свое? На пятки наступает Scala/Chisel?

DARPA, управление перспективных исследовательских проектов Минобороны США, описывает Chisel как технологию, позволяющую маленьким командам создавать большие цифровые проекты. И я вполне могу с этим согласиться, но есть нюансы.

Chisel — это, по сути, библиотека Scala, а точнее, Domain Specific Language. Языку Scala уже больше 20 лет, он постоянно развивается, сочетает функциональное и императивное программирование. При написании кода на Scala вам доступны все библиотеки Java. 

Scala — это масштабируемый язык, который позволяет добавлять свои языковые конструкции. На основе Scala можно создать язык под свои задачи. Так 12 лет назад и поступили инженеры в Беркли: выкинули из Verilog 90%, оставив только нужное, и обернули все это в Scala. Получился Chisel. 

Chisel используют прежде всего для создания RTL-описаний. Также он позволяет проводить симуляцию несложных модулей. Это удобно для создания юнит-тестов и моделирования работы различных алгоритмов. В плане симуляции не стоит возлагать на Chisel такие же надежды, как на System C или что-то подобное. Симулировать вы сможете лишь очень маленькие схемки, а генерировать — хоть целые кластеры из тысяч процессоров, вообще все, что захотите.

На основе Chisel/Scala можно написать свой HLS-инструмент (High Level Synthesis), где одним росчерком пера вы будете создавать очень большие схемы, что с использованием одного Verilog невозможно.

В блоге YADRO Денис Муратов подробно сравнил Chisel/Scala с SystemVerilog в создании RTL-описаниях, раскрыл основные преимущества и недостатки альтернативы, а также ее дополнительные возможности — функциональное программирование и переиспользование модулей.

Как не надо использовать Assert, если реализуете подход Design by Contract

Использовать Assert вместо if err != nil { return err}

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

Выполнять вычисления при вызове Assert

Еще одна распространенная и трудно выявляемая ошибка — это выполнение вычислений и присваивание значений переменным прямо при вызове Assert, которые могут быть упразднены при оптимизации кода компилятором:

•  e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),

•  Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).

Удалять Assert, несмотря на то, что это часть описания контракта

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

Например, вызывающая сторона может полагаться на некоторое поведение вызываемого кода. И если вызываемый код существенно изменился и контракт не выполнен, то вызываемая сторона тоже должна быть существенно переосмыслена.

В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.

Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →

Командное решение без долгих обсуждений: три проверенных метода

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

→ Голосование точками — быстрое выявление приоритетов

Этот метод помогает команде оперативно выбрать наиболее предпочтительный вариант. Каждый участник получает несколько голосов (например, в виде наклеек, отметок или фишек) и распределяет их между предложенными вариантами. Решение, набравшее больше всего голосов, считается приоритетным.

→ Степень поддержки — оцениваем и ранжируем

Этот метод предполагает, что каждый участник оценивает предложенные варианты по шкале, например, от 1 до 10. Чтобы решение считалось принятым, оно должно набрать средний балл выше установленного порога.

→ Метод NUF — объективный анализ вариантов

Этот метод помогает взвесить все «за» и «против», оценивая варианты сразу по трем ключевым критериям:

• Новизна (New): насколько инновационно и оригинально это решение?

• Полезность (Useful): решает ли оно реальную проблему?

• Осуществимость (Feasible): есть ли ресурсы и возможности для реализации?

Каждый участник ставит оценки от 0 до 10 по каждому критерию, после чего высчитывается средний балл. Затем команда выбирает решения с лучшими показателями, ориентируясь на самые полезные и реализуемые варианты.

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

Автор подарит колоду карт с еще большим количеством методов принятия решений тому, кто поделится своей историей в комментариях. Подробнее об условиях — в конце текста. 

Восставший из коррозии: реинкарнация одного «роботрона»

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

Вместо двух десятков мелких корпусов RAM и ROM я поставил по одной микросхеме памяти каждого типа, так как теперь это не дефицит. Особый интерес представлял последовательный порт RS-232 — на оригинальной плате он не был распаян, хотя функционал работы с ним в прошивке был! А значит, очень высок шанс, что интерфейс заведется.

Проект замерзает еще на пару лет, пока один из подписчиков, тов. Folk, не взялся за отрисовку платы в KiCAD. Месяц неспешной работы, и к январю 2022 года рождается она — новая плата для «Роботрона». Разрабатывалась плата один в один по габаритам старой, даже основные детали были на тех же самых местах. И тут я допустил три стратегических просчета...

Полная история восстановления и даже апгрейда Robotron S6130 — в статье Артёма Кашканова.

Как тестируют чипы перед производством: что такое системная верификация 

Системы на кристалле (SoC) состоят из логических и функциональных блоков. Такое деление позволяет независимо разрабатывать разные части системы, а затем модульно отлаживать их в изолированном окружении. Функциональная верификация — это процесс тестирования таких блоков по спецификации. Она проводится перед отправкой чипа на завод и называется pre-silicon стадией. Без этой процедуры велик шанс получить нерабочий чип, причем в объемах всей произведенной партии.

Проводить тесты можно при помощи таких инструментов, как:

• Функциональные симуляторы (например, QEMU) — работают очень быстро, но в отличие от других инструментов не предоставляют достоверной информации о работе устройства. Зато QEMU может почти молниеносно осуществить подачу требуемых данных и выдать результат в виде «прошел» или «не прошел», а также некоторые логи.

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

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

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

Как тестируют чипы на примере задач хакатона и как стать инженером по верификации, в статье рассказывают победители прошлогоднего SoC Design Challenge.

Как работает современный RAID-массив: разбираем реализацию YADRO

Чтобы обеспечить доступность данных, T-RAID решает определенный набор задач.

Построение пула хранения на несколько петабайт. Эту возможность обеспечивает архитектура T-RAID: схемы расположения данных, реализация страйпов и allocation-групп дисков.

Оптимизация ребилда дисков и нагрузки на них. T-RAID проводит ребилд только реальных данных, а также распределяет нагрузку ребилда на несколько дисков. Здесь задействована обработка ошибок через блоки, а также фоновые процессы recovery и balancer. В распределении нагрузки помогает фоновый воркер rate limiter и адаптивный троттлер фоновых процессов.

Защита от выхода из строя аппаратных компонентов СХД (процессора, материнской платы, блока питания, контроллера, системного диска). Достигается посредством двухконтроллерной работы в режиме active-active. Тома блоков доступны на запись и чтение одновременно с двух контроллеров при балансировке нагрузки к лунам. Реализацию active-active мы раскроем в отдельной части материала.

Обеспечение отказоустойчивой работы с самими данными от получения запроса до записи в диск. Это реализуется с помощью integrity-механизмов.

Отработка отказов оборудования. Здесь возможно несколько сценариев разного масштаба — от потери отдельного диска до потери целого контроллера или интерконнекта.

О том, как в T-RAID реализованы все перечисленные технические средства, в своей статье подробно рассказал Вячеслав Пачков, ведущий инженер по разработке ПО в департаменте СХД YADRO.

Быстрое трудоустройство в YADRO для разработчиков на С++

У нас стартовал SPRINT OFFER в команду разработки телеком-оборудования. Для «плюсовиков» это возможность получить предложение о работе всего за несколько дней. Если хотите пропустить долгие этапы собеседований, отправляйте заявку до 9 марта. 

Как все происходит

1. Подаете заявку — мы оперативно рассматриваем анкеты.

2. Проходите HR-скрининг и техническое интервью — без недель ожидания между этапами.

3. Получаете оффер — если все этапы успешно пройдены, предложение будет у вас в течение 3 дней.

Где предстоит работать 

Дивизион телекома создает решения для мобильных сетей. Инженеры разрабатывают базовые станции GSM/LTE, полный стек телекоммуникационных протоколов, а также системы управления и мониторинга. Большую часть кода разработчики пишут на C++. В зависимости от задачи они используют как современные возможности C++20, так и низкоуровневые оптимизации для повышения производительности.

Кого мы ищем

→ Software Engineer (Telecom Platform)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

• Разработкой платформы для базовых станций LTE/GSM (middleware, high availability, node management, delivery).

• Проектированием архитектуры, работа с C++/Linux.

• Интеграцией с аппаратной и программной частью системы.

• Оптимизацией кода и решение проблем производительности.

• Разработкой API, unit-тестирование, документация.

→ Software Engineer C/C++ (LTE/GSM)

Требуемый уровень: middle, senior, tech lead.

Чем предстоит заниматься:

• Разработкой программного обеспечения для базовых станций LTE.

• Реализацией стека протоколов 3GPP.

• Интеграцией с другими системами, оптимизация кода.

• Решением задач производительности и стабильности системы.

Подробнее о вакансиях и команде читайте на странице SPRINT OFFER. Успейте подать заявку до 9 марта!

Обойдемся и без Terraform: внедряем GitOps-подход для виртуальных машин

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:

1. В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.

2. На основе этих файлов формируются конфигурации для новых ВМ.

3. Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.

4. После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.

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

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

Ни единого разрыва: как ваш смартфон переходит из 4G в 3G или 2G

Сотовые операторы в России обслуживают более 260 миллионов абонентов (активных SIM-карт), а их сети работают с тремя поколениями технологий мобильной связи. Разберемся, как почти незаметно для нас смартфон переходит из LTE (4G) в 3G. А если базовой станции третьего поколения в зоне доступа не оказалось, то устройство подключается к 2G-сети.

Большинство операторов для взаимодействия между технологиями мобильной связи в части сервисов передачи данных используют архитектуру с Gn/Gp SGSN:

Мобильный трафик идет от абонента до базовой станции по радиоинтерфейсу и далее по транспортной сети оператора связи до шлюзов SGW и PGW — только потом выходит в интернет. Трафик на радиоинтерфейсе между устройством и базовой станцией, как правило, зашифрован, например, широко распространенным протоколом AES.

Трафик между базовой станцией и шлюзом SGW может быть зашифрован с помощью IPsec. Оператор анализирует трафик с помощью системы глубокого инспектирования трафика DPI. Эту систему реализуют на шлюзе PGW или на отдельном сетевом элементе — это так называемый standalone DPI.

Обычно для передачи мобильного трафика служит несущая по умолчанию (default bearer), которая позволяет подключиться к пакетным услугам. Несущая по умолчанию всегда является non-GBR, то есть не гарантирует скорость передачи данных. Поэтому при увеличении количества пользователей, которые подключены к одной базовой станции, скорость мобильного интернета снижается для каждого устройства. 

Для голосовых вызовов по сети LTE (VoLTE) используются две несущие. Первая — несущая по умолчанию с QCI5 для сигнальных сообщений. Вторая — выделенная несущая с гарантированной полосой пропускания (QCI1) для голосового трафика.

При перемещении пользовательского устройства между базовыми станциями обрыва связи не происходит благодаря контролируемой передаче управления соединением от одной базовой станции другой (процедура handover). При этом устройство обычно обслуживается теми же системами опорной сети. Впрочем, возможна смена сигнального узла MME или шлюза SGW.

Если 4G-покрытие от обслуживающей базовой станции ухудшается и рядом нет соседней 4G-станции, то устройство с помощью процедуры handover переводится на 3G-станцию либо перенаправляется на 2G-станцию.

В посте мы рассказали о взаимодействии различных технологий в части сервисов передачи данных. Михаил Бухтеев, который в YADRO отвечает за планирование функционала базовой станции LTE, подробно объясняет в статье, как передаются голосовые вызовы и как устроены мобильные сети.

Дашборд — лицо системы: как сделать его удобным для команд из более 100 инженеров

Переосмысление дашборда стало одной из важных задач в процессе обновления интерфейса TMS TestY.

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

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

Добавили поиск по проектам и табличное представление, в котором доступно то же самое, что и на карточках: переходы, добавление в избранное, переключатели Only Favorites и Show Archive

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

Какие еще обновления появились в TMS с открытым исходным кодом, читайте в статье.

А ты такой холодный: представим технологии Rust-дебаггеров в виде айсберга

На верхушке айсберга видим технологии DWARF, PTRACE и ELF, а внизу — набор более редких технологий. 

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

PTRACE — системный вызов, который позволяет одному процессу (tracer) управлять и исследовать другой процесс (tracee).  

ELF (Executable and Linkable Format) — формат исполняемых двоичных файлов. 

DWARF (Debugging With Arbitrary Record Formats) — стандарт, описывающий формат .debug_xxx секций в ELF.

Что касается «подводных» технологий, упомянутых на картинке: применяя закон Парето, можно смело сказать что 80% знаний необходимы, чтобы реализовать только 20% функционала (и не самого важного). Но если хотите узнать о них больше, напишите в комментариях.

Подробнее о PTRACE, ELF и DWARF, а также о функциях, которые они реализуют в отладчиках на Rust, читайте в статье.