Yandex for Backend

🚀 Погружаемся в технологии на deep tech night Уже 5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о технологических вызовах, с которыми IT-индустрия сталкивается в эпоху AI: от изменений в разработке до новых требований к архитектуре и инфраструктуре. Это событие для ML-разработчиков, бэкендеров, фронтендеров, тимлидов, аналитиков, продактов и всех, кто работает в IT-индустрии, внедряет AI в процессы, проектирует сложные системы и ищет новые решения. 🔥 Вас ждут темы от инфраструктуры и железа для нейросетей до AI-агентов и внедрения AI в разработку и два формата: 🟢 Hard — доклады о сложных и масштабных задачах для тех, кто хочет вдумчиво разобраться в технической стороне сферы. 🟢 Experiment — лайтнинги и интерактивные кейсы об экспериментах с AI-агентами, новых подходах и продуктовых находках. Для всех, кому интересно пробовать новое и следить за трендами. Среди спикеров — Мо Гавдат, десять лет руководивший бизнес-развитием в Google X, Алексей Гусаков, CTO Поисковых сервисов и ИИ, Сергей Мельник, руководитель сервиса Автономного транспорта и роботов, и другие эксперты из Яндекса и других IT-компаний. 🧬 Чтобы подключиться к онлайн-трансляции, нужна предварительная регистрация. Она также даст возможность задать вопросы экспертам в прямом эфире и первыми посмотреть запись после события. 🔶 Смотрите полную программу и регистрируйтесь на deep tech night. До встречи! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔍 Как построить здоровый мониторинг Нам нужны метрики и оперативное подсвечивание инцидентов, чтобы понимать, хорошо ли всё работает, и вовремя узнавать, если что-то идёт не так. Но чем больше новых измерений мы добавляем, тем больше появляется информационного шума. Меня зовут Настя Кузнецова, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. Хочу рассказать, как мы приводим в порядок мониторинг, какие метрики стоит взять за основу и в чём суть нашего правила 80/20. ❇️ Два главных принципа здорового мониторинга 1️⃣ Помните, что метрики — это маяки, а не микроскопы. Они сигнализируют о наличии проблемы, но не рассказывают детально, какая из шестерёнок огромного механизма барахлит. С алертами та же история: они просто показывают, есть проблема или нет, без указания на конкретную строку в коде 2️⃣ Стремитесь к балансу. Конечно, хочется замониторить все сервисы так, чтобы нигде и никогда не пропустить ни одну проблему. Однако нельзя полагать, что дашборд на 1000+ метрик будет кому-то полезен, ведь в этом случае никто не знает наверняка, на какой именно график надо смотреть, чтобы найти нужную информацию ❇️ Подход 80/20 Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем (80%). А бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения (20%). 🧬 Базовый набор для типичного бэкенда: RED-метрики для HTTP/gRPC, клиентов, очередей и баз данных. ❇️ В HTTP/gRPC-сервере замеряем три вещи: 🟢 Количество запросов. Тут мы можем увидеть, если кто-то решил спустить на нас DDoS или, наоборот, перестал это делать, а также если у нас куда-то утекает трафик 🟢 Ошибки, которые наш сервер отдаёт клиенту. В случае HTTP — это 4xx и 5xx, в случае gRPC — unavailable и прочее 🟢 Длительность запросов. Это помогает узнать, что сервер где-то начал подтормаживать или очень быстро отдавать что-то странное Всё это даёт возможность понять практически любую проблему на стороне сервера. ❇️ В очереди смотрим на лаги: Например, мы внесли в неё ряд данных, из-за этого там скопились сообщения, но по какой-то причине их не читают. Поэтому нам и нужны лаги — записанные сообщения минус прочитанные. Эта метрика позволяет получить разницу позиций в очереди. ❇️ В БД следим за connection pool: На стороне приложения есть клиентский пул, а между приложением и базой данных — отдельный серверный. Если наблюдать только за одним из них, отклонение на другом уровне останется незаметным, поэтому оба пула нужно включать в общий контур мониторинга. Метрики клиентского пула обычно можно подключить через Spring Boot и Micrometer. Если в архитектуре есть отдельный серверный пул, его нужно мониторить на стороне компонента, который им управляет. Такой контур помогает заметить риск заранее — до того, как он повлияет на запросы. 🔶 Читайте больше подробностей на Хабре. Там я поделилась золотыми метриками конкретно для Java-приложений и объяснила, как поймать 20% бизнес-специфичных. А также рассказала, как выбирать полезные алерты. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 Из лидов в разработчики и обратно Меня зовут Игорь Хураськин, я руководитель группы ML-инференса в Автономном транспорте. У меня за плечами больше десяти лет работы в Яндексе. За это время я успел поработать над поиском картинок, стать руководителем бэкенда в сервисе «Коллекции», перейти в Рекламу, а потом уйти в стартап по созданию 3D-кино. И сейчас я снова руководитель, но уже в беспилотных технологиях 🤯 Хочу объяснить, зачем несколько раз ротировался в разные сервисы, как одни технологии помогают развивать другие и почему я не боюсь перемен и не скучаю в рамках одной компании столько лет. 👩‍⚕️ Читайте все подробности в карточках выше! 🔶 А в статье на Хабре можно подробнее почитать про технологию для создания фотореалистичных 3D-копий сцен из объёмных частиц (сплатов), а не полигонов. И про YaGS Plugin — опенсорс-решение для работы с 3DGS внутри Unreal Engine. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔥 Новости программы deep tech night На конференции deep tech night вас ждут два формата: • Hard — технические доклады о сложных и масштабных задачах. Формат подойдёт тем, кто хочет вдумчиво разобраться в технической стороне темы. • Experiment — лайтнинги и интерактивные кейсы об экспериментах с AI-агентами, новых подходах и продуктовых находках. Этот формат для всех, кому интересно пробовать новое и следить за трендами. 👩‍⚕️ В карточках рассказываем о новых спикерах и их темах. Смотрите полную программу и регистрируйтесь на deep tech night, которая пройдёт 5 сентября. Присоединиться к конференции онлайн можно по предварительной регистрации. 🔶 Зарегистрироваться Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

