Yandex for Backend

💹 Как мы провели Back to Back 1 августа мы собрали 700 бэкенд-разработчиков одновременно в Москве, Белграде и Ереване. Послушали 25 докладов (а это 20 часов отборного контента!), обменялись идеями и встретили последний месяц лета вместе. Спасибо, что были с нами! ✨ Чем мы ещё занимались 🟢 Москва. Решали D&D-квесты и архитектурные каты, проходили космический квест, обсуждали агентную разработку и общались с экспертами. А на афтерпати зажигали вместе с группой «Научно-технический рэп» 🟢 Белград. Восхищались роборукой на экскурсии и соревновались в гонках на роверах 🟢 Ереван. Любовались офисом и дискутировали про софты и харды 📺 Записи трансляций: 🟢 Москва — C++ Zero Cost и Architecture&Performance 🟢 Белград — C++ Zero Cost 🟢 Ереван — Architecture&Performance 📸 Ищите себя на фотографиях: 📟 Москва 📟 Белград 📟 Ереван 🈯️ До встречи на следующих конференциях! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 Миллион устройств, один канал и никаких лишних TLS-рукопожатий Чтобы убрать обязательный хаб из умного дома, нужно столкнуться с серьёзными вопросами инженерии: устройства должны без посредников входить в экосистему, держать долгоживущее облачное соединение и обновляться. А мощным бэкендом здесь не поможешь, ведь все ограничения железа, памяти и CPU — на клиентской стороне. Меня зовут Вадим Иванов, я старший разработчик программного обеспечения в команде разработки Умного дома. И мы строим новую платформу, которая должна держать больше миллиона активных устройств. Поэтому было решено последовательно убирать лишнюю сложность на каждом слое — от заводского контура до транспортного канала. Рассказываю, что мы для этого сделали 🔽 1️⃣ Комиссионинг через BLE (Bluetooth Low Energy) Мы реализовали настройку устройства прямо с телефона. После первого запуска оно получает по BLE предварительно зашифрованный набор данных: 🟢 Параметры Wi‑Fi 🟢 Код авторизации 🟢 Данные клиента для обмена кода на токен 🟢 Служебные данные для регистрации в облаке А потом проходит доверенную цепочку: 🟢 Расшифровывает payload, который передан по BLE 🟢 Подключается к Wi‑Fi 🟢 По HTTPS меняет код авторизации на access token 🟢 Регистрируется в облаке 🟢 Поднимает постоянное облачное соединение 🟢 Отправляет описание своих возможностей 🟢 Перезагружается в рабочий режим 2️⃣ Мультиплексированный WebSocket/TLS-канал вместо кучи соединений Это дало нам сразу несколько эффектов: 🟢 Сетевой профиль устройства стал почти постоянным. Неважно, сколько у конкретного устройства возможностей — три или тридцать, — базовая стоимость облачного транспорта остаётся примерно одной и той же 🟢 Появилась одна reconnect-стейт-машина вместо нескольких. На массовом флоте это критично: reconnection storm всегда проблема и клиента, и сервера 🟢 Стало проще планировать серверную часть. Для облачных устройств мы выделили отдельный контур сервисов вокруг WebSocket-прокси и доставки сообщений, чтобы нагрузку можно было изолировать и проще считать 3️⃣ Однопоточная модель с фиксированной стоимостью по памяти Почти вся логика устройства: обработка директив, отправка событий, OTA, комиссионинг, сетевые реакции — проходит через одну очередь задач на FreeRTOS. Это решение выглядит менее эффектно, чем набор независимых потоков, но для embedded-платформы так оказалось намного лучше. Нам не нужно держать отдельные стеки, думать о гонках, мьютексах, порядке колбэков, ловить редкие зависания и разбираться с багами, которые проявляются раз в неделю на конкретной прошивке и конкретной Wi‑Fi-сети. 🔶 А в статье на Хабре я рассказал ещё больше подробностей о том, что мы сделали с сетевой устойчивостью, безопасностью и производством. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🕵🏻‍♂️ Телеметрия обучений LLM: как мы контролируем наши GPU Привет, меня зовут Иван Мякиньков, я разработчик бригады инфраструктуры «Генезиса» в Поисковых сервисах и ИИ. Каждый день в Яндексе происходит более 5000 обучений LLM. Из них около 1500 по разным причинам заканчиваются неудачей. Раньше диагностика выглядела так: обучение упало → скачиваем логи → ищем в простыне текста ошибку → пытаемся понять причину. На это уходили часы работы, а иногда приходилось ещё и идти к дежурному инфраструктуры за консультацией. Мы решили автоматизировать процесс поиска ошибок. А заодно уменьшить их количество и сделать обучения эффективнее. Для этого сначала нужно определиться с метриками. ❇️ Что такое компьют Наш ключевой ресурс — это GPU, на которых и происходят обучения. Мы называем их карточками. Компьют — это количество карточек, умноженное на время обучения. Чем метрика меньше, тем дешевле обучение. 💹 Решение: автоматическая регистрация и мониторинг Мы отказались от ручного копания в логах. Теперь при запуске обучения в фоне стартует процесс, который парсит их по набору регулярных выражений (правил). Если находится совпадение — система сразу отмечает ошибку. У нас есть дружелюбный интерфейс, в котором можно просто ввести ID обучения и увидеть все данные о нём, в том числе точную причину сбоя. Мы регулярно обновляем набор правил. Старые проблемы мы чиним, но появляются новые. Для непонятных новых кейсов мы прикрутили LLM, которая по логам может описать причину проблем. ❇️ Статистика — это очень полезно Из автоматизации есть приятное следствие: теперь мы можем собирать статистику по ошибкам. Можно отслеживать динамику конкретных проблем и лучше понимать, где теряем компьют. Если какая-то ошибка набирает обороты — мы чиним её и проверяем эффект по графику. ❇️ Как следить за эффективностью более точечно GPU-утилизация — это бинарная метрика, которая отмечает, работает или нет в данный момент конкретная карточка. Чтобы «залезть внутрь» и посмотреть, насколько она загружена, мы используем другой показатель — SM-утилизацию. Она показывает долю вычислительных единиц GPU, которые непосредственно заняты обучением. Сравнивая SM-утилизацию между запусками, мы находим узкие места в коде (например, слишком долгую инициализацию) и проблемы, вызванные троттлингом. ❇️ Итог: три кита телеметрии 🟢 Наблюдение за обучением и выявление проблем. В основном об этом мы говорили выше 🟢 Оповещения пользователей и дежурных в реальном времени. Бот в мессенджере тегает ответственных при сбоях и присылает ежедневные отчёты по состоянию всех запусков 🟢 Детализация по таймстемпам. Мы разметили код временны́ми метками и видим визуализацию этапов обучения и то, какое время они длились. Так мы можем следить, сколько компьюта на них уходит Всё это работает автоматически — без ручного вмешательства. 🔶 Подробности ищите в моём докладе на infra.conf. Там я рассказал о простых лайфхаках, которые помогают экономить ресурсы обучения, и о том, как мы научились быстро доносить информацию о проблемах до пользователей. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🟢 Как мы пустили сторонний код в продукт с 600 000 пользователей Меня зовут Женя Успенский, я руковожу разработкой фронтенда в Яндекс Трекере и отвечаю за архитектуру платформы плагинов. Это отдельный механизм, который позволяет без навыков кодинга расширять Трекер собственными модулями без модификации его ядра. Хочу рассказать, как мы архитектурно разделили и встроили сторонние расширения в продукт с устоявшейся кодовой базой, чтобы API не стал источником уязвимости. 😾 Когда мы задумали дать пользователям возможность писать свой код прямо внутри Трекера, первая реакция команды безопасности была: «Вы что, с ума сошли?» И их можно понять. Пустить сторонний JavaScript в B2B-продукт с чувствительными данными — это прямой путь к XSS, вытаскиванию токенов и утечкам. Поэтому нам нужна была архитектура, которая позволит создавать сложные интерактивные плагины с динамическим UI, но при этом упакует их в железную изоляцию. Важная развилка, которую мы прошли на старте: строить платформу под Трекер или сразу как общий механизм. Мы выбрали второе, так как хотим, чтобы плагины могли закрывать кросс-сервисные сценарии в нашей экосистеме. Спроектировали слой изоляции, авторизации и доставки плагинов так, чтобы в будущем на эту же инфраструктуру можно было безболезненно раскатывать расширения и для других продуктов Яндекс 360. ❇️ Как мы изолировали код Взвесив все за и против, остановились на классической изоляции через iframe. Это решение выглядит не так концептуально, зато даёт гарантии безопасности и позволяет быстро выйти в продакшен. Как это устроено: 🟢 Каждый плагин отдаётся с отдельного изолированного хоста, у которого нет доступа к cookie и хранилищу основного приложения 🟢 В параметрах iframe мы явно разрешаем только выполнение скриптов (allow-scripts) и жёстко ограничиваем все остальные возможности 🟢 Политика безопасности запрещает практически всё, в том числе сетевые запросы на любые внешние адреса, которые отличаются от собственного домена iframe Все ключевые модули получившейся системы мы оформили как самостоятельные, независимые пакеты. Это позволяет подключать к платформе плагинов любые другие сервисы и не переписывать архитектуру изоляции с нуля. А общение плагина с сервисом и внешним миром происходит через специальный объект Bridge, который для транспорта использует postMessage. ❇️ Что происходит под капотом API Трекера У нас есть интерфейс в клиентской части пакета Bridge со всеми методами и сущностями публичного API. Внутри происходит обращение к сервисной части, которая проверяет каждый вызов на предмет прав, которые прописаны в плагине, и выполняет запрос с правами текущего пользователя. Для походов во внешний мир плагин обязан задекларировать используемые домены в манифесте и указать способ авторизации. Для сервисов с доступом Трекер сам спросит токены для каждого домена, сохранит в защищённое хранилище и будет подмешивать при запросах. Плагин никогда не получает к ним прямого доступа. ❇️ Что мы сделали для разработки плагинов Наша консольная утилита в виде NPM-пакета закрывает весь жизненный цикл плагина: создание, отладку, проверку и публикацию. А у CLI есть режим отладки, который не требует развёртывания окружений или отправки кода на внешние серверы. В сочетании с готовыми шаблонами это позволяет сразу увидеть работу плагина в интерфейсе Трекера и дальше дорабатывать его под свою бизнес-логику. 🔶 Читайте все подробности в статье на Хабре. Там я рассказал, как построить безопасную экосистему плагинов: изолировать сторонний JavaScript, организовать взаимодействие с API и при этом сохранить удобный Developer Experience. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🍏 Тысяча «яблок» для песочниц: как и зачем мы обновили стойки в дата-центрах Привет! Меня зовут Владимир Аксёнов, я руковожу группой IT‑поддержки дата-центра в Yandex Infrastructure. Более 10 лет назад, когда у наших инженеров появилась потребность писать софт под iOS, мы начали ставить для этих задач первые Apple Mac mini c габаритами 197×197×36 мм: серверных версий не было. Теоретически можно было бы установить их в офисе, но мы выбрали строить песочницу сразу в дата-центре, чтобы гарантировать бесперебойное питание и охлаждение. Уместить в один юнит нашей стандартной стойки 19" два таких «миника» помогли специальные кредлы — подставки с креплениями. Осталось только настроить централизованное управление через MDM и радоваться: в те времена Apple mini было не так много, айфоны встречались редко, поэтому песочница получилась крошечной, не перегревалась и не перегружала инженеров. 🤔 К 2026-му многое поменялось. Мы укрупнили свою ферму, улучшили процессы обслуживания и поменяли систему кондиционирования. В том числе отказались от доохлаждения, оставив только энергоэффективный фрикулинг. Горячий коридор стал горячее. А физически взаимодействовать с разросшейся песочницей стало сложнее. Если нужно было провести диагностику, сбросить или обновить ОС с флешки: 🟢 Всё мешалось. Чтобы подключить монитор и клавиатуру к «минику», необходимо было глубоко (почти на метр) залезть в стойку, где жили PDU с кабелями питания и свитч с медными коммутациями. 🟢 Летом было жарко. По заявлению производителей, устройства Apple Mac mini можно спокойно эксплуатировать при достаточно высоких температурах, так как их процессоры сами по себе не сильно греются. Чего нельзя сказать об обслуживающих стойку людях: в самые жаркие дни лета температура в горячем коридоре могла достигать +55 °C. 🟢 Гасили соседей. Так как в один кредл устанавливалось два устройства, при замене неисправного нужно было вытащить весь кредл и отключить соседнее исправное устройство. А значит, согласовать и его вывод из эксплуатации. 🧬 Готовых решений, подходящих для наших дата-центров, на рынке не нашлось. И мы решили перепридумать кредлы, чтобы в условиях сауны горячего коридора не страдали ни люди, ни устройства. 🔶 Что у нас получилось, рассказываю на Хабре Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🚀 Back to Back начнётся через час! Уже сегодня состоится новая конференция Яндекса для бэкенд-инженеров, SRE и техлидов одновременно в Москве, Белграде и Ереване. 📺 Выбирайте город и подключайтесь к трансляции: 🗺 Москва, трек C++ Zero Cost: 🟢 Ютуб 🟢 VK Видео 🟢 Сайт 🗺 Москва, трек Architecture & Performance: 🟢 Ютуб 🟢 VK Видео 🟢 Сайт 🗺 Белград, трек C++ Zero Cost: 🟢 Ютуб 🟢 VK Видео 🟢 Сайт 🗺 Ереван, трек Architecture & Performance: 🟢 Ютуб 🟢 VK Видео 🟢 Сайт ❗️ Время для каждого города указано по местному часовому поясу. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend