Доклады

Репликация между инстансами СУБД позволяет повысить отказоустойчивость совокупной системы. Мы разберём, как устроена репликация в YTsaurus: распределённом key-value-хранилище, использующемся в Яндексе и ставшем в 2023 году Open Source-продуктом. Тогда как данные внутри одного кластера YTsaurus хранятся с избыточностью и позволяют переживать выпадения отдельных машин и стоек, межкластерная репликация в YTsaurus предназначена для обеспечения отказоустойчивости на случай выключения целых кластеров. Один из важных сценариев даунтайма кластера YTsaurus — обновление на следующую версию. Мы разберём, как работает межкластерная репликация в YTsaurus, какие гарантии даёт и как позволяет строить системы без даунтайма поверх обновляющихся кластеров YTsaurus.

На докладе расскажу о технических особенностях индексирования писем в почте Mail. ru. Остановлюсь на проблемах, с которыми столкнулись, и как эти проблемы решали.

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

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

Ядром ВКонтакте являются 70 специализированных баз данных (движков), организованных в 800 кластеров, имеющих в сумме 10000+ шардов.

Чтобы безболезненно переживать отказы мастера шарда, мы сделали BARSiC (Binlog Asynchronous Replication using Simple BD interface + Consensus) — в простонародье Барсик. Это система, которая обеспечивает автоматическое переключение ролей реплик и консистентность данных между ними, при этом не усложняет и не замедляет сами движки.

Расскажу, как мы проектировали BARSiC, почему отказались от стороннего консенсуса и каким образом с помощью модели TLA+ проверяем корректность кода Барсика на Go.

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

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

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

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

В докладе поговорим про текущие и перспективные решения хранения логов, обсудим архитектуру, положительные стороны и недостатки, почему все делают одно и то же, но немного по-разному и почему R&D-разработка — это сложно.

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

В докладе я расскажу, с какими проблемами мы столкнулись и как мы их решили при оптимизации YDB под архитектуру ARM. Детально рассмотрим основные проблемы оптимизаций высоконагруженных приложений под ARM. Расскажу про методы и инструменты, с помощью которых мы тестировали производительность, находили места для оптимизации, сравнивали производительность ARM и X86-64.

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

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

Сейчас уже есть возможность работать с Yandex Object Storage как с ФС с помощью GeeseFS, про которую мы рассказывали в прошлом году. Но для хорошего решения нам сильно не хватало возможности частичной перезаписи объектов - метода PATCH. Про него и будет доклад.

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

Есть во вселенной такой алгоритм — Raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul как наиболее известные проекты, его использующие).

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

Задача поиска по образцу на последовательности строк БД может возникать в различных сферах деятельности. Например, в финансовой аналитике — поиск определённых паттернов изменения цены акций; в системах борьбы с мошенничеством (AntiFraud) — поиск последовательностей событий, которые могут свидетельствовать о подозрительной активности, а также в IoT и многих других.

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

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

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

В составе платформы YDB работает сервис очередей сообщений — Topic Service. Он обладает надёжностью, масштабируемостью, гарантиями порядка и доставки.

В этом докладе рассказывается про ускорение YDB Topic Service и приведено сравнение с конкурентами.

Итак, у нас есть YDB. Это платформа, которая умеет обрабатывать большой поток быстрых транзакций (OLTP, Online Transaction Processing).

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

Имея такой стартовый набор, мы захотели научить YDB обрабатывать другой тип запросов — аналитические (OLAP, Online Analytical Processing).

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

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

Существуют несколько мифов о мультимастере: он медленный, сложно интегрировать с приложением, неудобен в обслуживании.

Недавно удалось получить опыт работы с мультимастером в реальных боевых условия. Теперь же хочется поделиться плюсами, минусами и life-хаками при работе с мультимастером на примере продукта PostgresPro Enterprise:
* как выжать максимальную производительность из мультимастера?
* почему можно забыть о проксях и балансировщиках?
* какой же trade-off и какие ещё бонусы можно получить?

Реализовать функционал создания бэкапов (или снапшотов) в СУБД непросто. Задача вдвойне сложнее, когда это нужно сделать в распределённой СУБД. Втройне — когда СУБД поддерживает распределённые транзакции. Тем не менее любой хороший Crash Recovery-план содержит противоречивые пункты — «Иметь под рукой полный бэкап» и «Обеспечить RPO в пределах 5 минут».

Мы реализовали в Ignite алгоритм «Consistent Cut» для снятия инкрементальных снапшотов. В докладе расскажу, как нам удалось сделать снятие максимально незаметным для пользователя, а восстановление каждого узла полностью автономным. Обсудим, про что не нужно забывать при разработке production-фичи, даже если ослеплен красотой алгоритма.

Путь от техдолга в 20 лет до построения катастрофоустойчивого решения в IT-компании среднего размера. Не пытайтесь повторить. Все трюки выполнены профессионалами, которые не знали, во что ввязываются.

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

* Методы, их преимущества и недостатки. Метод классического водопада. Метод циклического обхода и Agile. «Государственный» подход.
* Использование «философских» принципов при построении системы. Ретроспектива технологии.
* Инструментарий. Высокоуровневый дизайн и архитектура современных платформ мониторинга на примере VK Cloud.
* Имплементация и межкомандное взаимодействие. Как строить мониторинг для большой платформы, когда уже все написано и работает.
* Организационные особенности имплементации мониторинга. Карта ответственности в оргструктуре.

Что общего у водителя, пересевшего с автоматики на механику, и SRE-инженера, познавшего переход с K8s на Nomad?

Nomad выбирают за его флексабилити и админ-френдли-подход, но что, если вы продвинулись чуть дальше «стартовой локации»? В гайде не описаны тонкости реализации кастомных решений: например, про обновление Nomad с Raft 2 на 3, когда кластер построен на основе Consul.

Рассказываем, как пытались использовать функционал K8s на примере sidecar, внедряли многопоточные тесты, как подружили GitLab и Nomad. Делимся горьким опытом, советами по кастомизации Nomad и способами безопасной передачи секретов типа. env с помощью Vault в продуктовом окружении.

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

В выступлении я на своём личном опыте председателя ТСЖ расскажу об общности и разности подходов, а также о том, чему может научиться DevOps или SRE в эксплуатации собственных систем из реального мира.

Постмортем инцидента во внутренней инсталляции Yandex Tracker.

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

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

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

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

По следам гайда от Агентства национальной безопасности (NSA), в котором языки С/C+ признаются «опасными» и требующими перехода на «безопасные» C#, Go, Java, Ruby и Swift. Поймем, так ли плохо обстоят дела с безопасностью в С++ на самом деле, и что современная индустрия предлагает для решения данного вопроса.

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

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

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

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

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

В докладе мы расскажем вам:
* Какие системы контроля мы перепробовали, прежде чем прийти к своей собственной.
* Что такое виртуализация файловой системы, как она помогает в борьбе с большим количеством файлов и какие у нее есть подводные камни.
* Как мы вычисляем лог файла на графе из десятков миллионов коммитов за пару секунд, и почему так не может git.
* О наших костылях на максималках: что делать, если поверх твоей VCS не работает rsync и XCode.
* Как свести интерфейс к трем командам и перестать думать о ветках и коммитах.

Раньше расследование обращений вида «Я не могу дозвониться!», «Меня выкинуло посреди созвона!», «Я включаю демонстрацию экрана, а её никто не видит!» у нас в команде VK Звонков могло походить на поиск иголки в стоге сена или гадание на картах Таро. Мы тратили на выяснение причины жалобы огромное количество времени и сил. Но теперь всё изменилось!

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

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

В докладе расскажем о том, с какими трудностями мы столкнулись при использовании корпоративного мессенджера Mattermost. Доклад будет полезен тем, кто только собирается развернуть собственный корпоративный мессенджер, чтобы понять, на что обратить внимание и какие узкие места можно обнаружить. Пройдем путь развития сервиса от 20 человек до 10 тысяч: что делали, чтобы улучшить его работоспособность и облегчить жизнь при поддержке/администрировании.