📺 Новая порция докладов с infra.conf’26 Мы продолжаем рассказывать про выступления с нашей инфраструктурной конференции. В этот раз посоветуем бэкендерам сразу три доклада — и напишем, какой кому особенно зайдёт. 🟢 Егор Митрофанов, руководитель команды инфраструктуры бэкенда в Яндекс Банке. Рассказал, как в Финтехе пришли от ручного управления секретами в Vault к единому декларативному контракту сервиса. Его понимают все подсистемы сразу: Terraform, Vault, Kubernetes и Helm, CI-пайплайн, Grafana, Kotlin-компилятор и регуляторика ЦБ. ➖ Посмотреть можно тут 💡 Кому зайдёт: бэкендерам и платформенным командам, которые тонут в рассинхроне между инфра-конфигами, секретами, CI и кодом. 🟢 Николай Соколов, руководитель службы разработки IDM в Yandex Infrastructure. Объяснил устройство нашего IDM и принципы работы Yandex Infrastructure по управлению доступами к 1500 системам, благодаря которым не нарушается стабильность процессов. ➖ Посмотреть можно тут 💡 Кому зайдёт: бэкендерам, которые проектируют или пересобирают собственный IDM или систему управления доступами. 🟢 Андрей Мичурин, руководитель разработки систем деплоя в Yandex Infrastructure. Показал, как инженеры выкатывали сервисы раньше, как делают это сейчас и где мы все свернули не туда. Андрей также поделился, как устроена платформа деплоя в Яндексе и почему ряд проверенных решений из прошлого снова стали актуальны. ➖ Посмотреть можно тут 💡 Кому зайдёт: всем, кто катит сервисы и при этом хочет понять логику эволюции деплой-систем, а не просто «как нажать кнопку». Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🧬 «Главное — начать, а дальше разберёмся»: как расти в условиях неопределённости 👨‍💻 Привет! Меня зовут Женя Ширанков, я руковожу бэкендом продуктов Яндекс 360 — нашими платформенными сервисами. Мы отвечаем за технологии, инструменты и бизнес-логику, которые объединяют отдельные продукты в виртуальный офис.

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

