Апгрейд для сетевых инженеров: присоединяйся к разработке «соточных» коммутаторов

Разработчики коммутаторов KORNFELD ищут коллег. Нужны сетевые инженеры, которые будут тестировать сетевое оборудование, поддерживающее широкий спектр сервисов и протоколов, включая MC-LAG, BGP, OSPF, VxLAN, VPN, VRRP, LACP и другие. «Классические» тестировщики тут не подойдут — у успешного кандидата должен быть опыт работы с оборудованием типа Cisco, Huawei, Juniper, знание сетевых протоколов, применяемых в дата-центрах и офисах, — не только в теории, но и на практике. Фокус на мидл-специалистах и выше.

Получить быстрый оффер за 3 дня → 

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

Примеры задач сетевого инженера в тестировании:

• Анализ продуктовых требований/ПМИ/ПСИ и составление use-кейсов.

• Проведение разных видов тестирования: e2e, fail-over.

• Составление тест-кейсов, тест-планов на продукт — как на новый функционал, так и на существующий.

• Участие в совместных тестах, в том числе на площадке заказчика, и взаимодействие с командами разработки/L3/сервиса/документации.

Больше о вакансии — по ссылке.

Чтобы лучше представлять работу с KORNFELD, читайте статьи инженеров YADRO:

→ Жизненный цикл фичи в коммутаторе: от идеи через QA до прода

→ Как устроен L3-коммутатор: разбираемся с железом и настройками конфигурации

Игра-воспоминание: исследуйте 90-е, 00-е и 10-е и найдите «ошибки времени»

Вспомните, как все начиналось. Когда Интернет был в прямом смысле громким, музыка играла с Winamp, а первый компьютер был окном в новый, загадочный мир. Самое время вспомнить, как это было, — и проверить, насколько вы внимательны!

Мы предлагаем поностальгировать и сыграть в небольшую игру. Вы заглянете в 90-е, 00-е и 10-е, рассмотрите знакомые до мелочей детали и почувствуете атмосферу тех лет. Но есть одна хитрость: в каждой эпохе спрятано пять предметов, которых тогда еще не существовало, и вам нужно их отыскать. 

Открыть портал в другое десятилетие →

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

Ускоренный найм для инженеров C/C++: оффер за 3 дня

Телеком-команда YADRO создает решения для мобильных сетей нового поколения: базовые станции GSM и LTE, а также весь программный стек — от низкоуровневых протоколов до систем управления. Сейчас в команде открылись вакансии инженеров, отбор на которые можно пройти гораздо быстрее, чем обычно.

SPRINT OFFER — это формат ускоренного найма: все этапы отбора проходят всего за три дня. Чтобы попасть в программу, достаточно подать заявку до 19 октября.

Software Engineer (телеком-платформа)

Вам предстоит разрабатывать платформенное решение для телеком-систем. На его основе строятся современные узлы сотовых сетей LTE- и GSM-стандартов — например, базовые станции и системы управления. В это роли вы будете: 

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

• Разрабатывать компоненты платформы в технологическом стеке C++/Linux.

• Собирать и анализировать метрики для оценки производительности продукта.

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

• Поддерживать средства развертывания и обновления приложений.

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

• Обеспечивать качество продукта: исправлять дефекты, писать unit-тесты, проводить код-ревью, разрабатывать техническую документацию.

• Создавать инструменты, упрощающие работу других разработчиков.

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

Подать заявку по ссылке →

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

Создавайте высоконагруженные системы, которые обеспечивают стандарты связи разных поколений. Работа охватывает три уровня. L1 — низкоуровневое программирование, работа с радиоканалом и сигналами, близкая к железу. L2 — логика, работа с алгоритмами и математическими моделями. L3 — высокоуровневое программирование, бизнес-логика. В этой роли вы будете: 

• Разрабатывать решения совместно с командой — от этапа исследования и прототипирования до коммерческого внедрения пакетного ядра сети 5 поколения (5G).

