Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера. Задачи моей команды включают не только работу над самим браузером, но и прямое улучшение используемых в нём опенсорс‑решений, например Chromium и применяемых в нём проектов (Blink, V8, Catapult), в том числе и компиляторов (LLVM Clang). Другими словами, мы вносим вклад в сообщество. При этом поиск и создание улучшений для сторонних опенсорс‑проектов может стать прямой рабочей задачей даже в ходе стажировки.

К слову, моя работа в Браузере как раз с неё и началась. При отборе положительно сказалось наличие у меня pet‑проектов: отдельного внимания заслужил проект, использующий озвучку и SFX (сноска: сокращение от англ. sound effects — звуковые эффекты) из Heroes of Might and Magic V. Так удивительно совпало, что мой будущий руководитель ранее работал в Nival Interactive как раз над этой игрой.

А в этой статье я расскажу о том, как обычное сокращение полных файловых путей в логах до имени файла (например, path/to/filename → filename) может повлиять на размер исполняемых файлов и производительность Браузера, а также внести вклад в проект LLVM Clang.

Gray failure, то есть серый, или частичный отказ, — довольно коварная ситуация, когда система демонстрирует квазирабочее состояние. С одной стороны, по проверкам состояния мы наблюдаем работоспособность ресурса, но когда отправляем на него реальную нагрузку — ничего не работает.

Инциденты прошлого года показали нам, что серые отказы в Yandex Cloud могут приводить к деградации доступности для пользователей. Мы регулярно выявляем системные причины и внедряем улучшения на уровне всей облачной платформы, о чём подробнее уже рассказывали в одной из недавних статей. Но иногда решение проблемы серых отказов может требовать действий на клиентской стороне, которые не всегда очевидны. 

Меня зовут Александр Душеин, я технический лидер команды архитекторов Yandex Cloud и занимаюсь направлением клиентской надёжности. В этой статье я расскажу подробнее, что поможет избегать нештатных ситуаций: 

• какая работа по предотвращению серых отказов была проделана на нашей стороне за счёт слаженной работы всей команды;

• какие настройки стоит взять на вооружение пользователям Yandex Cloud и какие рекомендации могут быть полезны всем ответственным за Disaster Recovery;

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

Ежемесячно клиентская поддержка продуктов Яндекса обрабатывает миллионы обращений. Мы регулярно проверяем диалоги вручную. Это помогает бороться, например, с опечатками и другими ошибками операторов. Но проверить все диалоги в таком режиме невозможно — их слишком много. Поэтому мы решили посмотреть в сторону LLM-решений.

Привет! Меня зовут Дарья Шатько, я руководитель ML-группы в Yandex Crowd. В этой статье я расскажу, как мы с моим коллегой Антоном Удаловым внедряли большие языковые модели в контроль качества клиентской поддержки. А именно — почему регулярки и BERT не взлетели, как мы собрали репрезентативный golden‑датасет, как победили лимит контекста, снизили ложные срабатывания через многоступенчатый LLM‑flow и в итоге покрыли проверками абсолютно все диалоги поддержки.

При создании интерфейса важно проверить, как он реально выглядит. Часто это проверяют все участники процесса — от разработчиков до менеджеров. И для автоматизации и упрощения процесса визуального тестирования приложения есть специальный инструмент — golden‑тесты. Это методология тестирования, в которой текущий UI сравнивается с предварительно сгенерированным «золотым» эталоном. Если вы уже слышали про скриншот‑тесты — это примерно то же самое, но есть нюансы.

Меня зовут Даниил Липаткин, я тимлид в команде разработки курьерского приложения Яндекс Доставки. В этой статье:

— Мы познакомимся с методологией, рассмотрим её преимущества и недостатки, а также когда её стоит и не стоит применять.

— Напишем базовый Golden‑тест на примере стандартных инструментов библиотеки flutter_test.

— Рассмотрим пакет alchemist, который решает проблему платформозависимости flutter_test.

— Получим прикладные рекомендации по применению тестов и настройке IDE и CI.

Сегодня на Yandex Neuro Scale 2025 наша ML‑команда представила обновлённую AI Studio — платформу с большим набором инструментов для разработки ИИ‑агентов в единой end‑to‑end‑среде. Среди новинок — визуальный конструктор агентов, поддержка популярных API и реализация протокола MСP, механизмы AI search.

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

Вместе с коллегами из команды разработки Анастасией Каримовой и Дмитрием Рыбалко покажем, как это устроено под капотом:

— какие особенности эксплуатации нам нужно было учесть, чтобы найти баланс между производительностью и качеством;

