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

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

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Недавно в Брно состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз началась работа над C++29 и как раз о новинках и хочется рассказать.

Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service.

Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса.

В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться.

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20.

Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

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

На связи Юлия Шеянова, менеджер проектов в здравоохранении, Центр технологий для общества Yandex Cloud. В этой статье расскажу, как мы в Yandex Cloud вместе с Ассоциацией детских ревматологов (ASPiRRe) и студентом ИТМО сделали ИИ-агента для системы дистанционного мониторинга. 

Ниже — как он устроен и почему мы доверили модели только две узкие задачи, а все решения о рисках вынесли в детерминированные правила.

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

Привет! Я Константин Николаев, занимаюсь внедрением нейротехнологий в Поиске по картинкам. В этой статье я расскажу, как наша команда научила модели смотреть на картинку и читать текст документа одновременно: начали с тяжёлой мультимодальной VLM ради максимального качества, а затем дистиллировали её в набор лёгких моделей — по одной под каждую стадию пайплайна. Что из этого удалось довести до realtime‑поиска с десятками тысяч запросов в секунду и как совместный анализ двух модальностей добавил 5% релевантных картинок в топ выдачи — под катом.

На днях на Хабре вышла статья с разбором Яндекс Браузера и приложения Яндекс для Android. Автор сделал несколько выводов о работе приложений на основе анализа кода.

Часть наблюдений в статье действительно описывает существующие механизмы, однако их назначение интерпретируется неверно. Во многих случаях речь идёт не о специфике Яндекса, а о стандартных механизмах Android, Chromium, работе современных голосовых помощников или платёжных SDK.

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

Сразу оговоримся: автор не указал версии приложений, которые анализировал, поэтому в точности воспроизвести его опыт невозможно. Для разбора мы использовали актуальные версии Яндекс Браузера и приложения Яндекс из Google Play. Все описанные ниже механизмы можно проверить самостоятельно.

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

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

Привет, Хабр! В начале июня в Вене прошла главная международная конференция по робототехнике и автономным системам — International Conference on Robotics and Automation (ICRA). В этом году среди участников была и наша команда автономного транспорта Яндекса.

Топиков, которые обсуждаются на ICRA, много, потому что она не только об ML — она скорее о робототехнике в целом. Например, есть секции о механизмах и дизайне, а также о медицинских роботах. Было немало и чисто инженерных работ.

Ключевой топик докладов на конференции — RL, он же Reinforcement Learning, обучение с подкреплением. Также нас интересовали статьи по классическому пайплайну автономного автомобиля: perception + prediction + planner + simulation. Новые подходы к Robotic Learning тоже интересны, так как их можно перенести на задачи автономного транспорта.

Меня зовут Егор Волков, я занимаюсь претрейном модели планирования движения в автономном транспорте Яндекса. Вместе со мной на конференцию ездил Максим Спорышев — руководитель службы поведения и предсказания движения. В этой статье мы собрали самые интересные тренды, доклады и инженерные развилки, которые заметили на ICRA 2026, — от Reinforcement Learning и генерации редких edge‑кейсов до того, куда вообще двигается ML в робототехнике.

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

Привет, Хабр! Меня зовут Михаил Гольбах, я ведущий разработчик интерфейсов Yandex Cloud. Уже несколько лет мы с командой развиваем Ферму — сервис, который поднимает preview‑окружение под каждый пулл‑реквест. В этой статье расскажу, как Ферма выросла из простого self‑hosted‑скрипта на одной виртуальной машине в оркестратор на Docker и Kubernetes и почему в итоге мы открыли её код.

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

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

Год мы уговаривали людей описывать таблицы вручную — и собрали описания всего на 500 таблиц из 40 тысяч. Если описывать все данные с такой скоростью (при учёте, что постоянно появляются новые) — страшно представить, на сколько десятков лет мог бы растянуться этот процесс.

Меня зовут Роман Гриднев, я технический менеджер в Яндексе. Расскажу, как мы научились не писать документацию. «Не писать‑то все могут», — скажете вы. Но мы подключили к задаче LLM и дали людям вместо чистого листа черновик: пусть с ошибками, зато не пустую страницу, которая пугает. За полгода мы так описали 15 тысяч таблиц и сэкономили около пяти лет рабочего времени аналитиков. Со временем качество черновиков от LLM доросло до почти полного соответствия описаниям, сделанным людьми. 

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

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

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

За последние годы аудитория Трекера выросла до 600 000 пользователей — пропорционально выросло и количество запросов на новые функции. Бэклог разросся до уровня ответов «внесли в список, но обещать ничего не можем». При этом рынок трекеров очень конкурентный, и останавливать развитие core‑продукта ради разбора кастомных запросов нельзя.

В какой‑то момент мы пришли к выводу: сколько бы ни увеличивали команду разработки, запросов от пользователей всегда будет больше. Это не проблема планирования, а скорее структурное свойство зрелого продукта с большой аудиторией. Единственный способ масштабироваться в этой точке — не делать всё своими руками. 

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

