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

Практические кейсы от&nbsp;спикеров из&nbsp;крупных компаний: Яндекс, Ozon Tech, Авито, Т1, Альфа-Банк, Selectel, СберМаркет и&nbsp;SberDevices, Тинькофф, Postgres Pro, Лаборатория Касперского и&nbsp;других. 

Над программой конференции работали ключевые разработчики и&nbsp;техлиды команды Yandex Infrastructure, многие из&nbsp;них с&nbsp;опытом в&nbsp;индустрии более&nbsp;15&nbsp;лет.

Олег Бондарь

Анастасия Абрашитова

Николай Пирогов

Ильдар Каримов

Антон Кортунов

Андрей Глазков

Евгений Антонов

Саша Галкина

Сбор гостей (завтрак)

Шина данных уровня Яндекса требует нестандартных решений. Расскажем о&nbsp;том, как появился сервис YDB Topics, рассмотрим его архитектуру, причины отказа от&nbsp;Kafka, применённые оптимизации. И&nbsp;в&nbsp;заключение, как мы&nbsp;сделали Kafka API в&nbsp;режиме serverless.

YDB Topics: история взаимоотношений с&nbsp;Kafka

Перерыв

В Ozon используют S3 для разных задач, начиная от хранения картинок товаров для каталога, заканчивая бекапом баз данных. Мы храним десятки петабайт данных и обрабатываем сотни тысяч rps.

С&nbsp;ростом объёмов и&nbsp;нагрузок нас перестали устраивать opensource решения, такие как Ceph с&nbsp;RGW. В&nbsp;докладе я&nbsp;расскажу с&nbsp;какими проблемами мы&nbsp;столкнулись и&nbsp;как пытались их&nbsp;решать. Как мы&nbsp;спроектировали собственную реализацию&nbsp;S3, выбрали базу для хранения индекса и&nbsp;встроились в&nbsp;существующую архитектуру Ozon для максимально прозрачного переезда.

Расскажу и&nbsp;о&nbsp;проблемах с&nbsp;которыми мы&nbsp;столкнулись на&nbsp;разных этапах: при разработке, миграции и&nbsp;эксплуатации на&nbsp;реальной нагрузке. А&nbsp;еще о&nbsp;том, где мы&nbsp;смогли получить хороший выигрыш по&nbsp;использованию дисков, а&nbsp;где профит оказался меньше, чем мы&nbsp;рассчитывали.

Собственная реализация S3&nbsp;поверх Сeph&nbsp;&mdash; как мы&nbsp;научились предсказуемо работать с&nbsp;индексом и&nbsp;экономить место при тех&nbsp;же гарантиях

В&nbsp;рамках доклада мы&nbsp;разберём дизайн хранилища DNS-данных Яндекса, построенного поверх YTsaurus: посмотрим, какие требования предъявляются к&nbsp;такому хранилищу, какие буквы из&nbsp;CAP нам понадобятся, и&nbsp;как с&nbsp;решением задачи помогает объектная база данных YTORM, построенная поверх YTsaurus.

DNS over YTsaurus: как устроено хранилище DNS-данных всего Яндекса

Не&nbsp;существует масштабной инфраструктуры, которая имеет только линейные зависимости, на&nbsp;деле они часто неочевидные и&nbsp;хитросплетенные. Это затрудняет выполнение и&nbsp;постановку рабочих задач, поэтому необходимо иметь четкое понимание о&nbsp;взаимосвязях внутренних компонентов, что подразумевает их&nbsp;визуализацию и&nbsp;прозрачность. Мы&nbsp;расскажем о&nbsp;реализации предоставления этой неотъемлемой составляющей.

Потребитель и&nbsp;железка. Где связь?

Перерыв (обед)

Зачастую внутренние продукты развиваются без оглядки на&nbsp;данные. Какими функциями продуктов разработчики пользуются, а&nbsp;про какие даже не&nbsp;слышали? Какие задачи занимают слишком много времени? Какие сценарии можно упростить, а&nbsp;к&nbsp;каким все привыкли? Можно вооружиться статистикой, приложить небольшое усилие и&nbsp;получить много счастливых разработчиков. На&nbsp;примере поиска по&nbsp;интранету Яндекса расскажу&nbsp;&mdash; как мы&nbsp;делали метрику счастья пользователя, зачем проводить АБ-эксперименты и&nbsp;к&nbsp;чему это привело.

Зачем нужна продуктовая аналитика внутренних сервисов?

Вас ждёт рассказ о&nbsp;предпосылках выстраивания промышленной инфраструктуры. В&nbsp;докладе:

* погружение в предметную область ML и MLOps, для тех, кто пока не сильно знаком с ними;

* как выглядит целевая архитектура и&nbsp;инфраструктура для неё;

* какие &laquo;узкие горлышки&raquo; есть в&nbsp;архитектуре и&nbsp;как их&nbsp;можно расширить;

* какие могут возникать сложности в&nbsp;реализации. Также спикер поделится практическими бизнес-кейсами.

Промышленная инфраструктура AutoReTrain в&nbsp;реалиях крупного банка

* Что может переиспользовать&nbsp;DS от&nbsp;заводских промышленных линий?

* В&nbsp;чём специфика конвейеров обучения и&nbsp;инференса?

* Где необходимый уровень понимания ML-кода для выбора инфраструктуры?

* Как подбирать конфигурацию вычислительной инфры под профиль ML-нагрузки.

Непреодолимая легкость повышения утилизации GPU: Allocation и&nbsp;Profiling обычного человека

Нагрузочные тесты занимают много времени, а&nbsp;сами запуски часто заканчиваются провалом и&nbsp;результаты выбрасываются в&nbsp;мусорное ведро. В&nbsp;этом докладе расскажу о&nbsp;том, как мы&nbsp;обжигались на&nbsp;особенностях OS&nbsp;Linux, подкручивали power saving процессора, написали свой демон привязки ядер, читали умные книжки по&nbsp;математической статистике и&nbsp;что у&nbsp;нас из&nbsp;этого вышло (или пока выходит).

Улучшаем качество нагрузочного тестирования подкручивая инфраструктуру

При работе с&nbsp;резидентными базами данных применяются различные способы оптимизации производительности. Некоторые из&nbsp;этих способов можно было&nbsp;бы привнести и&nbsp;в&nbsp;Postgres.

В&nbsp;докладе рассматриваются следующие темы:

1. Pointer swizzling. Поиск по&nbsp;первичному ключу проходит длинный путь бинпоиском по&nbsp;страницам B-деревьев, распаковывая IndexTuple, TID, перекладывая страницы в&nbsp;разделяемые буферы, и, наконец, данных HEAP. На&nbsp;этой не&nbsp;самой прямой дороже есть пара мест, где можно срезать.

2. Более подходящие для кэширования структуры страниц. Бинарный поиск может затрагивать меньше строк кэша, а&nbsp;сама страница может иметь колоночную структуру (Partition Attributes Across layout).

3. Более оптимистичный подход к&nbsp;блокировке shared buffers: чтение без блокировки, сброс результата в&nbsp;случае каких-либо изменений.

Трюки in-memory баз данных в&nbsp;традиционных СУБД

Каждый сетевой пакет желает знать две вещи: как попасть в&nbsp;дата-центр и&nbsp;как его покинуть. Путь его лежит через L3&nbsp;балансировщики, файерволы, декапсуляторы. Обслуживание этой базовой части инфраструктуры обладает своей спецификой. В&nbsp;докладе рассмотрим причины появления необходимости в&nbsp;стандартизации, а&nbsp;так&nbsp;же причины, по&nbsp;которым победил облачный подход. В&nbsp;финале сделаем своё облако с&nbsp;dpdk и&nbsp;попыткой преодолеть кучу проблем монолитной инфраструктуры.

Как удобно жить на&nbsp;железе в&nbsp;2К24 базовой инфраструктуре