— как мы сталкивались с особенностями опенсорс‑инструментов для ML и учились справляться с этим разными способами;

— как мы упростили создание голосовых агентов и заодно уменьшили latency запросов.

Привет! Меня зовут Геннадий Денисов, я руковожу одной из команд разработки мобильного Яндекс Браузера для Android. Недавно в рамках одного проекта мы интегрировали С++‑код в мобильное приложение Браузера. В этой статье я поделюсь основными нюансами работы с Java Native Interface (JNI), инструментами для упрощения разработки и подробностями нашего подхода.

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

Меня зовут Владимир Быстрицкий, я руковожу группой AI-картографирования. В этой статье расскажу о процессе детектирования дорожных знаков в картопроизводстве Яндекса: с чего всё началось, как развивалось, какие технологии использовались. Ну и попробую ответить на самый, на мой взгляд, главный вопрос в любой ML-задаче: как собрать датасет и не разориться?

Привет! Меня зовут Олег Безушко, и наша команда отвечает за эксплуатацию видеоконференцсвязи (ВКС) в Яндексе. Мои коллеги уже писали, как мы управляем переговорками с помощью инструмента Room Passport, а сегодня я расскажу, что происходит «на земле»: чем живут инженеры ВКС и как справляются с огромным объёмом задач силами очень компактной команды.

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

Привет, Хабр! Меня зовут Иван Кузнецов, я Android‑разработчик в Кинопоиске. Сегодня расскажу историю разработки своего пет‑проекта, которая началась с код‑ревью очередного экрана на Jetpack Compose.

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

Вот только объяснения отнимают время и не всегда наглядно доносят суть проблемы. Особенно это актуально для новичков, которым сложно сопоставить абстракции с реальным поведением UI. А ведь для сложных асинхронных штук вроде RxJava или корутин есть визуализаторы — RxMarbles и FlowMarbles, а для самой частой головной боли в Compose до сих пор нет. Вот бы вместо стены текста просто кинуть ссылку со словами: «Смотри, вот что твой код делает на самом деле».

В этой статье я расскажу о разработке собственного приложения, которое в реальном времени визуализирует рекомпозиции. Чтобы заставить его работать, пришлось залезть под капот компилятора Kotlin и подружиться с его внутренними API: FIR и IR.

Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.

Однажды мы в Диске переносили общие данные из шардированного MongoDB в шардированный же PostgreSQL. После переноса пользовательских данных у нас осталась часть данных про общие папки.Их было сложно изолировать внутри шарда пользователя, и они остались в общей БД на MongoDB, которую мы так и назвали — CommonDB. Спустя время мы заметили, что общая БД не справляется с нагрузкой: все запросы перед выполнением должны были сначала получить информацию об общих папках, и только после этого они начинали работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — на их шарды.

Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.

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

На связи Борис Литвиненко из команды NOCDEV в Yandex Infrastructure — наша группа занимается автоматизацией сетей всего Яндекса. В прошлом году я уже рассказал о том, как и почему наши сетевые сервисы живут на отдельном железе с развёрнутым k8s‑кластером, избегая кольцевых зависимостей с остальной инфраструктурой компании. Среди прочего на тот момент мы использовали Calico VXLAN — с нашим разнообразным железом нам был нужен overlay, а Cilium тогда не умел работать с IPv6 для VXLAN. Однако всё меняется.

В 2025 году попытка включить Calico eBPF в нашем K8s‑кластере вылилась в запуск Cilium, в новом релизе которого как раз добавили поддержку IPv6 underlay для VXLAN. Поэтому сегодня я расскажу, как мы вместе с Кириллом Глушенковым @kglushen протестировали новый Cilium 1.18 — а заодно перешли с самописных salt‑рецептов для kubeadm на kubespray, столкнулись с не такими уж простыми особенностями dualstack, а ещё немного повайбкодили. Под катом — все наши приключения с нелинейным сюжетом.      

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

Привет! Меня зовут Серёжа Синягин, я старший разработчик в Яндекс Еде и пишу на C++. В этой статье расскажу о задаче, с которой столкнулся в работе: как мы определяем, какие рестораны доступны пользователю для заказа. По пути заглянем во внутреннюю кухню, обсудим библиотеку H3 от Uber и разберём, как устроены R‑деревья и как мы используем их у себя.

Всем привет! Меня зовут Руслан Дюсаев, и я занимаюсь машинным обучением в команде Спамообороны Яндекс Почты. Помимо технологий антиспама, мы с коллегами разрабатываем ML-фичи в сервисах Яндекс 360. 