• Создавать программное обеспечение для базовых станций LTE, реализуя полный стек протоколов 3GPP.

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

• Интегрировать решения с другими компонентами системы — как программными, так и аппаратными.

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

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

Узнать больше и подать заявку по ссылке →

Успеть за пять дней: отклик — интервью — оффер за пять дней для инженеров по безопасности

Надежные продукты начинаются с безопасного кода. Команда безопасности следит за уязвимостями, укрепляет процессы и поддерживает CI/CD в форме. И мы в YADRO укрепляем команду —  ищем специалистов на позиции Application Security Engineer и DevSecOps. Принимаем заявки до 28 сентября.

Получить быстрый оффер → 

Application Security Engineer

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

• проводить триаж уязвимостей, найденных с помощью SAST, SCA, Secret Detection и других инструментов;

• оценивать защищенность продуктов на основе моделей угроз и выполнять специализированные тесты (fuzzing, сканирование портов и др.);

• исследовать новые векторы атак и участвовать в тестировании на проникновение;

• разрабатывать PoC решений для функций безопасности;

• участвовать в выборе и внедрении инструментов тестирования.

Подать заявку и узнать больше о вакансии можно по ссылке → 

DevSecOps / Infrastructure Engineer

Присоединяйтесь к нам в роли инженера, который будет развивать практики DevSecOps, совершенствовать подходы к безопасности инфраструктуры разработки и CI/CD, а также помогать командам интегрировать проверки безопасности в процессы. В этой роли вы будете:

• внедрять и развивать DevSecOps-практики;

• выявлять и устранять угрозы в инфраструктуре продуктов и CI/CD-процессах,

• проектировать и внедрять безопасную архитектуру CI/CD;

• обеспечивать стабильную работу инструментов SAST/SCA/DAST и создавать Quality Gates;

• автоматизировать процессы с помощью GitLab CI, Ansible, Helm;

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

Подробнее о вакансии по ссылке →

Новая глава в твоей QA-карьере может начаться через три, два, один… 

Как насчет того, чтобы сменить привычную тестовую среду на что-то новое? Например, на тестовый стенд с BBU, RRU, симулятором ядра сети и т. д. И сделать это еще до осенних холодов. 

Инженеры YADRO из дивизиона Телеком ищут коллег, которые присоединятся к тестировщикам-автоматизаторам. Нужны QА-инженеры с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Приветствуется опыт работы с Linux и понимание сетей, базирующихся на TCP/IP. 

Поучаствовать в спринт-офере до 7 сентября → 

_____________________________________________________________

А чтобы узнать больше про тестирование в телекоме, изучите эти статьи: 

→ Какими инструментами пользуются в телекоме

→ Пример тестирования определенной функции в телекоме

→ Нестыдные вопросы про телеком

Как проходит онбординг и рост новичков в HW QA

Войти в hardware-тестирование можно с любым бэкграундом. В команде HW QA в YADRO есть специалисты, которые ранее не работали с серверами, и те, кто с первого дня уверенно пользуется осциллографом. От новых сотрудников не ожидают готовых экспертных знаний — важны мотивация и желание разбираться. Остальному обучают внутри команды.

В первую неделю — оформление, знакомство с командой, лабораторией, стендами и процессами, закрепление ментора. За 14 дней — полное погружение в работу с BMC. В первый месяц поощряется командное взаимодействие. 

На 2–4 неделе — изучение Linux, устройства продуктов, компонентов, прошивок и инструментов, работа по чек-листам: запуск тестов, анализ результатов. Ко второму месяцу — доступ к целевой платформе, документации и задачам среднего приоритета. 

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

Сейчас команда ищет HW QA-инженера в департамент разработки аппаратных средств. Задачи — тестирование инженерных образцов, валидация компонентов, настройка стендов, автоматизация, работа с BIOS, BMC и прошивками.

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

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

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

«Клей» для GPIO в QEMU

В прошлой статье мы пришли к выводу, что QMP — это лучше, чем ничего. Но хочется большего — библиотеку или программу (желательно, уже готовую), которая умеет читать/писать и узнавать об изменении состояния через poll() / pselect() / select() / epoll() / read(). 

В таком случае для каждой модели GPIO нужен «клей», похожий на тот, что используется с chardev — мы включаем его прямо в модифицированный QEMU. Очевидное название такого «клея» — gpiodev. Вот его основные функции, которые сейчас почти полностью соответствуют GPIO UAPI в Linux:

• сообщать количество линий, конфигурацию, название и потребителя каждой линии,

• читать и задавать состояние линии,

• отслеживать изменения состояния и конфигурации линии (вход/выход, запрос/освобождение).

«Клей» состоит из двух групп, первая — это индивидуальные для каждого модуля GPIO функции, которые gpiodev использует, чтобы запросить специфическую информацию:

• LineInfoHandler() — информация о линии: имя, флаги и потребитель,

• LineGetValueHandler() — состояние линии: условный 0 или 1,

• LineSetValueHandler() — задать состояние линии: 0 или 1.

По аналогии с GPIO UAPI напрашиваются также функции LineGetMultiValueHandler() и LineSetMultiValueHandler() для запроса и выставления линий, но я решил ограничиться минимальным набором.

Можно ли организовать прозрачное взаимодействие с устройствами внутри QEMU — использовать те же библиотеки и инструменты, как и для реальных устройств? Читайте во второй части трилогии о долгом пути до GPIO в QEMU.

DeepSeek, Qwen, T-lite, T-pro: на чем мы запускаем LLM для своих ИИ-сервисов

До фреймворка vLLM мы использовали NVIDIA Triton в паре с TensorRT LLM бэкендом. Но перешли на vLLM, потому что с ним оказалось намного проще добавлять новые модели. Да и по стабильности vLLM показал себя лучше: нормально работал под нагрузками там, где связка Triton и TensorRT начинала сбоить и падать. К тому же инференс-сервер vLLM изначально предоставляет OpenAI-совместимые REST API, что упрощает его использование в других продуктах. А инференс-сервер Triton работает с более обобщенным KServe REST API, который сложнее интегрировать в другие продукты.

Не обошлось без проблем и с vLLM: на наших валидационных тестах модель давала неконсистентные ответы даже с нулевой температурой. Оказалось, что это известная особенность vLLM, даже упомянутая в документации. Мы нашли несколько советов, как минимизировать этот эффект: отключать prefix caching опцией --no-enable-prefix-caching и фиксировать random seed опцией --seed. Это помогало при одном запущенном инстансе модели, но при нескольких, даже работающих на одном железе и версии софта, проблема всплывала снова. Также неконсистентность ответов возникает при больших нагрузках — например, когда тесты запускаются одновременно с бенчмарком.

Еще один вызов — это накладные расходы от litellm-proxy и его масштабирование под нагрузками. LLM Gateway, в качестве которого мы используем LiteLLM, превращается в боттлнек кластера, так как все другие сервисы взаимодействуют с кластером именно через него. То есть именно на него идет суммарная нагрузка от всех возможных пользователей, которая потом распределяется между разными моделями и их инференс-серверами.

О том, как устроен инференс-кластер YADRO, подробно рассказал Владислав Виноградов. Бонус к разбору программной и аппаратной части кластера — челленджи и бенчмарки!

Как устроено тестирование телеком-продуктов

Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные). Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях: 

• Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.

• Бокс-тестирование предполагает интеграцию нескольких компонентов базовой станции в рамках единой среды. В этом режиме используются симуляторы пользовательских устройств и ядра сети. 

• Системное тестирование охватывает проверку сквозных (end-to-end) сценариев на реальной аппаратной платформе. В отличие от бокс-тестов, здесь задействуются реальные пользовательские терминалы и максимально приближенная к коммерческой опорная сеть.

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

Выделим полевое тестирование. Оно позволяет в реальных радиоусловиях с реальными абонентскими терминалами протестировать описанные выше процедуры. Для такого тестирования используется специальный автомобиль, в котором установлено оборудование для проведения drive-тестов.

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

В статье Ивана Политова и Антон Васина, инженеров из департамента разработки и проектирования опорной 5G-сети в YADRO, читайте подробнее, как в компании тестируют телеком-продукты.

Что ты сделал для хип-хопа IT-инфраструктуры в свои годы? Писал UEFI и BMC для высоконагруженного оборудования 

В YADRO есть распределенная команда, которая разрабатывает и сопровождает собственные программные реализации UEFI (BIOS) и BMC. Для самого разного оборудования — от серверов до телеком- и клиентского оборудования. 

Познакомиться с командой → 

Какие задачи выполняют в команде BIOS/BMC: 

• Реализуют программную поддержку новых аппаратных продуктов компании, определяют протоколы и методы взаимодействия между программными и аппаратными компонентами продуктов YADRO.

• Проводят верификацию микрокода и выполняют проверку прошивок микросхем всех продуктов компании. Выстраивают стратегию тестирования.

• Исследуют новые программные и аппаратные технологии для применения в продуктах. Рефакторят код для повышения производительности.

• Придумывают методы безопасного обновления прошивок BIOS и BMC, чтобы обеспечить минимальный или нулевой даунтайм.

• Добавляют новые фичи и меняют существующие — от WebUI до политик управления аппаратными компонентами.

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

От вибростендов до полевых испытаний: тесты Hardware QA в реальных условиях

Как понять, выдержит ли стойка или сервер поездку через всю страну в контейнере или грузовике? Чтобы проверить, готово ли оборудование к реальной транспортировке, команда HW QA использует целый комплекс инструментов и методов:

• Вибростолы воспроизводят типичные транспортные нагрузки — от тряски в грузовике до промышленных вибраций. Оборудование фиксируется на платформе, и на него подаются колебания заданной частоты, амплитуды и направления. Вибротесты стоек показывают, как сервера реагируют на тряску: анализ ускорения и спектр вибраций (частоты до 10–40 Гц).

• Датчики ускорений фиксируют рывки и удары, чтобы оценить реальные перегрузки компонентов.

• Полевые испытания: перевозят стойки по России, ставят датчики и собирают реальные профили нагрузок в зависимости от типа грузовика и подвески.

Почему это важно? Даже один отвалившийся кабель в пути может сделать стойку непригодной к использованию.

Это лишь часть арсенала Hardware QA в YADRO. В статье директор департамента верификации и контроля качества Игорь Попов рассказал, как команда проверяет стойки и серверы на прочность, какие инструменты используют и как команда инженеров моделирует реальные условия работы оборудования.

Как устроен livepatch-модуль для ядра Linux

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

• исправленный код одной или более функций из vmlinux и/или из модулей ядра,

• метаданные, указывающие, как применить эти исправления к соответствующим компонентам ядра Linux. 

Чтобы применить лайвпатч-обновление, нужно загрузить этот модуль ядра, например, с помощью insmod или modprobe, а затем активировать его, как правило, через sysfs. 

При этом старый код ядра Linux (тот, который хотим обновить) и новый (тот, что в лайвпатч-модуле) сосуществуют в памяти системы. Это дает возможность при необходимости отменить лайвпатч-обновление в runtime: деактивировать его через sysfs, а затем выгрузить лайвпатч-модуль.

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

Примечания:

• У TuxCare / KernelCare лайвпатчи поставляются в другом, проприетарном, формате, но мы его рассматривать не будем.

• Для некоторых архитектур, например RISC-V, при активации и деактивации патча вызывается stop_machine(), то есть работающие процессы при этом все-таки останавливаются на некоторое время. Начиная с версии 6.16 ядра Linux, для RISC-V stop_machine() уже, вероятно, не будет использоваться в таких ситуациях.

Все, что нужно знать о лайвпатингче для ядра Linux, вы найдете в цикле статей: от подготовки лайвпатча до работы на x86, ARM и RISC-V.

Читать первую часть →

Читать вторую часть →

Как мы синхронизировали съемку для возрожденного проекта DPED

Команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева продолжает рассказывать о работе по возрождению и улучшению DPED (Deep Photo Enhancement Dataset). 

Мы решили задачи автоматизации, но столкнулись с еще одной проблемой: фото на планшете и камере снимались с некоторой задержкой относительно друг друга. Использование простых пауз (time.sleep) оказалось ненадежно и неэффективно. Тогда мы реализовали многопоточное решение:

• Первый поток управляет съемкой с камеры с помощью библиотеки pyautogui.

• Второй поток управляет съемкой с планшета через ADB.

• Оба потока обмениваются информацией через очередь (queue.Queue() из стандартной библиотеки Python) — это потокобезопасная структура данных, которая позволяет одному потоку передать сигнал другому. В нашем случае очередь используется для передачи сигнала о начале съемки с камеры. Получив этот сигнал, планшет почти без задержки запускает захват изображения.

В процессе тестирования среднее время задержки составило 50 мс, но разброс данных достигал 93 мс. То есть, существуют случаи, когда мы получаем изображения с непозволительной задержкой в 100 мс и более. Мы отметили этот момент, но продолжили собирать датасет, а изображения с большой задержкой — удалять.

Скрипт автоматизации съемки кадров:

import subprocess
from threading import Thread
import pyautogui
import time
from queue import Queue

# координаты для кликов мыши

CAMERA_SHUTTER_BUTTON = (329, 748)    # кнопка затвора в приложении

FOCUS_POINT = (1189, 204)            # точка фокуса или область кадра