1) Да будет свет, или Как все начиналось: почему появилась необходимость в корпоративном мессенджере. Первая версия сервера 3 в 1 (БД, сервер Mattermost + сервер авторизации все вместе). Добавление инструментов. Привлечение IT-команд.
2) Первый блин не комом! Реакция пользователей: плюсы и минусы. Добавление функционала на основе Обратной Связи (плагины). Увеличение функционала — самописные плагины. Как мы придумали использовать скрытые сообщения (что дало: экономия, безопасность, сокращение времени решения задачи).
3) А нам 1 год! Увеличение пользователей и устранение узких мест. Настройка отказоустойчивости (уменьшаем время простоя; делаем общий конфиг без синхронизации). Наработка автоматизаций (скрипт автообновления, скрипт автопроверки версий, автоочистка файлового хранилища, автоочистка каналов). Вторая версия сервера + s3-хранилище. Создаем свой сервер видеозвонков на базе LiveKit.
4) Что будет дальше? Выводы, что имеем сейчас. Графики доступности сервиса (было/стало), графики нагрузок на систему (было/стало). Новый функционал, который планируем внедрить: интеграция с внутренней HR-системой, интеграция с Outlook.

* Что было до cilium (параллельный интерактив «Какой у вас CNI»)?
* Причины появления cilium в VK.
* Эксплуатация cilium в наших кластерах.
* С какими задачами и проблемами столкнулись при эксплуатации cilium?
* Сценарии отказа cilium.
* Мониторинг cilium.
* Минусы cilium.
* Онлайн-тест — надо ли вам переходить с calico на cilium?

В google SRE book приводится статистика, что около 70% сбоев приходится на этап внесения изменений в работающую систему. То есть создание хорошего, отказоустойчивого деплоя может принести вам до 70% успеха в деле обеспечения надёжности ваших приложений.

В процессе развития IТ-индустрии сформировалось несколько популярных подходов и стратегий деплоя. Давайте разберём варианты их реализации в Kubernetes как самой популярной инфраструктурной платформы.

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

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

Один из антипаттернов наблюдаемости — это Wall of Dashboard.

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

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

Разработка рекомендательной платформы с использованием ML SOTA-алгоритмов требует больших CPU/RAM-вычислительных ресурсов. К примеру, на одном из экземпляров нашей рекомендательной платформы до оптимизации использовалось ~ 930 CPU/4,7 Tb RAM только на ML.

Мы расскажем, как при помощи динамического выделения стендов/ресурсов на базе технологий Node Autoscaler, HPA, самописного плагина для автоматического развертывания стендов можно повысить эффективность разработки, сэкономив до 30% стоимости. При этом сохранить темпы роста количества разрабатываемых фич и количества партнёров и сделать так, чтобы разработчики, в том числе и DS, могли проводить свои эксперименты, не мешая друг другу в облаке Cloud.ru.

О чем пойдёт речь:
1. О нашей рекомендательной системе и основном техническом стеке.
2. Как мы сделали feature-окружения для разработки моделей.
3. Как мы настроили масштабируемую систему в облаке для сокращения стоимости и в результате получили до 30% суммарной экономии на всех стендах.

MaaS — monitoring as service.
* Как узнавать о проблемах с сервисами до первого обращения клиента?
* Как использовать мониторинг на пользу, не подглядывая в монитор соседа?
* Как не «утонуть» в постоянно дребезжащих алертах?
* Как мониторинг улучшает отношения между бизнесом и IТ?

Расскажу, как мы поменяли 4 системы мониторинга за 4 года. Покажу 5 факапов, которые стали причиной изменений (однажды мы посреди ночи разбудили десятки человек из-за сбоя системы мониторинга).

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

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

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

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

В рамках доклада рассмотрим топ-10 угроз для LLMA, кейсы атак и способы предотвращения угроз. Проведем приоритизацию, соотнесем со знакомыми примерами и в кулуарах поделимся своими находками и «случаями на производстве».

* Уязвимости консенсусов платформы Hyperledger Fabric (Raft, Kafka, SmartBFT).
* Уязвимости и архитектурные особенности платформы Hyperledger Fabric.
* Потенциальные атаки на протоколы и компоненты платформы.

Всё, что вы положите в контейнер, может быть использовано против вас. Именно такой фразой можно описать Living off the Land (LotL) атаки.

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

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

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

В этом докладе мы поговорим с вами о базе. О тех психологических механизмах, которые лежат в основе психологии влияния. Эти основы, подтвержденные многочисленными исследованиями и экспериментами социальных психологов 20 и 21 века, крайне эффективно используются в различных областях — от фишинга, маркетинга и продаж до любовных аферистов и мошенников кол-центров «службы безопасности». Эти уязвимые механизмы — наше эволюционное наследие, legacy-код нашего мозга.

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

Доклад описывает технологию zkSNARKs, используемую для масштабирования сервисов и в различных zero-knowledge-протоколах. Эта молодая технология сейчас находится на острие развития современной криптографии, ей занимаются в топовых университетах мира, а решения на ее основе позволяют доказывать исполнение вычислений на trustless-клиентах с легкой, constant-sized-верификацией на стороне сервера. Она идеально ложится на блокчейн-технологии, где легкая верификация располагается на сильно ограниченной в ресурсах блокчейн-стороне, но и для других архитектур открывает множество новых возможностей. Например, сверхлегкие доказательства наличия пользователя в некотором списке, аутентификация без обращения к базе пользователей, доказательства нахождения некоторого значения в storage и т.п.

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

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

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

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

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

Кто такие «мы»? Мы — это направление ML Integrity в Почте Mail. ru, и мы отчетливо понимаем две вещи:
* каждая лишняя секунда, в течение которой злоумышленник имеет доступ к аккаунту, может привести к катастрофическим последствиям для пользователя;
* злоумышленники, получая доступ к почте, ведут себя, мягко говоря, аномально и крайне несвойственно для владельца ящика.

В докладе будет рассказано, как, полагаясь на эти две посылки, мы разработали систему детекта взломов — FieldMarshal (Fast Mail. Ru Supervisor Hacking Alert). FieldMarshal выявляет скомпрометированные ящики, основываясь на поведенческом эмбеддинге пользователя, причем время реакции на несанкционированное проникновение составляет считанные секунды.

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

Кроме прочего, в докладе мы осветим:
* как обучать transformer-based эмбеддинг пользователя и как знания текстовых моделей могут помочь вам в этом;
* как спроектировать систему, которая в online-режиме будет распознавать взломы в потоке действий;
* как при помощи одного большого проекта прокачать в команде ML, System Design и разработку микросервисов.

Мы рассмотрим полный путь построения новой ленты рекомендаций ВКонтакте с фокусом на персонализированном медиаконтенте. Особое внимание уделим ML, аналитической и бэкендной части задачи. Вместе узнаем, какие алгоритмы машинного обучения применимы в данной задаче, как с ними работать в рамках огромного массива данных (терабайтов). Как контролируемо ставить множество А/B-тестов и тестировать сразу много гипотез в каждый момент времени, чтобы как можно быстрее двигаться к нашей конечной цели — новой ленте. А также выясним, как построить бэкенд-архитектуру вокруг такого высоконагруженного продукта, как лента рекомендаций ВКонтакте.

Команда Антиспам (подразделение Антифрод) занимается созданием услуги по защите абонентов от нежелательных (навязчивых, рекламных) спам-вызовов, а также повышением информированности абонентов о таких звонках.

Услуга работает на уровне сети, не задействуя устройство абонента, и блокирует подозрительные звонки, перенаправляя их на голосового ассистента, а абонент получает SMS или push-уведомление о характере звонка.

Data Science в команде находит применение в:
* построении механизмов сбора и обработки обратной связи и получении разметки (таргета) на основе всех доступных источников (интернет, мобильное приложение, опрос абонентов, экспертные соображения, жалобы и обращения)^;
* построении классификатора спам-номеров, выявляющих токсичные номера с разделением на категории (финансы, медицина, опросы...)^;
* мониторинге качества решений как на офлайн (точность, полнота, скорость определения — в номерах, звонках, жертвах), так и онлайн (отток, средняя длительность, кол-во спамеров) метриках^;
* выявлении оптимальной версии модели на основе А/В-тестирования^;
* автоматизации процессов переобучения, валидации, мониторинга качества данных и инференса моделей^;
* поддержании алгоритмов в рабочем состоянии в условиях сильной сезонности и дрифта признаков, а также при приспособлении спамеров к новым условиям (под воздействием этикетки, недозвонов) и смене поведения (переход в мессенджеры, частая смена номерных емкостей).

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

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

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