Я считаю, что расти можно даже в условиях неопределённости. Во многом благодаря этому у нас появился техрадар — инструмент для мониторинга и управления технологиями. Мы считаем его показателем здоровья продуктов. Он помогает понять, где появляются проблемы, что устаревает и нужно ли обратить внимание на безопасность и подумать о переменах. 👩‍⚕️ В карточках делюсь, как сложился мой карьерный путь и почему рост до руководителя просто один из способов делать больше интересного. 🔶 Подробнее читайте в блоге о работе в Яндексе. А познакомиться с нашим техрадаром поближе можно в демоверсии для внешних пользователей. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔥 Делимся первыми спикерами на deep tech night В карточках рассказываем, кто и на какие темы будет выступать на конференции 5 сентября. А чтобы получить доступ к эфиру, задать вопросы экспертам в прямом эфире и первыми посмотреть запись после события, зарегистрируйтесь на сайте. 🔶 Подробности о докладах и форма регистрации Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🛎 Открыли регистрацию на «Я про бэкенд» 3 октября в Москве и онлайн будем обсуждать хард-корный бэкенд и масштабные челленджи на серверной стороне AI. На реальных кейсах разберём новые нетривиальные вызовы и как с ними справляться, понетворкаем и вообще классно проведём время. Приготовили доклады в шести направлениях: 🟢 Архитектура систем с AI/ML 🟢 Хранение и стриминг данных 🟢 Работа на стыке бэкенда с железом 🟢 Алгоритмы и подходы к решению практических задач 🟢 MLOps: деплой, эксплуатация, наблюдаемость и так далее 🟢 Другие интересные челленджи на бэкенде А ещё, как и в прошлом году, инженер Яндекса онлайн попробует решить задачу, которую вы предложите. Об этом расскажем чуть позже. 🔶 Регистрируйтесь по ссылке, чтобы ничего не пропустить в меняющемся бэкенде. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

💹 Как мы провели 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

🟢 Старый сервис в новой реальности Многие из вас видели mirror.yandex.ru, возможно, качали ISO-образы дистрибутивов. Внешне сервис за последние 19 лет никак не трансформировался: всё те же файлы по HTTP и rsync. Но под капотом произошли некоторые изменения 👀 👨‍💻 Меня зовут Борис Литвиненко, я ведущий разработчик группы разработки сетевой инфраструктуры и мониторинга в Yandex Infrastructure. Хочу рассказать, с какими новыми вызовами столкнулось зеркало и как мы их решали. 👩‍⚕️ Читайте подробности в карточках выше 🔶 А если вам интересно раскрыть архитектурную тайну одного из самых старых и базовых сервисов Рунета и узнать ещё больше деталей, например какой размер HDD-дисков сейчас в ходу, — смотрите мой доклад на ютубе и слушайте подкаст на linkmeup. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🛎 Back to Back пройдёт уже в эту субботу! 1 августа состоится конференция для бэкенд-инженеров, архитекторов, SRE и техлидов, поэтому не упустите возможность зарегистрироваться 🚀 ➖ Напоминаем главное: Back to Back пройдёт одновременно в Москве, Белграде и Ереване, а также онлайн для всех, кто далеко.

📍 В Москве мы соберём сразу два трека: 🟢 C++ Zero Cost — про производительность, системную разработку и инженерные задачи на C++ 🟢 Architecture & Performance — про архитектуру, производительность и реальные продакшен-задачи