def tablet(q):
    time.sleep(0.1)
    if q.get() == 1:
        p = subprocess.Popen(r'.\adb.exe shell', stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        p.stdin.write(b'input keyevent 27')
        p.stdin.close()

def camera(q):
    pyautogui.click(*CAMERA_SHUTTER_BUTTON)
    pyautogui.moveTo(*FOCUS_POINT)
    q.put(1)
    pyautogui.mouseDown()
    time.sleep(0.02)
    pyautogui.mouseUp()

q = Queue()
thread1 = Thread(target=camera, args=(q,))
thread2 = Thread(target=tablet, args=(q,))
thread1.start()
thread2.start()

В оригинальной работе DPED точные значения задержки не указывались: авторы фиксировали устройства на механическом стенде и выполняли съемку вручную, без программной синхронизации или последующего анализа временного лага между кадрами. Насколько нам удалось выяснить, синхронизация производилась «на глаз», что не позволяет оценить точность в миллисекундах. Таким образом, можно утверждать, что наша реализация обеспечивает более детерминированный и измеримый результат по синхронизации.

Читайте в статье, как команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ доводит снимки с планшета YADRO KVADRA_T до качества полупрофессиональной камеры Sony Alpha ILCE 6600.

Пошаговые инструкции сборки — больше не ад для техписов

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

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

На данный момент мы собрали из исходников документы для 647 конфигураций серверов. Даже при таком сравнительно небольшом количестве инструкций мы простым делением получаем затраты на один документ в размере 2 человеко-часов. Это в 12,5 раз дешевле, чем писать отдельные инструкции вручную — выше мы оценивали затраты такого подхода. В итоге с документацией справляются шесть человек — а если бы мы делали инструкции вручную, потребовалось бы не меньше 13 сотрудников. После внедрения конструктора мы оценили дальнейшие трудозатраты, продолжили работу с динамической документацией, и уже через несколько месяцев система начала окупаться.

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

Из чего состоит MeyerSAN — решение для имитации ошибок в СХД

Проект MeyerSAN — это программно-аппаратный комплекс на основе сервера VEGMAN. Комплекс имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию системы хранения данных на ошибки. Решение необходимо для тестирования и валидации работы подсистем, которые находятся в составе СХД и определяют проблемные диски. 

Как это работает: 

1. Мы подключаем сервер к системе хранения данных. 

2. С помощью ПО и драйверов заставляем СХД видеть сервер как диск или несколько дисков.

3. Вносим отклонения в поведение диска. Например, имитируем ситуацию, когда пользователь записал данные в диск, а прочитать их не смог.

Задача MeyerSAN — эмулировать проблемы с дисками: задержки, ошибки, порчу данных и метаданных.

Архитектура MeyerSAN состоит из трех больших блоков: 

1. REST, так называемый MRSNMGMT. Позволяет конфигурировать систему в соответствии с пожеланиями.

2. MRSNLib. Cодержит бизнес-логику приложения: обработку и модификацию команд.

3. Драйверы низкого уровня. Они предоставляют нам механизмы транспорта и позволяют соответствовать всем протоколам.

Средний компонент, MRSNLib, команда разработчиков написала на современном С++ 23. Как именно инженерам удалось интегрировать новейший стандарт, а также паттерны объектно-ориентированного программирования в проект MeyerSAN, рассказывает один из создателей проекта Константин Крюков в новой статье.

Как создать простейшую модель GPIO для QEMU

Предлагаю два варианта, которые я условно решил назвать MMIO и PCI. Последний — тоже MMIO, но в QEMU они добавляются разными путями. Начнем с сердца любой MMIO-модели — апертуры.

Апертура и адресное пространство

Как я упоминал в одной из своих статей, любое MMIO-устройство — это MemoryRegion с заданными шириной доступа и размером. Для того, чтобы он был виден CPU или другому устройству, такому как DMA, его нужно разместить в соответствующем адресном пространстве — например, пространстве, назначенном для cpu0:

      0x0                                    0xffffffffffffffff
      |------|------|------|------|------|------|------|------|
0:    [                    address-space: cpu-memory-0        ]
0:    [                    address-space: memory              ]
                    0x102000           0x1023ff
0:                  [             gpio        ]

В любое время можно посмотреть существующие адресные пространства и регионы памяти в мониторе QEMU:

(qemu) info mtree
[...]
address-space: cpu-memory-0
address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000102000-00000000001023ff (prio 0, i/o): gpio
[...]

Тогда в модели устройства нам нужно всего лишь создать такой регион и назначить ему соответствующие функции записи и чтения:

static const MemoryRegionOps mmio_mmio_ops = {
    .read = mmio_gpio_register_read_memory,
    .write = mmio_gpio_register_write_memory,
    .endianness = DEVICE_NATIVE_ENDIAN,
    .valid = {
        .min_access_size = 4,
        .max_access_size = 4,
    },
};
 
[...]
memory_region_init_io(iomem, obj, &mmio_mmio_ops, s,
                      "gpio", APERTURE_SIZE);
[...]

Фактически это означает, что все семейство инструкций Load/Store будет вызывать mmio_gpio_register_read_memory()/mmio_gpio_register_write_memory() при совпадении адреса чтения/записи с адресом региона в адресном пространстве.

static uint64_t mmio_gpio_register_read_memory(void *opaque, hwaddr addr, unsigned size);
static void mmio_gpio_register_write_memory(void *opaque, hwaddr addr, uint64_t value, unsigned size);

Передаваемые аргументы и возвращаемое значения интуитивно понятны. Отмечу, что hwaddr addr — это адрес относительно начала нашего региона, а не абсолютный адрес.

Нам остается лишь создать устройство и добавить его регион в файле машины:

gpio = qdev_new(TYPE_MMIO_GPIO);
sysbus_mmio_map(SYS_BUS_DEVICE(gpio), 0, ADDRESS);

Почти десять лет назад Никита Шубин, ведущий инженер по разработке СнК в YADRO, сделал возможность чтения и записи GPIO для QEMU. Читайте первую часть трилогии о долгом пути до GPIO в QEMU.

Как улучшить режим ночной съемки с помощью нейросети на примере MEFNet

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

MEFNet — это подход к слиянию изображений с разной экспозицией. Он создан для работы со статическими последовательностями кадров произвольного разрешения и в произвольном количестве. Название MEFNet происходит от термина Multi-Exposure Fusion, то есть «многоэкспозиционное смешивание». Отсюда и сокращение MEF.

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

Схема работы алгоритма MEFNet. Источник: Ma, K., Duanmu, Z., Zhu, H., Fang, Y., & Wang, Z. (2019). Deep guided learning for fast multi-exposure image fusion. IEEE Transactions on Image Processing, 29, 2808-2819

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

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

• Слои 1–6 используют ядра размером 3×3 с разными коэффициентами расширения (dilation rates): 1, 2, 4, 8, 16, 1. Это позволяет захватывать контекст на разных масштабах.

• Слой 7 — финальный слой с ядром 1×1, который преобразует фичи в весовые карты.

• Нормализация — после каждого сверточного слоя (кроме последнего) применяется адаптивная нормализация (AN), сочетающая нормализацию по экземпляру (instance normalization) с обучаемыми параметрами.

• Активация — используется Leaky ReLU (LReLU) для сохранения структурной информации.

Подробнее о MEFNet и других алгоритмах улучшения режима ночной съемки в мобильных устройствах на примере планшета KVADRA_T читайте в статье Полины Лукичевой из команды AI ML Kit в YADRO.

Как навели порядок в работе техписателей и ускорили процессы

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

Чтобы навести порядок, команда предприняла несколько шагов:

• Ввели единый стиль оформления задач, документов и исходников.

• Определили правила именования файлов, веток и структуру репозитория.

• Согласовали формат взаимодействия внутри команды.

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

Стали шире использовать возможности разметки: избавились от лишнего, ввели переиспользование через ключи (conkeyref, keyref) и упростили поддержку кода. Поработали и с визуальной частью:

• Ввели правила для изображений: фиксированные размеры, формат, плотность.

• Стандартизировали визуальный стиль.

• Убрали визуальный шум, сфокусировались на главном.

• Установили лимит на размер изображений для ускорения загрузки.

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

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

Подробнее о бережливом подходе к технической документации читайте в статье Ивана Холодкова, старшего технического писателя направления производственной документации в YADRO.

Аркадный автомат на RISC-V: сбиваем астероиды с микроконтроллером MIK32 АМУР

Вадим Новиков решил реализовать игровую физику в условиях bare metal, используя свой предыдущий опыт на C++/SFML. В проекте использовалась плата Elbear Ace-Uno на базе микроконтроллера MIK32 АМУР, SPI OLED-дисплей SSD1306 разрешением 128×64 и джойстик HW-504 (KY-023), а также модули SPI (цифровой интерфейс передачи данных), аналого-цифровой преобразователь для калибровки и чтения положения джойстика и GPIO для вывода настройки и ввода состояния кнопки.

Код на C включал непрозрачные типы, которые позволяют реализовать подобие инкапсуляции из ООП. С ними можно объявить в заголовочном файле указатель на некую структуру, но не определять ее. А в единственной трансляции определить структуру и статические функции для взаимодействия с внутренними полями, которые недоступны извне. И поместить туда, соответственно, реализацию открытого интерфейса. Вместо использования регистров напрямую Вадим подключил библиотеку hardware abstraction layer (HAL), чтобы впоследствии было проще портировать проект на STM32 и другие микроконтроллеры.

Результатом работы стала Asteroids — реинкарнация классической игры эпохи аркадных автоматов. Корабль игрока непрерывно выпускает снаряды. После столкновений снаряда с астероидом исчезают оба объекта, при столкновении с кораблем — только астероид. Астероиды, вышедшие за нижнюю границу, возвращаются сверху экрана. Корабль же выйти за границы экрана не может.

Это лишь один из интереснейших проектов, реализованных студентами по итогам последнего потока курса YADRO по программированию микроконтроллеров на RISC-V. Интересно узнать о других проектах? Мы уже рассказали о них в статье.