В статье расскажу, как мы делали Нейрофильтр с YandexGPT 5 в Почте. Он работает на базе двух нейросетей. Первая, созданная на основе CatBoost, определяет важность каждого письма, чтобы сделать выборку из главных сообщений. А вторая, построенная на базе YandexGPT, выделяет ключевые тезисы из них и выводит краткое резюме. Подробнее о технологиях отбора и суммаризации говорим в этой статье. 

«Сторонние куки больше не нужны», — заявили разработчики Google Chrome и в январе 2024 года начали принудительно отключать их у каждого сотого пользователя браузера. Однако уже в июле последовало осторожное: «Ну, с другой стороны...» — и отмена кук была отменена.

Многие даже не заметили, что произошло. Но на самом деле речь шла о том, как должен работать интернет в целом: отказ затронул бы почти каждый сайт из тех, что ты посещаешь,%USERNAME%.

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

Привет! Меня зовут Николай Олигеров. Сейчас я работаю аналитиком данных в Яндекс Путешествиях, а до этого я был продуктовым аналитиком в Лавке — мой рассказ будет именно про неё.

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

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

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

Сага «Звёздные войны» давно стала больше, чем просто серией фильмов. Миллионы людей объединены общей страстью, и для многих из них обладание своим личным световым мечом становится очень важным. Ведь это не только предмет коллекционирования, технологический артефакт или даже спортивный инвентарь, а символ джедайской (или ситхской) философии.

На этом интересе вырос целый рынок. Есть компании, которые производят световые мечи целиком. Есть те, кто специализируется только на отдельных компонентах: рукоятях, платах, светодиодных модулях и прочей электронике.

Привет, на связи Крэйл из команды умных устройств Яндекса. Но сегодня я расскажу не о Станциях, а о своём необычном хобби. Однажды ко мне обратились производители компонентов с задачей разработать электронику для кастомных световых мечей. Проект оказался ярким во всех смыслах. А в статье я расскажу о том, какие были условия и как я справлялся с поставленными задачами.

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

Специалисты Санкт‑Петербургского государственного педиатрического медицинского университета (СПбГПМУ) совместно со Школой анализа данных (ШАД) и Центром технологий для общества Yandex Cloud разработали решение на базе нейросети, которое помогает оценить развитие мозга новорожденных по МРТ‑снимкам. При подозрении на ДЦП и другие болезни ЦНС решение работает как вспомогательный инструмент, который сокращает время расшифровки результатов МРТ до нескольких минут вместо нескольких дней.

Меня зовут Юлия Бусыгина, я руковожу проектом со стороны Yandex Cloud, и в этой статье мы вместе с профессором Александром Поздняковым расскажем подробнее, как проектировали решение, обучали модель, как тестируем и оцениваем его эффективность.

Привет! Меня зовут Валерий Ильин, я руководитель сектора разработки мобильных роботов в Яндекс Роботикс. До недавнего времени в нашей линейке роботов отдельно жили мобильные роботы (робот‑инвентаризатор и робот‑тотоносец) и проекты на основе роборук (депалетизатор, пикер). Решения закрывали две основные операции на складе: перемещение товара и его отбор, но по отдельности. Идея объединить их и собрать робота, который закрывает обе операции, зрела в мыслях уже давно. Но прежде чем задумка воплотится в жизнь, ей нужно было созреть, набраться сил, а нам — опыта.

В феврале 2025 года мы начали разработку автономного робота, который сможет делать всё, что делает человек‑комплектовщик, — только не уставая и в предсказуемом темпе.

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

Под катом разберём, с какими ограничениями сталкивается классическая роботизация (стационарные роборуки, AMR‑ и FMR‑тележки), почему склады не готовы радикально менять процессы и как это повлияло на архитектуру решения. А ещё я покажу, как мы сделали локальное планирование на роботе, доработали софт мобильной платформы, а также добавили камеры и обработку глубины. В конце поделюсь промежуточными результатами и расскажу о наших планах — от стекинга до тестов на реальных складах.

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

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

Меня зовут Руслан Савченко, в Yandex Infrastructure я руковожу разработкой динамических таблиц YTsaurus — системы, в которой поведенческий таргетинг хранит данные. В этой статье я подробно разберу кейс поведенческого таргетинга с динтаблицами: почему таблицы в памяти иногда тормозят из‑за аллокатора, зачем мы внедрили xdelta, как именно устроены агрегатные колонки и что пришлось сделать, чтобы миллисекунды отклика в 99,9 перцентиле стали реальностью.