Привет, Хабр! На связи Дима Мандельштам, мобильный разработчик в core‑команде Яндекс 360, и Лёша Карпенко, руководитель команды дизайн‑системы. Дизайн — часть повседневной работы наших команд, и он не живёт отдельно. Поэтому сегодня в статье мы вместе поговорим о том, как мы собирали компонент List‑item.

Мобильные разработчики в этой статье найдут метод, с которым можно достичь баланса между гибкостью кода и простотой поддержки. Мы расскажем, как применили data‑driven‑подход к рефакторингу UI: написали анализатор AST для поиска реальных паттернов использования и вывели математическую метрику сложности API. А ещё расскажем о том, как аргументировать и провести масштабную переработку legacy‑кода, не останавливая продуктовую разработку.

Продуктовым дизайнерам будет интересен альтернативный взгляд на проектирование List‑item в дизайн‑системе. Мы разберём, как собирать List‑item — как универсальный компонент с максимальной гибкостью или как набор семантических шаблонов под конкретные сценарии.

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

Привет, Хабр! На связи Саша Лопинцев, SRE в группе разработки сетевой инфраструктуры и мониторинга Yandex Infrastructure. Я очень люблю мониторинг — а когда дело касается видимости сетевого трафика, нам не обойтись без анализа flow‑данных. 

Сегодня расскажу, как и почему мы переехали с устаревшего flow‑коллектора на GoFlow2, реализовали запись в БД и через etcd решили проблемы с шаблонами. Новая система обрабатывает 85 тысяч пакетов статистики в секунду, обеспечивает отказоустойчивость и помогает создавать отчёты. Если вам интересно узнать чуть больше об архитектуре, экспериментах, ошибках и решениях, полезных для инфраструктурного мониторинга в продакшн‑среде, читайте далее.

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

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

Я Илья Хохлов, руководитель службы разработки сервисов маршрутизации. Наша команда отвечает за ключевые алгоритмы навигации в Картах и в Навигаторе: маршрутизацию, прогноз времени в пути и позиционирование. В этой статье я расскажу о том, как мы переосмыслили ранжирование маршрутов в навигации на Картах и в Навигаторе: как именно ML‑модель понимает, какой маршрут предлагать первым, и как это решение повлияло на количество сходов с маршрута.

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

Привет, Хабр! Меня зовут Игорь Березняк, я руковожу группой процессинга в Техплатформе Городских сервисов Яндекса. В этой статье по мотивам моего доклада на Highload++ расскажу, как мы проектировали шардирование PostgreSQL, чтобы выдерживать нагрузку, сохранить доступность и уложиться в строгие требования по latency.

Всем привет! Я Светлана Давыдова, работаю менеджером проектов в команде Поиска. В моём отделе поисковых интерфейсов работает 24 команды. За 5 лет мы выстроили множество процессов, но перед нами всё ещё стоят вызовы: разный уровень развития команд, специфичные задачи и нехватка времени на улучшения. Из-за этого не все команды могут одинаково эффективно развиваться и повышать качество своих продуктов.

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

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

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

Меня зовут Евгений Михайленко, я руковожу бизнесом и продуктом Physical AI в команде Яндекс Роботикс. В этой статье я разберу, как современные архитектуры и концепт Guidance, который мы объединили с тестом Возняка, помогают преодолеть разрыв между роботами‑специалистами и будущими генералистами.

Привет, Хабр! Меня зовут Виктор Юрченко, я руковожу командой симуляции сенсоров в автономном транспорте Яндекса. Основная задача, которая стоит перед нашей командой, — искать способы делать симуляции ближе к реальности в части сенсорных данных. И недавно сотрудники команды совместно с исследовательским отделом Яндекса разработали собственный метод для симуляции изображений в проездах — MADrive (Memory-Augmented Driving Scene Modeling).

MADrive позволяет достоверно генерировать синтетические изображения для новых дорожных сценариев. Кроме того, для его работы был собран и выложен в опенсорс крупнейший открытый датасет автомобилей — MAD‑Cars. Он может быть полезен для различных задач 3DCV: от 3D‑реконструкции до генерации синтетических сцен.

В этой статье расскажу, почему симуляции так важны для автономного транспорта, как работает MADrive и чем может быть полезен датасет MAD‑Cars.

…Был обычный ноябрьский вечер, 2024 год шёл к своему завершению: на носу была «чёрная пятница». Я вернулся домой в Новосибирск из почти двухнедельной командировки, пробыв в пути 12 часов и поспав часа четыре. В 19:07 алерт сообщил мне о падении одного из контроллеров. В целом, проблема не критичная, так как сервисы зарезервированы. Но всё же одним глазом я заглянул в чат с разбором.

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

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

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

Всем привет! Меня зовут Катя Еникеева, я руковожу командой аналитики перевода в Яндексе. Мы занимаемся оценкой качества машинного перевода — моделей, которые работают в Яндекс Переводчике, Браузере, Поиске и во множестве других сервисов.

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

Под катом вас ждёт обзор самых интересных решений, представленных на конференции EMNLP 2025.

Наша команда перевода приехала на EMNLP 2025 не только слушать, но и рассказывать о своей работе. В этом году у нас приняли две статьи: одну — в Findings основной конференции, вторую — на WMT. О них я тоже подробно расскажу.

Всем привет! Меня зовут Дарья Андреева, я руковожу командой бэкенда Биллинга и B2B‑платформы Яндекс 360. Наша команда, чтобы сократить TTM и освободить разработчиков от рутины, создаёт удобные внутренние инструменты. Сегодня я хочу поделиться своим опытом и порассуждать о внутренних инструментах.

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

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

В далёком мае 2018 года я опубликовал на Хабре статью, в которой наша команда представила первую Станцию с Алисой. Тогда это был большой эксперимент для Яндекса: никто не знал, смогут ли умные колонки занять свою нишу на российском рынке. Но всё получилось. С тех пор мы разработали уже полтора десятка моделей, каждая из которых нашла своих пользователей. Теперь наше первое устройство занимает лишь 3% от общего числа всех умных колонок с Алисой.

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

Из этой статьи вы узнаете о новой категории архивных устройств и тех критериях, которым должна соответствовать умная колонка с Алисой, чтобы туда попасть. Ну и, конечно же, мы поговорим о судьбе столь любимой многими (в том числе — автором этих строк) Яндекс Станции первого поколения, прекращение поддержки которой мы откладывали как могли.

Всем привет, меня зовут Андрей Матвеев, я разработчик в команде платформы надёжности Яндекс Такси. Если проще — я занимаюсь тем, чтобы Такси работало стабильно. А ещё я техлид проекта virtual‑orders — это наша система нагрузочных учений. Изначально она была для Такси, но теперь мы активно внедряем её в Еду и Лавку.

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

ИИ‑агенты — очень горячая тема. Кажется, все их делают, но также кажется, что реальную пользу приносит только небольшая часть. Один из основных удачных примеров — DeepResearch, глубокий поиск, отвечающий на сложные вопросы. Многие им пользуются в ChatGPT или Perplexity, но у внешних решений нет доступа к нашим корпоративным данным, поэтому мы сделали свой DeepResearch и сэкономили время сотрудников компании.

Меня зовут Сергей Скородумов, я руководитель отдела поисковых сервисов. В статье расскажу про ИИ‑агентов в целом, как мы делали своего, за счёт чего растили его качество и какие главные выводы сделали. 

Загадка: во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2? 

Ответ: в 2,5 раза!

Привет! Меня зовут Стёпа, и я разработчик в Яндекс Go. Я хочу поделиться тем, как математика может встречаться в самых неожиданных местах — даже в такой рутинной задаче, как настройка интервала поллинга. В статье я рассмотрю модельный пример, который встречался каждому разработчику, и просчитаю его с математической точки зрения, использовав базовые факты из теории вероятностей и статистики.

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

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

Привет, Хабр! Меня зовут Владислав Волох, я руковожу группой разработки сервиса DataSphere в Yandex Cloud — и я люблю учить нейросети тому, что делать вручную не хочется. Эта любовь к инженерным решениям и ML пригодилась в быту: так появился мой пет‑проект автомата для приготовления простых коктейлей со встроенной базой рецептов, который уже полюбился многим коллегам. 

В этой статье расскажу, как это работает и как я собирал свой аппарат под управлением iOS, не написав при этом ни одной строчки кода.

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

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

Из всего многообразия жанров, которые были представлены на домашних компьютерах 80-х и 90-х, один — незаслуженно забыт, хотя в своё время был дико популярным. Англоговорящие товарищи называют его Platform Adventure или Arcade Adventure, а в русском языке устоявшегося названия нет. Но можно условиться на «аркадном квесте» — почему бы и нет?

Владельцам ZX Spectrum этот жанр, скорее всего, известен по серии игр про Диззи. Помимо привычной беготни с прыжками в стиле Super Mario Bros., в таких играх нужно решать разные задачки‑головоломки и общаться с персонажами.

Например, самая простая задачка выглядит так: нужно выбраться из подвала с деревянной дверью, имея в своём распоряжении пучок сухих листьев, спички и ведро с водой. Решение очевидное: листья положить под дверь, поджечь, дождаться, когда дверь сгорит вместе с листьями, а затем потушить огонь водой. Есть и сложные задачи — ради их решения нужно несколько раз пробежать всю доступную карту, поболтать с десятком персонажей и использовать дюжину разных предметов.

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

Но в 80-е аркадные квесты гремели если не на весь мир, то как минимум на всю Европу. Игры этого жанра попадали в топы продаж, а то и вовсе занимали в них первые места. Наибольшая популярность, само собой, досталась вышеупомянутому Диззи, поэтому аркадные квесты частенько называют «диззиподобными» играми. Вот только это определение не очень справедливое, ведь жанр зародился за три года до появления Dizzy — The Ultimate Cartoon Adventure.

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

Привет, Хабр! Меня зовут Кирилл Курдюков, и мы с командой делаем YDB (СУБД Яндекса). Как и с языками программирования, популярность СУБД определяется не только их возможностями, но и экосистемой.

В предыдущей статье я рассказал о том, как разработать Java-клиент для распределённой СУБД и интегрировать его с популярными ORM. А из этой статьи вы узнаете, как под капотом работает ADO.NET, почему управление пулом сессий может сильно влиять на ваш код работы с базой данных и какой стратегии обработки ошибок можно придерживаться для разработки отказоустойчивых сервисов. Статья будет полезна тем, кто изучает особенности взаимодействия в распределённых системах или просто хочет научиться лучше писать клиентский код, работающий с современными распределёнными системами.

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

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

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

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