Yandex for Backend
前往频道在 Telegram
Канал для бэкендеров от Яндекса. Рассказываем про события по Python, Go, Java и C++ и не только, делимся экспертизой, обсуждаем технологии и поддерживаем бэкенд-комьюнити. Другие каналы Яндекса по стекам разработки: https://t.me/addlist/Hrq31w2p1vUyOGZi
显示更多9 817
订阅者
-124 小时
+247 天
+12630 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
七月 '26
七月 '26
+74
在2个频道中
六月 '26
+190
在2个频道中
Get PRO
五月 '26
+249
在3个频道中
Get PRO
四月 '26
+333
在0个频道中
Get PRO
三月 '26
+282
在3个频道中
Get PRO
二月 '26
+311
在2个频道中
Get PRO
一月 '26
+240
在0个频道中
Get PRO
十二月 '25
+359
在5个频道中
Get PRO
十一月 '25
+586
在7个频道中
Get PRO
十月 '25
+474
在2个频道中
Get PRO
九月 '25
+203
在3个频道中
Get PRO
八月 '25
+144
在2个频道中
Get PRO
七月 '25
+131
在0个频道中
Get PRO
六月 '25
+236
在0个频道中
Get PRO
五月 '25
+181
在0个频道中
Get PRO
四月 '25
+231
在1个频道中
Get PRO
三月 '25
+94
在0个频道中
Get PRO
二月 '25
+121
在0个频道中
Get PRO
一月 '25
+179
在0个频道中
Get PRO
十二月 '24
+312
在4个频道中
Get PRO
十一月 '24
+399
在3个频道中
Get PRO
十月 '24
+165
在0个频道中
Get PRO
九月 '24
+242
在0个频道中
Get PRO
八月 '24
+327
在8个频道中
Get PRO
七月 '24
+173
在3个频道中
Get PRO
六月 '24
+1 438
在6个频道中
Get PRO
五月 '24
+112
在0个频道中
Get PRO
四月 '24
+393
在1个频道中
Get PRO
三月 '24
+755
在6个频道中
Get PRO
二月 '24
+231
在2个频道中
Get PRO
一月 '24
+89
在0个频道中
Get PRO
十二月 '23
+271
在0个频道中
Get PRO
十一月 '23
+3 198
在3个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 12 七月 | +1 | |||
| 11 七月 | +4 | |||
| 10 七月 | +7 | |||
| 09 七月 | +4 | |||
| 08 七月 | +11 | |||
| 07 七月 | +6 | |||
| 06 七月 | +12 | |||
| 05 七月 | +2 | |||
| 04 七月 | +9 | |||
| 03 七月 | +3 | |||
| 02 七月 | +7 | |||
| 01 七月 | +8 |
频道帖子
+8🤖 Когда код не управляет логикой: observability для AI-агентов
На связи Даниэль Халиулин, технический менеджер в Yandex Infrastructure. Сейчас AI-агенты развиваются и интегрируются в сервисы с огромной скоростью. Но если не контролировать их работу, последствия могут быть неприятными.
Представьте ситуацию: очень важный AI-агент сломался прямо в проде. Инфраструктурные метрики при этом горят зелёным, а в логи заглядывать страшно. Как понять, почему агент стал галлюцинировать? На какие данные смотреть, как и где их хранить? Что делать, когда привычные метрики теряют актуальность?
👩⚕️ В карточках я разобрал, что значит observability AI-агентов, почему трейсы сменяют логи и какие инструменты можно использовать для мониторинга.
🔶 А в полном выступлении на infra.conf’26 я рассказал обо всём подробнее. Смотрите доклад на сайте или на ютубе.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend
| 2 |  🔡 Как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей
Представьте: пользователь добавляет одного сотрудника в группу где-то в глубине иерархии и почти минуту смотрит на лоадер. А запрос показать список всех участников и вовсе роняет базу по тайм-ауту.
Именно так вела себя наша старая схема хранения оргструктуры. Речь о Директории — компоненте B2B-платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов.
Меня зовут Малик Минубаев, я занимаюсь развитием B2B-платформы в Яндекс 360. Хочу рассказать, как мы пересобрали архитектуру хранения оргструктуры.
❇️ В поисках идеального паттерна
Наша оргструктура состоит из двух сущностей:
1️⃣ Подразделения — это строгое дерево, у каждого только один родитель
2️⃣ Группы — это направленный ациклический граф, который может входить в любое количество других групп и организационных сущностей
Специфика системы такова, что читающих операций у нас в сотни, а иногда и в тысячи раз больше, чем пишущих. Оргструктура для нас — это графы и деревья с колоссальным преобладанием операций чтения. Именно скорость обхода графа вглубь — это наш приоритет. Но обычным тюнингом или поднятием лимитов в конфигах обойтись было нельзя, потому что системе требовалось новое хранилище.
Мы перебрали классические древовидные паттерны: Adjacency List, Materialized Paths, Nested Sets, но они не умеют работать со структурой групп, где один объект может входить в несколько контейнеров.
➖ У нас осталось два кандидата: Bridge Table и Closure Table. Но листинг состава групп на верхних уровнях вложенности занимает около 20 секунд — это непозволительная роскошь для высоконагруженного B2B-сервиса. Так мы окончательно убедились, что нужно использовать Closure Table.
Но его классические варианты и академические оптимизации либо отлично работают на запись, но проваливают удаление рёбер, либо эффективно обрабатывают удаление, но плодят дубликаты, которые намертво вешают чтение через DISTINCT.
💡 И мы поняли: необходимо собственное архитектурное решение. Нам нужно было убрать дубликаты на уровне схемы данных, но при этом сохранить возможность легко перестраивать граф при удалении рёбер.
🔶 Читайте подробности в статье на Хабре. Там я рассказал, какое решение мы придумали, зачем разделили архитектуру хранения на два слоя и как нам удалось выкатить такое масштабное изменение в прод без даунтаймов.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 1 540 |
| 3 |  🧬 Инженерная кухня SPQR
На связи Денис Волков из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой опенсорс-системы SPQR, которая облегчает переезд на шардированную инсталяцию. Хочу немного рассказать о нашем решении: как мы к нему пришли и что под капотом.
🤔 Нам было нужно построить систему, которая: общается с приложением по протоколу PostgreSQL, позволяет докидывать шарды на лету и держит метаданные о распределении данных в оперативной памяти. А ещё не разваливается, если один ключ приносит непропорционально большую нагрузку, и умеет всё это делать без даунтайма.
Из каких блоков собран SPQR:
🟢 Роутер. Принимает клиентские подключения, разбирает запрос, находит нужный диапазон и отправляет запрос на шард. Сам данные он не перевозит
🟢 Координатор. Управляет метаданными и выполняет длинные операции: создаёт задачи перевоза, ведёт их состояние, двигает данные и переключает маршрутизацию
🟢 QDB на базе etcd. Хранит общие метаданные: distributions, key ranges, lock state, а также промежуточное состояние длинных операций
🟢 Балансер. Отдельная утилита, которая смотрит на состояние шардов, ищет перекосы нагрузки и инициирует перевозы там, где они нужны
Если коротко: роутер маршрутизирует запросы, координатор перевозит данные, QDB хранит состояние, а балансер решает, что пора двигать.
💹 Как выглядит алгоритм роутинга:
1️⃣ Приходит SQL-запрос
2️⃣ Роутер вытаскивает из него ключ шардирования
3️⃣ Если используется хеш-шардирование, ключ сначала прогоняется через хеш-функцию
4️⃣ Полученное значение ищется в таблице диапазонов
5️⃣ По диапазону находится шард
6️⃣ Запрос уезжает на нужный PostgreSQL-кластер
🔶 В статье на Хабре я рассказал ещё больше подробностей о том, как мы построили эту систему, зачем SPQR оперирует key range, как координатор перевозит данные маленькими кусками и как балансировщик понимает, что именно надо двигать. А также поделился компромиссами и граблями, которые встретились нам по дороге.
👀 Если хотите проверить подход на своих нагрузках без самостоятельной сборки — попробуйте Managed Service for Sharded PostgreSQL.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 108 |
| 4 |  🟢 Поможем подготовиться к собесу и прокачать резюме
Мы перезапускаем наш MVP-проект с бесплатными карьерными консультациями для разработчиков от опытных рекрутеров Яндекса. Приходите к нам, а мы поможем с резюме или профилем LinkedIn, расскажем о наших карьерных треках и ответим на все интересующие вопросы о наймовых процессах в IT.
Кого зовём: бэкенд-разработчиков уровня мидл+ с опытом от 3 лет.
Как всё устроено:
🟢 Отправляете заявку
🟢 Выбираете удобную дату и время
🟢 Узнаёте всё, что хотели, на 45-минутном созвоне
🔶 Узнать подробности и отправить заявку
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 531 |
| 5 |  +8🏠 Как мы вынесли рекламу в офлайн
Меня зовут Юра Журихин, я руководитель разработки наружной рекламы в Поисковых сервисах и ИИ. В нашей бизнес-группе большое количество разных бэкенд-сервисов. И наружная реклама — один из таких нетривиальных примеров.
Мы долго занимались онлайн-рекламой и уже успели стать в ней экспертами. Но сейчас я хочу рассказать, с какими вызовами мы столкнулись, когда выносили её в мир офлайна.
👩⚕️ Читайте об этом в карточках выше
🔶 На конференции «Я про бэкенд» я более подробно рассказал о методах определения аудитории вблизи физических рекламных экранов и поделился алгоритмами отслеживания видимости рекламы на движущихся носителях. А также объяснил, какие способы помогли нам переосмыслить традиционные методы оценки эффективности наружной рекламы.
📺 Смотрите доклад на ютубе.
📎 Кстати, конференция «Я про бэкенд» пройдёт уже этой осенью — будем много говорить про бэкенд и то, как он меняется в эпоху ML.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 173 |
| 6 |  🈯️ Приглашаем на Back to Back!
Это конференция для бэкенд-инженеров, архитекторов, SRE и техлидов. Поговорим о том, что болит в больших системах: latency, bottlenecks, отказоустойчивость, масштабирование и инфраструктура. А также обсудим архитектурные решения, которые нельзя проверить на слайдах — только в продакшене.
Когда и где:
📆 1 августа
📍 Одновременно в Москве, Белграде и Ереване
В каждом городе — свой фокус программы:
🟢 В Москве и Ереване собираем инженеров на Architecture & Performance — трек про производительность и реальные продакшен-задачи
🟢 В Москве и Белграде ждём всех, кто дружит с C++, — трек C++ Zero Cost про производительность, системную разработку и инженерные задачи
💹 Но это не всё! На площадках будут активности от команд и сервисов Яндекса. А если не сможете приехать лично — подключайтесь онлайн к любому из городов.
🔶 Полную программу мы соберём к началу июля, но регистрация уже открыта! Так что переходите на страницу своей площадки, чтобы узнать подробности и оставить заявку:
📟 Москва
📟 Белград
📟 Ереван
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 978 |
| 7 |  🔨 Как мы чиним невидимое: сеть в Yandex Cloud
🎙️ Меня зовут Костя Крамлих, я руководитель службы сетевой виртуализации в Yandex Cloud. Недавно я заглянул в гости к ребятам из подкаста «Разбор полётов» — поговорили про сеть, надёжность и немного про стажёров.
Что мы обсудили:
🟢 Принцип нашей работы
Все Data Plane должны работать полностью при отказе Control Plane — это самое главное и фундаментальное свойство надёжности.
Почему? Control Plane — это сложные сервисы с бизнес-логикой, вероятность отказа там гораздо выше. А Data Plane — это то, что реально процессит трафик клиента.
Если упал Control Plane — неприятно, но клиент может подождать. Но если перестал работать Data Plane — трафик не идёт. А для пользователя это в 10 раз хуже.
🟢 Мы стремимся обновляться незаметно для клиентов
Раньше перезапуск Data Plane ронял трафик. Поэтому мы используем Blue Green Deploy прямо на хосте: привозим на живой сервер две инсталляции Data Plane и плавно переключаем интерфейсы виртуальных машин с одного на другой.
Результат — сотни миллисекунд, которые укладываются в TCP-ретрай. И подавляющее число наших клиентов этого вообще никак не замечает.
🟢 Собственная модель учений
В большом Яндексе их проводят почти 20 лет: просто отключают один дата-центр фаерволом и смотрят, все ли сервисы выжили. Но в облаке так нельзя: мы не можем диктовать клиентам, как строить резервирование.
Поэтому у нас гибридная модель. Раз в две недели на препроде полностью отключаем одну зону. А некоторые сервисы (региональные, консоль) тестируем прямо на проде: они по своему построению должны выдерживать отказ любой зоны.
🔶 Слушайте больше подробностей о том, как мы строим сетевые продукты в Yandex Cloud, в полном выпуске подкаста «Разбор полётов» на сайте, ютубе и в Яндекс Музыке.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 607 |
| 8 |  💹 YaFF в опенсорсе: как и зачем мы сделали zero‑copy-представление для Protobuf
В высоконагруженных C++-сервисах часто используют Protobuf. Он по-своему удобен, но парсинг миллионов объектов в секунду забирает заметную часть процессорного времени. Переезд на FlatBuffers кажется решением, однако на практике это не «Protobuf без парсинга»: различия в схемах, API и доступе к вложенным данным делают миграцию дорогой и рискованной.
🟢 Мы выложили в опенсорс YaFF (Yet Another Flat Format) — альтернативный способ представления Protobuf для высоконагруженных сервисов. Библиотека позволяет встраиваться в существующую Protobuf-инфраструктуру и работать с данными, но не расходовать ресурсы на их десериализацию. Это даёт возможность экономить до 20% вычислительных мощностей.
🔶 Читайте в статье на Хабре все подробности об архитектуре YaFF. Внутри: тернистый путь к успеху, низкоуровневые детали и красивые цифры бенчмарков.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 847 |
| 9 |  🧬 Как Яндекс Диск выдерживает сотни гигабит входящего трафика
Типичная схема бэкенд-приложения выглядит стандартно: группа экземпляров сервиса и балансировщик перед ними. Пользователь отправляет на него запрос, а тот проксирует его на конкретный инстанс. Эта схема отлично работает на лёгких API-запросах, но рассыпается, как только трафик становится тяжелее.
Меня зовут Илья Абрамов, я разработчик в Диске. И в нашем случае речь идёт о массовой загрузке файлов. Миллионы пользователей с разной скоростью интернета загружают данные самых разных размеров — от крошечных документов до многогигабайтных архивов. Хочу рассказать, как мы решили проблему распределения такой нагрузки.
❇️ Что сделали
Мы полностью отказались от промежуточных балансировщиков при загрузке файлов. В нашей текущей архитектуре путь данных выглядит иначе: пользователь отправляет тяжёлый трафик напрямую в сервис.
Но для этого нам пришлось переосмыслить сам принцип того, как клиент находит нужный сервер, и придумать, как сэкономить сетевые ресурсы. Ведь если хост перегружен, пользователи либо вообще не могут загрузить файл, либо сталкиваются с катастрофическим падением скорости.
❇️ Поэтому мы разделили процесс на два типа запросов:
🟢 Control (управляющие). Это легковесные HTTP-запросы. Их задача — получить одобрение на загрузку и узнать адрес целевого сервера. Они проходят через стандартный балансировщик, так как почти не создают сетевой нагрузки
🟢 Data (данные). Это тяжеловесные потоки байтов, которые идут напрямую от пользователя к выбранному серверу и минуют промежуточные звенья
❇️ Теперь архитектуру загрузки в Диске формируют два ключевых компонента:
🟢 Балансерун (Balancer). Он выбирает наиболее подходящий экземпляр сервиса для конкретного пользователя. Балансерун в реальном времени держит в памяти актуальный список всех живых серверов (через Service Discovery) и мониторит их состояние. И на выходе отдаёт пользователю уникальную ссылку на загрузку
🟢 Кладун (Uploader). Это сервис, который принимает входящий data-запрос по прямой ссылке и сохраняет файл в целевое хранилище
💹 Схема взаимодействия выглядит так: пользователь спрашивает у Балансеруна, куда положить файл → Балансерун анализирует загрузку системы и отвечает: «Вот ссылка на сервер №3» → пользователь открывает прямое соединение с этим сервером и отправляет данные в Кладун.
🔶 В статье на Хабре я рассказал, как мы искали идеальный алгоритм для достижения равномерной утилизации сети на всех аплоадерах (и почему это было не так-то просто), а также как нам пришлось глобально переработать логику и в итоге создать алгоритм HOBA 🤸🏻
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 437 |
| 10 |  📖 Как использовать Temporal
Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта.
❇️ Не поддавайтесь иллюзии чистой архитектуры
Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы.
Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход.
❇️ Как надо делать:
🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK
🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования
🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity
💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики
Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность.
Какие инструменты могут помочь:
🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение
🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката
🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться
➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫
🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 648 |
| 11 | все | 1 |
| 12 |  🎙 Мы знаем, что бэкендерам есть что рассказать про серверную сторону AI
За последние пару лет искусственный интеллект проник во все сферы. Сложно построить новый проект без умных рекомендательных и генеративных технологий. Появились сотни новых AI-first-продуктов и тысячи AI-фич в обычных сервисах.
🈯️ Приглашаем на «Я про бэкенд 2026». На этой конференции мы поговорим о высоконагруженных рекомендательных, генеративных и других системах под капотом продуктов с AI/ML, а также о вызовах, с которыми сталкиваются их разработчики.
В прошлом году было 13 докладов от специалистов из Яндекса, Авито, Т-Банка, Сбера и VK. Например, спикеры рассказали, как выжимать максимум из decoder attention на GPU и как сэкономить 200 тысяч CPU в рекомендательном движке Рекламы. Посмотреть все выступления можно в плейлистах на ютубе или в VK Видео.
В этот раз мы ждём ваши доклады на такие темы:
🟢 Архитектура систем с AI/ML
🟢 Работа на стыке бэкенда с железом, в том числе глубокая оптимизация по использованию GPU, CPU, памяти, сети
🟢 Облачные и коммунальные решения, инфраструктура
🟢 Алгоритмы и подходы к решению практических задач
🟢 Хранение и стриминг данных
🟢 MLOps: деплой, эксплуатация, наблюдаемость и так далее
🟢 Любые другие темы, связанные с интересными челленджами на бэкенде
🔶 Отправить заявку на участие можно тут
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 305 |
| 13 |  💹 Как мы откатываем за секунду и не ломаем прод
Меня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за разработку систем деплоя. Платформа развёртывания входит во внутреннюю инфраструктуру компании, которая решает сложные задачи: от строительства дата-центра до IDE и код-систем.
🎙 В новом выпуске подкаста «В офисе» я объяснил, как устроена платформа, которая обслуживает все деплои Яндекса. Вот три кейса из этого разговора:
1️⃣ Концепция антихрупкости
Классический Kubernetes, Docker и OpenSSH не вывозят наши масштаб и требования, поэтому мы написали свой SSH. Это помогает нам находить выход из любой аварии и строить архитектуру таким образом, чтобы поломка одного приложения никак не влияла на весь пайплайн. Зачем? Чтобы любой наш сервис умел деградировать, а не падать.
И деградация одного никак не влияла на остальные.
2️⃣ Агентская часть деплоя
Система стала настолько сложной (стейт-машина, у которой было больше 17 переходов), что погружение нового разработчика в работу у нас занимало примерно год. Поэтому мы переписали логику на поведенческих деревьях — как в движке для ботов Unreal Engine.
Их можно переиспользовать и визуализировать, при этом сложность разработки упала в несколько раз, а новый инженер пишет код в продакшен уже буквально через две недели.
3️⃣ Роллбэки за секунду
Чтобы откатить докер-контейнер, нужно было заново его собрать, проинициализировать скрипты, переменные окружения и секреты. Это занимало много времени. Мы придумали механизм снапшотов. Контейнер, на который нужно откатиться, уже есть в системе: он собран, всё разархивировано, переменные окружения и секреты скачаны. Так что для отката остаётся только «исправить симлинк» и запустить ворклоуд.
🔶 В полном выпуске подкаста я также рассказал, как мы обеспечиваем стабильность сервисов, что сложнее всего реализовать в деплой-платформе и как сломать Яндекс Музыку 😄 А ещё объяснил, почему сервисы вообще падают. Полный выпуск подкаста — на ютубе.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 832 |
| 14 |  💻 Декомпозиция, автоматизация и 15 минут нагрузки
Меня зовут Дима Александров, я руководитель технических решений в Яндекс Лавке. За годы работы мне довелось плотно заниматься вопросами надёжности как в Еде, так и в Лавке. А недавно я составил стратегию надёжности, где зафиксировал майндсет и конкретный план действий.
Каждый деплой всегда сопряжён с рисками: можно сделать ошибку в коде, подтянуть бажную зависимость или неверно рассчитать нагрузку. Поэтому нужно системно повышать предсказуемость релизов.
Что мы для этого делаем:
🟢 Проводим автоматическое нагрузочное тестирование в CI. Перед каждой выкладкой мы запускаем его в изолированном load-окружении. Сервис должен поработать под полной нагрузкой хотя бы 10–15 минут. Этого достаточно, чтобы убедиться, что утилизация ресурсов и тайминги ответов не деградировали по сравнению с прошлым релизом
🟢 Запускаем end-to-end-тесты в продакшене. Мы регулярно проверяем capacity системы в целом с помощью нагрузочного тестирования в проде. Это помогает своевременно заметить нехватку запаса прочности или выловить кривой релиз
🟢 Тотально автоматизируем регресс. Если у вас много ручного тестирования, то ошибок из-за человеческого фактора не избежать. Единственный выход — автоматизировать 75–90% сценариев. Это даёт возможность гонять полный пакет регресс-тестов на каждый релиз
🟢 Декомпозируем изменения. Чтобы сократить шанс что-то внезапно сломать, мы разбиваем приложения на модули, уходим от монолитов на бэке и фронте, изолируем блоки
🟢 Управляем ресурсами автоматически. Система должна сама докидывать их, если обнаружила нехватку. А когда нагрузка спадает — перекидывать мощности, например, на аналитические вычисления
🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, какие два способа помогают снизить ущерб от любого инцидента. И объяснил, что помогает вовремя реагировать на множество алертов в сложной распределённой системе с кучей сервисов
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 546 |
| 15 |  +8🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузками
Спасибо всем, кто присоединился поговорить об инфраструктуре, платформах и observability. Было супер 🈯️
Делимся хайлайтами о том, как команда Yandex Infrastructure модернизировала строительство и охлаждение дата-центров, чтобы ускорить внедрение AI:
🟢 Концепция «кампус дата-центров». Для поддержания растущих нагрузок Яндекс изменил подход к размещению вычислительных мощностей. Теперь мы будем объединять независимые дата-центры с одной локацией в кампусы с общей внешней инфраструктурой. Это поможет оптимизировать энергопотребление и увеличить мощности в три раза до 180 МВт — рекорд для России.
🟢 Жидкостное охлаждение. Для его реализации наши инженеры разработали сайдкары — дополнительные стойки с жидкостно-воздушными радиаторами. До недавних пор мы использовали только фрикулинг — охлаждение воздухом. Сайдкары дополнят этот подход без масштабной реконструкции дата-центров. Сочетание двух технологий сделает терморегуляцию дата-центров эффективнее и ускорит адаптацию инфраструктуры к растущим нагрузкам наших сервисов и продуктов внешних партнёров.
🟢 Dev Cluster. Инструмент для динамического распределения GPU-ресурсов поможет разработчикам за несколько кликов настраивать конфигурацию контейнеров для любых задач без сложной настройки.
💹 Наши распределённые хранилища уже работают с эксабайтами данных, обеспечивая вам стабильные платформы разработки и деплоя. Теперь мы готовы к нагрузкам, которые ещё вчера казались предельными. Ждём новые фичи в YandexGPT и других сервисах! 🧠⚡️
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 440 |
| 16 |  🚗 Как мы связали бэкенд UMO 5 с телематикой автомобиля
На связи Миша Чарзавакян, руководитель разработки Яндекс Электро, и Лёша Косенко из Яндекс Авто. Хотим рассказать, как мы строили Connected Car для нового электромобиля UMO 5 с технологиями Яндекса.
Речь об удалённом управлении машиной: согреть салон зимой в минус 15, проверить состояние, отправить команды. Кажется, звучит довольно просто, но давайте заглянем под капот.
❇️ Как устроена телематика в UMO 5
У каждого современного автомобиля есть блок телематики, который отвечает за взаимодействие с внешним миром. Мы пошли не по пути прямой интеграции бэкенда с этим блоком, а сделали cloud-to-cloud. Наш бэкенд общается с сервером партнёра, а тот — уже с телематикой.
В обычной схеме это HTTP-трафик для получения состояния и отправки команд + Kafka для результатов команд, алертов и сообщений. И мы думали, что интеграция будет максимально тривиальная. Но нет.
❇️ Главная боль — Kafka
У партнёра развёрнут кластер Kafka из трёх инстансов. Когда наш бэкенд к нему подключался, Kafka возвращала список своих внутренних IP-адресов. А драйвер нашего бэкенда пытался подключиться к этим IP, но не мог, потому что это внутренняя сеть партнёра.
Мы не понимали, что с этим делать. В нашей команде вообще не было экспертизы в Kafka: в Городских сервисах она не используется.
❇️ Как решили проблему
Нам помог самый простой AI-промпт. В Kafka есть выделенный параметр advertised.listeners, который позволяет переопределять IP-адреса кластера Kafka. Мы попросили партнёра прописать на их стороне наши IP. И — о чудо! — всё заработало.
🔶 В полном выступлении мы также рассказали, что ещё есть под капотом электромобиля. Спойлер: там не только батарея 64 кВт/ч и мотор на 200 лошадиных сил 🙃 А ещё мы объяснили, как работает Алиса в UMO и почему она может это делать даже без интернета. Смотрите видео на сайте Городских сервисов, ютубе и в VK Видео.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 545 |
| 17 |  🏗️ infra.conf’26 уже сегодня: подключайтесь обсудить инфраструктуру, платформы и observability
Совсем скоро встретимся, чтобы поговорить о высоких нагрузках, инструментах, базах данных, надёжности, доступности, управлении инцидентами и особенностях эксплуатации инфраструктуры в эпоху ML.
Доклады начнутся в 11:00 мск. В программе:
🟢 Как управлять доступами к 1500 системам (и без бутылочных горлышек)
🟢 Зачем нужен механизм выгрузки метаданных объектов в S3 Inventory
🟢 Как освободить разработчиков от рутины с помощью агентов и Kubernetes-операторов
🟢 Что помогает перемещать десятки петабайт данных внутри S3
🔶 Полное расписание
Подключайтесь к трансляции на сайте конференции. Для тех, кто будет очно, дополнительно подготовили экспозону и несколько мастер-классов.
🈯️ До встречи на infra.conf’26!
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 476 |
| 18 |  🛎 Приглашаем на Vertis Java Meetup
Это встреча разработчиков и инженеров от Яндекс Вертикалей. Мы обсудим практический опыт, новые подходы, реальные задачи и пообщаемся с коллегами и единомышленниками в неформальной атмосфере.
Когда и где:
📆 18 июня, 18:00
📍 Екатеринбург, «Ельцин-центр»
В программе:
🟢 Как мы используем Temporal в Недвижимости. Герман Михайлов, бэкенд-разработчик в Яндекс Недвижимости, расскажет, как и зачем мы перешли с сервисов-scheduler’ов на Temporal. А также поделится, можно ли (не) построить космолёт на десятки тысяч workflow в секунду и во сколько обойдутся первоклассные наблюдаемость и отказоустойчивость
🟢 CGLIB, Spring AOP и нарушение гарантий JVM. Михаил Черноскутов, бэкенд-разработчик в Яндекс Путешествиях, разберёт реальный случай, где NullPointerException возник на final-поле с инициализацией new ConcurrentHashMap<>(). И расскажет, как Spring через CGLIB создаёт прокси, почему final-методы могут обойти AOP-перехват и что происходит с инициализацией полей при low-level-инстанциации
📟 А после докладов вас ждёт «Громкий вопрос»
Это интеллектуально-юмористическая игра из одноимённого интернет-шоу. Каждый участник должен правильно ответить на поставленный вопрос. Но есть нюанс: игроки друг друга совсем не слышат! 🤯
🔶 Зарегистрироваться на Vertis Java Meetup
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 225 |
| 19 |  +8🤩 Хотите узнать, о чём мечтали в детстве разработчики Яндекса?
Мы тоже хотели, поэтому ко Дню защиты детей наши бэкенд-разработчики заполнили виртуальные анкеты. Мы задали вопросы, чтобы узнать об их детстве, первой написанной программе и школьной оценке по информатике. Спойлер: пятёрок по информатике было много, а преподавателем так никто и не стал 😄
👩⚕️ Давайте вместе посмотрим страницы из анкет в карточках выше!
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 437 |
| 20 |  🚀 Делимся записями докладов с Backend Talks от Яндекс 360
Инженеры Яндекс 360 каждый день строят высоконагруженные отказоустойчивые и масштабируемые системы, которые выдерживают больше 1 000 000 RPS: Диск, Телемост, Почту и другие цифровые сервисы.
💹 16 мая в Москве прошла Backend Talks от Яндекс 360 — конференция о разработке, технологиях и будущем. Мы собрали больше 300 гостей офлайн и подготовили для них программу сразу в двух залах: с классическими докладами и воркшопами. А также обменялись опытом, обсудили реальные кейсы и поиграли в настолки.
О чём мы поговорили на конференции:
🟢 Направленный ациклический граф в PostgreSQL: как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей. Малик Минубаев, разработчик в B2B-платформе, рассказал, почему стандартные паттерны хранения иерархий не работают для ориентированного ациклического графа. А также сравнил несколько вариантов Closure Table с бенчмарками на реальной нагрузке
🟢 Как Яндекс Диск выдерживает сотни гигабит входящего трафика: устройство балансировки загрузок. Илья Абрамов, разработчик в Диске, разобрал, почему нам не подошёл подход «как у всех», и показал эволюцию алгоритма балансировки загрузок: от наивного Round-Robin до разработки собственного алгоритма
🟢 Как формировать технологический стек и не погибнуть в священных войнах: от хаоса к процессам и техрадару. Дмитрий Сафонов, руководитель команды разработки платформы микросервисов, рассказал, как строить стек для промышленной разработки и разрешать споры о технологиях. А также поделился опытом внедрения Техрадара в Яндекс 360
🟢 Зачем и как бэкендеру расти в карьере в 2026 году. Дмитрий Соломонов, руководитель группы B2B-разработки бэкенда Диска, рассказал, как развивать команду с помощью индивидуальных планов и выбора узкой специализации для разных уровней разработчиков. И поделился, как связать получение знаний с реальными задачами
🟢 Семь раз подумай, один раз пошардируй: как мы начали горизонтально масштабировать метаданные чатов Телемоста. Никита Звонарев, разработчик в Мессенджере, рассказал, что может предпринять команда, когда вертикально масштабироваться уже не получается, а сервису нужно функционировать дальше в условиях возрастающей нагрузки, и как при этом не устроить себе проблемы в будущем
🎙 Мы уже выложили записи докладов на ютуб и в VK Видео для тех, кто не смог посетить конференцию.
📷 А фотографии с мероприятия можно найти вот здесь.
🈯️ Спасибо, что были с нами на Backend Talks Яндекс 360
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 334 |
