Доклады

Как повысить безопасность своего кода при помощи чистых функций? Подойдет ли Go для любителей «функциональщины»?

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

В докладе обсудим разные типы функций, «чистоту», посмотрим на ФП-код с точки зрения производительности, тестируемости и поддержки.

Разработчикам довольно часто хочется переписать легаси-проект по красоте. Неизменно возникает вопрос: а «по красоте» — это как? Для ответа на этот вопрос прибегают к помощи широко известных подходов «Чистая Архитектура», «Гексагональная Архитектура» и «Предметно Ориентированное Проектирование (DDD)».

Но так ли просто переписать проект, следуя этим подходам на Go? Как язык может в этом помочь и как он может мешать? А, возможно, Go не так уж хорош для реализации сервисов с чистой архитектурой и DDD, а Rust, несмотря на свою «низкоуровневую природу», наоборот, подходит лучше?

С этими вопросами мы постараемся разобраться на докладе с высоты нашего практического опыта рефакторинга сервиса на Go.

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

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

Профессия разработчика быстро эволюционирует, а скрипт собеседований, кажется, не успевает за этой эволюцией. Зачем мы пишем на собеседованиях одинаковые задачи с литкода, рассказываем теорию про отличие тредов и горутин, и как работает garbage collector (будто бы собеседующий сам знает ответ)? Почему на каждом втором собеседовании просят спроектировать сокращатель ссылок? Почему вроде стараешься, вкладываешься, а зарплату повышают коллеге, который больше нравится продакту?

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

Бонус: задачи для собеседований, которые не решает ChatGPT, и матрица компетенций для оценки своего уровня.

WebAssembly (WASM) представляет собой виртуальную машину, предназначенную для выполнения высокопроизводительного кода, написанного на различных языках программирования, не только в браузере, но и в других средах. Хотя WASM изначально разрабатывался для веб-приложений, его потенциал выходит далеко за пределы браузеров, открывая новые возможности для создания кросс-платформенных приложений и сервисов.

Golang стал одним из первых языков, поддерживающих WASM, и в настоящее время занимает одно из ведущих мест среди языков с хорошей поддержкой этой технологии. В данном докладе мы сосредоточимся на внебраузерных применениях WASM, обсудим, как правильно подготавливать Go-приложения для запуска в WASM-рантайме, а также рассмотрим сложности, с которыми сталкиваются разработчики. Мы уделим внимание подводным камням, связанным с интеграцией Go с WASI (WebAssembly System Interface), и обсудим текущие вызовы, мешающие разработчикам компилятора Go поддерживать актуальные стандарты и расширять функциональность вне браузера.

Мы в Т-Банке активно используем Go в качестве языка для разработки ML-приложений. В этом докладе мы поговорим про backend-часть, ведь ML не заканчивается на обучении. Мы не будем говорить о том, как устроены модели, чаще всего для backend-разработчика они являются «чёрными ящиками», строительными блоками, такими же как очередь или база данных. Но реальное ML-приложение, такое, например, как система распознавания речи, синтеза речи или голосовой биометрии — это несколько моделей + бизнес-логика. Также для разных запросов может потребоваться разный набор моделей, поэтому ML-приложение имеет нестандартную архитектуру.

В докладе мы:
* вспомним, что такое пайплайны;
* почему ML-приложение можно представить как пайплайн из моделей;
* напишем небольшое приложение на примитивах языка без использования дополнительных библиотек;
* напишем небольшое приложение на нашей собственной библиотеке;
* обсудим, какую пользу мы получили в команде от использования собственной библиотеки пайплайнов.

Когда нам приходится работать в многоядерных системах, где доступно значительно больше ядер, чем привычные 4 или 8, то стандартные подходы и даже стандартная библиотека могут не обеспечивать достаточной производительности. Поговорим о том, как в таких условиях выжимать максимум из доступного CPU.

Из доклада вы узнаете:
* почему и когда стоит шардировать работу с atomic-значениями и с map;
* зачем нужны такие алгоритмы, как biased locking for reader writer locks;
* что такое оптимистичное чтение и когда его можно использовать.

Мы также рассмотрим протокол MESI, работу кэша CPU и способы его эффективного использования.

Часто ли вы сталкивались с необходимостью при чтении чужого пулл-реквеста переходить в полноценную IDE, потому что в веб-платформе не хватает нормальной навигации по коду? А задумывались, откуда эта проблема и как её решить? Расскажем о том, как подошли к решению этой задачи в новой платформе для разработчиков SourceCraft от Яндекса.

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

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

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

Расскажу, как можно ускорять код, используя абстрактный ассемблер Go. Разберу часто используемые SIMD-инструкции, покажу, как можно пользоваться инструкциями, которые не поддержаны из коробки, затрону gccgo и Cgo. Приведу и разберу примеры программ.


Подготовительные материалы:
https://www.youtube.com/watch?v=KINIAgRpkDA
https://habr.com/ru/companies/badoo/articles/317864/ (дублирующая статья)
https://habr.com/ru/companies/vk/articles/358088/
https://go.dev/doc/asm

Когда мы начали заниматься фаззингом в Go, готовых решений не существовало — нам пришлось стать первопроходцами и разрабатывать всё с нуля. Сегодня наш опыт служит основой для других команд в YADRO.

В своём докладе я поделюсь лучшими практиками по выбору и настройке инструментов фаззинга для Go. Рассмотрю неочевидные проблемы и дам полезные советы, которые не найти в открытых источниках. После выступления вы сможете легко писать и запускать фаззинг-тесты для ваших продуктов, а не только для учебных задач. Приходите узнать, как сделать фаззинг неотъемлемым элементом вашей разработки на Go!

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

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

Расскажем о задаче (CDN на Go).
* Почему на Go.
* Кратко: как оно работает?
** упирались в Х — решили так.
** упирались в Х2 — решили так

Уперлись в TLS — стали терминировать hitch, но и в него уперлись.

Тут поговорим кратко о том, как, чем и зачем его можно терминировать. Почему стандартный Go не справился, и почему решили «править» его, а не уйти с Go вообще (но думали).

Собственно, тут и будем говорить по гошный TLS и TLS вообще, как он работает, какие способы есть его «прокачать».

Как итог, с «и 40 Gbps — уже боль», мы отдаем 100 с достаточно старого железа.

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

В докладе мы подробно разбираем работу шедулинга горутин и устройство моста между Go и С/С++. Слушатели узнают, как мы отслеживаем аллокации памяти и сопрягаем данные между языками.

Задумывались ли вы когда-нибудь о том, что такое мьютексы и атомики на самом деле? И как они устроены под капотом? И зачем вообще нужны, если формально при записи переменной эта запись условно атомарна? Или не совсем?

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

Доклад посвящен основам механической симпатии: как работа процессора с памятью и кэшем отражается на производительности Go-приложений. Обсудим важность принципов локальности и методы оптимизации представления данных. Рассмотрим метод оптимального обмена информацией между горутинами с учётом конкурентности в многоядерных системах и согласованности кэша. Разберемся, как проектирование кода с учетом архитектуры процессора может дать ускорение до 30% без значительных изменений кода.

CGо — это мощный и удобный инструмент, позволяющий вызывать любые функции на C/C++, не опасаясь блокировки своей Go-программы. Однако за это удобство приходится расплачиваться в случае неблокирующих вызовов, таких как асинхронные операции в ядре ОС или числодробительные задачи (сжатие/распаковка, криптография, математические расчеты и т. д.).

Помимо накладных расходов на каждый вызов C, нас также может ожидать неожиданная просадка производительности при обработке больших объемов данных. Кроме того, использование CGо может привести к потере гарантий на время исполнения горутин.

В докладе мы разберем случаи, когда CGо может негативно сказаться на производительности проекта. Обсудим, как Go внутри своего рантайма «экономит» на неблокирующих вызовах, как мы можем использовать эти механизмы, а также рассмотрим другие обходные пути.

В докладе будут рассмотрены ключевые аспекты авторизации и причины платформизации этого решения. Мы обсудим, зачем нужна авторизация и какие преимущества даёт платформенный подход к управлению доступом. Уделим внимание сравнению двух моделей авторизации — RBAC (ролевая) и ABAC (атрибутивная), а также их применению в разных сценариях.

Далее мы разберём различные подходы к реализации авторизации, начиная от хардкода и заканчивая использованием декларативных языков, таких как CEL и Rego. В заключение будет рассмотрен процесс организации платформы контроля доступов: как осуществляется генерация политик, интеграция клиентов и проверка доступов к ресурсам.

Конкурентность в Go открывает широкие возможности, но также и представляет риск «выстрелить себе в ногу» — от обращения горутин к одним и тем же данным до проблем с work-stealing. В этом докладе мы рассмотрим, как дополнить и расширить идеи из выступления Роба Пайка по конкурентности в Go.

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

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

В своем докладе я сравню разные инструменты для генерации моков интерфейсов в Go. Возьмем наиболее популярные генераторы моков: Mockery, Gomock, Minimock — и посмотрим на практических кейсах плюсы и минусы каждого из них по сравнению с аналогами, удобность и сложность использования, а также бестпрактис по написанию юнит-тестов с моками. И попробуем ответить на вопрос, какой же мокер самый лучший?

В мире микросервисов часто возникает необходимость сделать согласованные изменения в разных сервисах. На докладе будет рассмотрен один из подходов — сага.

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

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

Temporal набирает популярность, и большие компании чаще начинают его использовать для решения своих задач. Довольно частый кейс использования — это процессинг заказов и платежей, чуть реже — сборка и деплой сложных релизов, еще реже — специфичный бэкенд для чат-бота. Но сегодня я хочу посмотреть чуть шире на Temporal и предложить его для реализации MVP, когда вместо сервисов мы используем только Temporal Workflow.

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

* Обсудим, зачем в Go добавили новый и весьма нетривиальный функционал — итераторы, также называемый range over funcs.
* Посмотрим на бенчмарки: быстрые ли итераторы? Быстрее каналов или медленнее?
* Как их использовать, где могут быть полезны, в чем была мотивация их добавлять в язык.

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

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

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

Дизайнеры — люди, от которых меньше всего ждут вклада в Open Source, и зря!

Моя любовь к доступным продуктам и продуктовый подход позволили создать уникальную и успешную историю. У маскота языка Go изначально отсутствовала мимика, был скудный набор изолированных иллюстраций и неудобная лицензия. Сейчас Free Gophers Pack хорошо знаком многим гоферам и широко используется в комьюнити.

Расскажу, как появился и развивался проект, чем мне помог продуктовый подход и почему к Open Source имеет смысл привлекать не только тех, кто умеет кодить. А также почему я сменила лицензию и как это все помогает котикам.

Мы рассмотрим в докладе три основные стратегии работы с gRPC в WEB-разработке: gRPC-Web, Buf Connect и gRPC-Gateway. Обсудим их ключевые преимущества и недостатки, а также проведем детальное сравнение производительности с помощью бенчмарков на базе k6. В завершение мы поделимся экспериментальными подходами для улучшения производительности gRPC-Gateway, включая использование кастомных маршаллеров и оптимизаций на уровне генератора.

У нас было три монолита на PHP, по 180 минут на выкатку каждого, 30 минут на обновление наличия товара на сайте, полсервиса на Go и PHP, множество джоб всех сортов и расцветок, а также Docker, Cobra, целая куча репозиториев в GitLab, пинта чистого Kubernetes и Terraform. Не то чтобы это был необходимый арсенал для разработки, но если начинаешь собирать удобный деплой, становится трудно остановиться. Единственное, что вызывало опасение, — это сервисная архитектура. Нет никого более беспомощного, безответственного и испорченного, чем разработчики и архитекторы, пытающиеся определить границы предметных областей и не создать новый монолит при распиле старого. Но мы знали, что рано или поздно окунемся и в это.

Чаще всего мы, как Gо-разработчики, пишем всевозможные микросервисы. И уже давно все привыкли, что управляет ими некий монстр под названием Kubernetes. Он автоматически переподнимет наш упавший под, поможет скалировать сервис и многое другое. А что кубер не делает автоматически, то по старинке делается ручками.

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

А что сегодня используется для написания операторов? В подавляющем большинстве случаев это будет kubebuilder или operator-sdk, и оба используют библиотеку kubernetes-sigs/controller-runtime как основу.

Доклад посвящен обзору внутреннего устройства библиотеки controller-runtime, пониманию тонкостей функционирования отдельных её частей и их влиянию на разработку Kubernetes-операторов. Знание внутренних механизмов позволит иначе взглянуть на вопросы оптимизации производительности и повышения надежности операторов, построенных на базе CR.

В рамках доклада расскажу про:
* компоненты controller-runtime — Manager, Controller, Reconciler, Client и другие, их связь и внутреннее устройство;
* жизненный цикл контроллера, механизм доставки уведомлений и др.;
* подводные камни и грабли, которые могут встретиться при разработке операторов, варианты их обхода и способы оптимизации.

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

В своём докладе я поделюсь историями и открытиями из своего опыта, начиная со студенческих лет и заканчивая настоящим временем. Расскажу о том, что мне зашло, и о моментах, в которых стоит «подстелить соломку».

Ежедневно платформа умного дома Sber обслуживает сотни тысяч открытых долгоживущих соединений с устройствами пользователей, чтобы обеспечивать опыт управления устройствами в реальном времени 24/7. Характер такой нагрузки существенно отличается от привычного в вебе паттерна «запрос – ответ», что формирует определенную специфику проектирования и сопровождения такого бэкенда. Примерно год назад мы прошли долгий путь, состоящий из инцидентов и улучшений, об этом и будет доклад.

В этом докладе расскажу:
* как понять, что текущая система перестает устраивать;
* как выбрать подходящие инструменты и научиться сравнивать их;
* как готовить приложения на Go и работать с профилировщиками нагрузки;
* как выглядит инфраструктура api-gateway за пределами приложения;
* с какими проблемами можно столкнуться и как их обнаружить.

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

Давайте узнаем!

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

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

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

Сделаем «живое» демо нагрузочного тестирования Valkey, Redis, Memcached, PostgreSQL, MySQL и, может быть, ещё чего-нибудь, если успеем.

В Авито у нас несколько тысяч микросервисов, десятки команд разработки и единая платформа, на основе которой делаются все наши микросервисы. Из доклада вы узнаете, как наша команда ArchGovernance помогает разобраться во всём этом архитектурном хаосе и позволяет найти ошибки в архитектуре при помощи инструмента arch-rater.

Я расскажу:
* как мы обрабатываем 5 миллионов трейсов;
* как строим карту взаимодействия между нашими микросервисами и какие инструменты для этого используем;
* какие способы анализа этой карты мы используем, чтобы находить проблемы в архитектуре и повышать надёжность.

Картинки — это часть поиска Яндекса, работающая с визуальным контентом и обрабатывающая более 10 000 тяжёлых запросов в секунду с помощью десятков тысяч CPU в рантайме. Мы расскажем, как, столкнувшись с необходимостью масштабирования сервиса, с помощью ML в сочетании с архитектурными изменениями смогли не только увеличить пропускную способность в ~2 раза на том же железе, но и дать инструмент для более гибких продуктовых внедрений.

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

Гибридный поиск — это сочетание классического полнотекстового поиска и векторного поиска. Я расскажу, как мы в Т-Банке внедряли гибридный поиск, какие проблемы пришлось решать и какой результат мы получили.

Наш поиск реализован на базе OpenSearch. Для улучшения полноты поиска мы реализовали отдельный сервис векторного поиска на базе векторной БД Qdrant. В докладе я затрону следующие темы: что такое векторный поиск, что такое векторные БД, какую проблемы мы хотим решить с помощью векторного поиска, как векторный поиск устроен у нас, как смешивать результаты полнотекстового и векторного поиска.

API Gateway — широко распространённая технология, которую применяют многие компании. Каждый делает это по своему и закладывает разный функционал в него.

В этом докладе я расскажу, какой API Gateway создали мы в Авито, что в него заложили, какие подходы применили.

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

В Яндексе для этого разработали собственное решение - AppHost.

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

Расскажу, как контент в KION попадает в рекомендации, на персональные витрины, как мы разрабатывали ТВ-витрину. А еще про самые интересные бизнес-правила и как редакция помогает растить смотрение.

В KION есть элемент «блендер». Он формирует витрину, используя разные источники, применяет свыше 50 бизнес-правил, и все это — быстрее, чем за 300 мс для каждого запроса. При этом рекомендации и витрины формируются максимально релевантные пользователю. Например, просмотренный фильм больше не покажется на витрине. Или если пользователь несколько раз не реагирует на постер фильма, витрина предлагает ему другой, чтобы пользователь с большей вероятностью обратил внимание на тайтл. Все это строго персонально и очень быстро.

В связи с ростом количества клиентов и объема трафика VK Рекламы увеличивается объем данных в системе и потребление аппаратных ресурсов, поэтому повышается вероятность возникновения проблем. Чтобы снизить риски потерь в этих условиях, необходимо заниматься оптимизацией архитектуры сервиса и заранее позаботиться о том, как резко не деградировать при возникновении нештатных ситуаций с использованием принципа graceful degradation.

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

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

Devhands.io — R&D-центр, который активно занимается корпоративным обучением. Как бэкендеру расти в «хайлоад»? Можно ли, вообще, изучать темы «large-scale and performance» и как? Поделимся нашим взглядом, опытом и кейсами.

Distributed-101: что же такое распределённые системы без «зауми». Eventual consistency, CAP-теорема и PACELC-классификация простыми словами, их влияние на развитие разработки больших нагруженных проектов.

Технология WebAssembly (Wasm), вопреки распространенному мнению, с момента создания подразумевала возможность использования на бэкенде. Помимо браузеров, Wasm активно используется для плагинов/расширений в качестве полезной нагрузки в облаках/контейнерах, для переносимых компонентов ПО, и даже для смарт-контрактов в блокчейне.

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

Feature Platform — новый взгляд на решение типовых задач из мира ML-разработки. Я расскажу, из каких компонентов состоит платформа и что стоит учитывать при ее проектировании, проанализирую рынок, сформулирую свои требования к системе на основе на прикладной задачи и соберу MVP на основе конкретных возможностей.

Цифровой банк — это десятки продуктов, сотни сервисов, тысячи команд и десятки тысяч людей, которые 24/7 что-то проектируют, разрабатывают, тестируют, катят в прод или, наоборот, откатывают с прода, включают и выключают фичи, делают бэкапы и миграции, и это не считая интеграций, за фасадом которых происходят вещи и похуже. Как обеспечить надежность услуг для пользователя в таком муравейнике? Грамотно проектировать? Да. Применять GitOps, канарейки, нагрузочные тесты? Тоже да. Круглосуточные дежурства SRE-инженеров и даже разработчиков? Без этого никуда! Но всё это лишь части общей картины, которая много-много больше.

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

В Яндексе много различных сервисов, и каждый из них представляет большой интерес не только для людей, но и для роботов. Роботный трафик, в первую очередь, создаёт излишнюю нагрузку на сервис, что может привести к нарушению его работоспособности или вовсе к отказу. Не всегда задачей робота является скачать информацию с ресурса. Робот (или даже целый ботнет) может совершать злонамеренную атаку с целью положить сервис — DDoS.

Много лет в Яндексе существует система «Антиробот», призванная защищать сервисы от DDoS-атак и парсинга. Это один из самых высоконагруженных сервисов в Рунете по количеству обрабатываемых запросов в секунду.

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

Мобильные платежи давно стали неотъемлемым атрибутом нашей жизни. На докладе расскажем о том, как устроена платформа мобильных платежей - сердце мобильных платежей «Мир». С какими трудностями и проблемами приходится сталкиваться и как их решаем.

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

