Привет! Меня зовут Алексей Архипенко, я руковожу группой разработки ML‑инфраструктуры в команде YTsaurus. Мы часть Yandex Infrastructure и предоставляем пользователям внутри Яндекса инфраструктурный фундамент для самых разных задач машинного обучения.

YTsaurus — основная платформа для хранения и обработки данных Яндекса, которая доступна на GitHub под лицензией Apache 2.0. Это позволяет всем желающим загрузить систему на свои серверы, а также дорабатывать её под свои нужды. Мы уже писали в прошлых постах про её выход в опенсорс и дальнейшее развитие, а также кейсы использования в рекламе. Сегодня расскажу, как Яндекс запускает в ней почти все ML‑обучения и batch‑инференс.

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

Разные команды собирали интерфейсы на общем фреймворке Gravity UI, но постепенно там появилось столько вариаций, что стало сложно поддерживать единый пользовательский опыт. Да и коллеги всё чаще сталкивались с тем, что тратят время на одни и те же решения. 

Чтобы перестать каждый раз изобретать велосипед, мы собрали накопленные практики в единый подход и сделали инструмент для чат‑ботов с ИИ — @gravity‑ui/aikit. Он позволяет создать полноценный интерфейс ассистента за несколько дней и при этом легко адаптировать его под разные сценарии.

Меня зовут Илья Ломтев, я старший разработчик в команде Foundation Services Yandex Cloud, и в статье я расскажу, почему мы решили собрать AIKit, как он устроен, немного о планах на будущее — и о том, что можно попробовать у себя.

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

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

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

Привет, Хабр! Меня зовут Макарий, и как Senior SRE в Yandex Cloud я не только участвовал в разработке Managed Service for Kubernetes, но и всегда любил в свободное время посмотреть, что интересного понавыпускали для «кубика». Kubernetes, как де‑факто стандарт оркестрации контейнеров, предлагает базовые механизмы для управления вычислительными ресурсами. Однако стандартный планировщик Kubernetes (kube‑scheduler) разрабатывался с учётом общих принципов балансировки нагрузки и не специализирован для уникальных особенностей рабочих GPU‑нагрузок.

Предлагаю рассмотреть весь спектр возможностей — от встроенных механизмов шедулинга K8s до специализированных планировщиков, таких как Volcano, Apache YuniKorn и KAI‑Scheduler. Проанализирую конкретные сценарии, в которых каждый из этих инструментов демонстрирует свои преимущества, и предложу рекомендации по выбору оптимального решения для ваших рабочих GPU‑нагрузок.

Всем привет! В этой статье поговорим про бэкапы PostgreSQL в Kubernetes через призму самого популярного опенсорс-оператора для этой СУБД — CloudNativePG. Мы расскажем о том, как внедрение нового решения на основе WAL-G позволило ускорить резервное копирование и восстановление больших баз данных и поделимся своим опытом доработки CloudNativePG.

На связи Иван Архипов, ведущий разработчик в команде платформы данных в Yandex Cloud, и я приглашаю под кат всех, кому интересна эксплуатация PostgreSQL в Kubernetes!

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

Сегодня мы, команда платформы данных в Yandex Cloud, хотим рассказать о SPQR — нашем опенсорс‑инструменте, который который создавался как ответ на боль шардирования и эксплуатации крупных OLTP‑систем. Под катом — история о том, что стало отправной точкой для его создания, какие задачи он помогает решать, на чём основано наше решение и что помогает ему быть довольно простым в эксплуатации.

Всем привет, меня зовут Семён. Я пишу на С++ и работаю в группе Антиробота. Антиробот — это сервис, который на уровне L7 защищает нас от парсеров и DDoS-атак. Разрабатывать его начали более 10 лет назад — сначала он предназначался только для защиты Поиска, затем был внутренним инструментом, который в онлайн‑режиме анализирует запросы к сервисам Яндекса. Постепенно Антиробот вырос в настоящий highload. Сейчас это часть облачного сервиса Smart Web Security (SWS).

