infra.conf'25 уже 5-го июня.

Команда Yandex Infrastructure, которая создаёт и предоставляет внутреннюю инфраструктуру Яндекса, опубликовала программу конференции infra.conf'25.

Спикерами infra.conf'25 станут ведущие инженеры и разработчики Яндекса, Купера, MTS Web Services, Positive Technologies, AvitoTech, Sber AI и других компаний.

Конференция пройдет 5-го июня, самое время оставить заявку на участие.

30 лет.

23 мая 2025 года языку Java исполняется 30 лет. Первая версия Java (1.0) была разработана компанией Sun Microsystems и выпущена в 1995 году.

Танцуют все.

5 миллиардов событий.

Что такое 5 миллиардов событий — это обезличенные и тщательно зачищенные данные за 8 месяцев работы Яндекс Музыки, на которых можно обучать и тестировать рекомендательные системы. Пару дней назад Яндекс выложил в опенсорс Yambda (YAndex Music Billion-interactions DAtaset) — один из крупнейших в мире датасетов для развития рекомендательных систем.

Датасет представлен в трёх вариантах: полная версия содержит 5 миллиардов данных, уменьшенные — 500 миллионов и 50 миллионов. Данные датасета и код для замеров доступны на HuggingFace.

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

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

Агенты не спасут.

Вместе с Алексеем в две каски развлекались в 293-м эпизоде подкаста «Разбор полетов». Порадовались появлению нового сервиса Yandex Neurosupport от Yandex B2B Tech.

Вспомнили, что мы любим Java и слегка тронули JEP 512 и свет нашего Брайана Гетца. Подвисли немного на теме агентов и в частности обсудили Amazon Q Developer

Слушать подкаст на Яндекс.Музыке.
Читать полезняшки от «Разбора Полетов».

#подкаст #debriefing

Архитектурная задача: тяжелый камень на собеседовании.

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

1. Общение с десятками незнакомых людей.

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

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

2. Архитектурные задачки: вот где настоящая проба на прочность.

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

По итогу забега собеседований мой студент подошёл к задаче конструктивно: добавил себе в личный roadmap проработку типовых архитектурных задач. Так что если узнаёте себя — не удивляйтесь, c этим сталкиваются почти все! На мой взгляд, архитектурное мышление можно и нужно тренировать — как раз на такого рода open-ended задачах, всегда есть, куда расти.

Сыграйте в архитектурную игру — и прокачайте себя

Кстати, а что если сыграть в архитектурную игру наоборот? Вдруг у вас есть на пальцах какая-нибудь нетривиальная архитектурная задачка: как построить систему X, обеспечить отказоустойчивость у Y, распределить нагрузку, минимизировать стоимость владения и так далее.

Если вам интересно не просто поэкспериментировать «для себя», а увидеть, как с задачей справляются архитекторы топовых продуктовых компаний — да, такое реально!

Присылайте свои архитектурные задачи — лучшие обсудят и разберут в прямом эфире ведущие backend-разработчики Яндекса:

👉 Оставить задачу для разбора

Есть собственный pain point или интересная архитектурная загадка? Не стесняйтесь — отправляйте тему, и, возможно, вашу задачу выберут для публичного разбора с комментариями и советами!

Теорема Кука — Левина.

Гладишь ты такой в ночи бельишко, и на фоне играет третьесортный русский телесериал. И тут герой обсуждает теорему Кука, у меня чуть утюг не выпал.

Точнее, работу в кругах математиков принято называть теоремой Кука — Левина. Доказательство теоремы было сформулировано Стивеном Куком в работе 1971 года. Но в то же самое время независимо теорему доказал советский математик Леонид Левин.

В этом дуэте через некоторое время возник третий участник — Ричард Карп. Стивен за свою работу в 1982 году получает престижную премию Алана Тьюринга. И вслед за ним в 1985 году ту же премию получает Ричард, по факту за продолжительный вклад в теорию алгоритмов и решение ряда задач.

Как-то уже писал, что в 1983 году Кен Томпсон и Деннис Ритчи получили премию Тьюринга за разработку общей теории операционных систем и, в частности, за создание ОС UNIX.

Тут мысль остановилась и пошла спать.

Платформа для разработчика как продукт.

После просмотра выступления Романа Елизарова про платформу для разработчика как продукт — вот ссылка на его доклад — не дают покоя несколько мыслей. Доклад рекомендую к просмотру тем, кто занимается внутренними платформами и инфраструктурой в IT-командах.

Роман затронул несколько важных моментов, которые у меня резонируют и, думаю, также попадут во многих из вас:

1. Продукт должен быть ориентирован на пользователя и иметь чёткую цель 

Это кажется очевидным, но на практике мы знаем, сколько можно потратить ресурсов впустую, создавая очередную платформу «потому что модно», «бизнес попросил» или «у конкурентов есть». 