TrafficSoft — российский разработчик высокопроизводительных сетевых решений для дата-центров и телеком-операторов. Сегодня наши продукты обслуживают миллионы абонентов и обрабатывают десятки терабит трафика в России и за рубежом.

Наша история началась в 2014 году с R&D-проекта: мы поставили перед собой цель создать софт, способный заменить проприетарные сетевые решения для обработки трафика в сетях операторов связи. Взяли за основу Open Source-приложение L3fwd из DPDK, сделали первые нагрузочные тесты и разработали прототип нашего первого продукта — CGNAT. Это положило начала созданию нашей платформы, способной в будущем претендовать на звание «Сетевой операционной системы».

В докладе я расскажу о том, как эволюционировала архитектура нашего софта: от L3fwd, то есть полного ее отсутствия, до полноценной программной платформы, построенной на событийно управляемой архитектуре с собственными Scheduler, TCP-стеком и гибкими возможностями в сфере debug, на базе которой сейчас работают все наши продукты.

Расскажу о том, как в погоне за производительностью, гибкостью и масштабируемостью в условиях жесткой конкуренции и постоянного отсутствия времени, мы достигли сотен миллионов PPS и миллионов CPS и RPS в наших продуктах. И о том, как, казалось бы, самые хорошие идеи разбивались о стену неидеальной реальности мира hardware.

В последнюю чёрную пятницу у нас в Wildberries было около миллиона RPS в поиске и рекомендациях товаров. И эти запросы обслуживает меньше тысячи серверов.

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

* Программа лояльности в НСПК - что это.
* Как было сначала (MVP).
* Как рассчитать кешбэк:
** за 30 секунд,
** иногда за год,
** для всех.
* Как выплатить кешбэк (ну или забрать его назад).
* Что будет дальше.

Юридические, фактические, почтовые — адреса везде. Без адреса курьер не доставит заказ еды. Разбираемся, как правильно готовить адрес в системе любого масштаба. Почему Озон привозит заказ к калитке моего дома, а Я.Маркет так не умеет.

В логистическом агрегаторе ДоставИМ моя команда проделала большой путь решения проблем с адресами, разработав до этого крупнейшую в РФ адресную базу — на нём мы впервые поняли, что из 1000+ активных клиентов почти столько же кастомных адресных баз, а у самих доставщиков ситуация не лучше.

Расскажу о том, как мы учились мэтчить адреса, подключались к платным публичным сервисам и разочаровывались в них, выходили за рамки РФ, учили страшные слова типа ЦХДПА, КЛАДР и ФИАС, как нерешаемую за год задачу решили за один спринт и что из этого я определённо готов затащить в архитектуру новой системы и рекомендовать тебе.

Бонусом в конце поделюсь крутым решением, которое уже несколько лет не может доехать до РФ, но точно когда-нибудь будет в ДоставИМ 2.0.

Что обсудим? Сначала посмотрим на карту развития бэкенд-программиста от мидла до эксперта. Её можно использовать как для составления плана на обучение, так и для быстрой проверки «зон роста» (в том числе тех зон, которые нужно подтянуть как для перехода на новый «уровень», так и для прохождения интервью — а часто это разные зоны).

Затем обратимся к тем, кто собирается менять работу или находится уже в процессе поиска.

Поговорим о следующем:
* Как, вообще, понять, менять работу или нет?
* Обсудим типовые ошибки, которые совершают программисты на разных этапах:
- составление резюме: формат, фокус и почему (и когда) это до сих пор важно, нужны ли референсы и сопроводительные письма;
- от общения с рекрутером до общения с будущим руководителем;
- прохождение coding sessions;
- прохождение architecture (system design) sessions.
* Как можно было бы классифицировать компании, чтобы понять — компания «нормальная» или нет.
* Какие вопросы задать себе, чтобы понять, чего вы хотите сами, и в зависимости от этого сформировать список вопросов для компании, чтобы понять, ваша это компания или нет.
* Ну и, если успеем, поучаствуем в спецолимпиаде: какой трек выбрать, IC или EM?

Очевидно, что в современном мире разработки ПО без метрик будет непросто. Метрики помогают нам понять, как живут наши сервисы. А для того, чтобы собирать, хранить и анализировать метрики, нужен инструмент. В Т-Банке такой инструмент — это observability-платформа Sage, в которую собирается телеметрия всех сервисов банка.

Подсистема метрик Sage за 4 года прошла несколько витков эволюции.

В своем докладе я расскажу:
* как мы прошли путь от Prometheus до кластерной Victoria Metrics cо сроком хранения метрик до 1 года;
* как несколько сбоев вскрыли наши проблемы и стали триггером к следующем витку эволюции наших подходов;
* как мы адаптировали пайплайн записи и поиска метрик при постоянном росте количества записываемых временных рядов;
* какие знания мы получили о кластерной Victoria Metrics и на какие ее метрики мы обращаем внимание в первую очередь.

Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему метрик.

Аббревиатура WASM всё чаще встречается в описании совершенно различных продуктов — от браузеров до ядра Linux.

Разберёмся, как появилась эта технология, какие задачи она пыталась решить изначально, и какие задачи перед ней стоят сейчас. Посмотрим на внутреннее устройство и актуальные реализации. Затем попытаемся встроить WASM в angie и обсудим, какие проблемы при этом возникают, и попытаемся понять, как надо проектировать такие интерфейсы.

В заключение посмотрим в будущее и обсудим компонентную модель WASM-приложений.

1. Зачем нам проезжать 1 млн километров каждую ночь в симуляторе?
2. В чем отличие Open Loop- и Closed Loop-симуляций и зачем они?
3. Как мы сделали одновременно детерменированное и многопоточное исполнение пайплайна на базе ROS.
4. Как мы запускаем распределенную симуляцию в YTsaurus.

Виртуальную сеть в облаке часто сравнивают с кровеносной системой человека, которая доставляет до сервисов сетевые пакетики, словно кислород до клеток. В 2015 году основа этой «кровеносной системы», которую мы использовали — Software-Defined Network (NSX) перестала развиваться и затем поддерживаться VMware. Кроме этого, к прежнему решению были вопросы по части производительности и надёжности.

Мы решили перейти на Оpen Source-решение OVN, и в докладе я расскажу обо всех этапах этого перехода: от предпосылок, выбора и тестирования нового решения до исправления багов в его коде.

В результате мы смогли смигрировать все инфраструктуры клиентов облака в 3 Availability Zone’ах в новый SDN «на лету», решить проблемы производительности и открыть дорогу новым фичам в сети.

Какие артефакты архитектуры необходимы нам в компании? А какие они вообще бывают и сколько их? А как с ними потом работать и не страдать? Знакомые вопросы?

Мы хотели бы поделиться нашим опытом организации архитектурных артефактов в масштабах экосистемы. Рассказать о том, как мы использовали на практике «Enterprise Architecture on a page», что применили из описанных артефактов, как их связали и что автоматизировали с помощью систем.

Если вы думаете, что финтех — это исключительно о банках, подумайте еще раз. Этот «монстр» проник во все сферы: e-commerce, e-grocery, betting и многое другое. И даже если вы меняете компании, вы все равно оказываетесь в том же самом бесконечном круге финтеха. Почему? Давайте разберемся вместе!

За годы работы в этом домене я столкнулась с одной и той же архитектурной реальностью, которая не просто надоедает, а вызывает ненависть. Финансовые институты существуют с древних времен и, как любой древний механизм, они опираются на веками выработанные подходы и правила. Эти правила — основа стабильности и понятности, независимо от границ, языков и законов. Но как в любом древнем механизме, хотелось бы в финтехе перестать встречать один и те же «немного поломанные» решения.

В этом докладе я не просто выскажу свои недовольства. Я на примерах покажу, где именно финтех «ломает» и почему. Но главное — мы не остановимся на жалобах. Мы рассмотрим решения, которые помогут превратить «финтеховою» ненависть в НЕискреннюю любовь.

Приготовьтесь к веселому и динамичному путешествию по миру финансовых технологий! Без уныния, но с песнями (но точно без танцев)!

В этом докладе я расскажу о том, как мы перепроектировали систему управления товарными данными и почему результаты эволюционного развития наших сервисов перестали нас устраивать. В условиях, когда у нас более миллиарда товаров, рост объемов данных превратил горизонтальное масштабирование в настоящую проблему. Я расскажу, какие архитектурные решения могут устранить эти трудности и чем сможет помочь централизованное хранилище, в частности, какие задачи оно должно решать, а каких точно избегать. Также расскажу о взаимодействии сервисов в новой архитектуре, выборе СУБД и сложностях, с которыми мы столкнулись при реализации. Отдельное внимание уделю процессу миграции: как перейти на новую схему без сбоев в работе. Наконец, расскажу, что у нас получилось в итоге.

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

Мы вместе пройдем путь эволюции системы, позволяющей находить копии видеоконтента: от прототипа до production-ready-решения, использующего Java/C++, низкоуровневую работу с ffmpeg, нейросети (libtorch), FAISS с IVF-индексами на GPU. Рассмотрим ключевые проблемы, с которыми мы столкнулись: многопоточное декодирование видео и снятие отпечатков, размеры и масштабирование индексов, квантизация, повышение точности работы алгоритма матчинга.

Летом этого года мы выпустили обновленную программу лояльности СберСпасибо для 80 млн клиентов. Чтобы сделать программу прозрачнее, мы перевели взаимодействие с пользователями в режим реального времени, что увеличило нагрузку на системы в десятки раз.

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

И всё это для того, чтобы и вы могли уверенно делать запуски любых масштабов!

Часто ли вы задаетесь вопросом, как работают лифт, стиральная машина или… светофор? Кажется, что это достаточно простые системы, однако зачастую это далеко не так.

Данный доклад посвящен закулисьям разработки с нуля сложной системы управления светофорными объектами Москвы. Я расскажу, как мы прошли путь длиной в три года, применяя Go, Postgres, NATS, K8S, ML, чтобы получить готовую АСУДД.

Перколятор (percolate queries) — функциональность, позволяющая реализовать обратный поиск. Перколятор давно существует в ElasticSearch и OpenSearch, а недавно был добавлен в Sphinx, используемый в Авито.