Обычно виртуальные машины используются в&nbsp;качестве нод кластера Kubernetes, но&nbsp;что если их&nbsp;поменять местами? И&nbsp;начать использовать платформу Kubernetes для запуска виртуальных машин наряду с&nbsp;обычными контейнерами. Машинами с&nbsp;различными операционными системами, еще и&nbsp;на&nbsp;отличающихся архитектурах. В&nbsp;каких случаях это может быть полезно? На&nbsp;каких технологиях это будет работать и&nbsp;как виртуальные машины будут интегрированы в&nbsp;экосистему Kubernetes?

Спикер расскажет возможные решения для запуска тестовых стендов с&nbsp;виртуальными машинами. А&nbsp;также покажет возможную интеграцию с&nbsp;сервисами из&nbsp;мира Kubernetes. И&nbsp;наконец про трансформацию платформы тестирования в&nbsp;Yandex Cloud.

Виртуальные машины в&nbsp;Kubernetes: как и (главное) зачем?

Service Mesh&nbsp;&mdash; это паттерн построения сетевого межсервисного взаимодействия, набравший популярность с&nbsp;распространением микросервисной архитектуры и&nbsp;ростом числа сервисов, которым надо общаться по&nbsp;сети. Типичный Service Mesh состоит из&nbsp;двух частей: Control Plane&nbsp;&mdash; сервис, отвечающий за&nbsp;построение карты сети, и&nbsp;Data plane&nbsp;&mdash; чаще всего, это sidecar proxy, принимающий конфигурацию с&nbsp;Control Plane и&nbsp;непосредственно отвечающий за&nbsp;обработку запросов к&nbsp;сервису и&nbsp;от&nbsp;него.

В&nbsp;Плюс Фантехе мы&nbsp;строим Service Mesh под названием Buckyball. Мы&nbsp;реализовали свой собственный Control Plane на&nbsp;основе k8s для хранения спецификаций узлов сети и&nbsp;построения единой карты. На&nbsp;Data plane мы&nbsp;используем Envoy в&nbsp;качестве sidecar proxy, а&nbsp;также нашего демона buckyball_d, который взаимодействует с&nbsp;Control Plane, реализует внутренний протокол Service Discovery, а&nbsp;также протокол XDS для динамического обновления конфигурации Envoy.

Наша цель&nbsp;&mdash; реализовать на&nbsp;уровне Service Mesh основные требования к&nbsp;сетевому взаимодействию между сервисами: балансировка трафика, межсервисная аутентификация, end to&nbsp;end TLS, observability и&nbsp;reliability, и&nbsp;многое другое. Мы&nbsp;тесно интегрированы с&nbsp;системой Infrastructure as&nbsp;Code, развиваемой в&nbsp;Яндексе, что позволяет нам подключать сервисы всего несколькими строчками YAML&nbsp;конфигурации. При этом все связи между сервисами декларативны, хранятся в&nbsp;репозитории и&nbsp;живут одной жизнью с&nbsp;кодом самих сервисов.

В&nbsp;настоящее время Buckyball активно внедряется в&nbsp;Яндекс Музыке, Кинопоиске и&nbsp;Сказбуке, а&nbsp;так&nbsp;же пилотируется в&nbsp;нескольких других сервисах Плюс Фантеха, и&nbsp;даже за&nbsp;его пределами.

One mesh to&nbsp;rule them all: история внедрения Service Mesh в&nbsp;сервисах Плюс Фантеха

На&nbsp;дворе уже середина 2024 года и&nbsp;мы&nbsp;все чаще слышим об&nbsp;использовании инструмента Cluster API для управления жизненным циклом Kubernetes кластеров. Наша команда тоже не&nbsp;стала исключением и&nbsp;перешла с&nbsp;использования собственной обвязки вокруг RKE и&nbsp;Terraform на&nbsp;него (и&nbsp;даже написала парочку своих infra провайдеров).

В&nbsp;ходе доклада затронем следующие темы:

* Откуда вообще взялся RKE и&nbsp;причем тут terraform?

* В&nbsp;какой момент решение изжило себя, каких проблем хотелось избежать в&nbsp;чудесном новом мире?

* Покомпонентно сравним старый и&nbsp;новый процесс управления кластерами.

* Рассмотрим те&nbsp;новые фичи, которые привнес с&nbsp;собой CAPI.