На успешных продуктах вроде GitHub Actions или Firebase — видно, что каждая их функция отвечает на конкретную боль пользователя и реально облегчает жизнь. Хотя со временем что-то лишнее (или непонятное внешнему наблюдателю) налипает. Еще один отличный пример — внутренняя платформа Backstage от Spotify. Их всех объединяет философия: каждая новая фича убирает барьеры для разработчиков, а не создаёт новые.

2. Метрики — не просто красивые графики

Роман совершенно прав: метрики — это не самоцель. Цифры ради отчёта мало что дают — важно понимать, какую реальную пользу они показывают. Можно измерять аптайм, скорость деплоя, NPS — но всё это имеет смысл, только если метрики реально связаны с удовлетворённостью и эффективностью команд. cto

3. Документация и поддержка — не nice-to-have, а must-have 

Каждый, кто пытался разобраться в обрывочном или устаревшем README, меня поймёт 😅 (Сам не раз сталкивался с самописными сервисами без документации.) Хорошая документация и поддержка делают платформу реально ценной для всей компании. Не зря такие проекты, как Stripe, серьезно вкладываются в документацию, и это помогает выделяться среди конкурентов. Небольшая заметка про важность документации.

4. Удобный интерфейс — не для красоты, а ради бизнеса 

Тут вообще можно столько копий сломать, что даже начинать не хочется. Любой разработчик, застрявший в сложных ритуалах деплоя или в интерфейсах уровня Jenkins-2015, знает, о чём речь. 

В итоге 

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

Закон Амдала, или почему не всё параллелится.

Представьте, что вы пытаетесь ускорить приготовление борща, привлекая больше поваров. Звучит логично – чем больше рук, тем быстрее, верно? Не совсем! И именно об этом нам рассказывает закон Амдала.

В 1967 году Джин Амдал сформулировал то, что сейчас считается одним из фундаментальных законов компьютерной архитектуры. Суть проста: если у вас есть задача, которую вы пытаетесь распараллелить, максимальное ускорение всегда будет ограничено той частью, которую нельзя выполнить параллельно.

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

Вернёмся к борщу. Некоторые операции можно распараллелить (например, нарезка овощей), но есть те, которые должны выполняться строго последовательно (варка: мясной бульон и т.д.). Сколько бы поваров вы ни добавили, борщ не сварится быстрее определённого времени из-за этих последовательных операций. Тут вы меня поправите, мол, можно заранее заварить бульон, так, например, поступают при промышленной готовке плова, когда заранее готовят зирвак. Но это тоже время.

То же самое в программировании — даже если у вас есть 128 ядер, программа не станет работать в 128 раз быстрее. Всё упирается в ту самую последовательную часть, которую никак не распараллелить.

Вспомнил я это не случайно. Необходимо было консультировать одного молодого человека с легаси-проектом на Java 6. По памяти вспомнил формулу закона Амдала и книжку, в которой впервые к месту прочитал объяснение и сразу знакомился с применением этого закона:

Java Concurrency in Practice

Сейчас, благодаря издательству «Питер», книжка доступна на русском языке:

Java Concurrency на практике

Взял ее в руки, и прям накатила ностальгия. Начал читать, и прям поперли флешбэки, чуть позже вернусь к этой книге еще.

#книга

Приключения в South HUB: D&D с умной колонкой.

Вернулся с крутого летнего лагеря для C-level — South HUB. Провел там три игры Dungeons & Dragons в роли мастера (про наш D&D надо конечно рассказать отдельно), и у меня был необычный помощник — новая Яндекс Станция Стрит .

Почему она оказалась идеальным компаньоном для D&D?

Два ключевых момента:

1. Автономность: колонка работает через мобильный хотспот или Bluetooth. А если заранее скачать треки - вообще не нужен интернет. Идеально для выездных игр!

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

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

Прям горжусь, как удачно всё сложилось — и игры провел, и новую колонку протестировал в деле. Теперь это мой must-have для выездных D&D сессий 🎪

А вот представьте себе виртуального менеджера в вашем трекере задач! 🤔

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

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

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

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

Как думаете, такой помощник реально мог бы облегчить жизнь команде? 🤔

Но в начале мы, конечно, кайфанем, прям вижу в тикете переписку:

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

Young Con 2025.

Уже на следующей неделе мега-событие в Москве. 25 июня на Live Арене пройдет Young Con 2025. Коллеги ждут 8 000 человек (в прошлом году было круто и было 5000).

Ярмарки вакансий, продуктовые зоны, доклады и пробные собеседования. Все для тех, кто начинает карьеру в ИТ.

П.С. А я в это время буду на питерских конференциях и вырваться не смогу, но обещают, что будет эпично.

Немного о безопасности дома.

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

Сейчас мои коллеги запустили в производство и уже поставляют умную IP‑камеру для дома. Она работает в экосистеме умного дома с Алисой и стоит недорого.

Высоконагруженные системы, ARGUS и музыка.