В своем докладе я расскажу о том, как работает перколятор в Sphinx, чем он отличается от решения в ElasticSearch, за счет чего получился довольно быстрый и, самое главное, разберем как «обычный» практический кейс для сохраненных поисков на большом масштабе, так и несколько «необычный» кейс для поиска соответствия в потоке разнородных JSON-данных.

Расскажу, что такое YTsaurus и как он работает на примере задачи симуляции езды автономного транспорта:
* как устроена map-reduce-операция в YTsaurus;
* какие есть подводные камни, влияющие на скорость симуляции;
* как быстрее читать входные данные;
* как оптимальнее доставлять код приложения.

А также покажу, какие еще есть способы уменьшить общее время симуляции.

Этот доклад — первое публичное представление современной архитектуры национального видеохостинга RUTUBE. Покажу техническую начинку и характеристики видеоплатформы и поделюсь предпосылками архитектурных решений:
* устройство видеохранилища (и это не S3 — расскажу почему);
* видеобалансер для петабайтов контента;
* CDN на сотни узлов.

Познакомлю с продуктовым ландшафтом: кто нас смотрит, откуда (по данным Mediascope), и как работает воспроизведение видео. А главное — что у нас изменилось после замедления YouTube, и будем ли мы пересматривать архитектурные и инфраструктурные подходы.

«Яндекс Лавка» сейчас состоит примерно из 100 микросервисов, которые поддерживают различный функционал: цикл заказа, каталог, поиск, промокоды, пуши, скидки, инструменты поддержки, платежи. На базе этих технологий мы решили построить модульный SaaS-продукт, способный динамически настраивать необходимый функционал для каждого партнера без кратного роста команды разработки.

В этом докладе расскажем, как:
1. выбирали синглтенант или мультитенант;
2. выбирали признак, по которому изолировать наши микросервисы, и учились с ним жить;
3. разделяли конфигурации и эксперименты между B2C- и B2B-направлениями;
4. научились разворачивать наши инсталляции в различных контурах;
5. сократили время развертывания нового клиента от нескольких месяцев до недели и теперь стремимся к 1 дню;
6. какие боли перенесли и какой опыт вынесли.

В апреле мы запустили новую Алису, в которую внедрили большие языковые модели. В своем докладе я расскажу, что потребовалось изменить в нашем ассистенте, чтобы заставить Алису думать по-новому.

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

Посмотрим, что получилось в итоге, что можно улучшить и почему мы все еще это не сделали.

Кто не встречался с самыми крупными распродажами года — на Черную пятницу, Новый год или гендерные праздники? В это время продавцы стараются сделать свои товары максимально привлекательными, а покупатели — урвать по выгодной цене. На самом деле, это происходит не только в периоды крупных ретейл-поводов. Акции на маркетплейсах — важный инструмент работы с ценами в любое время года.

Яндекс Маркет — сервис для выбора и покупки сотен миллионов товаров от сотен тысяч продавцов. В высокий сезон здесь совершается более 800 заказов в минуту, а больше 80% из них — по акциям.

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

Одним из наиболее распространенных способов запуска веб-приложений на языках PHP, Python и Ruby является связка nginx и сервера приложений, которыми чаще всего выступают php-fpm, gunicorn, unicorn, uwsgi, puma и подобные или даже Apache в этой роли.

У такого способа есть ряд существенных недостатков:
* необходимость правильно настраивать и поддерживать работоспособность ещё одного компонента в инфраструктуре, а то и нескольких;
* ошибки сопряжения и отсутствие мониторинга со стороны nginx рабочих процессов приложения напрямую, что приводит в итоге к 502-504-ошибкам при возрастании нагрузки, которые частенько видят посетители;
* дополнительные накладные расходы на обмен данными между nginx и приложениями снижают производительность и масштабируемость.

Мы занимаемся внедрением возможности запуска процессов приложений непосредственно в nginx в рамках Angie — его главного обратно совместимого форка, разрабатываемого бывшей командой разработчиков nginx. При этом это будет простая и полноценная замена упомянутых выше связок с простой конфигурацией и без необходимости вносить какие-либо изменения в код приложений.

Поговорим про преимущества такого подхода и посмотрим на результаты бенчмарков, которые обещают быть интригующими.

Перед некоторыми сервисами спустя время встаёт задача быстро релизить свои ресурсы, например, новые версии ML-модели или шарды поисковой базы. Задача сложна тем, что пользовательский процесс может долго перезапускаться из-за десятка гигабайтов нетривиального состояния в памяти, и релиз даже мегабайтного ресурса окном на сотни подов может затянуться на часы. Всё усложняется тем, что система должна быть надёжной — нужно предусмотреть как минимум отказ источника ресурсов, проблему некорректной версии ресурса и откат на стабильную версию.

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

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

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

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

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

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

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

У нас была железка с ксеоном и 48 ядрами, PostgreSQL с одиссеем, MySQL, Memcached и Redis со множеством клонов, а также redis-benchmark, xwrk и k6. Не то чтобы это был необходимый запас для исследования. Но если начинать бенчмаркить — трудно остановиться. Единственное, что вызывало у меня опасение, — это k6. Нет ничего более беспомощного, безответственного и испорченного, чем писать сценарии на javascript. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Мы взяли Xeon Gold 24/48C 128GB RAM и при помощи напильника исследовали «деградацию» перформанса самых последних версий «классических» компонентов СУБД (PostgreSQL, MySQL) и кэшей (Redis, Valkey, DragonFly, Memcached) на read-only-нагрузке. Будет много latency-throughput-диаграмм, на основе которых мы выясним, кто сможет «вытянуть» миллион RPS, с каким latency, для какого числа одновременных соединений.

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

Про выделение микросервисов из монолита рассказывали много, но у каждого свой путь, в докладе расскажем про наш.

От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven-архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.

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

В докладе Алексея вы узнаете:
* какая бывает архитектура нагрузочного софта и почему одни утилиты медленные, а другие очень быстрые;
* какие параметры можно и нужно менять при проведении нагрузочного тестирования;
* что такое coordinated omission и как с ним бороться;
* почему именно latency/throughput-диаграмма, а не число RPS является основной характеристикой и «паспортом» сервиса;
* какую опасность таят в себе «перцентили» и как их нужно использовать;
* особенности и демо wrk2/wrkx (выжмем 100K+ из какого-нибудь сервиса).

Вы хотите использовать Apache Kafka в своих системах? А может быть, уже это делаете? Мы — да и много, но местами мы ее используем не только как систему обмена сообщениями, но и как хранилище данных. Это хорошо или плохо? Удобно или только боль? На эти вопросы я отвечу в своем докладе, расскажу, в каких вариантах мы используем Kafka, поведаю историю, как мы столкнулись с проблемами бэкапа данных из Kafka и как решали их на 400 сообщений в треде в мессенджере.

Чтобы вы не допускали ошибок в использовании Apache Kafka, мы сделали это за вас, и я расскажу об этих ошибках.

Через A/B-эксперименты принимается огромное количество внедрений в Яндексе, поэтому процесс анализа метрик стоит на критическом пути.

На больших объемах данных классические подходы расчета метрик A/B через MapReduce дают большие задержки — часы и дни.

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

Все клиенты Т-Банка могут выйти с сотрудником на связь по видеозвонку — это важная часть нашего процесса обслуживания. С помощью видеосвязи мы надёжно аутентифицируем клиентов на чувствительных операциях и доверительно общаемся с SME и private-клиентами.

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

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

* Изучим вертикальное и горизонтальное расширения кластера Пикодата;
* научимся делать бэкап и восстановление кластера;
* разберем наиболее часто встречающиеся проблемы эксплуатации и методы их решения.

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

В этом докладе мы посмотрим на возможности, которые дают WebAssembly-рантаймы вне браузера. Я расскажу про опыт внедрения WASM-рантайма в Tarantool, про встреченные на этом пути сложности и про то, как WASM позволил научить сервер приложений в Tarantool говорить на вашем любимом языке, каким бы он ни был.

У нас большая дата-платформа с несколькими системами хранения и обработки данных. Но не во всех системах есть хороший data governance и правильные процессы. Иногда это приводит к тому, что данные можно легко удалить по ошибке, что и произошло.

Но в этот раз рассказ будет не только про ошибку, но и про то, как нам удалось (почти полностью) ее исправить и что мы делаем, чтобы ее не повторить.

В программе:
* полная остановка боевого кластера Hadoop;
* поднятие еще двух кластеров для пользователей;
* восстановление данных с дисков после удаления (и очистки корзины);
* игрища с побайтовыми чтениями и поиском parquet magic numbers в петабайтном стогу сена.

Обзорный доклад о NewSQL СУБД Picodata. Основные концепции, архитектура, «фишки», сценарии использования и отличия от других СУБД.

Любая СУБД должна не только предоставлять качественный сервис, но и эффективно работать на каждом этапе жизненного цикла данных, и резервное копирование — один из ключевых этапов этого жизненного цикла. При этом возможны различные подходы к резервному копированию, но, независимо от подхода, необходимо обеспечить ключевые требования по производительности: минимизировать время снятия копии и ее объем, контролировать нагрузку на базу в процессе резервного копирования, уложиться в допустимые RPO и RTO.

В докладе расскажем о нашем инструменте Ptrack и применяемом в нем механизме хранения изменений на основе bloom filter и сравним его с выходящим в PostgreSQL 17 Walsummarizer и его механизмом хранения — roaring bitmap.

Взаимодействие с дисками — один из самых важных компонентов в работе пользователя с облаком. Оно должно быть стабильным, быстродействующим, а также иметь возможность скейлиться и адаптироваться к нагрузке клиента. Расскажем, как мы этого добились с помощью самописного сервера-библиотеки (которая теперь в открытом доступе!) и что у нас получилось.

Picodata — это распределенная СУБД. Мы сделали ее на основе Tarantool, который выступает локальным хранилищем и реализует репликацию. На фасаде мы реализовали новый движок распределенного SQL, а управлять всем этим поставили кластер-менеджер на основе алгоритма Raft.

Чтобы разобраться, как это работает, придется научиться думать в терминах распределенной стейт-машины, но я все объясню:
* почему такая сложная архитектура — это на самом деле просто;
* какие у отказоустойчивости критерии, и где границы сохранности данных;
* как работает расширение функциональности при помощи плагинов на Rust.

* Dev Room Picodata День 2, 15-40.

Изучим на практике:
* требования к ресурсам для развертывания кластера Picodata;
* инструменты для развертывания кластера;
* постановка кластера на мониторинг;
* создание, модификация и управление данными.

Хранение бэкапов — это всегда очень большие объемы данных и долгий срок хранения. Разрабатывая нашу систему хранения данных (СХД) для резервных копий TATLIN.BACKUP, мы столкнулись с недопустимо быстрым ростом метаданных для восстановления данных, причём метаданные часто дублировались. При среднем сжатии данных в 6 раз и доступной ёмкости для данных в 690 ТБ, объём метаданных достигал 13 ТБ, что занимало всю выделенную ёмкость под них.

Я расскажу:
* как мы решали эту проблему с использованием структуры Дерева Меркла и сократили объём метаданных на 83% при средней дедупликации в 6x раз;
* как это позволило нам ускорить поиск дубликатов в 10 раз;
* о применении content-defined chunking-алгоритма для построения дерева для того, чтобы эти решения работали;
* о подобных (но не наших) решениях для систем контейнеризации и распределённых key-value-хранилищ.

Наш подход сильно экономит дисковое пространство, а значит, и финальную стоимость хранения. И его также могут использовать системы хранения и БД для ускорения операций поиска, pull/push-операций данных или быстрой синхронизации реплик в распределённых БД.

Во ВКонтакте мы храним несколько триллионов фото, аудио и прочих файлов на тысячах серверов. Из-за такого объёма невозможно пользоваться нашими обычными подходами к разработке движков. Я расскажу, как менялась архитектура хранилища за 18 лет, что используется сейчас, как мы обеспечиваем отказоустойчивость.

Как мы управляем кластером PostgreSQL на 650+ двухтерабайтных шардов с помощью собственного сервиса шардирования.

Яндекс Почта — высоконагруженный сервис, который держит 300 000+ RPS и хранит информацию о миллиарде пользователей. Для хранения всей метаинформации мы используем PostgreSQL на 650 шардов. Чтобы справляться с такими нагрузками, мы реализовали собственный сервис шардирования — шарпей.

В докладе подробно расскажу:
1. как мы пришли к реализации сервиса шардирования;
2. как устроено основное хранилище информации о распределении пользователей по шардам и в самих шардах;
3. какие технические подходы мы используем, чтобы максимально уменьшить время получения информации из основного хранилища;
4. разберем историческое развитие сервиса, и какие оптимизации нам понадобились после переезда в Облака;
5. разберем преимущества такого решения, и как эти преимущества помогают многим сервисам Яндекс 360.

Осенью 2024 года вышел Valkey — клон Redis, поддержанный Linux Foundation и cloud-провайдерами, в первую очередь AWS.

Рассмотрим особенности Valkey, сделаем живое демо и в дискуссионной манере обсудим его перспективы.

Время выполнения SQL-запросов зависит от наличия индексов, актуальной статистики и т.п. Большинство проблем с производительностью СУБД решаются оптимизацией самых медленных запросов. Но, увы, бывают ситуации, когда классическая оптимизация запросов не приносит желаемого успеха, система продолжает себя вести неадекватно.

На HighLoad++ 2022 мы уже показали, какие бывают аномальные случаи, но прошло время, и кое-что исправлено, а что-то новое нашлось.

Приходите на доклад, чтобы узнать:
* что изменилось в PostgreSQL за последние два года;
* когда индексы могут тормозить или совсем не работать;
* какие сюрпризы заложены в fetch size'е
и другие увлекательные истории. Давайте вместе обсудим, каким иногда бывает PostgreSQL.

* Чем заменить MySQL или как превратить хеш-мапу в полноценную базу данных, привет YTsaurus.
* Всегда ли нужна нормализация данных?
* Потоковая обработка данных: per aspera ad astra.
* Версионирование данных — must have!
* Проблема размножения обновлений по иерархии объектов.

* Устройство плагина.
* Создание плагина, его установка и обновление.
* SDK Picodata.

Недавно мы добавили стоимостный оптимизатор в YDB, зачем мы это сделали и какие задачи он поможет решать?

YDB создавалась как OLTP-система для поддержки высоконагруженных проектов с большим объемом транзакций. Обычно в таких системах запросы довольно простые, хотя все равно попадаются и аналитические запросы со значимым количеством соединений таблиц. Такие запросы довольно сложно оптимизировать вручную, и на помощь приходит стоимостный оптимизатор. Многие наши конкуренты, такие как CockroachDB, TiDB, Yugabyte добавили стоимостные оптимизаторы к своим продуктам.

Но несколько лет назад мы также решили добавить колоночное хранение и сложную аналитику в YDB. В этом сценарии качественный стоимостный оптимизатор становится просто необходим, и требования к нему намного более серьёзные, чем в сценарии OLTP. Причем, поддерживая сразу строчное и колоночное хранение в одной СУБД, можно перейти в режим HTAP, где пользователь даже не знает, где будет исполняться его запрос — сверху строчного или колоночного хранилища — это решает как раз оптимизатор запросов.

В этом докладе мы расскажем о том, как мы написали свой стоимостный оптимизатор для этих сценариев, какая у него текущая функциональность на данный момент, сравнимся с конкурентами в области OLTP- (CockroachDB, Yugabyte), OLAP- (GreenplumDB, Teradata, Oracle Exadata, Trino) и HTAP- (TiDB) решений и расскажем о планах развития.

Rust последние несколько лет стабильно остаётся самым любимым языком программирования по данным StackOverflow Developer Survey. Также в последние годы его всё больше используют и в индустрии. За 3 года разработки Picodata мы успели познакомиться со многими нюансами языка и готовы поделиться своим опытом. Затронем такие темы, как тулинг, кривая обучения, надёжность, скорость разработки и выполнения, особенности архитектуры.

YDB — это распределенная платформа для работы с данными с поддержкой OLTP-, OLAP- нагрузок и потоковыми очередями сообщений (топиками, аналогичными топикам в Apache Kafka). Apache Kafka — признанный лидер в сфере потоковых брокеров сообщений.

Транзакции в любой системе — это, с одной стороны, мощный инструмент упрощения кода пользователя и работы с системой в целом, а также достижения гарантий, которые до этого невозможно/сложно было получить. Например, Apache Kafka за счет транзакций позволяет достичь exactly once-гарантий. А с другой стороны, это зачастую достаточно сложная и интересная архитектура внутри системы. Транзакции позволяют сложность перенести из пользовательского кода в серверный.
Основной упор в докладе делается на рассмотрение архитектуры транзакций в YDB и Apache Kafka со сравнением плюсов и минусов этих подходов.

В докладе будут рассмотрены следующие аспекты:
* что такое топик, транзакционная запись в топик, транзакционное чтение из топика;
* модельная задача решардирования с гарантиями порядка и exactly once-обработки. Почему ее нельзя решить без транзакций в Apache Kafka. Как она решается без транзакций в YDB. Как она решается в обеих системах с использованием транзакций;
* архитектура транзакций в Apache Kafka;
* архитектура транзакций в топиках YDB;
* сравнение производительности транзакций в Apache Kafka и YDB.

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

В этом докладе я хочу рассказать про самые интересные фичи динтаблиц YTsaurus и сценарии использования в Яндексе.

Apache Iceberg — популярный табличный формат для построения современных lakehouse-платформ. В докладе мы детально рассмотрим архитектуру и реализацию Apache Iceberg.

Представьте, что вам необходимо выполнить анализ данных, распределённых по нескольким системам хранения: например, таблицы, размещённые в реляционных СУБД, надо объединить с CSV-файлами из S3. Что вы предпримете? Если данных немного, можно написать простой скрипт на любом ЯП, который последовательно вычитает данные из каждого источника в оперативную память и объединит их в одну таблицу, после чего её можно будет проанализировать. При этом вам придётся написать свою реализацию JOIN либо использовать для этого стороннюю библиотеку неизвестной эффективности.

Но что делать, если данных очень много, они имеют сложную структуру, а для описания аналитических операций над ними гораздо лучше подойдёт привычный и выразительный SQL? Здесь на помощь приходят СУБД и движки обработки запросов с федеративными возможностями. В этом докладе мы поговорим о принципах работы таких систем и о ключевых оптимизациях, позволяющих им быстро и эффективно извлекать и обрабатывать большие объёмы данных из внешних источников.

1. Проблематика миграции на PostgreSQL.
* Отсутствие готовых нагрузочных тестов: вызовы и риски.
* Методы оценки производительности PostgreSQL без проведения полноценного нагрузочного тестирования.

2. Проблемы традиционного нагрузочного тестирования.
* Потенциал ошибок и неточностей в симуляции реальной нагрузки.

3. Методы оценки производительности PostgreSQL без стандартных нагрузочных тестов.
* Верификация производительности БД до ввода в эксплуатацию.
* Выявление возможных узких мест и проблем в конфигурации.
* Примеры использования статистических данных для идентификации узких мест.

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

В первой части доклада рассмотрим с какими особенностями поведения операционной системы приходится сталкиваться для обеспечения надежного хранения данных. Разберем, почему нельзя ретраить fsync, как к этому пришли разработчики PostgreSQL (спойлер: было потеряно какое-то количество данных, и сломано очень много копий в спорах с разработчиками ядра Linux).

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

Развитие баз данных привело к появлению технологий категории Distributed SQL: решений для исполнения запросов на больших объёмах данных. Движок распределённых запросов — это важный компонент подобных распределённых СУБД, позволяющий работать с ними через привычный SQL-интерфейс.

В докладе расскажу о внутреннем устройстве движка, который мы разработали в Пикодате. Покажу, как устроены фазы планирования и исполнения запросов и какую роль в этих процессах играют ключи распределения и библиотека горизонтального масштабирования Vshard. Поделюсь тем, как в процессе исполнения DDL-запросов используются алгоритмы Raft и CaS.

В конце доклада приведу сравнение с другими СУБД, предоставляющими функциональность распределённого SQL.

Valkey, в отличие от Redis, изначально построен по полностью Open Source-модели, у него нет Entrerprise-версии, которая бы каким-то образом ограничивала его развитие.

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

В этом докладе мы посмотрим на некоторые из этих патчей, оценим (с бенчмарками) их позитивные (а местами и негативные) эффекты на производительность.

* Существующие подходы к шардированию данных.
* Особенности подхода, выбранного в Picodata.
* Алгоритм сборки кластера. Discovery-узлов.
* Целостность метаданных в кластере.

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

Настоящее живое демо Redis/Valkey-кластера: принципы организации данных в кластере, масштабируемость, отказоусточивость, производительность. Попробуем выжать 1.000.000 (один миллион) RPS.

Любая SDS воспринимается как монолитная и монструозная коробка, в которой боязно что-то менять и сложно что-то проверить с коротким циклом обратной связи. В своем докладе расскажу, как тестировать изменения в Ceph без опасений и влияния на продакшн и какие инструменты помогают команде «Рунити» воспринимать каждый отдельный Ceph как облако.

Тезисы доклада:
* Ceph как легко развертываемый кластер;
* функциональное тестирование на виртуальных машинах;
* путь изменений от виртуальных машин при разработке решений до продакшна;
* воспроизведение функциональных пользовательских кейсов в изолированных окружениях.

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

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

Kubernetes уже добрался и до enterprise-систем, в которых много легаси, коробочных решений и жестких требований по безопасности. Что самое неприятное — в таких системах предстоит долго (если не всегда) жить в условиях двоевластия по управлению сетями и мониторингом безопасности, когда разработке и эксплуатации хочется современных инструментов и подходов, а безопасникам — старых проверенных iptables.

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

Современные платформы на базе Kubernetes предоставляют очень широкие возможности для управления безопасностью сетевого взаимодействия приложений. Настолько широкие, что можно все настроить «как надо», а получить совсем не то, что ожидалось. В докладе на одном из таких примеров разберем механизмы безопасности сети в Kubernetes, а также погрузимся в детали реализации и лучшие практики на примере популярных Open Source-проектов.

Как сделать платформу, которая будет ускорять разработку и делать эксплуатацию надежнее?

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

Наша команда давно и успешно развивает сервис централизованного логирования в МТС. За это время мы успели вырасти в сотни раз по объемам, пользователям и нагрузке, перейти от одного единственного кластера Elasticsearch к геораспределенной системе из множества кластеров OpenSearch. Не все наши изначальные архитектурные решения выдержали проверку временем, и с их последствиями мы боремся до сих пор. А часть компонентов пришлось дорабатывать или заменять собственными решениями.

В докладе расскажем, как нам удалось сделать геораспределенную систему логирования на базе OpenSearch на 300+ TB и 3 000 пользователей. Как менялись наша архитектура и стек с ростом нагрузки. И самое главное — что бы мы сделали по-другому, если бы начали с нуля.

Рассмотрим ключевые паттерны использования PowerShell DevOps'ами в распределенных системах с акцентом на практические примеры и бизнес-кейсы. Обсудим, где и почему PowerShell может быть предпочтительнее Ansible. Очертим возможности PowerShell 7 в 2024 году. Включены примеры с кодом, методы логирования и тестирования, а также рекомендации по структуре скриптов для сложных решений.

Доклад ориентирован на тех, кто хочет эффективно использовать PowerShell для автоматизации в DevOps.

Контейнеризация позволяет сделать более надёжными и масштабируемыми даже «немодные» монолитные приложения. Я докажу это на практическом примере перевода сетки высоконагруженных новостных сайтов на базе Drupal 8 в Kubernetes. Обсудим типовые паттерны архитектуры приложений в контейнерной среде, лучшие практики миграции, а также типичные сложности и распространённые ошибки.

Доклад поможет решить проблему автомасштабирования и управления такими PHP-приложениями, как Drupal в облачных средах. Вы узнаете, какие шаги предпринять для успешной миграции монолита в K8s и как в рамках одного кластера развязать окружения друг от друга. А также как экономить на инфраструктуре благодаря HPA и значительно уменьшить Time-to-Market за счёт автоматизации CI/CD-процессов.

Что делать, если деплой в облачный кубер падает из-за нехватки ресурсов, но мониторинг говорит, что реальная утилизация ниже 20%, при этом стоимость инсталляции в месяц составляет 8-значную сумму?

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

Наша трансформация DevOps началась в 2019 году с внедрения IT-стандартов, которые включали практики Continuous Integration, Code Review и Trunk Based Development. Мы активно развивали инженерную культуру, улучшали процессы и автоматизировали оценку практик. В 2020 году добавились Continuous Delivery, Logging и Monitoring, а переход на GitLab открыл новые возможности для оптимизации CI/CD-процессов. В 2022 году «IT-Стандарты» были преобразованы в «Лучшие практики», позволив командам самостоятельно достигать технического совершенства и следовать инженерным целям.

Сегодня, в 2024 году, мы делаем следующий шаг — запускаем платформу «Технические возможности», которая автоматизирует оценку практик и сбор метрик. Эта платформа позволит оценивать зрелость команд с помощью интеграций и опросов, объединяя в себе методы из DORA Core Model и внутренние метрики в компании. Платформа реализует единую экосистему для управления инженерной культурой и техническими процессами, помогая командам не только улучшать свои результаты, но и двигаться в сторону долгосрочной устойчивости и эффективности.

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

В этом докладе мы расскажем вам о практике наших учений по отключению ДЦ. Поделимся одним конкретным случаем, когда у нас произошел факап, который привел к тому, что в патрони-кластере (и не одном) в строй вернулись мастера на старых таймлайнах.

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

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

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

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

В докладе расскажу:
* как разработать безопасную архитектуру мобильного приложения с использованием СКЗИ;
* как обеспечить быстрый процесс выполнения требований ФСБ России по оценке влияния мобильных приложений на встроенные СКЗИ;
* какие инструменты и методы использовать для контроля целостности и безопасности кода на этапе разработки;
* как автоматизировать процесс контроля релизных сборок и обеспечить соответствие стандартам безопасности.

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

Даже при наличии правильно сегментированной сети с гранулярной выдачей минимально необходимых доступов — VPN все еще дает доступ в сеть компании.

В своем докладе я расскажу, как минимизировать риск при выдаче доступа к VPN для наименее доверенных групп сотрудников. Про то, как можно заменить доступ к сети компании через VPN максимально точечным и гранулярным доступом до веб-приложений с помощью достаточно простого и лаконичного решения — Identity Aware Proxy, сделав тем самым весомый шаг в сторону Zero Trust.

Приложения, перед которыми стоит задача высокой производительности, зачастую пишутся на небезопасных с точки зрения использования памяти языках программирования, таких как С и С++. В Яндексе разрабатывается и используется множество сервисов, написанных на С++, как доступных исключительно для внутренних пользователей, так и опубликованных в Open Source: YDB, YT, userver, etc.

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

В Российской Федерации на законодательном уровне начали формировать первичные требования к умным многоквартирным домам и их безопасности. Рассмотрим разницу между умным домом и умным многоквартирным домом. Ознакомимся с международным анализом уязвимостей и угроз кибер-физических систем современных домов и использования IoT и IIoT на службе цифровизации домов. Сформулируем гипотезы перспектив повышения уровня безопасности умного многоквартирного дома.

История ошибок переполнения буферов насчитывает более 35 лет. За это время появилось множество технологий, которые должны были избавить нас от этого класса уязвимостей раз и навсегда. Мы постоянно слышим, что переполнения в 20хх году уже "мертвы". Однако на деле количество найденных ошибок и, что еще важнее, их эксплуатация в реальных атаках только растет.

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

В Сбере больше 1500 команд, разрабатывающих и поддерживающих около 2000 автоматизированных систем (АС). Эти АС используют компоненты стандартного технологического стека от операционной системы, систем управления виртуализацией и контейнерами до Middleware и баз данных. АС регулярно масштабируются, команды создают новые и выводят старые микросервисы, технологический стек меняется под влиянием внешних и внутренних факторов. Один из актуальных факторов – импортозамещение. Управление доступом к компонентам технологического стека и между ними сложный технический вопрос не только для Сбера и его большой инфраструктуры, но и для других компаний в России и мире. Перед нами стояла задача решить эту задачу для более 500 000 экземпляров компонентов техстека и не только автоматизировать предоставление доступа и создания технических и привилегированных учетных записей, но и управление их жизненным циклом, ролями, полномочиями и секретами.

В рамках доклада мы разберем:
* организацию учета, продуктов, компонентов и др., а также как вести привязку команд сопровождения и развития;
* организацию ролей и учетных записей в IGA;
* что такое PAM и Vault, передачу секрета УЗ под управление в эти системы;
* управление доступом к Vault и PAM из IGA, разделение ролей;
* управление доступом на примере Linux. Централизованная аутентификация vs ssh-ключи. Управления sudo. Разграничение доступа;
* как использовать Vault для работы с сертификатами, магия istio + vault agent;
* преимущества и недостатки внедрения такой автоматизации.

В современном мире атаки на базы данных и утечки становятся все более актуальной проблемой для организаций. Несмотря на то, что многие СУБД предоставляют различные способы контроля доступа к базам данных, пароли все еще часто используются, а другие способы защиты не применяются.

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

Атакуя приложение, хакер держит в голове некоторую его модель, меняющуюся по ходу проверки гипотез и включающую в себя критичные точки выполнения, способы воздействия на них и ожидаемую реакцию приложения. Дерево атак, реализуемых хакером, является набором достижимых путей в такой модели. Функциональность вторична для хакера, он мыслит «вне коробки» приложения и свою модель строит, исходя из необходимой ему «функциональности», которая позволит провести эффективную атаку.

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

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