В этой статье я расскажу, как с нашим сервисом мы прошли путь от текстовых правил до машинного обучения. Вы узнаете, зачем вообще нужен Web Application Firewall (WAF) — межсетевой экран для веб-приложений — и разберётесь, как он устроен. А ещё — как работают рулсеты, почему у нас их целых три и какие существуют метрики для оценки качества и быстродействия сервиса.

Всем привет, меня зовут Володя. Я работаю в Yandex Infrastructure и занимаюсь развитием систем балансировки нагрузки. В статье расскажу, как развивалась наша новая система управления конфигураций с момента её создания в 2018 году, а ещё о том, как мы переходили на новый Data Plane балансировки и какие новые интересные вызовы это породило с точки зрения массовости задач и управления ресурсами. 

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

Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. 

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

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

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

Проект LUWRAIN — пример именно такой истории. Это платформа для разработки невизуальных приложений, которая тринадцать лет создаётся усилиями энтузиастов. Сегодня у неё появляется шанс сделать рывок — с помощью LLM и инженерных подходов, основанных на открытых технологиях. В случае LUWRAIN, как и в случае многих похожих инициатив, существует поиск правильного соотношения смысла и усилий. Поэкспериментировать и найти баланс в том числе помогла программа грантов Yandex Open Source.

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

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

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

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

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

В этом году на nexthop 2025 я также расскажу об автоматизации масштабируемой сети для BareMetal‑серверов — так что, если эта тема интересна, заглядывайте к нам 19 ноября.

Привет, Хабр! Меня зовут Виктор Смирнов. В Yandex Infrastructure я c недавнего времени занимаюсь фронтендом YQL: транслятором и инструментами разработки.

В этом посте я расскажу про новый модуль автодополнения запросов на YQL, а также продемонстрирую, как он преобразил консольный клиент YDB CLI.

Меня зовут Владимир Аксёнов, я работаю в Yandex Infrastructure и руковожу IT‑поддержкой в том самом дата‑центре Яндекса, который стал первой площадкой в собственности компании. Это определило его судьбу первопроходца: именно здесь мы тестируем множество технологий, которые затем распространяются на другие дата‑центры.

За 13 лет на этой площадке мы наблюдали радикальные изменения форм‑фактора сетевого и серверного оборудования, что повлекло за собой серьёзные метаморфозы во всём дата‑центре. Мы прошли путь от стандартной 19-дюймовой стойки до четвёртого поколения стоек собственного дизайна, а от холодных коридоров с доохлаждением — пришли к энергоэффективному фрикулингу. 

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

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

Сергей Виноградов на конференции Data&ML2Business рассказал про разработку и построение DWH для задач Яндекс Пэй. В этой статье — дополненный рассказ о том, как устроена аналитическая платформа на базе Greenplum® и ClickHouse®, которую решили строить на базе managed‑сервисов в облаке. А также о том, как жизнь аналитиков облегчает связка Apache Spark™ и Jupyter‑ноутбуков в Yandex DataSphere.

В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы. 

Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.

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

Меня зовут Юлия Рубцова, я ведущий менеджер продукта Yandex Monitoring. В этой серии статей я и мой коллега Владимир Гордийчук @gordiychuk рассказываем про реальные сценарии использования мониторинга облачных решений. Что вас ждёт: мы покажем, как настроить дашборды, быстро проверить гипотезы при расследовании инцидента, а в конце соберём лучшие практики для настройки мониторинга. 

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

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

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

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

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

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

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

В среду 24 сентября мы провели главную конференцию Yandex Cloud — в этом году под новым названием Neuro Scale. Помимо анонсов всех новинок со сцены команда хотела ярче показать работу новых фич облака на реальных задачах. Поэтому многие интерактивы конференции создавали сами разработчики для разработчиков. 

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

— как мы дистанционно управляли байком на Serverless Vibe Code Challenge;

— для чего засовывали сосиски в серверную стойку;

— как нейронные сети помогли нам «озвучить» мицелий экзотических грибов чёрных рейши.

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

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

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

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

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

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