Эта неделя наполнена технологическими конференциями. Сегодня и завтра веду «Красный зал» на Saint HighLoad, подходите, будет интересно.

Кстати, в кулуарах задали вопросик: «А что из «высоконагруженного» происходит в мире, от чего меня прям распирает?» И вы знаете, у меня есть ответ. Недавно ребята катнули ARGUS — новое поколение генеративных моделей.

Помните, я писал про один из крупнейших в мире датасетов для развития рекомендательных систем — примерно 5 миллиардов событий. Так вот, ARGUS в Яндекс Музыке ворочает объемом более чем в 20 раз превышающим Yambda.

Ну и что, спросите вы. А то, что внедрение ARGUS увеличило количество лайков на незнакомых треках на 20%. Подробно про внедрение можно почитать тут.

Особенно в рассказе Кирилла меня впечатлило то, как он рассказывает про результаты A/B-тестов и замеры, поверьте, вживую это еще круче, чем в тексте. Хотя в тексте вы все можете считать обстоятельный рассказ, но он не передает ту вовлеченность и эмоции, которыми Кирилл заражает слушателей.

Кайфовый мерч.

Зажали меня тут в кулуарах с запросом: а что на конференции прям вот самый-самый мерч?

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

Залипание, привычки, карты.

Знаете, что самое интересное в работе над продуктами? То, как сильно мы, пользователи, привязываемся к определенным паттернам поведения. Это как любимое кресло – вроде и не самое удобное, но попробуй пересади нас в другое!

Вот как пример. Уже скоро середина лета, пешие прогулки по городу (в моем случае полуночные). И хочу признаться, многие годы отдавал предпочтение картам от 2gis в соотношении 70 на 30 относительно Яндекс Карт.

Но вот уже какое-то время стал замечать, что баланс сильно изменился. Последние пару месяцев явно 60 на 40 в пользу Яндекс Карт. Что случилось? Мне непонятно. Но мою пользовательскую привычку Яндекс Карты смогли перебить.

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

🎯 Как закрепить нужные паттерны поведения у пользователей.
Тут важно создать такой опыт использования, чтобы он стал частью ежедневной рутины. Чтобы действия выполнялись на автомате, без лишних раздумий.

🎯 Как переманить пользователей от конкурентов.
А это уже настоящее искусство – нужно не просто предложить что-то лучшее, но и помочь людям преодолеть инерцию привычек.

Интересно, что даже явные улучшения в продукте могут натолкнуться на сопротивление пользователей. Потому что «а я привык по-старому» 🤷‍♂️

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

А у вас есть примеры, когда вы долго не могли отказаться от привычного инструмента в пользу более современного? Делитесь в комментариях!

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

Все проспал, проспал, а нет не проспал!

Коллеги разыгрывают кастомные настолки и фирменные рюкзаки. Они решили совместить полезное с приятным: предлагают пройти небольшой квиз по нашей инфраструктуре — а заодно получить шанс на приз.

Всё просто:
🟣 отвечаете на вопросы квиза про наши продукты и технологии
🟣 заполняете форму
🟣 и подписываетесь на канал Yandex Infrastructure

Важно: отправка призов только по РФ.

🚩 Среди участников 7 июля случайным образом выберут 10 победителей — каждый получит набор из фирменной настолки и рюкзака.

Есть вопросики.

Бывает так, что вы открываете приложение, и в нем всё переставили. Поздравляю, скорее всего, вы попали в продуктовый эксперимент! И я такой же, как вы. Иногда недоумеваю, и мне в новой Лавке так же бывает полезна инструкция от Максима Ильяхова, чтобы добраться до раздела «Вы покупали».

А кто все это придумал? Продакт!

Продакт рано или поздно должен ставить рискованные и смелые эксперименты. И для части аудитории это может оказаться болезненным воздействием. А другая часть аудитории увидит для себя пользу. Дальше всё зависит от метрик. Вот гипотеза. Вот эксперимент. Вот метрики. И во многих случаях сразу видно — это гипотеза «золото». А эта так себе проявилась.

Бывает, без хорошенькой такой, развернутой P&L, кучи метрик и дополнительного исследования и не разобраться. Можно задать много прямых и хороших вопросов, которые крутятся на языке.

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

Мне вспомнился прекрасный анекдот про круизный лайнер, когда вседержитель на корабль три года всех собирал. А тут не три года, а прям быстро — 26 июля пройдёт Product : Fest — фестиваль Яндекса для продактов и продуктовых дизайнеров.

Приходите, чтобы честно обсудить боли с коллегами (от коммуникации с разработчиками до работы с AI) и вдохновиться кейсами громких запусков от CPO и арт-директоров. И, конечно же, понетворкаться на утреннем кофе-рейве и вечернем боулинге.

Обещают четыре локации: «Слушаем», «Общаемся», «Катим», «Танцуем». Между докладами можно славно покатать шары понетворкать и задать острые вопросы.