Доклад посвящён тому, как взять лучшее из обоих подходов для разработки «hackerproof»-приложений.

Быстрый рост IТ-компаний, как правило, влечет за собой необходимость в увеличении мощностей IТ-инфраструктуры. Как следствие, это несет за собой сложности в части поставки нового оборудования и масштабирования информационных систем. Облачные провайдеры могут значительно облегчить решение этих проблем за счет быстрого предоставления необходимых вычислительных ресурсов и управляемых сервисов. Однако при размещении своих сервисов в облаке, важно сохранить должный уровень защищенности.

Относительно недавно мы в своей компании тоже столкнулись с подобной задачей, поэтому готовы рассказать о «подводных камнях» заезда нагрузок экосистемы Т-Банка в публичное облако на примере Yandex Cloud, а именно: особенности обеспечения доступа пользователей в YC, настройка сетевой сегментации в большом количестве облаков, защита пайплайна и обеспечение контроля публикации приложений из YC.

Решили выстроить процесс автоматизированного анализа кодовой базы на уязвимости, но DefectDojo не выдержал нагрузки? С такой же проблемой столкнулись и мы два года назад. За это время мы разработали собственную платформу оркестрации SAST- и SCA-инструментов и ежедневно проводим полторы тысячи сканирований, подключив к системе шесть тысяч проектов, а наша БД, хранящая «сырые» сработки, перевалила за 300 гигабайт.

Расскажем, как мы справляемся с такими объёмами, чего нам стоило разработать собственную систему vulnerability management силами 3 разработчиков, как мы справляемся с анализом проектов в миллионы строк кода и как проводим многоступенчатую дедупликацию данных, благодаря которой 150 миллионов «сырых» срабатываний SAST-анализаторов превращаются в несколько тысяч агрегированных срабатываний в Web-UI, с которымИ работают разработчики.

Кратко:
Попробуем разобраться, как инструментально отлавливать уязвимости бизнес-логики максимально «слева», а самое главное — как обернуть это в понятный и ненасильственный для команд процесс.

Подробно в тезисах:
* уязвимости бизнес-логики — самая неприятная история, которую не найти сканерами;
* отловить такие проблемы может и сама команда на ранних этапах планирования, необязательно привлекать Security;
* моделирование угроз можно и нужно обернуть в процесс, а командам — дать инструменты, которыми они смогут пользоваться в своих Agile-процессах;
* варианты процессов и инструментария: плюсы, минусы, опыт и обратная связь;
* как дальше этот процесс можно увязать: с чемпионами, с моделью зрелости команд, с оценкой рисков и адаптивностью проверок безопасности на гейтах.

ЭЦП сейчас используется повсеместно и за последние несколько десятков лет эволюционировала во множество алгоритмов, начиная с симметричного MAC и заканчивая пороговыми, групповыми подписями, квантово-устойчивыми подписями и даже zero-knowledge-доказательствами валидности проверки подписи.

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

В докладе разберём на примерах различные векторы атак на CI/CD. Подробно рассмотрим, к чему приводит их реализация и какого импакта можно добиться. Обсудим, как защититься от таких атак, и рассмотрим практические примеры использования различных способов смягчения рисков.

VK развивает более 200 проектов — суммарно это более 40 тысяч репозиториев с кодом, который команды разработки хранят в разных системах контроля версий. Чтобы строить процессы безопасной разработки, инженерам ИБ нужно иметь под рукой актуальную информацию обо всех из них.

Для этого мы (департамент защиты приложений VK) своими силами разработали на Python инструмент, ежедневно осуществляющий обход всех систем контроля версий, укладываясь в rate-limit, и сохраняющий в БД информацию о репозиториях (и образах), хранящихся в них, чтобы мы могли быстро и эффективно искать уязвимый код, библиотеки и чувствительную информацию.

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

При внедрении DevSecOps-практик многие сталкиваются с такими проблемами:
* выявленных уязвимостей больше, чем команда может исправить;
* высокий false positive rate статического анализатора;
* у команды продукта не хватает знаний и компетенций для исправления уязвимости, она не понимает, что требуется сделать;
* нехватка инженеров ИБ на рынке, которые могли бы сопровождать команды и улучшать качество работы анализаторов;
* текучка кадров и динамичность технологического стека — мы не успеваем учить всех принципам безопасной разработки.

В докладе расскажем о том, как создавали и внедряли решение для помощи разработчикам в устранении уязвимостей и недостатков в коде с использованием технологий ИИ. Поделимся результатами сравнения коммерческих и Open Source-моделей, различными трюками для улучшения качества, тестирования, обогащения данных. Покажем примеры работы и общую архитектуру решения.

Наш ассистент умеет:
* объяснять суть уязвимости, предлагать векторы атаки (важность конкретного кейса);
* предлагать варианты исправления в коде через GitLab и/или IDE;
* выявлять False Positive-результаты работы SAST;
* собирать обратную связь для улучшения качества работы;
* использовать внутреннюю базу знаний для принятия решений.

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

В докладе пойдет речь о том, как Timeweb Cloud применяет свой подход и масштабирует сетевые сервисы под бизнес-задачи клиентов.

Из доклада вы узнаете:
* о проблемах органического роста сетей в облаке. Откуда берутся L2-домены на десятки тысяч машин, как при этом ведет себя сеть (физическая и виртуальная);
* особенности поведения сетевого оборудования, с которыми вы можете столкнуться;
* с какими запросами приходят клиенты и как это влияет на развитие сетевых сервисов;
* об опыте внедрения и масштабирования подхода Timeweb Cloud — physical vtep vs linux kernel, L3 directconnect vs L2.

Ситуация в IT в России изменилась после 2022 года за счет западных санкций и наших законов. Целые сегменты рынка опустели, ушло большинство западных вендоров, и встал вопрос, что теперь делать с IT-системами. Организации либо начали проектировать свои решения, либо искать отечественных вендоров, которые могут заместить западные продукты и решения. Но практически все такие решения зависят от Open Source-продуктов, на которых они обычно основаны.

Доклад посвящен тому, какие есть подводные камни, при работе с Open Source-продуктами, рассмотрены различные мифы про их использование. К чему надо готовиться при внедрении таких продуктов и чего лучше не делать. Также будет рассказано про методологию построения своего продукта на базе OpenStack.

Service Mesh – технология, которая призвана обеспечить гибкое, стабильное и надежное общение сервисов. Технология, призванная упростить эксплуатацию сетевого взаимодействия. Но сделает ли она систему проще?

За последние шесть лет в Авито мы внедрили два собственных Service Mesh-решения и перешли на Istio. Поговорим о причинах данных переходов, о сложностях, с которыми мы сталкивались, и об их решениях.

Затронем следующие темы:
* причины выбора собственной реализации и почему в итоге ушли на Istio?
* почему Istio не сделает проще?
* польза и трудности от внедрения mTLS;
* как мы ускоряем разработку Service Mesh и отлаживаем его работу.

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

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

В этом докладе хочу поделиться опытом эксплуатации десятков многотенантных кластеров K8s с тысячами RPS входящих запросов. CPU, MEM, HDD и Network — далеко не единственные коммунальные ресурсы, за которые ваши поды будут сражаться. Помимо них, у нас есть ingress, а еще egress. В каждом случае надо разбираться отдельно: где-то Open Source-сообщество уже сильно вам помогло, а где-то вам надо помогать сообществу.

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

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Для участия в workshop вам потребуется ноутбук с доступом в Internet и ssh-клиент.

ЦОДы уровня TIER 3 не падают. А даже если падают, то есть DRP-планы, и на бумаге мы должны прекрасно пережить отказ дата-центра. Поэтому часто бывает соблазн отложить задачи техдолга чуть в сторону. Но иногда достаточно проблем с электропитанием, программного сбоя или просто человеческого фактора, и все риски могут стрельнуть разом.

Расскажем о том, как пережить падение ЦОДа на опыте VK Cloud. Как мы восстанавливались, корректируя архитектуру решения без простоя для клиентов и сервисов, и какие уроки приготовили для вас.

Большинство из вас в курсе, что мы в CDEK в конце мая заводили наш энтерпрайз с полного нуля. Пока воспоминания свежи, поделимся лайфхаками. Что уже должно быть у вас в коде (и в голове) до того, как все полетит в тартарары? Какие ваши апи самые важные? Какие, казалось бы, одноразовые скрипты не стоит выкидывать? Какие схемы стоит нарисовать заранее? Какие дополнительные навыки стоит изучить, чтобы быть полезным во время армагеддона?

Это будет история о том, как наш проект внезапно столкнулся с нагрузкой в 20 000 RPS в самый ответственный момент, какие управленческие и технические решения мы принимали в условиях кризиса, чтобы минимизировать ущерб и восстановить работу системы.

Поделюсь нашим опытом разграничения нагрузки, оптимизации запросов в базе данных и API, а также тем, как мы избавлялись от старых «костылей». Вы узнаете, как нам удалось увеличить устойчивость системы до 10 000 RPS всего за двое суток, и какие у нас планы по достижению стабильной работы при нагрузке свыше 20 000 RPS.

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

Расскажу, как мы держим «Пульс» не ниже 99,99 — обрабатываем ежедневную нагрузку автоматизированных HR-процессов более 3000rps, переживаем пики нагрузки при повседневной работе, по рассылкам об обучении или важной информации от руководства, либо High Season пользовательской активности в конце кварталов или года.

В докладе разберем подход к конфигурированию базового образа для запуска Java-приложений в контейнеризированной среде без изменений кодовой базы. На основе практических исследований выясним, как повысить утилизацию CPU, какой тип аллокатора выбрать, на что влияет выбор GC (пропускная способность, максимальная задержка, потребляемые ресурсы), как эффективно использовать всю доступную память, какие области необходимо ограничить, как защитить себя от прихода сверхпиковой нагрузки.