Но конференция — это не только хард-корный технический контент 😉 На афтерпати вас ждёт вкусный плов и выступление группы «Научно-технический рэп». 🔶 Регистрируйтесь и смотрите программу 🈯️ До встречи в эту субботу! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🤔 Как понять, куда уходит память Привет, меня зовут Сергей Кривохатский, я пишу прикладной код на C/C++ для умных устройств с Алисой. Сегодня я хочу рассказать, как мы работаем с памятью. Для нас это важная тема, потому что типичная умная колонка с Алисой имеет скромное железо и совсем немного оперативной памяти. Например, у наших младших моделей всего 256 Мб ОЗУ на всё устройство. За каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес-логикой, обработкой звука, локальными нейросетями. 👩‍⚕️ В карточках я коротко рассказал, как мы ежедневно собираем и анализируем memory-дампы с миллионов колонок. 🔶 Подробности об этом читайте в моей статье на Хабре. Там я дополнительно показал, как выглядит наш внутренний инструмент для анализа этих данных и как с его помощью мы ищем и исправляем утечки памяти, оптимизируем код и проводим анализ экспериментов. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🤖 Observability на стероидах Когда у вас 3 миллиарда семплов в секунду, 60 гигабайт логов и 44 миллиона спанов, вы уже не просто настраиваете мониторинг — вы пишете его с нуля. Так внутри Яндекса вырос Monium — система наблюдаемости, которая теперь доступна как отдельный продукт. 🎧 В новом выпуске подкаста linkmeup sysadmins Владимир Гордийчук, CTO Yandex Monium, рассказал, зачем его команда написала свой мониторинг, вместо того чтобы использовать Prometheus, Grafana или ELK. 👩‍⚕️ Собрали ключевые моменты из этого выпуска в карточках выше В подкасте также обсудили: 🟢 Какие архитектурные подходы позволяют держать высокие нагрузки 🟢 Сколько стоит мониторить всё и как это обосновать перед менеджментом 🟢 Каковы самые запоминающиеся инциденты и почему после них мониторинг стал другим 🟢 Какие рекомендации можно внедрить уже завтра, чтобы не тонуть в дашбордах и ложных срабатываниях 🔶 Слушайте все подробности на ютубе, сайте или в Яндекс Музыке. 🈁 А ещё приглашаем заглянуть в группу пользователей Monium. Там можно задать вопрос разработчикам и узнать о последних обновлениях. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🛎 Успейте зарегистрироваться на Back to Back До Back to Back осталось меньше двух недель! Напоминаем: это новая бэкенд-конференция Яндекса, которая пройдёт сразу в трёх городах — Москве, Белграде и Ереване. Присоединиться можно как офлайн, так и онлайн. 💹 Немного о программе: 📍 Москва Савва Лебедев из Positive Technologies расскажет, как команда добавляла поддержку LuaJIT в eBPF-профилировщик Perforator. Даниил Подольский из YADRO разберёт аутентификации в гетерогенных системах, а Антон Пионтковский из Yandex Cloud объяснит, что делать, когда данные отсортированы не так, как ожидает запрос. 📍 Белград Душан Йованович из Inceptive разберёт возможности статической рефлексии в C++26, а Александр Зайцев, зависимый от PGO эксперт, поделится опытом использования Profile-Guided Optimization и расскажет, как получить от неё реальный прирост производительности. 📍 Ереван Брюс Момджиан, один из самых известных евангелистов PostgreSQL в мире, выступит с докладом про WAL. А Монс Андерсон из Exness расскажет о современных подходах к генерации распределённых идентификаторов для масштабных систем. 🔶 Выбирайте площадку и регистрируйтесь. Вас ждут доклады про бэкенд, производительность, распределённые системы и современный C++. 🈯️ До встречи на Back to Back! Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend