Поговорили с&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 2024

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

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

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

Вас ждёт насыщенная программа днём, а&nbsp;также игры и&nbsp;нетворкинг вечером.
Регистрация уже открыта: регистрируйтесь на&nbsp;очное или онлайн-участие.

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

Иван Пузыревский

infra.conf 2025

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;инфраструктуре

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

Wi-Fi Марафон 2024

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

[Yandex Infrastructure](https://infra.yandex.ru/) — команда, которая создаёт и развивает внутреннюю инфраструктуру Яндекса — уже несколько лет проводит митапы DevPlatform Party (ex DevTools Party).

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

Очередной митап прошёл 26 февраля в офисе Яндекса в Москве и онлайн.


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

Сбор участников, завтрак

Киноут

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

Открытие трека

Поговорим про проблемы платформизации и&nbsp;автоматизации жизни разработчика/SRE-инженера в&nbsp;большой компании, посмотрим на&nbsp;опыт Яндекса, наши успехи и&nbsp;неудачи на&nbsp;этом пути, расскажем про внутреннее устройство нашей Internal Developer Platform (IDP).

Все дороги ведут в платформу

Перед нашей командой в&nbsp;SourceCraft поставили интересную задачу. С&nbsp;одной стороны, нужно сделать платформу, где мы&nbsp;даём пользователю набор из&nbsp;мощных инструментов. С&nbsp;другой стороны, мы&nbsp;должны быть уверены, что пользователь не&nbsp;сможет навредить себе или другим пользователям. Очевидно, что эти требования противоречивы. Если дать слишком много свободы&nbsp;&mdash; пользователи начнут стрелять себе (и&nbsp;другим) в&nbsp;ногу. Если усиливать ограничения&nbsp;&mdash; пользователи не&nbsp;смогут решать свои проблемы. Наш CI/CD&nbsp;&mdash; поиск баланса между этими двумя полюсами.

В&nbsp;докладе я&nbsp;расскажу:
&mdash;&nbsp;Как мы&nbsp;проектировали архитектуру, устойчивую ко&nbsp;внутренним и&nbsp;внешним атакам.
&mdash;&nbsp;Как мы&nbsp;оптимизировали работу системы сразу на&nbsp;уменьшение latency и&nbsp;увеличение throughput.
&mdash;&nbsp;Какие решения оказались удачными, а&nbsp;от&nbsp;каких пришлось отказаться.
&mdash;&nbsp;Как искали уязвимости с&nbsp;помощью пентестов.
&mdash;&nbsp;Как расшивали узкие места.
&mdash;&nbsp;Какие у&nbsp;нас планы на&nbsp;будущее.

Облачный CI/CD - 5-звёздочный отель для особо любимых пользователей

Вы&nbsp;когда-нибудь видели, как ML-инженер плачет в&nbsp;уголке от&nbsp;очередного падения инференса в&nbsp;проде? А&nbsp;DevOps-инженера, который внезапно осознал, что теперь его зовут не&nbsp;только когда падает кластер, но&nbsp;и&nbsp;когда &laquo;модель не&nbsp;учится&raquo;?
Мы&nbsp;построили ML-платформу, которая:
&mdash;&nbsp;прячет Airflow от&nbsp;гнева богов (и&nbsp;админов);
&mdash;&nbsp;превращает ML-сервисы в&nbsp;микросервисы, чтобы они наконец научились себя вести;
&mdash;&nbsp;а&nbsp;ещё&nbsp;&mdash; делает счастливыми ML-разработчиков (ну&nbsp;почти).
Приходите, расскажем, как мы&nbsp;выжили и&nbsp;даже получили фидбек, который не&nbsp;стыдно читать!

ML-платформа: зачем она нужна вам, нам и ML-инженерам

Кофе-брейк

За&nbsp;последние пару лет в&nbsp;рантайме Алисы появилось множество больших языковых моделей&nbsp;&mdash; и&nbsp;в&nbsp;рамках Алисы нового поколения, и&nbsp;в&nbsp;смарт-функциях на&nbsp;ТВ. При этом нагрузка на&nbsp;модели постоянно растёт: растёт число пользователей, усложняются задачи в&nbsp;погоне за&nbsp;качеством, модели становятся тяжелее. В&nbsp;таком сетапе стоимость инференса оказывается критичной. Расскажу, какие прикладные подходы по&nbsp;оптимизации мы&nbsp;пробовали, с&nbsp;какими проблемами столкнулись, какие варианты показали больше всего профита и&nbsp;чем можно воспользоваться, применяя доступные фреймворки для инференса. Доклад будет полезен всем, кто интересуется применением LLM&nbsp;в высоконагруженных сервисах.

Как мы оптимизировали инференс LLM в Алисе

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

Опыт эксплуатации Cluster API в Авито

Наши B2B-партнёры&nbsp;&mdash; это бизнесы. Одна из&nbsp;задач нашей инфраструктуры&nbsp;&mdash; обеспечивать их&nbsp;потребности. С&nbsp;другой стороны, мы&nbsp;тоже бизнес, у&nbsp;которого инфраструктура&nbsp;&mdash; большая часть расходов.
Как экономить на&nbsp;виртуальных машинах, сохранив стабильность&nbsp;&mdash; вот в&nbsp;чём вопрос.
В&nbsp;докладе я&nbsp;расскажу как мы&nbsp;используем VPA, HPA и&nbsp;ClusterAutoscaler для масштабирования приложений, что пришлось сделать, чтобы их&nbsp;подружить.

Масштабируем продакшн K8s во все стороны

Обед

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

Проектируем пайплайн обучения модели генерации видео

LEOPARD — Layered Exporter Of PyTorch with Automated Reporting and Diagnostics

Задача идентификации&nbsp;&mdash; вполне математическая проблема, решение которой помогает в&nbsp;создании полезных систем. В&nbsp;докладе расскажу про UUID (Universally Unique Identifier), математические, философские и&nbsp;инженерные вопросы, которые возникли при проектировании и&nbsp;переделывании этой технологии. Ещё немного расскажу про свой опыт реализации стандарта UUID&nbsp;v7, который был принят в&nbsp;ядро Postgres.

Новый UUID как первичный ключ в вашей базе данных

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

Afterparty

Яндекс x&nbsp;Акустика IT&nbsp;STAND-UP&nbsp;&mdash; стендап-проект и&nbsp;серия вечеринок, где ребята из&nbsp;IT на&nbsp;вечер превращаются в&nbsp;рок-звёзд и&nbsp;выступают с&nbsp;монологами о&nbsp;том, как они создают технологии и&nbsp;продукты.

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

Специальный эпизод проекта для конференции infra.conf: &laquo;Ну&nbsp;это&nbsp;же точно уже не&nbsp;повторится?&raquo;

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

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

Яндекс x Акустика IT STAND-UP. Специальный эпизод для infra.conf'25

Доклад о&nbsp;том, как использовать YDB для хранения аналитических признаков и&nbsp;разметок и&nbsp;быть счастливым.

Фичестор Городских сервисов Яндекса

В&nbsp;докладе расскажу про&nbsp;то, как мы&nbsp;в&nbsp;Диске переносили общие данные из&nbsp;нешардированного MongoDB в&nbsp;шардированный PostgreSQL. После переноса данных пользователей в&nbsp;шардированную&nbsp;БД у&nbsp;нас осталась часть данных про общие папки, которые было сложно изолировать внутри шарда пользователя. Спустя время общая&nbsp;БД не&nbsp;справлялась с&nbsp;нагрузкой: все операции перед выполнением должны сначала получить информацию об&nbsp;общих папках и&nbsp;только после этого начинать работать. Поэтому надо было дублировать информацию ближе к&nbsp;другим данным пользователей&nbsp;&mdash; в&nbsp;их&nbsp;шарды. Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода&nbsp;&mdash; у&nbsp;нас сотни миллионов пользователей, которые не&nbsp;должны были ощущать процесс перехода и&nbsp;не&nbsp;потерять доступ к&nbsp;своим данным. При этом было необходимо выкатывать изменения не&nbsp;сразу на&nbsp;100%, а&nbsp;частично, с&nbsp;возможностью в&nbsp;любой момент отключить функционал. При выкатке также нельзя было допустить downtime.

В&nbsp;качестве решения мы&nbsp;разделили данные так, чтобы гостям не&nbsp;приходилось ходить куда-то, кроме своего шарда, а&nbsp;для согласованности данных с&nbsp;владельцем общей папки мы&nbsp;применили паттерн &laquo;сага&raquo; и&nbsp;любое изменение происходило таким образом, чтобы данные были доставлены в&nbsp;три базы:
&mdash;&nbsp;к&nbsp;владельцу,
&mdash;&nbsp;к&nbsp;гостю,
&mdash;&nbsp;в&nbsp;общую MongoDB (для failback&rsquo;а).
Я&nbsp;подробно рассмотрю процесс записи в&nbsp;несколько инстансов&nbsp;БД без распределённых транзакций и&nbsp;миграцию с&nbsp;минимальными ограничениями для пользователей.

Танец на канате: миграция без остановок, или Как мы подружили Mongo и PostgreSQL

В&nbsp;этом докладе я&nbsp;расскажу, как мы&nbsp;выстраивали систему наблюдаемости в&nbsp;крупном e-commerce, используя опенсорс-решения OpenTelemetry, Qryn и&nbsp;Coroot.

Разберём наш путь:
&mdash;&nbsp;Почему отказались от&nbsp;Elastic APM, и&nbsp;почему Grafana Tempo не&nbsp;справился с&nbsp;нагрузкой.
&mdash;&nbsp;Как MinIO не&nbsp;выдержал объёма данных, переход на&nbsp;S3&nbsp;привёл к&nbsp;потере трейсов, а&nbsp;Qryn с&nbsp;ClickHouse помог решить проблему хранения.
&mdash;&nbsp;Как мы&nbsp;научились превращать трейсы в&nbsp;метрики с&nbsp;помощью VictoriaMetrics, построили дашборды в&nbsp;Grafana и&nbsp;вывели мониторинг на&nbsp;новый уровень.
&mdash;&nbsp;Как Coroot помог нам анализировать аномалии и&nbsp;быстрее разбираться с&nbsp;инцидентами.

Превозмогая опенсорс: опыт внедрения OpenTelemetry, Qryn и Coroot в ecom.tech

Стремительный рост использования средств контейнеризации поставил перед индустрией&nbsp;ИБ новые задачи и&nbsp;вызовы, сделав привычные инструменты неэффективными. За&nbsp;этим последовал рост решений на&nbsp;базе eBPF для обеспечения безопасности среды выполнения контейнеров. Одним из&nbsp;таких решений является Tetragon&nbsp;&mdash; компонент проекта Cilium. В&nbsp;рамках доклада будут рассмотрены вопросы разработки Tracing Policy с&nbsp;учётом полученной экспертизы в&nbsp;ходе работы над решением по&nbsp;обеспечению безопасности контейнеров.

Tetragon: лучшие практики и нюансы разработки Tracing Policy

Последние пять&nbsp;ли мы&nbsp;строим направление мобильной инфраструктуры. Мы&nbsp;прошли путь от&nbsp;саппорта сборки и&nbsp;Gradle-плагинов до&nbsp;своих полноценных сервисов, которые помогают инженерам решать ежедневные задачи. В&nbsp;докладе я&nbsp;расскажу, как мобильная инфраструктура усложняется: вокруг появляются новые системы и&nbsp;фреймворки, а&nbsp;разработчикам приходится разбираться во&nbsp;всё большем количестве технологий. Мы&nbsp;пройдём стадии развития инфраструктуры&nbsp;&mdash; от&nbsp;небольшого стартапа до&nbsp;крупной корпорации. Обсудим, почему задачи мобильной инфры отличаются от&nbsp;привычных DevOps/SRE, бэкенда и&nbsp;фронтенда. И, наконец, расскажу о&nbsp;самых больших и&nbsp;неожиданных вызовах, которые стоят перед нами сегодня.

Особенности мобильной инфры в бигтехе

Gosper — компонент контрол-плейна в нашем сторадже

Облачные расходы растут, а&nbsp;бюджеты&nbsp;&mdash; нет. Знакомо? В&nbsp;этом докладе я&nbsp;расскажу, как мы&nbsp;создали инструмент, позволяющий выявлять неэффективно используемые виртуальные машины в&nbsp;Yandex Cloud и&nbsp;оптимизировать затраты без ущерба для производительности.
На&nbsp;примере нашего решения мы&nbsp;поговорим о&nbsp;том, как собирать метрики использования ресурсов в&nbsp;облаке, анализировать загрузку vCPU и&nbsp;формировать конкретные рекомендации по&nbsp;оптимизации. Мы&nbsp;вместе посмотрим, как обычный отчёт в&nbsp;Excel превращается в&nbsp;интерактивную дашборд-систему, которая не&nbsp;только экономит ваши средства, но&nbsp;и&nbsp;помогает убеждать руководство в&nbsp;необходимости изменений.
Доклад будет полезен и&nbsp;инженерам, и&nbsp;тем, кто отвечает за&nbsp;бюджет на&nbsp;инфраструктуру. Вы&nbsp;узнаете, что такое осознанное потребление облачных ресурсов, а&nbsp;также почему оверпровижининг&nbsp;&mdash; это зло, с&nbsp;которым нужно и&nbsp;можно бороться.

Облачные технологии по приземлённым ценам: как мы оптимизировали затраты без ущерба для производительности

В&nbsp;Яндексе есть разные сервисы для управления инфраструктурой. Что-то позволяет провести диагностику сервера, что-то сконфигурировать сеть, а&nbsp;что-то поставить&nbsp;ОС на&nbsp;сервер. И&nbsp;все они работают сами по&nbsp;себе. Мы&nbsp;смогли не&nbsp;только подружить эти сервисы, но&nbsp;и&nbsp;создать продукт, позволяющий эффективно управлять тысячами выделенных серверов. В&nbsp;докладе расскажем, как с&nbsp;помощью Temporal и&nbsp;капельки магии мы&nbsp;научились выдавать серверы за&nbsp;15&nbsp;минут и&nbsp;сделали сервис для аренды baremetal-инфраструктуры.

Железный тетрис: собираем BareMetal из инфраструктурных сервисов

В&nbsp;ходе доклада рассмотрим, какие вообще бывают способы защитить свои операторы от&nbsp;невалидных или &laquo;плохих&raquo; с&nbsp;точки зрения бизнес-логики входных значений.
Пройдёмся по:
&mdash;&nbsp;CRD + CEL-валидации в&nbsp;них;
&mdash;&nbsp;валидации в&nbsp;коде оператора;
&mdash;&nbsp;валидации в&nbsp;виде хуков Kubebuilder (ака классические standalone-хуки);
&mdash;&nbsp;OPA/Kyverno/прочие admission controllers.
В&nbsp;итоге слушатель сможет составить собственную картину, когда лучше использовать те&nbsp;или иные фишки.

Враг не пройдёт — валидируем входные данные в CR для операторов K8s

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

infra.conf'25

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

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

Обмен опытом

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

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

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

В&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;многие другие.

Митап Yandex Infrastructure

Спикеры

Программа

Сбор гостей, регистрация, закуски и напитки

Приветствие участников, обзор Yandex Infrastructure

Жизнь в большом репозитории

Перерыв

Устройство сети Yandex Cloud

Транзакции в YDB между топиками и таблицами

Нетворкинг, еда и напитки

Другие мероприятия

infra.conf'25