Привет, Хабр! Меня зовут Женя Успенский, я руковожу разработкой фронтенда в Яндекс Трекере и отвечаю за архитектуру платформы плагинов. Со статьёй мне помогал мой коллега Дима Куприк, который отвечает за весь проект целиком. Он расскажет, почему мы вообще решили дать возможность пользователям самим модифицировать Трекер, как плагины помогают решать специфические задачи команд и какие сценарии мы автоматизировали первыми. 

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

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

Быстрые команды удобнее не только пользователям, но и системе: запросы через слово «Алиса» требуют обращения к модели распознавания речи ASR, которой из‑за её размеров необходимы серверные вычислительные ресурсы, а модель быстрых команд устроена гораздо компактнее. Она работает прямо на устройстве, а значит, ограничена вычислительными ресурсами самой колонки — её CPU и оперативной памятью. Из‑за этого модель нельзя сильно увеличить: ей приходится оставаться компактной, зато запрос обрабатывается быстрее. 

За распознавание быстрых команд отвечает нейросеть. Её архитектура почти полностью совпадает с решением для наушников Яндекс Дропс, которое подробно описал в своей статье Григорий Афанасенко. Разница в основном в масштабе: наша модель весит всего от 0,5 до 1,5 МБ в зависимости от железа конкретного устройства.

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

Интернет — это зависимость без зафиксированной версии. Сегодня он возвращает одно, завтра — другое, а послезавтра — ничего. Поэтому мы решили сохранить для сборки тот интернет, который она однажды увидела. Для этого пришлось перехватывать HTTPS, выпускать собственные сертификаты, переподписывать индексы Debian и выяснять, почему Docker отправляет «случайные» заголовки.

В этой статье я расскажу, как разрабатывал кеширующую MITM-проксю, которая перехватывает весь HTTP/HTTPS-трафик и отдаёт ранее сохранённые ответы. Разберём также неочевидные технические проблемы, с которыми пришлось столкнуться.

Типичная умная колонка с Алисой — это скромное железо и совсем немного оперативной памяти: у младших моделей её всего 256 МБ на всё устройство сразу. И за каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес‑логикой, обработкой звука, локальными нейросетями.

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

Меня зовут Сергей, я работаю в команде, которая пишет прикладной код на C/C++ для умных устройств с Алисой (например, колонок, телевизоров и автомобилей). Под катом расскажу, как мы построили и используем инструмент для анализа потребления памяти в проде на нашем флоте Linux‑колонок.

Всем привет! На связи Владимир Аксёнов, руководитель группы IT‑поддержки дата‑центра в Yandex Infrastructure. На Хабре я уже рассказывал об эволюции IT‑оборудования в дата‑центрах Яндекса, показывал наши собственные стоечные решения и делился опытом, как мы тестируем комплектующие для стоек. Но история с сосисками в дата‑центре — не единственная интересная инженерная задача, были ещё и яблоки! 

А под яблоками я имею в виду оборудование Apple, поскольку нашим внутренним пользователям‑разработчикам регулярно необходима среда для тестирования приложений под целевые платформы. И если под Windows, Android и Linux создать такую песочницу нетрудно, то с iOS и MacOS сложность в том, что необходимое оборудование Apple не выпускается в виде серверных решений для дата‑центров.

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

Привет, Хабр! На связи команда генеративных моделей в компьютерном зрении. Вместе с другими командами мы делаем мультимодального ассистента Алиса AI. Внутри него мы развиваем несколько вариантов визуальной генерации с помощью отдельной модели Alice AI ART. Два базовых сценария её работы — генерация по тексту (Text‑to‑Image, T2I) и редактирование по картинке с инструкцией (Image‑to‑Image, I2I). Именно о них пойдёт речь. 

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

В этом году мы поставили себе цель, которая звучала просто, а на практике оказалась полугодовым приключением: не только подтянуть качество, а сделать одну модель, которая одинаково хорошо умеет и в T2I, и в I2I. Внутри мы называем такой режим unified или просто uni. Вас ждёт рассказ об отдельных экспериментах и наблюдениях, которые помогли нам сделать первый шаг в этом направлении и привели нас к Alice AI ART 2.0, — включая те, которые красиво не сработали (спойлер: их хватало).

Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift‑мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods — вы счастливчик. Если нет, добро пожаловать под кат. 

Привет! Меня зовут Даниил Гиренко, я Flutter‑разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня.

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

Привет, Хабр! Меня зовут Никита, и я один из тех, кто каждый год делает Frontend CTF в рамках конференции «Я 💛 Фронтенд». Сегодня хочу с вами поделиться, как и зачем мы ежегодно делаем соревнование для тех, кто любит пробираться сквозь загадки, секреты и спрятанные подсказки в браузерной игре.