Внедрение ClusterAPI&nbsp;&mdash; стоит&nbsp;ли овчинка выделки?

Микросервисная архитектура в&nbsp;действии. Гибкая адаптация пот техническую задачу. Заказчик ставит новые требования, архитектура готова к&nbsp;вызовам. Управление on-prem решением через призму DevOps-практик и&nbsp;инструментов. Примеры Update, Backup/Restore, Scale in/out, Scale up/down. Насколько далеко может зайти разработка&nbsp;ПО в&nbsp;парадигме DevOps и&nbsp;Agile. Строили SaaS решение, использовали типичные SDLC процессы и&nbsp;практики. Собрали on-prem коробку, добавили в&nbsp;неё инструменты и&nbsp;процессы. Получилась автономная фабрика ПО + CI/CD, которой может управлять администратор.

CI/CD кунг-фу в&nbsp;онпреме. Поставка ПО&nbsp;в&nbsp;окружение заказчика вместе с&nbsp;CI/CD процессами из&nbsp;коробки (на&nbsp;примере SaluteJazz)

В&nbsp;докладе расскажу о&nbsp;специфике тестов в&nbsp;Kaspersky, и&nbsp;почему пришлось писать свою автотестовую систему. Поделюсь общими терминами и&nbsp;расскажу о&nbsp;том, как наша система исполняет тесты. Поговорим о&nbsp;разных типовых (и&nbsp;не&nbsp;очень) сценариях использования, а&nbsp;также о&nbsp;некоторых технических деталях эксплуатации.

Собственная автотестовая система Hive

Локальное окружение&nbsp;&mdash; это боль. Часто&nbsp;ли вы&nbsp;слышали фразу &laquo;у&nbsp;меня локально все работает&raquo;? DevOps культура научила нас схлопывать окружения для прода, пре-стейбла, тестирования. Или делать их&nbsp;идентичными. А&nbsp;как&nbsp;же Dev окружения? Что если&nbsp;бы мы&nbsp;имели возможность стандартизировать&nbsp;их? Dev окружение должно быть единым&nbsp;и, возможно, близким к&nbsp;проду. Ремоутная разработка имеет ряд проблем в&nbsp;стабильности. При чём&nbsp;же здесь Managed DevEnv или среда разработки как сервис? Расскажем про плюсы и&nbsp;минусы, возможности Codenv. Поделимся историями успеха.

DevEnv как сервис

Из&nbsp;доклада вы&nbsp;узнаете:

* существует ли разница подходов классического DR & Cloud Native DR;
* что скрывается за HA и почему это не DR;
* что такое disaster avoidance;
* основные стратегии восстановления в Cloud;
* Cloud Agnostic как следующий шаг disaster avoidance.

Современный мир Cloud Native и подходы к его аварийному восстановлению

Аварии случаются у&nbsp;всех. Иногда это небольшие инциденты. Иногда большие и&nbsp;страшные.

Каждая такая авария&nbsp;&mdash; это стресс для инженеров и&nbsp;пользователей.

Мы&nbsp;решили сделать &laquo;оружие последнего шанса&raquo;&nbsp;&mdash; fallback систему, позволяющую прикрыть Авито закешированным всем.

В&nbsp;докладе мы&nbsp;рассмотрим:

* дизайн такой системы;

* проблемы, с&nbsp;которыми мы&nbsp;столкнулись в&nbsp;ходе реализации;

* подходы к&nbsp;обеспечению качества такого кеширования;

* подходы к&nbsp;масштабированию;

* метрики успешности.

Static-Fallback

Инженерные истории  
со&nbsp;смыслом. Всё&nbsp;про&nbsp;создание  
инфраструктуры и&nbsp;эксплуатацию  
высоконагруженных систем

infra.conf

Алексей Башкеев

Развитие инфраструктуры&nbsp;&mdash; бесконечный процесс. Мы&nbsp;15&nbsp;лет делаем фундамент из&nbsp;технологий, на&nbsp;которых работает весь Яндекс, используем лучшие инженерные практики, понимаем их&nbsp;плюсы и&nbsp;минусы. Нам есть чем поделиться с&nbsp;сообществом&nbsp;и, конечно, чему научиться у&nbsp;других.  
Поэтому мы&nbsp;решили создать площадку для обмена опытом с&nbsp;экспертами из&nbsp;компаний, которые решают похожие задачи. Именно так появилась конференция infra.conf.

infra.conf&nbsp;&mdash; всё про создание инфраструктуры и&nbsp;эксплуатацию высоконагруженных систем

Yandex Infrastructure

Новости команды, статьи, анонсы мероприятий и&nbsp;многое другое

Telegram-канал

Собираем IT-специалистов, обмениваемся опытом и&nbsp;лучшими практиками

Чат в&nbsp;Telegram

Приглашаем разработчиков, сетевых инженеров, DevOps и&nbsp;SRE специалистов, а&nbsp;также всех, кому интересны open source продукты&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure в&nbsp;Новосибирске.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса.

Поговорим про систему контроля версий Arc, сервисы платформы для работы с&nbsp;данными (YDB)&nbsp;&mdash; таблицы и&nbsp;топики. А&nbsp;также про особенности сборки и&nbsp;тестирования в&nbsp;монорепозитории большой компании.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Митап Yandex Infrastructure

Приглашаем backend разработчиков, DevOps и&nbsp;SRE инженеров на&nbsp;Yandex Infrastructure Meetup в&nbsp;Екатеринбурге.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса. Поговорим про приватное контейнерное облако, использование простаивающих ресурсов во&nbsp;внутреннем облаке Яндекса и&nbsp;про YTsaurus&nbsp;&mdash; платформу для обработки и&nbsp;хранения больших данных.

Помимо докладов запланирована нетворкинг-сессия&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Приглашаем backend разработчиков, сетевых инженеров, DevOps и&nbsp;SRE инженеров, а&nbsp;также всех, кому интересны open source продукты Яндекса&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса.

Поговорим про устройство сети Yandex Cloud, Nirvana&nbsp;&mdash; вычислительную платформу Яндекса, а&nbsp;также про использование технологии SRv6.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Приглашаем разработчиков бэкенда, инженеров DevOps и&nbsp;SRE на&nbsp;митап Yandex Infrastructure в&nbsp;Минске.

На&nbsp;встрече расскажем, как мы&nbsp;создаём и&nbsp;развиваем платформу для разработчиков Яндекса.

Поговорим про систему контроля версий Arc, сетевую инфраструктуру Yandex Cloud и&nbsp;сервисы платформы для работы с&nbsp;данными (YDB)&nbsp;&mdash; таблицы и&nbsp;топики.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Приглашаем разработчиков, DevOps и&nbsp;SRE специалистов, а&nbsp;также всех, кому интересны open source продукты&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure в&nbsp;Нижнем Новгороде.

Расскажем, как мы&nbsp;создаём и&nbsp;развиваем внутреннюю инфраструктуру&nbsp;&mdash; фундамент из&nbsp;продуктов и&nbsp;технологий, которые помогают разрабатывать, деплоить и&nbsp;эксплуатировать все основные сервисы Яндекса.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

DevPlatform Party

Nexthop

Приглашаем разработчиков, SRE и DevOps инженеров на митап команды Yandex Infrastructure в Санкт-Петербурге.

Расскажем, как мы создаём и развиваем внутреннюю инфраструктуру - фундамент из продуктов и технологий, которые помогают разрабатывать, деплоить и эксплуатировать все основные сервисы Яндекса.

Помимо докладов запланирована нетворкинг-сессия с едой и напитками – для знакомства, ответов на вопросы и неформального общения.

Участие бесплатное, но необходима регистрация.

Митап Yandex Infrastructure в Санкт-Петербурге

Я.Субботник — технологическое мероприятие, основная аудитория которого — разработчики и технические специалисты. 
 
17 февраля команда Yandex Infrastructure провела очередную встречу, посвящённую инфраструктуре.  