И в завершение мы пройдемся по ближайшими планам, которые нам предстоят для поддержания качества алгоритмов с учетом изменения поведения спамерами (появление номеров-однодневок, перевод трафика в WhatsApp, маскировка под положительный трафик).

За последний год мы собрали, разметили и выложили в открытый доступ 3 больших датасета для различных задач компьютерного зрения (Computer Vision, CV): HaGRID, EasyPortrait и Slovo. Использование краудсорсинга платформ для разметки этих данных подвигло нас создать методы агрегации разметки, которые позволили добиться максимальной точности.

Решение обобщить эти методы на другие CV-задачи привело нас к созданию фреймворка агрегации, о котором и пойдет речь в докладе. Мы расскажем о:
* самых популярных способах разметки больших данных в CV: о краудсорсинге и нейронных сетях;
* необходимости агрегировать разметку на примере HaGRID, EasyPortrait и Slovo;
* мотивации создания фреймворка агрегации и о его реализации.

В конце продемонстрируем работу фреймворка для различных типов CV-разметки. Фреймворк доступен в Open Source, и мы планируем его поддерживать и обновлять, в том числе ориентируясь на пожелания комьюнити!

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

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

Дата-скетчи (HyperLogLog, CPC, Theta, Count-min, Fdt, KLL и др.) могут стать отличным инструментом для всех, кому необходимо извлекать полезную информацию из больших объемов данных на ежедневной основе, используя приемлемое количество времени и ресурсов.

В своем докладе я расскажу, как мы вдохновились игрой «Акинатор» (https://ru.akinator.com/), которая угадывает загаданного вами персонажа с помощью наводящих вопросов, а мы взяли за основу похожий подход и создали продукт, который помогает нашим пользователям находить товар мечты.

«Хочу новую футболку, но не знаю какую...»

Как же это работает на практике, когда в голове пользователя запрос звучит не слишком конкретно? За всем этим стоит применение машинного обучения и Computer Vision, которые позволяют определять атрибуты товаров и искать похожие на них.

Заглянем под капот Laкинатора (да-да, именно так мы его и назвали) и узнаем, как путем проб и ошибок мы выстраивали логику обучения, какие бизнес-результаты принесли.

Расскажу про связь качества моделей и меток, на которых она обучена, про способы улучшить качество меток, полученных от крауда (Toloka, MTurk и аналоги). Поделюсь историями из жизни — плохими и хорошими примерами, как можно организовать сбор меток, и как их качество помогает улучшить распознавание речи, распознавание текста по картинке, синтез речи и другие ML-модели.

Популярные распределенные SQL-движки, такие как Trino, Presto и Dremio, умеют выполнять SQL-запросы непосредственно к файлам в озере данных, что позволяет компаниям более гибко и эффективно анализировать свои данные за счет уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Подобные продукты используют принцип разделения compute и storage, при котором обработка и хранение данных происходит на разных серверах. Несмотря на многочисленные преимущества, разделение compute и storage приводит к серьезному вызову: как обеспечить высокую производительность обработки информации, хранящейся на удаленных серверах? Конкурентоспособен ли такой подход по сравнению с классическими хранилищами данных?

В докладе мы рассмотрим реализацию ключевых оптимизаций, которые позволяют Trino, Presto и Dremio быстро «перемалывать» данные из вашего озера: использование метаданных Parquet и ORC для уменьшения количества зачитываемых данных (partition pruning, project/filter/aggregate pushdown), динамическая фильтрация (runtime filtering), материализованные представления (materialized views), а также многочисленные кэши: кэш метаданных, кэш данных и кэш промежуточных результатов запросов.

Для OK Hadoop — это ключевой компонент инфраструктуры: он активно используется как для реализации продуктовой аналитики, так и для продакшна рекомендательных систем. С точки зрения объемов это более 200 PB в HDFS, 70k vcores, 200 TB RAM.

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

Поговорим о проблемах железного Hadoop, о том как запустить Hadoop в контейнерах в Облаке, а также о схемах миграции сотен петабайт (и конечно же, о проблемах в пути).

В рамках доклада хочется осветить историческую хронологию того, как человечество пришло к текущему состоянию NLP-индустрии (появление ChatGPT и других LLM), какие челленджи, сложности и препятствия стояли перед сообществом и что нас может ждать дальше.

Обсудим следующее:
1. Состояние NLP до появления модели трансформера в 2017 году.
2. Что такое языковые модели.
3. Появление GPT-1, BERT, и как transfer learning изменил индустрию.
4. Появление GPT-2 и zero-shot.
5. Появление GPT-3, больших языковых моделей и few-shot.
6. Появление инструктивных моделей Flan-T5, Instruct-GPT, ChatGPT.
7. Их возможности, ограничения и перспективы.

Представьте себе мир, где слова не используются для общения! Наш доклад раскрывает секреты создания переводчика для языка, которым нельзя говорить и писать. Узнайте, почему русский жестовый язык (РЖЯ) — не просто жесты, а мощный инструмент передачи абстрактных понятий. Какие трудности возникают при переводе РЖЯ и как их преодолеть? Будьте первыми, кто узнает о новых данных и инновационных подходах, основанных на нейросетях! Не упустите шанс овладеть новым языком — языком жестов! Готовы ли вы открыть дверь в мир без слов и звука? Мы расскажем о проблемах и особенностях русского жестового языка и как мы решаем эту задачу в нашей команде. В качестве бонуса выкладываем большой датасет в открытый доступ, что поможет ускорить реализацию AI-сервисов распознавания и генерации РЖЯ!

1. ML-ликбез. Про используемые в дальнейшем термины простыми словами.
2. Классический MLops и его принципы.
3. Почему Large Language Models действительно такие крутые.
4. Эволюция генерации языка. Как мир пришел к LLM.
5. Многообразие LLM: основные модели и их особенности.
6. Развернуть LLM и радоваться жизни: обзор способов, лицензий и требований к железу.
7. Квантизация и файн тьюнинг — убрать нельзя использовать.
8. Векторные базы данных и LangChain.
9. LLM всегда ли нужен?
10. Заключение.

Успех ChatGPT вдохновил многих исследователей попробовать технологии, которые лежат в основе обучения подобных моделей. Подход к Fine-tuning больших моделей с помощью LoRA-адаптеров, а также механизм RLHF для учета мнения людей существенно упростили решение генеративных задач. А Instruction tuning позволил использовать генеративные модели в кейсах, в которых сложно формализовать задачу заранее.

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

В своем докладе я:
* расскажу о самих технологиях SFT, LoRA, RLHF, Instruction tuning;
* покажу примеры реализации и расскажу о некоторых особенностях и подводных камнях этих технологий;
* подробно расскажу о реализованных нами кейсах в сфере HR tech;
* поделюсь архитектурными решениями;
* расскажу о ближайших планах.

В докладе расскажем о внедрении LLM GigaChat в виртуального ассистента Сбера.

Обсудим следующие вопросы:
* цель. Зачем LLM в виртуальном ассистенте;
* использование внешних навыков;
* процесс обработки запроса;
* структура промпта;
* эксперименты и результаты.

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

В этом докладе разберем следующие вопросы:
* Как выбрать современную компактную архитектуру с наилучшим балансом скорости и качества?
* Какие трудности могут возникнуть при распределенном обучении face recognition-модели на датасетах с миллионами изображений и сотнями тысяч классов?
* При помощи каких методов передачи знаний от больших моделей к более маленьким можно минимизировать потери в точности из-за сокращения размера архитектуры?

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

* Как сетки попали в прод, и что с ними произошло.
* Как получилось ускорить пайплайн в 10 раз.
* Как удалось конвертировать сеть с нетипичной архитектурой в TensorRT.
* Как удалось удачно зарефакторить код и упростить интеграцию.

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

В данном докладе будет рассмотрено развитие идей NLP от вероятностных моделей в прошлом до современных больших языковым моделей. Мы поговорим об интересных архитектурах и путях развития.

В Тинькофф робот Олег для поддержки пользователей работает несколько лет и сейчас NLP-команда обучает модели для более 1000 тематик (интентов) по разным направлениям и продуктам.

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

Поделимся, как мы в Яндексе сделали zero-cost-инфраструктуру распределенного обучения поверх распределенной транзакционной файловой системы:
1. Никаких модификаций однопоточного однопроцессного кода обучения на Python — экономим время DataScientist’а. Не нужно быть бэкендером-профессионалом, чтобы писать распределенный код обучения.
2. Никакого дополнительного оверхеда по производительности под Python GIL при переходе к распределенному обучению — улучшаем утилизацию железа.
3. Автоматическое масштабирование обучений с 1 GPU на сотни видеокарт, I/O на чтение/запись в десятки GB/s — улучшаем общую емкость систем обучения.

• Какие этапы проходила модель от pretrain-а до релиза в продукт, и с какими сложностями мы столкнулись
• Как мы починили баг в фреймворке распределенных коммуникаций NCCL и ускорили pretrain на 30% для всех
• Как уложиться на инференсе в имеющиеся вычислительные ресурсы, ускорив модель в N раз без значительных потерь в качестве

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

На мастер-классе рассмотрим как аспекты применения ИИ в разработке и тестировании, так и методы работы с ChatGPT для проектирования архитектуры. В ходе мастер-класса разберем конкретную архитектурную задачу, вместе с участниками спроектируем архитектуру решения используя ChatGPT в качестве copilot ассистента архитектора.

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

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

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

* Распределенное хранилище размером 80+ Тб.
* Проблемы масштабирования.
* Невозможность строгих гарантий.
* Откуда взялась потребность усложнять простую схему.
* Как изначально звучал продуктовый заказ.
* Как устроена транзакционность в Метрике.
* Какие проблемы возникают, когда появляются связи между пользователями.
* Как мы пошли «в лоб» и к чему это привело.
* Как мы пришли к идее «команд».
* Переход к eventual consistency.
* Планировщик и decision maker как участник конвейера.

В эпоху быстро меняющихся потребностей пользователей, платформа A/B-тестирования становится ключевым инструментом принятия решений в любом продуктовом сервисе. С учетом того, что наш онлайн-кинотеатр обслуживает миллионы пользователей по всей России и имеет нагрузку в несколько тысяч запросов каждую секунду, мы стремимся к тому, чтобы сервис сплитования трафика для А/B экспериментов был максимально незаметным для пользователей. Отсюда и цель: время ответа при расчете групп для А/В-экспериментов должно быть не более 10 мс. Поэтому возникает вопрос: как именно мы достигаем такой эффективности, и что может пойти не так?

Приглашаем вас на наш доклад, где мы поделимся тем:
* что такое A/B-эксперименты и как происходит сплитование трафика в них;
* как мы искали узкие места в производительности сервиса на Python и устраняли их;
* как нам удалось разогнать сервис до времени ответа в 5 мс в 99,9% запросов, но всё равно наблюдать большой процент запросов, отвалившихся по тайм-ауту;
* как мы расследовали причины тайм-аутов к нашему сервису и нашли проблемы там, где не ждали — в инфраструктуре. И как это обнаружение помогло другим других сервисам компании;
* что бы мы сказали сами себе, если бы встретились полгода назад.

* Как разработчик видит хайлоад (джун/мидл/сеньор);
* виды точек отказа в хайлоаде с точки зрения backend;
* память сервиса под нагрузкой;
* пулы потоков;
* пулы соединений к базе данных;
* пулы tcp-соединений;
* пулы jms-сессий и соединений;
* реактивность (project reactor) и распространенные ошибки (java/kotlin);
* прокси и балансировщики;
* примеры инцидентов и их решение (как можно было предотвратить);
* диагностика и мониторинг хайлоад-проблем (практические примеры мониторинга).

Доклад описывает принцип работы системы сканирования на роботе Spectro (на уровне компьютерного зрения), челленджи, с которыми мы столкнулись по Perfomance во время разработки, как выполняется базовая бизнес-логика для проведения инвентаризации робота, а также какие результаты собирает робот и как склад ими пользуется уже сейчас.

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

Здесь мы сталкиваемся с проблемой обеспечения прямой и обратной совместимости: что произойдет при обновлении одного из компонентов независимо от другого?

Если бы компоненты были микросервисами, в качестве интерфейса выступал бы JSON поверх HTTP или другой высокоуровневый протокол RPC. Но мы хотим сочетать независимость развития компонентов с нативным вызовом функций и нативным представлением структур.

Доклад дает обзор подходов к этой проблеме и набор практических приемов.

Мы в Flussonic два года назад резко перешли на API-first-подход к построению систем, и это было необходимо для возможности расти и развиваться. Мы внедрили OpenAPI 3.1 для коммуникации сложных систем на Erlang, Golang, Python, Rust, Rails, C, Node.js. Репозиторий со схемами стал местом, где бизнес может договариваться с разработкой на простом и формальном языке. В нём сейчас 56 тыс. строк кода в YML-файлах и 140 тыс. строк кода в результирующих json-файлах.

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

В докладе будет рассказано про доработки инструментов вокруг такого репозитория с OpenAPI-схемами, который становится главным местом сборки целой компании.

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

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

Основной причиной появления FinOps стало увеличение неэффективности использования облачных ресурсов. Данный показатель называется cloud waste и на текущий момент равняется 30% — это означает, что около 30% всей облачной инфраструктуры, которые используют различные организации в мире (или около 147 миллиардов долларов) потрачены впустую, не принося никакой пользы владельцам инфраструктуры.

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

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

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

О чем поговорим: как нам балансировать рост бизнес-нагрузки и возможность по производительности и отказоустойчивости АС на примере комплекса розничных CRM-систем Газпромбанка.

* Что такое опенсорс для Яндекса?
* Почему мы выкладываем наши технологии в открытый доступ.
* Как структурировать работу с опенсорс внутри большой корпорации? Какие подходы сегодня есть, и как это делает Яндекс, разделяя проекты по разным типам?
* Open Source и Inner Source как двигатель культуры разработки внутри компании.

* Организация, настройка и поддержка платформы Kubernetes в Мир Plat.Form.
* Интеграция команд проектов в Kubernetes.
* Полезные инструменты управления, которые зарекомендовали себя.

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

* Что кроется за привлекательностью событийной архитектуры и риски распределённой архитектуры.
* Нюансы нагрузки при разработке событийной архитектуры.
* Инфраструктурные вопросы при переходе на событийно-ориентированную архитектуру и микросервисы.
* Возможно ли в организации бесконечное хранение событий?
* Организационные вопросы при переходе на событийную архитектуру.

Осенью Яндекс запустил уже вторую версию собственной LLM — YandexGPT 2.

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

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

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

* Что такое легаси-система на примере автоматизированной системы по обслуживанию кредитов в Газпромбанке.
* Инженерные практики в работе и улучшении легаси-систем.
* Методология и подводные камни миграции.

Почему C4-модели мало и сколько слоёв архитектуры нужно большой организации.

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

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

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

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

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

Крупная федеральная сеть салонов красоты. До 20 000 сотрудников, занятых в процессе украшения мира, но дисциплина прихрамывает. Задача: собирать фотоотчеты от каждого сотрудника и проверять их за 10 минут до утренней планерки в разных часовых поясах... или о том, как Telegram боты спасают топ-менеджеров в 2023 году.

Тезисы:
* Как не напугать сотрудников и подключить их к сервису слежки и контроля.
* Куча контента для SMM как приятный бонус при реализации чат-бота.
* Какие есть реальные ограничения Telegram, и как этично их можно преодолеть. Реальные цифры требуемого железа под сервисы.
* Нейронки в проде, или Как по фото определить соблюдение корп. стандартов.
* Интеграция YClients и особенности работы API.

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

* Как понять, что нам нужно нагрузочное тестирование?
* Как быть, если у нас мало опыта и ресурсов?
* Как разобраться в результатах?
* Я — менеджер, и что мне может дать проведение НТ?

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

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

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

В докладе вы узнаете про особенности построения хранилища YDB на HDD на примере архитектурного кейса крупнейшей системы мобильной аналитики в РФ.

* Кратко расскажем про процессинги аналитических продуктов и как устроен в них стейт.
* Нагрузки и требования.
* Как мы пришли к порядковому росту размера стейта (с 100 терабайт до петабайта).
* Как мы на этом сэкономили.
* Какие были варианты.
* Какие были трудности при записи и при чтении.
* Ложка дегтя в смысле загрузки ресурсов.
* Как мы выбираем, куда поместить данные, и как именно мы это делаем.
* Как мы управляем этим стейтом.
* Как мы справляемся с нагрузкой (12 gbit/sec).

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

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

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

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

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

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

Мы в 1С уже очень давно строим фреймворки для своих пользователей. И, конечно, при создании своего PaaS-облака, при разработке его слоя управления (админки и control plane) решили использовать свой веб-фреймворк, в котором решены такие вопросы, как управление пользователями и правами доступа, есть встроенный BI для очень наглядных графиков и многое другое.

МТС — это огромная экосистема продуктов, в которой каждую секунду происходят тысячи взаимодействий между компонентами. В 2019 году мы запустили внутренний сервис распределенной трассировки, чтобы помочь командам отслеживать ошибки в работе экосистемы. За это время мы прошли длинный путь, подключив 1000+ сервисов, научившись обрабатывать 150 тысяч спанов в секунду и несколько раз поменяв архитектуру решения.

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

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

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

Облака — это не только независимая инфраструктура где-то в интернете. Это еще и непосредственные физические сетевые стыки с крупными клиентами прямо в их ЦОДах. Чаще всего сети — это ответственность сетевых инженеров. А у них обычно все построено на вендорном железе. Но что делать в том случае, если привычных всем вендоров больше нет?

Поговорим о проблемах вендорных решений, использовании их на примере такой задачки, как организация внешних стыков облака. Расскажем о том, как сделать то, что предоставляют вендоры из подручных материалов. Представим свою реализацию EVPN VTEP из стандартных Open Source-инструментов — OpenVSwitch, gobgp, Python.

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

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

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

В своем докладе я расскажу о том, как на коленке написать детектор аномалий, который будет перемалывать несколько тысяч метрик в минуту и работать одновременно с данными из Zabbix, Graphite, Prometheus, Clickhouse да и вообще с любой БД или системой мониторинга.

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

За все время существования мы привыкли к линейному росту — каждый год продукт увеличивался в 1,5-2 раза, но в 2021 году все изменилось. Для запуска важных продуктовых инициатив нам требовалось поддержать рост х20 и несмотря на то, что мы имели неплохой «запас прочности», к таким цифрам мы не были готовы.

На Saint Highload++ 2023 я уже рассказывал, как мы готовили к росту один из наших сервисов (highload.ru/spb/2023/abstracts/10416). В этот раз я поделюсь опытом поддержки роста х20 уже на уровне всей компании и расскажу:
• как мы искали узкие места и потенциальные точки отказа среди нескольких десятков сервисов, через которые проходит объявление перед тем, как попасть на Авито;
• о подходе к нагрузочному тестированию, который позволил нам за квартал справиться с задачей, которую мы изначально оценили в несколько человеко-лет
• об основных проблемных местах в нашей архитектуре и решениях, которые помогли с ними справиться;
• о концепте инструмента прогнозирования нагрузки и проактивного поиска проблемных мест, который в будущем поможет исправлять их заранее.

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

Метод — архитектурный редизайн.

Результат — успех.

В докладе представлено пошаговое решение с обоснованиями и демонстрацией модели производительности.

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

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

Также обсудим самые популярные вопросы и заблуждения CQRS:
* могут ли команды возвращать значения. Если нет, то почему?
* могут ли query писать логи?
* что делать, если две команды должны использовать общую логику?
* поможет ли CQRS при росте нагрузки на сервис?

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

Мне в Uzum выпала уникальная возможность написать сервис для процессинга заказов с нуля, и я расскажу, с какими проблемами предстоит столкнуться, если вы тоже выберете Temporal для построения вашей собственной Order Management System, а также покажу, как оценить производительность подобной системы.

Мир не идеален — любая крупная система состоит из множества отдельных подсистем. Не все из них мы можем контролировать при работе над нашей задачей. А согласно закону Мёрфи, если что-нибудь может пойти не так, оно ОБЯЗАТЕЛЬНО пойдёт не так. Применительно к созданию распределённых систем это означает, что абсолютно всё вокруг когда-нибудь сломается.

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

Расскажем про практики и свой опыт создания софта с self-healing на принципах closed loop automation (что является основной причиной высокой стабильности всеми любимого K8s), сравним с привычным в индустрии event-based-подходом, и честно признаемся об увеличении накладных расходов и излишней трате денег работодателя в счёт своего спокойного сна ночью.

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

Ранее наша команда рассказывала, как в товарном поиске Яндекса строится база: https://highload.ru/moscow/2022/abstracts/9515. А в этом докладе расскажем о рантайм- и ML-части нашего поиска.

Поиск по товарам Яндекса — это сервис, работающий над базой из более, чем миллиарда документов под нагрузкой свыше десяти тысяч RPS. Казалось бы, разработка архитектуры поиска такого масштаба — понятная и решенная задача, но появление приставки ecom добавляет к общей схеме несколько существенных доработок.

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

Дано: распределённая сервисно-ориентированная система с сотнями пользовательских запросов в секунду.

Цель: получать молниеносный ответ на пользовательские запросы без исполнения задач в IT-инфраструктуре.

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

Внутри доклада:
* Подходы к работе с обработкой запросов в микросервисной архитектуре.
* Варианты доступных на рынке решений (Redis, Hazelcast, Apache Ignite, Memcached).
* Опции Hazelcast: критерии выбора Open Source vs Enterprise.
* Опыт использования: примеры проблем и рекомендации.
* Границы применимости бесплатной библиотеки Hazelcast.

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

VK Mini Apps — это открытая платформа для встраивания кроcс-платформенных приложений, расширяющих возможности ВКонтакте как на вебе, так и на iOS- и Android-клиентах. Сейчас мини-приложения глубоко проросли в инфраструктуру VK. Их используют миллионы пользователей ВКонтакте.

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

Расскажу, как устроена платежная система Яндекса, которая обрабатывает платежи от всех сервисов компании. Из доклада вы узнаете, что FinOps — это:
* не бывшие Яндекс.Деньги, а отдельная система;
* высоконагруженная платежная система, обрабатывающая до 1,2 тыс. платежей в секунду;
* повышенные требования к надежности и отказоустойчивости (мы должны быть ещё более надежными, чем самый надежный сервис Яндекса). Минуты простоя — это убытки в миллионы денег;
* широкая география приема платежей — от Перу до Эмиратов;
* event sourcing-система, написанная на Golang, работающая в 3 ДЦ, использующая YDB.

И ещё много чего полезного.

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

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

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

В своем докладе я расскажу, как мы внедряли ЦР, а именно:
* что такое Цифровой Рубль;
* правила обмена с Платформой ЦР. Этапы подключения к Платформе ЦР и проведение пилота;
* трудности реализации ЦР;
* особенности реализации бизнес-процессов ЦР. Отличия цифровых рублей от безнала;
* текущая архитектура ЦР в экосистеме Банка. Система взаимодействия с платформой ЦР, её интеграции, реализация требований ЦБ;
* встраивание SDK ЦБ в наш мобильный банк;
* Vertical Slice в реализации проекта;
* планы на будущее развитие ЦР.

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

На примере внедрения в Яндекс.Go новой технологии Live Activity от Apple поговорим про:
* сложность отладки и поиска проблем асинхронных задач;
* почему не нужно пытаться брать слишком много задач на каждую ноду;
* как быть, если асинхронность добавляется еще и на клиенте;
* почему в таких случаях не стоит пользоваться вашей основной базой данных;
* как держать ваше состояние консистентным без возможности сервисам сообщать о своем состоянии друг другу;
* зачем нужно иметь возможность конфигурировать выполнение таких задач.

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

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

В этом докладе я бы хотел рассказать о том, почему мы отдали предпочтение event sourcing вместо CDC, какие альтернативы для описания схем рассматривали, почему в итоге остановились на avro и как автоматика помогает нам контролировать все изменения.

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

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

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

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

Мы поговорим про два вызова продукта класса NGFW с точки зрения разработки:
* как быстро обрабатывать большой объем трафика? Spoiler — сетевой стек Linux нам не друг.
* развеем мифы про железо. Может ли NGFW обойтись без специализированного и дорогостоящего железа? И если да, то чем за это придется заплатить?

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

Миграция СУБД с одной технологии на другую — достаточно сложный процесс, который связан не только с конвертацией кода и переливкой данных, хотя и здесь есть неочевидные нюансы.

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

В июле 2022 года, собрав команду из ведущих инженеров, работавших над разработкой и поддержкой веб-сервера nginx, мы открыли свою компанию — «Веб-Сервер» и начали разработку Angie — российского веб-сервера с открытым исходным кодом.

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

Информативно. По делу. Отчет за год, без лишней воды.

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

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

Первые компьютеры разрабатывались не «с нуля».

В докладе спикеры расскажут о развитии ткацкого ремесла (процесс переплетения нитей и создания ткани), в результате развития и оптимизации которого был создан ткацкий станок с перфокартами… а там и до ЭВМ пара шагов: вычислительная машина Бэббиджа, язык Ады Лавлейс для программирования этой машины, калькулятор Шойца, табулятор Холлерита, аналоговый компьютер Буша и машина Тьюринга, ну а дальше семимильными шагами в 21 век и современность.

Также можно будет попробовать работать с ткацкими инструментами и за станком.

Задумывались ли вы когда-нибудь, что значит вся эта наша «биг дата» в масштабах математики? Насколько миллиарды пользователей и терабайты данных далеки от по-настоящему «биг»-величин?

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

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

Tarantool — это платформа для in-memory-вычислений, написанная на C/C++ и Lua. Миры Lua и С/C++ очень тесно связаны: у Tarantool есть модули на Lua, модули на Lua могут использовать модули, написанные на C/C++. В процессе исполнения и в Lua-коде, и в C/C+±коде могут возникать исключения, которые иногда необходимо обрабатывать в другом компоненте, может быть написанном на другом языке.

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

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

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

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

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

Я расскажу, как сделать наличие проблем с точностью видимым, на примере реализации нашего раcширения XNumPy библиотеки NumPy на Rust и Cython, автоматически вычисляющего точность расчётов. Это почти не требует изменений в коде и снабжает те же результаты математической оценкой их точности. Я расскажу, какие математические и программистские приёмы позволили сделать расширение производительным.

Поговорим о трейсинге в Авито: какую он задачу решает, и как у нас выглядит архитектура трейсинга, обрабатывающая миллионы спанов в секунду от нескольких тысяч сервисов, объединенных в service mesh (который, как оказалось, помогает). Расскажем, как мы меняли подходы к семплированию данных и почему мы ушли от Jaeger к OpenTelemetry и собственному инструменту, объединяющему трейсинг, логи и метрики.

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

Для проведения Cybercamp (это созданная нами платформа киберучений, где участники выполняют задания в формате CTF) необходимо было предоставить доступ к платформе (создать рабочие места, изолировать команды друг от друга, выдать необходимые сетевые доступы) 500 участникам. Эти рабочие места содержат в себе целый арсенал инструментов для отработки навыков Red и Blue Team.

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

В результате нам удалось 2 года подряд проводить киберучения без инцидентов ИБ и каких-либо простоев, затрачивая минимум усилий на поддержку мероприятия во время его проведения.

Расскажу, как мы внедрили межсервисную авторизацию на базе Open Policy Agent для более чем 2000 сервисов, работающих на PaaS и при этом не сломали прод и сознание разработчиков от написания авторизационных политик на языке rego. Мы обеспечиваем стабильность работы описываемого решения в нашем service mesh в продакшне, даем возможность управлять доступами вплоть до каждого endpoint'а, и избегаем поломок из-за случайного некорректного закрытия доступов.

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

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

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

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

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

Спойлер — никак:) Но мы умеем обеспечивать прозрачное сетевое взаимодействие подов во множестве кластеров Kubernetes так, как будто все они размещены в одном огромном «суперкластере». Мы используем Istio, но не используем Istio Multicluster. В докладе я расскажу, как все это работает.

Представим, что вы предприимчивый лидер инженерной команды, которая предоставляет зрелую платформу для разработчиков широкому кругу команд в вашей компании. Компания достаточно большая и быстро растет, затраты на платформу становятся видны на основных финансовых радарах. Продукты компании являются или претендуют на то, чтобы быть самостоятельными бизнесами, в любом случае их волнует собственный P&L. В этот самый момент вы можете столкнуться некоторыми из нижеперечисленных проблем:
* потребители не знают, во сколько им обходится платформа. Рассматривают ее как условно бесплатное образование и медицину в СССР, с соответствующим отношением — не вдумчивым потреблением;
* руководство компании не знает, как гибко контролировать траты на платформу, на каких потребителей нужно создавать давление и какое;
* потребители создают давление на платформу вида «перееду во внешнее облако, там лучше и дешевле»;
* руководитель платформы сталкивается со сложностями в обосновании роста команды платформы, каждый раз приходится искать новые аргументы;
* если потребители — самостоятельные бизнесы, то у них возникают сложности с расходными статьями в P&L.

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

В моем докладе вы узнаете:
* что такое Yandex Infrastructure и Yandex platfrom engineering, кто ее потребители и какую задачу мы решали;
* зачем брать деньги с пользователей, за что и когда целесообразно начать это делать;
* платформа — это cost center, profit center или что-то посередине;
* модель аккаунтинга — как выявить потребителя и построить иерархию потребления;
* модель тарификации — SKU, сколько стоит железо и люди. CAPEX или OPEX?
* люди и железо — какие драйверы изменений?

Движение опенсорс имеет огромные масштабы, оно разношёрстное и даже выгоду от него получают по-разному!

Про выгоду и будет рассказ! Представим себя начинающим разработчиком, погрузимся в дивный мир «бесплатной работы» и поймём, зачем оно нам. Дорастём до разработчика в большой компании, приятно удивимся и осознаем, что всё базируется на опенсорс. Ну, а напоследок — уже выложим корпоративный проект в опенсорс и осознаем плюсы от такого шага.

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

В рамках доклада мы сфокусируемся на нашем опыте и приведем примеры следующих технологий:
1. Сравнительное тестирование фирменного решения контейнерной виртуализации iSula с решениями Docker/Podman. Мы провели тестирование, включающее измерение временных затрат на ключевые операции при запуске 10, 100 и 1000 контейнеров как последовательно, так и параллельно.
2. Наш опыт использования единой кодовой базы OpenScaler/openEuler для создания специализированных дистрибутивов для Edge-устройств архитектур X86/ARM/RISC-V.

В 1997 году в интернете сидели около 400 тысяч россиян, а сейчас среднемесячная аудитория рунета составляет более 100 миллионов пользователей. Вместе с количеством пользователей за 25+ лет выросло количество интернет-сервисов, объемы обрабатываемых и хранимых данных, сложность используемых технологий.

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

Мы вспомним, как менялись технологии разработки — от Apache и PHP на отдельных железных серверах, до текущего многообразия способов написать веб-сервис и облачных технологий. Проследим путь от проприетарных универсальных СУБД до появления специализированных опенсорсных систем обработки и хранения, от ручной проверки и выкладки по FTP до масштабных систем CI/CD и многое другое.

Также в докладе вас ждет большая новость о новой инициативе от Yandex Open Source.

Yezzey — открытое расширение GreenplumDB, которое позволяет перенести таблицу в S3, но при этом сохранить нативный формат данных. При таком подходе производительность многих запросов оказывается сходной с производительностью запросов к таблицам на локальных SSD-дисках.

Эта технология — очередной шаг в направлении облачной аналитической СУБД для Greenplum, при этом весь код доступен в open source. В докладе я хотел бы также рассказать и о будущих шагах на этом пути.

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

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

Важные составляющие успеха опенсорс‑проекта — это сообщество пользователей и сотворчество контрибьюторов. В докладе я расскажу, как с помощью инструментов DevRel и маркетинга развивать сообщество, поддерживать совместное творчество и наращивать популярность проекта. А еще поделюсь списком метрик здоровья опенсорс-сообщества, который я составила и проверила на практике за время работы с Apache Ignite.

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

Проект вырос, окреп, популярен. Планы были амбициозные. Мы это сделали. А вот поддерживать и развивать... как?

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

Всё на примере популярного PHP-фреймворка Yii.

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

В 2013 году был создан репозиторий Gitee как национальная альтернатива Github. К 2023 году на Gitee было зарегистрировано более 7 миллионов активных разработчиков, более 25 миллионов репозиториев и подключено более 2000 университетов Китая. Это сделало Gitee вторым крупнейшим репозиторием Open Source-проектов в мире после Github.

В 2020 году ведущие компании Китая — Alibaba, Baidu, Huawei, Inspur, 360, Tencent и China Merchants Bank — создали национальный фонд OpenAtom для поддержки развития проектов с открытым исходным кодом в Китае. Сегодня проекты этого фонда, такие как openEuler и OpenHarmony, объединяют десятки тысяч индивидуальных разработчиков и тысячи китайских компаний, что делает их крупнейшими Open Source-сообществами в мире и основой национального IТ-суверенитета Китая.

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

ALT Linux Team — это международная команда разработчиков, объединённая вокруг репозитория свободного ПО — проекта Сизиф. Ключевая особенность деятельности команды ALT заключается в открытом подходе к разработке. Все, в том числе и проприетарные продукты компании «Базальт СПО» — дистрибутивы семейства Альт — поставляются в исходном коде, а компоненты, составляющие эти продукты, доступны по свободным или открытым лицензиям (за исключением закрытых драйверов и программных решений некоторых известных компаний).

* Где и как можно встретить наработки команды ALT?
* Какие свободные проекты разрабатывает команда ALT для корпоративных задач?
* Как, вообще, работает модель разработки «бесплатных» программ с точки зрения разработчика?

Open Source-продукты с каждым годом все сильнее входят в нашу жизнь и активно двигают индустрию вперед. Без ряда решений уже сложно представить современную индустрию — Kubernetes, OpenStack, Prometheus, Grafana и еще множество подобных продуктов различного масштаба и выполняемых задач. Вокруг многих из них существуют комьюнити. Однако далеко не весь код, хранящийся в Open Source на различных git-платформах, хорошо изучен и активно разрабатывается. Очень важно не только добавить новый компонент в свою систему, но и убедиться в том, что он не принесет в нее новых бэкдоров и уязвимостей.

В докладе мы расскажем вам:
* как сделать ревью и приемку Open Source-решения;
* как сделать его харденинг;
* какие решения можно использовать для сканирования на уязвимости;
* дадим чек-лист по приемке Open Source-компонента на «боевое дежурство».

В основе наших сервисов лежит Open Source-распределенная база данных — Apache Ignite, точнее, наш продукт, на ней основанный.

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

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

Не обойдем стороной и тему сотрудничества Open Source и Enterprise в нашем случае и в общем, риски и выгоды обеих сторон.

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

Проекты в Open Source разрабатываются так, что задаешься вопросом — почему же все это не превратилось в хаос? Как эти люди, вообще, способны выпустить завершенный, работающий продукт?

В этом докладе мы поговорим о том, как устроен проект OpenJDK. Он будет интересен тем, кто хочет разобраться в процессах крупного Open Source-проекта и унести что-то себе.

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

Но что, если вы обычная аутстаффинговая компания? Моя компания занимается аутстаффом: мы нанимаем разработчиков, обучаем их, и затем они работают на проектах наших клиентов, где редко можно встретить Open Source.

Несколько лет назад, смотря на успехи Open Source и на то, как мы заботимся о наших сотрудниках, я решил провести эксперимент. Что, если помогать разработчикам с их начинаниями? Оплачивать личное время работы над проектами, помогать им с дизайном, сайтами для их pet projects. Рассказывать об их Open Source силами нашей редакции. Использовать проекты для обучения разработчиков и много чего еще. Я выделил бюджет, наметил процессы, и эксперимент начался.

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

Это доклад о том, что я хотел сделать, что получилось, а что пошло совсем не так, как ожидалось.

Дженерики, которые ранее были темой для холивара, плотно вошли в нашу жизнь, но вы когда-нибудь задумывались, что стоит за [T any]? Почему дженерики Go именно такие, и чем они отличаются от других языков? Какой магией они обладают, и что такое «gc shape»?

Стандартная библиотека Golang, в частности пакет database/sql, предоставляет универсальный интерфейс общения с базами данных. Однако он далеко не сразу имел сегодняшний вид. Мы в команде YDB имели драйвер для нашей базы данных, начиная с версии Golang v1.11, и сталкивались с различными трудностями в процессе эксплуатации в продакшнах наших пользователей.

Этот ретроспективный доклад о том, какие недочеты были в пакете database/sql, во что это выливалось при эксплуатации и как он становился все лучше от версии к версии Golang.

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

Например, из него вы узнаете:
* почему не все for-range-циклы равны между собой;
* что такое small-size-объекты;
* какие палки в колеса вставляет escape analysis и как их обойти.

Создание новой версии реестра национальной доменной зоны BY и БЕЛ.

В докладе расскажем о:
* истории и основных принципах работы национальной доменной зоны BY (БЕЛ);
* разработке Gо-сервиса, работающего по протоколу TCP;
* выявлении узких мест при нагрузочном тестировании;
* проблемах с надежностью работы сервиса с внешними клиентами при нестабильной работе сети;
* профилировании приложения на проде и выявлении глупых ошибок программиста.

Возникла необходимость улучшения системы хранения данных о товарах. Мы решили построить систему на базе Kafka, Confluent и kSQL для обработки огромного объема быстро меняющихся данных о товарах при ~9к сообщений в секунду в пиках при штатной работе и ~50к в секунду при нештатной работе.

В докладе расскажем о следующем:
* причины, по которым мы решили написать свою ETL-систему и выбрали эти технологии;
* как построить решение на основе Kafka, Confluent и kSQL для обработки большого объема меняющихся данных и создать микросервисную архитектуру на Go с помощью небольшой команды;
* проблемы, с которыми мы столкнулись при разработке и использовании данной системы;
* как мы решили эти проблемы, переписав часть системы (Sink-коннекторы) на Go.

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

Кроме решения бизнес-задачи (достижения нужного time-to-market), ещё это интересно вот почему:
* сервис-хранилище позволил нам обеспечить изоляцию структуры данных в БД от потребителей этих данных;
* одновременно мы решили проблему большой вариативности запросов при помощи составных индексов и партиций;
* смогли сохранить баланс между единой ответственностью сервисов и небольшим их количеством с помощью сервисов обвязки.

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

В своём докладе я расскажу о том, к каким практикам мы пришли на нашем объёме и почему типовые решения «1 сервис — 1 поставщик» не так хороши, как кажется.

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

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

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

В докладе расскажем, как мы делали систему управления остатками и ценами:
* какие технические сложности возникают при больших объемах данных (~30к магазинов, ~10-20к SKU, ~ 500 млн строк, 150к/рпс на запись);
* монолит vs микросервисы. Что выбрали и с каким сложностями столкнулись;
* Postgres vs Tarantool. Не самый очевидный выбор;
* работа с Kafka: конфигурация, графики, семантика «exactly-once», драйвер kafka-go от segmentio;
* согласованность в конечном счете — когда и зачем ее можно применять, как достичь;
* извечный вопрос: предподготовить данные или рассчитать на лету? Мы выбрали гибридный подход;
* на какие метрики ориентировались: технические и бизнесовые;
* покажем наши дашборды, расскажем, как мы мониторим асинхронную систему и проводим нагрузочное тестирование, графики ТТХ, нагрузки, таймингов.

