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

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

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

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

Привет! Меня зовут Алексей Архипенко, я руковожу группой разработки 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;

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