Рассказали, как в Яндексе создают и развивают внутреннюю инфраструктуру, которая помогает разрабатывать, деплоить и эксплуатировать сервисы компании. Поговорили про подходы и сложности построения инфраструктуры, про устройство сети Yandex Cloud, монорепозиторий, опенсорс-продукты YDB и YTsaurus, стораджи и многое другое. 


Я.Субботник по&nbsp;инфраструктуре

Core Infrastructure Bootcamp

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

Приём заявок на выступление уже открыт — будем рады видеть вас в качестве спикеров!

Ключевые темы:
- Platform engineering — создание и поддержка инфраструктуры и платформ для эффективной разработки и разработчиков. Собственные vs вендорские решения
- DevOps-практики и культура, включая DevNetOps и DevSecOps
- Эксплуатация систем: управление конфигурациями, SRE, доступность, отказоустойчивость, мониторинг, логирование, наблюдаемость систем, тестирование, безопасность
- Аппаратное обеспечение, умные устройства 
- Базы данных и хранилища
- Инструменты коллаборации, разработка и эксплуатация
- Инфраструктура и аналитика ML

Принимаем заявки до 1 апреля. С ответом вернёмся не позднее 10 апреля.

По любым вопросам, пожалуйста, пишите Саше Галкиной: galkinaal@yandex-team.ru / tg @nu_saash.


Конференция Яндекса по инфраструктуре — Приём докладов закрыт

Yandex Platform Engineering Bootcamp