DDD — подход, состоящий из множества элементов, и, если смотреть на этот клубок сверху, можно ужаснуться и отложить все его преимущества в долгий ящик.

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

Взяв CRUD, с которого чаще всего начинают множество проектов, мы постепенно соберём бизнес-правила и преобразуем кусочек за кусочком в доменную модель, применяя тактические паттерны DDD (Factory, Value Object, Entity, Aggregate, Repository), учитывая все их особенности в Go.

Дополнительно я познакомлю вас с опенсорсными инструментами, которые нам помогают дружить: Go Way и DDD. Они:
* позволяют не плодить getter и setter через сохранение публичных свойств у структур, но с запретом их редактировать вне домена;
* следят за тем, чтобы слои инфраструктуры и приложения не врастали в домен;
* отделяют представления (БД, API и т. д.) от домена.

Расскажу, с какими особенностями языка Go я столкнулся при разработке open source-приложения для стриминга видео в реальном времени — go2rtc.

В частности:
* оптимизации при работе с []byte,
* упрощение кода с помощью io.Reader / io.Writer,
* снижение CPU при работе с сетью с помощью bufio.NewReader / bufio.NewWriter / io.Copy,
* использование http.ResponseWriter для потоковой передачи данных,
* тонкости применения reflection для JSON, YAML и при написании своего Marshaler,
* архитектурные решения проекта go2rtc.

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

В этом докладе мы погрузимся в мир Protobuf и инструмента buf — мощной утилиты для линтинга протофайлов, проверки обратной совместимости API, генерации кода и валидации запросов. Я расскажу о разнообразии фич и удобств, которые предлагает buf.

Однако, как и в любой бочке меда, есть ложка дегтя — его недоступность в России из-за санкций. Эта проблема подтолкнула нас к разработке собственного решения, замещающего сервер buf.

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

Используете PostgreSQL с jsonb, но соскучились по mongo — тогда вам нужен FerretDB! Это написанный на Go прокси-сервер запросов mongo в SQL с открытым исходным кодом, совместимый с драйверами для разных языков и разными инструментами для mongo. Инструмент активно развивается.

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

Никаких happy path! Рассказ о том, как нам перестало хватать баннера «Что-то пошло не так» и как мы учились сообщать пользователю об ошибках во время выполнения запроса в системе хранения данных. Мы рассмотрим средства для работы с ошибками в Go, чем они хороши и что делать, если на пути встает сериализация.

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

Это доклад о том, как выжать максимум из кодогенерации.

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

Как пользователи продуктов, мы довольно часто используем возможность исполнения скриптов. Самый очевидный пример — это написание плагинов к nginx (lua) или traefik (go). Есть и менее наглядные примеры — строка к json-элементу в утилите jq также парсится и разбирается как скрипт.

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

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

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

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

Инженерам свойственно разбираться во внутреннем устройстве систем и залезать туда, куда не просили: кто в детстве не разбирал будильник или в молодости не дампил базу через SQL-инъекцию. Не так давно я наткнулся на термин, который используется внутри планировщиков — work stealing. Конечно же, меня больше всего заинтересовал глагол «stealing» и возник вопрос: «А можно ли влезть в планировщик снаружи и украсть, например, горутину?».

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

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

Как ускорить ваш код на Go с помощью арен?

В этом докладе мы погрузимся в мир «region-based memory management», расскажем о том, зачем оно нужно, и дадим советы по оптимизации кода. Присоединяйтесь, чтобы сделать ваш Go-код ещё лучше!

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

А что делать, если не устраивает что-то посерьезнее, чем библиотека логов?

Мы используем свои сервера раздачи контента; готовимся к переезду в собственное распределенное хранилище объектов; используем JIT-пакетирование и шифрование видео на лету и все это пишем на Go.

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

Stateless Postgres Query Router — production ready open-source-решение для горизонтального масштабирования PostgreSQL через шардирование. Система работает по протоколу Postgres и написана на Go.

Мы расскажем:
* как оно устроено и работает внутри;
* что нужно, чтобы собрать прокси postgesql-протокола своими руками;
* почему иногда для значительного увеличения производительности достаточно просто обновить зависимости;
* как написать свой лексер запросов, если pganalyze/pg_query_go слишком медленный.

Знаете ли вы, что IDE можно расширять под себя? Делать что-то кастомное, уникальное, нужное лично вам. Мы, ВКонтакте, сделали несколько плагинов, которые кардинально упрощают жизнь бэкенд-разработчикам. Теперь готовы поделиться опытом: как их делать, что нужно знать, каким образом IDE хранит код, как реверс-инжинирить при отсутствии документации и даже что делать в связи с уходом JetBrains из РФ. А главное — идеи и принципы никак не зависят от специфики ВКонтакте и точно могут быть обобщены на ваши задачи и процессы.

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

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

Представьте, вы пришли на интервью. Какой вопрос будет первым? Что-то про slice или map. А что потом? Ну, наверное, что-то про concurrency и как устроена многопоточка в Go. Вы думаете: «Ну почему опять эти базовые вопросы. Это же так просто».

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

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

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

Как попасть в Big Tech? Этим вопросом задается большое число разработчиков, поэтому я решил рассказать о бинарных деревьях, которые встречаются на собеседованиях топовых Big Tech-компаний в России.

Мы начнем с базовой терминологии, чтобы всем было комфортно, а закончим разбором задач с собеседований, и за время доклада ты:
* узнаешь о 5 разных обходах деревьев;
* решишь 3 задачи с собеседования;
* разберешься в решении 9 задач.

Чтобы получить максимум пользы от доклада:
* возьми ноутбук,
* зарегистрируйся на leetcode.

* Возможно ли пройти собеседование на сеньора при помощи chatGPT?
* Как использовать chatGPT эффективно, отвечая на вопросы и генерируя код на Golang?
* Как изменить процесс собеседования, чтобы действительно проверить знания разработчика?
* Что действительно нужно учить в Golang, чтобы соревноваться с chatGPT?

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

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

В этом докладе я расскажу, как перенёс идеологию фикстур из pytest в Go.
Фикстуры позволяют писать очень лаконичные тесты и не отвлекаться на подготовку окружения.

* Значительная часть теста может отводиться на подготовку окружения;
* фикстура — инструмент для получения окружения «без подготовки»;
* покажу, как выглядят фикстуры в pytest и Go;
* расскажу о возникших задачах реализации и принятых решениях.

Из доклада вы узнаете:
* что такое fuzzing-тестирование и чем оно отличается от обычного unit-тестирования с рандомайзером;
* как можно сгенерировать необходимые данные для теста на основе входящих случайных данных от метода t.Fuzz();
* в каких случаях лучше всего применять fuzzing-тестирование и как оно находит баги, где, казалось бы, их быть не должно.

Кроме того, я расскажу, как мы в Wildberries планируем применить fuzzing для нагрузочных и интеграционных тестирований.

Результаты использования fuzzing-тестирования:
* сократилось количество обращений пользователей в техподдержку по вопросам функционала сервисов контента;
* счастливые QA;
* счастливые ИБ.

А давайте представим, что внезапно нам выключили GitHub, или, например, мы не сможем скачать и поставить себе свой GitLab. В целом не выглядит как что-то невозможное, ведь terraform'ом пользоваться уже не так приятно, как раньше. И аналогов систем хранения кода полно, но вот что делать с DevOps Platform-функциональностью? Чем заменить?

Мы в Last.Backend давно делаем систему управления инфраструктурой и поняли, что в этом случае нам надо как раз добавить только git, а остальное вроде как и есть. В докладе я хотел бы поделиться, как и какими инструментами и пакетами мы пытаемся этого добиться. Как и почему делаем это на Go и почему нам пришлось изобрести собственную базу данных, чтобы сделать это хорошо и максимально быстро.