Вопрос управления расходами на инфраструктуру был и остаётся актуальным. А в нынешние турбулентные времена — актуальным вдвойне. Для облаков придумали FinOPS — с инструментами, графиками, детализацией вплоть до вызова конкретной serverless-функции. А что в on-prem? По-прежнему непонятные таблички и ещё более непонятные счета?

Давайте разбираться.

* Чем отличается облако и он-прем с точки зрения затрат?
* Из чего состоит «Железный» FinOPS?
* При чём тут управление рисками?

В компании Скала^р используется собственное решение для управления сложными IT-инфраструктурами, основанное на графовом Control Plane, разработанном на базе опыта в суперкомпьютерной индустрии. Это решение, распространяемое по открытой лицензии Apache 2.0, объединяет программные и аппаратные компоненты в единую модель IT-инфраструктуры, при этом эффективно обрабатывая большой поток сигналов и поддерживая кластеризацию с резервированием данных.

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

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

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

Говорят, все, что утекло в Интернет, останется там навсегда. Это не так — хранение данных стоит денег и требует ресурсов. SSD дороги и недолговечны. Но как же быть, если вам нужно сохранить Интернет в архив для будущих исследователей? Для этого существуют технологии хранения «холодных» данных. Они дешевле и надежнее SSD и даже HDD.

В докладе я расскажу, какие существуют технологии хранения данных, чем они отличаются друг от друга. Почему магнитные ленты из 80-х все еще актуальны. Где еще живут забытые оптические диски. Что разрабатывают им на замену. И, оказывается, есть новые российские конкурентные технологии.

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

Мы поместили сервисы реальной точки доступа в контейнер, создав эффективный и масштабируемый инструмент для решения задач имитации функционирования Wi-Fi-сетей в различных сценариях.

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

Представьте ситуацию: единое тестовое окружение, в котором работает более 300 микросервисов, нагрузка свыше 300 RPS на сервис, и этим окружением пользуются все — от разработчиков до аналитиков.

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

Мы выбрали Wiremock, который может быть не только мок-сервером, но и прокси. Однако оказалось все не так просто — Wiremock начал падать даже при нагрузке в 100 RPS, Kubernetes перезапускал поды, а один из багов Kubernetes и вовсе сломал мастер-ноду.

Всё это мало напоминало успех, но в результате — после множества экспериментов и расследований — мне удалось разобраться в причинах. После исправлений всех проблем и аппрува от создателя Wiremock — производительность Wiremock выросла в десятки раз, он стал выдерживать нагрузку более 1000 RPS. Чтобы узнать, как мы с этим справились, с какими проблемами столкнулись и как мы их решали, приходите на мой доклад. Будет интересно и поучительно!

Производительность etcd-кластера с множеством объектов — головная боль команд, которые любят и ценят кубернетес. И вот почему: чаще всего для роста производительности кластера используют горизонтальное скалирование, а это приводит к нагрузке на кластер из-за увеличения времени согласования записи данных. В результате вместо шустрого кластера получается неповоротливый тяжеловес. Мы в VK Cloud разогнали наш Managed Kubernetes под очень высокие нагрузки (500 000 объектов в кластере) и сохранили его производительность. В докладе расскажу, как мы провели тюнинг ectd-кластера, какие настройки нужны, чтобы повысить производительность Kubernetes-кластера. Рецепты пригодятся для команд, которые работают с Kubernetes в облаке и готовят его на своем железе.

* Почему горизонтальное масштабирование etcd-кластера — это плохо;
* почему etcd — это не про большие объемы, и какой опыт у Google, AWS;
* надо понимать, что хотите хранить в etcd;
* как перекосы в типах хранимых данных влияют на производительность и как это исправить;
* что нужно не хранить в etcd и выносить за пределы кластера;
* как одна ошибка в манифесте может заставить достичь лимитов Kubernetes и сломать его.

Технологии не стоят на месте. Особенно, если речь заходит о Java-технологиях и JVM.

Когда говорят о производительности Java и микросервисов на Spring Boot, есть несколько болевых точек, в которые постоянно бьют: время запуска и динамическая компиляция байт-кода JIT-компилятором JVM.

В этом докладе мы поговорим о новшествах, которые появились в Java и JVM: CRaC и GraalVM. Они призваны решать упомянутые проблемы. Но разработчики и рынок еще к ним не готовы, потому что не знают, как именно это работает и что, вообще, с этим делать.

Добро пожаловать в мир Java и компиляторов! :)

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

На докладе будут освещены следующие аспекты:
* как внедрение платформы помогает снижать MTTR и повторяемость критичных инцидентов?
* какие технические сложности проектирования и разработки нам пришлось преодолеть, чтобы сделать отказоустойчивый продукт?
* инцидент-менеджмент — это только про IТ или не только?

Наивный способ отправлять файлы по сети — это читать данные в буфер из файла (системный вызов read) и записывать этот буфер в сокет (системный вызов send). Такой подход не самый эффективный, потому что переключения контекста и лишние копирования из кэша ядра в пространство пользователя и, наоборот, из пространства пользователя в буфер сетевой карты очевидно излишни. Для оптимизации такой задачи еще в начале 2000-х в ядре linux появился системный вызов sendfile, в него можно было передать файловый дескриптор, сокет, количество байт и отступ, и в итоге за один системный вызов ядро делало необходимую работу без лишнего копирования и только с одним переключением контекста. Проблема только в том, что данная схема не работает если мы используем TLS, потому что данные перед отправкой в сокет надо зашифровать блочным шифром. С версии ядра 4.13 уже появилась частичная поддержка (TLS 1.2), а с версии ядра 5.1 полноценная поддержка (TLS 1.3) шифрования трафика на стороне ядра — kernel TLS (сокращенно kTLS).

В докладе подробно будет рассказано, каким образом можно реализовать поддержку kTLS с упором на java. Реализация этого функционала позволила значительно улучшить скорость отдачи данных консьюмерам в кластере Apache Kafka.

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

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

Доклад о том, как мы изменили архитектуру для увеличения стабильности связи с IoT-устройствами, как не получать downtime в высокочастотном сервисе, а также как решали вопросы с балансировкой соединений и сообщений от IoT-устройств и как жить в K8s с «несовременными» протоколами обмена сообщений.

В линейке складских роботов Яндекса есть несколько роботов. Один из них — робот Spectro — выполняет задачу инвентаризации и актуализации состояния товара на складе.

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

Доклад посвящен системе сканирования на роботе Spectro и задачам, которые ей необходимо решать. Поговорим об организации пайплайна обработки данных, как эффективно получать синхронные кадры с камер и как нам в этом помог YDB. Расскажем о средствах профилирования, которые помогли улучшить наш код, а также почему мы отказались от ROS2 при реализации системы сканирования.

Генеративные нейросети научились рисовать картины, писать осмысленные тексты и подняли ряд непростых вопросов. Можно ли использовать в серьезных проектах код, написанный нейросетью? Что такое, вообще, «хороший код»? Действительно ли «Исходники — лучшая документация»? Я пишу код 25 лет, а пять лет изучаю нейрофизиологию, чтобы писать код чуть лучше.

В докладе я расскажу о том, что современная наука знает (или не знает) о коде: как мы его осознаем, сколько строк «влезает в голову», что делает код «читаемым». И вместе с вами прикину, какое будущее нас может ожидать и к чему можно готовиться прямо сейчас. Станет ли код на любом языке программирования новым «ассемблером», который будут писать и читать нейросети по текстовому описанию. И нужно ли заботиться о том, чтобы код был читаем для человека?

* Объяснение OpenRAN в целом и их роль как спецификаций, достаточных для проектирования и производства отдельных узлов RAN небольшими командами при некосмических бюджетах.
* Преимущества OpenRAN по аналогии с текущим состоянием рынка оборудования стека Ethernet-IP-TCP-App.
* Юридические и регуляторные основания и предпосылки к внедрению OpenRAN.
* Политические предпосылки к внедрению OpenRAN, в частности, потенциал к импортозамещению.

Препятствия к разворачиванию OpenRAN:
- в аппаратном обеспечении;
- в программном обеспечении;
- в организационных аспектах существующих поставщиков;
- кейсы из наработанного опыта.

Random Coffee на HighLoad++ 2024 — это интерактивное событие, направленное на развитие профессиональных связей между участниками конференции. С помощью специального Telegram-бота участники могут зарегистрироваться и получить случайно подобранного собеседника для непринужденной беседы. Активность позволяет каждому найти интересные знакомства и обсудить актуальные темы в сфере высоких нагрузок и смежных областях. Присоединяйтесь к Random Coffee и откройте для себя новые возможности нетворкинга!

Открытость данных против интеллектуальной собственности. Боты против систем защиты — эта игра в кошки-мышки идёт уже много лет. В докладе я расскажу о текущей ситуации в этом сражении.

Я участвую в развитии сервиса, который скачивает 200М страниц в день с сайтов, защищённых антибот-системами. Расскажу, как мы пытались заставить браузер в контейнере под Linux выглядеть как браузер под Windows.

О вызовах, с которыми мы столкнулись при масштабировании системы обхода таких антибот-систем, как
* Cloudflare,
* Datadome,
* Incapsula.

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

App.Farm — это PaaS-платформа, предназначенная для управления интеграционными потоками и средой исполнения приложений в РСХБ.

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

Во время доклада вспомним, как работают асинхронные движки, а также разберём, почему стандартный GDB не справляется с отладкой асинхронных приложений на С/С++.

На примере наших приключений по исправлению ошибок в Odyssey (пулер соединений для PostgreSQL) разберём, как всё-таки можно научиться искать ошибки в асинхронных приложениях с помощью GDB.

Задача идентификации клиентского трафика остро стоит для большинства компаний, которые используют эти знания для рекламных кампаний, борьбы с фродом, ботами при условии невозможности проставить third-party cookie. Одним из возможных решений является использование технологии server-side fingerprinting, при котором сервер анализирует данные клиентского соединения.

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