Трансляция ежегодной конференции в области беспроводных и Wi-Fi технологий.
Присоединяйтесь к [чату мероприятия](https://t.me/ekahau_rus).

Wi-Fi Марафон 2024

Playbutton. Конференция о технологиях стриминга

Поговорим про балансировку нагрузки, инфраструктуру для сетевой автоматизации, автоматическую выкладку конфигурации в многовендорной сети, топологию Dragonfly, BGP- и BMP-коллекции, CDN и DNS, безопасность и многое другое.

Больше 20 докладов, плотно упакованных в два зала, и море места для общения.

Обмен опытом

Техническая зона, посвящённая Annet — основному инструменту сетевой автоматизации в Яндексе. Берите с собой ноутбуки — будем «пачкать» руки.

Мастер-классы

Классика конференций — продолжаем общение, атакуем докладчиков вопросами.

Afterparty

В&nbsp;этом году будет два трека докладов: Enterprise Networks и&nbsp;Common Network Topics

Открытие конференции

Bonjour, Annet. О зоне мастер-класса

Перерыв. Распределение по залам.

В докладе расскажу об IP-роутинге в фабрике дата-центра, построенного в топологии Dragonfly+, также известной как Megafly. Поговорим про мотивацию: почему мы вообще решили этим заняться.

IP-роутинг в сетях дата-центров, построенных в топологии Dragonfly

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

Актуализация конфигураций: мультивендорный рок-н-ролл

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

Кластеризация stateful-устройств

С первой конференции nexthop в 2018-м, когда был представлен доклад «Балансировка нагрузки в Яндексе: проблемы роста от зарождения и до наших дней», прошло шесть лет. За эти годы многое изменилось: инфраструктура балансировки переехала на новый dataplane на DPDK (YaNET), задачи управления конфигурациями решает L3 Manager, а все изменения в dataplane балансировки происходят в лучших традициях CI/CD, без участия человека.
Из выступления вы узнаете, как мы к этому состоянию пришли, какие неожиданные проблемы ждали нас на пути и как мы их решали. Расскажу об особенностях планирования ресурсов для большого динамичного парка клиентов. Поговорим о том (спойлер!), почему хорошая система L3/L4-балансировки не всегда полезна и что мы планируем с этим делать в ближайшем и отдалённом будущем.

Балансировка нагрузки в Яндексе: новые проблемы роста

В докладе расскажу, какие проблемы возникли при имплементации протокола BMP у разных вендоров, как мы решили их у себя и как это повлияло на архитектуру сервиса.

Мониторинг фабрики EVPN с помощью BMP

Обеденный перерыв

Ретроспективный доклад об истории развития DNS в инфраструктуре Яндекса. Расскажем, какой путь проделали системы DNS: от классического подхода в далёком прошлом до высокопроизводительных решений DNS XDP и BPF-программ в настоящем. Обсудим, какие идеи были заложены в конструкции, как они менялись и какие задачи решались. Не последнюю роль в этом играли (и играют) инциденты. Полученный (горький) опыт, выявленные ошибки построения таких схем определяли вектор развития. DNS, являясь системой с непредсказуемым паттерном нагрузок, требует многократного запаса устойчивости и соответствующих методов. В конце доклада мы представим реализации нескольких таких методов: DNS BPF-изоляция классов запросов и DNS XDP-оффлоад.

DNS: история и развитие в инфраструктуре Яндекса

Никто не любит менять коней на переправе, однако в нашем случае это был вопрос не выбора, а скорее выживания проекта как такового. При этом выбор был не в виде «выберите лучших», а в формате «найдите лучших из худших». Наша история о том, как в безвыходной ситуации был пройден путь по доведению EVPN-VXLAN-фабрики ЦОД на базе WhiteBox + SONIC от состояния «не работает ни в каком виде» до уровня «работает, и даже под нагрузкой». Эта тема так или иначе актуальна для всех, кто переходит на импортозамещённые решения по построению сетей ЦОД.

Искусство поедания кактуса, или Как мы строили фабрику в современных условиях

В докладе рассмотрим: 
 - Роль сети в Yandex Cloud: сеть — это связующее звено, которое объединяет все сервисы
 - Network Load Balancer: один из базовых сетевых сервисов — экспресс-обзор архитектуры
 - Почему возможностей для горизонтального масштабирования уже недостаточно
 - Отказ от использования ядерного TCP/IP-стека: зачем это нужно и что взамен
 - Выбираем способ доступа: TUN/TAP, DPDK, Netmap, eBPF/XDP
 - Трудности на пути к успеху: с какими сложностями нам пришлось столкнуться
 - Что же получилось в итоге: посмотрим на результаты.

История об одном RnD, или Как мы бустили проверки здоровья в Network Load Balancer

Архитектура сетевых сервисов гибридных облаков в Yandex Cloud

- Почему Anycast’а недостаточно, для того чтобы отправить пользователя на ближайший к нему сервер с контентом?
- Зачем нам активный мониторинг сети со стороны клиента?
- А на чём обучать модель? 
- И когда стоит остановиться?

Я отвечу на эти вопросы и заодно расскажу, как работал CDN в VK, как сейчас работает VK CDN (да, это другое!) и почему в будущем нас ждёт Big Data и нейронки.

Поймай меня, если сможешь! или Как пользователи с операторами связи мешают работе CDN

BGP-данные нужны, BGP-данные важны. Но как их доставить до приложения? Да ещё и в реальном времени? Или получить состояние маршрутизации для заданного времени в прошлом в рамках ретроспективного анализа? В этом докладе я расскажу, как в Яндексе реализованы сбор и обработка данных маршрутизации, и покажу, как их можно использовать на примере обнаружения BGP-аномалий.

BGP и BMP коллекции

Закрытие конференции

Перерыв. Распределение по залам

«Во всем виновата сеть»?
Как вообще измерить правильность работы сети? В докладе расскажу, как регулярно проверять корректность работы сети при помощи спецификации и технологии формальной верификации. А также разберем, какие задачи решает верификация:
- построить пути прохождения трафика с учетом L2, L3, FW, VPN и NAT;
- проконтролировать сегментирование сети на зоны безопасности;
- обнаружить петли коммутации/маршрутизации;
- и многое другое.

Как проверить, что сеть работает правильно: формальная верификация

Доклад посвящён вопросу, ставшему уже, по сути, философским: писать свой SDN или адаптировать решение из опенсорса? Расскажу о том, бывают ли проблемы в SDN, не связанные с высокой нагрузкой, а также поделюсь опытом эксплуатации различных решений по виртуализации сетей в приватных облачных средах. Вы услышите историю о том, как усилиями совсем небольшой команды можно создать собственный безагентный механизм SDN, который решает проблемы с консистентностью OpenFlow-правил, обладает механизмом «самовосстановления», крайне полезным для миграций и обновлений, а также расширяет функционал файрвола и позволяет создавать по-настоящему изолированные оверлейные сети поверх IPSec.

SDN в приватных облачных средах

Расскажу, как наша команда развивает свою автоматизацию управления конфигурациями, как борется с дрейфом конфигурации на сети и как можно попробовать повторить наше кунг-фу дома с помощью открытого менеджера конфигураций Annet.

Annet, у нас diff, возможно, unsafe, по коням! Автоматизация конфигурации сети в облаке

В докладе рассмотрим: 
- Что общего у офисной и out-of-band-сетей
- Ключевые элементы внешней связности кампусной сети
- FreeBSD в качестве роутера (и всего остального)
- Историю отношений инфраструктурной сети и сети дата-центров: полученный опыт, декаплинг сетей и планы развития.

Внешняя связность инфраструктурных сетей Яндекса

Обзор возможностей компактного инструмента для технических специалистов, занимающихся построением и обслуживанием сетей передачи данных и Wi-Fi-сетей.

WLAN PI. Инструмент инженера

Рассказ про особенности сети в нашем кластере и про то, как мы решали связанные с ними задачи.
 - Разнородность сетапов (ДЦ, IX, NOC-room)
 - Особенности Яндекса: IPv6, HBF
 - Как решали задачи с использованием опенсорс-тулов.

Сеть в кластере K8s-сервисов сетевой инфраструктуры

Поговорим о фреймворке ААА и о стеке протоколов, применяемых в корпоративных (проводных, беспроводных, VPN) сетях связи для авторизации доступа сотрудников, неуправляемых устройств, гостей. Рассмотрим MAB и 802.1х, варианты EAP, интеграцию с PKI и доменом. Отдельно посмотрим на гостевой доступ к Wi-Fi на предприятии и BYOD. Обсудим отказоустойчивость, безопасность и атаки, пути развития технических решений: профилирование, двухфакторную авторизацию и т. д. Расскажем о доступных на рынке ААА-системах. Доклад будет сопровождаться примерами настройки оборудования различных вендоров, дампами фреймов и скриншотами интерфейсов.

Авторизация в корпоративных сетях связи

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

Выбор NGFW в 2024 году: как мы в Точке тестировали разные решения

Ни одна хакерская атака не обходится без сетевого взаимодействия, и трафик зачастую нам может дать гораздо больше ответов об ИБ-инциденте, чем многие думают. Иногда он даже и надежнее, чем другие способы (хостовые) анализа угроз. 
Я покажу на схеме инфраструктуры, как чаще всего выглядит цепочка атаки. А затем на её примере разберу различные способы анализа трафика с их плюсами и минусами. Кроме того, поговорим про роль ML, зачем нужно хранить сырой трафик и как анализ для целей ИБ может выручить ИТ.

Трафик как источник правды: сетевой анализ для выявления угроз

В своём докладе я поделюсь опытом Яндекса в задаче организации и поддержания Wi-Fi сети для своих сотрудников. Эта задача включает в себя множество различных аспектов: от планирования сети — до выбора её архитектуры и обеспечения безопасности. Кроме того, важно, чтобы сети строились быстро, были гибкими — с учётом возможных будущих изменений. 

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

Wi-Fi в Яндексе

BGP и BMP коллекции. Трансляция из Большого зала

Конференция  
по_сетевым_технологиям

Москва  
и_онлайн

Enterprise networks

Network security

Enterprise Wireless

Common Network Topics

nexthop

Сайт Yandex Infrastructure

Хабр

YouTube

и&nbsp;чат

2018

2019

2020

2021

2022

2023

Как это было

Ошибка

Команда Yandex Infrastructure создаёт и&nbsp;предоставляет внутреннюю инфраструктуру Яндекса&nbsp;&mdash; фундамент из&nbsp;продуктов и&nbsp;технологий, на&nbsp;базе которого тысячи инженеров разрабатывают, деплоят и&nbsp;эксплуатируют основные сервисы Яндекса: Поиск, Такси, Маркет, Алису, Кинопоиск и&nbsp;многие другие.

Мероприятия