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

Базы данных и системы хранения (14)

Транзакционная репликация в YTsaurus

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

Доклад принят в программу конференции

Устройство индексов в почте Mail.ru

Миграции данных
Электронная почта
Бэкенд / другое
Базы данных / другое
Отказоустойчивость
Оптимизация производительности
Распределенные системы
Оптимизация
Хранилища
Обработка данных
Рустем Гафаров

Почта Mail.ru, VK

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

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

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

Доклад принят в программу конференции

BARSiC — асинхронная репликация и консенсус для 70 баз данных

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

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

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

Доклад принят в программу конференции

Как пережить спринт в 1 год и переехать в Clickhouse

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

Доклад принят в программу конференции

Как мы построили платформу данных из 300 витрин общим размером 10,5 ПТб на базе Hadoop и GreenPlum со стабильной обработкой ежедневного инкремента в 15Тб

В докладе рассмотрим:

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

Доклад принят в программу конференции

Когда нужно делать свою базу данных

Распределенные системы
Оценка сложности проекта
Хранилища
Обработка данных

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

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

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

Программный комитет ещё не принял решения по этому докладу

YDB оптимизации производительности под ARM

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

Программный комитет ещё не принял решения по этому докладу

Частичная модификация объектов в Yandex Object Storage: как мы улучшаем работу ФС поверх S3

Распределенные системы
Работа с облачными сервисами
Хранилища

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как при помощи бумаги, карандаша и алгоритма Raft достичь консенсуса

Распределенные системы
Алгоритмы и их сравнение
Теория
Расширение кругозора

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

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

Доклад принят в программу конференции

Поиск по образцу на последовательностях строк в БД

Задача поиска по образцу на последовательности строк БД может возникать в различных сферах деятельности. Например, в финансовой аналитике - поиск определённых паттернов изменения цены акций; в системах управления безопасностью (SIEM) - поиск последовательностей событий, которые могут свидетельствовать об инциденте безопасности, IoT и многих других.
Для реализации таких запросов к базам данных в стандарте SQL:2016 была введена конструкция MATCH_RECOGNIZE, которая постепенно появляется в популярных базах данных с тем или иным набором ограничений, т.к. конструция довольно сложная и имеет большое количество особенностей и режимов работы.
В своём докладе я расскажу о реализации MATCH_RECOGNIZE в YDB: о том, как это работает под капотом, какие подходы и алгоритмы реализованы, с какими сложностями мы столкнулись.
Отдельная часть выступления будет посвящена отличиям в обработке аналитических запросов на табличках и обработке на потоках "живых" данных. Какие возникают ограничения при обработке потоков, как бороться с большим стейтом, необходимым для накопления цепочек совпадений на сложных образцах и пр.
И в завершении доклада, конечно же, будут представлены данные о производительности новой конструкции на различных типах запросов для табличек и потоков.

Программный комитет ещё не принял решения по этому докладу

YDB Topic Service: как мы повышали производительность очереди сообщений

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

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

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

Доклад принят в программу конференции

Реализовать OLAP: как мы делали колоночное хранение в YDB

Базы данных / другое

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

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

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

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

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

Доклад принят в программу конференции

Мифы и реалии архитектуры мультимастера в реляционной СУБД PostgreSQL

PostgreSQL
Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Архитектуры / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Расширение кругозора
Жилин Михаил

Postgres Professional

Павел Конотопов

Postgres Professional

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

Доклад принят в программу конференции

Алгоритм инкрементальных бэкапов в Apache Ignite

Базы данных / другое
Распределенные системы
Алгоритмы и их сравнение
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы

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

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

Доклад принят в программу конференции

Менеджмент крупных проектов (6)

По мотивам шестого подвига Геракла

Дмитрий Кырхларов

Актион-Диджитал

Путь от техдолга в 20 лет до построения катастрофоустойчивости в IT-компании среднего размера (~260 сотрудников, ~100 продуктов).
В докладе будет упор на решения, которые позволяют не бояться отказа целого дата-центра. Так же, коснёмся влияния богатого legacy на архитектурные подходы.

Доклад принят в программу конференции

Что такое качество продукта и как его измерить

Выбор стратегии долгосрочного развития, KPI
Продуктовая разработка
Антикризисный менеджмент
Управление / другое
Enterprise-системы
Метрики
Методологии

Что такое качество продукта и зачем его измерять

Измерение качества продукта

Как улучшить качество продукта

Преимущества высокого качества продукта
Резюме основных идей презентации

Программный комитет ещё не принял решения по этому докладу

Зачем нужен отдел Customer Care, когда есть тех. поддержка? И когда наступает пора его открывать?

Большие проекты/команды
Поиск и развитие команды
Обслуживание клиентов, техническая поддержка, обратная связь

- История Customer Care, какие факторы бизнеса и ценности компании повлияли на создание и формирование отдела.
- Ожидание от работы отдела vs суровая реальность при взаимодействии и выстраивании отношений с коллегами, клиентами и при работе над клиентскими проектами
- Результат работы в цифрах

Программный комитет ещё не принял решения по этому докладу

Современные методы построения платформы мониторинга

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

Доклад принят в программу конференции

Как учиться у заказчиков

Большие проекты/команды
Работа со внешним заказчиком/исполнителем

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

Программный комитет ещё не принял решения по этому докладу

Сколько нужно разработчиков, чтобы вкрутить лампочку?

Методологии и процессы разработки ПО; Сроки и приоритеты
Большие проекты/команды
Выбор стратегии долгосрочного развития, KPI
Оценка сложности проекта
Управление проектами

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

Программный комитет ещё не принял решения по этому докладу

DevOps-практики и культура (4)

SRE-практики как управление многоквартирным домом

Менеджмент в эксплуатации
Глеб Гончаров

СберМаркет

SRE-практики как управление многоквартирным домом

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

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

Доклад принят в программу конференции

Team Topologies, культура DevOps и собственные наработки на страже перфоманса и психологического комфорта

Вацлав Довнар

Независимый эксперт

В докладе мы рассмотрим типичные причины конфликтов при кросс-командном взаимодействии между командами (QA, разработки, DevOps, безопасности), а затем обсудим как их решать с помощью наработок не представленных ни в одном фреймворке, а так же с помощью подходов предлагаемых в культуре DevOps и фреймворке Team Topologies

Программный комитет ещё не принял решения по этому докладу

История одного инцидента: как парализовать работу 20к сотрудников и организовать чемпионат по игре в тетрис

Бэкенд / другое
Управление инцидентами

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

Доклад принят в программу конференции

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

Управление конфигурацией
Непрерывное развертывание и деплой
Непрерывная интеграция
DevOps на собственном (арендованном) оборудовании
Надёжность продакшена
Автоматизация разработки, доставки, эксплуатации
DevOps / SRE

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

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

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

Доклад принят в программу конференции

Безопасность, DevSecOps (2)

Kubernetes без интернета

Менеджмент в эксплуатации
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер
Инфраструктура
Безопасность инфраструктуры

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

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

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

Программный комитет ещё не принял решения по этому докладу

С++ и безопасность: можно ли сделать лучше?

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

Доклад принят в программу конференции

Узкотематические секции (7)

Перестаньте писать свою аутентификацию!

Ирина Блажина

"Оператор Газпром ИД"

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

Программный комитет ещё не принял решения по этому докладу

Gstreamer не только для мультимедиа - потоковая обработка данных в реальном времени

Фреймворки
Python
Оптимизация производительности
Архитектуры / другое
Machine Learning
Оптимизация
ML
Обработка данных
Андрей Попов

Positive Technologies

GStreamer - это мощный фреймворк для стриминга мультимедиа и не только. Из доклада вы узнаете как создавать пайпланый обработки потоковых данных с помощью gstreamer. Как написать собственные элементы пайплайна и применить алгоритмы машинного обученя в реальном времени. Будет несколько live-demo с реальными примерами, а так же сравнение с другими подходами при работе с data streaming.

Программный комитет ещё не принял решения по этому докладу

От CPU к GPU: Когда ядра решают

Виталий Шутов

ВКонтакте

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

Доклад принят в программу конференции

Как мы строили Telcocloud в условиях санкций

Павел Михайлик

Инфосистемы Джет

1) Специфика архитектуры и требований TelcoCloud в сравнении с облачными решениями
2) Требования предъявляемые к сетевой инфраструктуре TelcoCloud
3) Whitebox как доступное решение в построении сетевой фабрики

Программный комитет ещё не принял решения по этому докладу

Построение надежной системы алертов для реагирования на разладки элементов выдачи поиска в реальном времени

1) Для обнаружения разладок элементов выдачи поиска применили единый сервис обработки кликов

2) Надежный и простой набор алертов, который своевременно обнаружил почти все разладки избранных элементов выдачи поиска для десятков команд уже в первые полгода внедрения

Программный комитет ещё не принял решения по этому докладу

Arc - внутренняя VCS для монорепозитория Яндекса

C/C++
Совместная работа, система контроля версий, организация веток
Оптимизация
Обработка данных
Инфраструктура
Лайфхаки

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

Доклад принят в программу конференции

Чтобы всех отыскать, воедино созвать: система трейсинга событий в VK Звонках

Алексей Шпагин

ВКонтакте, VK

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

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

Доклад принят в программу конференции

Эксплуатация систем (13)

Наш опыт обеспечения отказоустойчивости для 100+ баз с помощью автоматического фэйловера

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

- Перед нами встала задача обеспечения автоматического фейловера 100+ баз в нашем продукте VK WorkMail для обеспечения бесперебойной работы нашего решения (Почты, Облака и Календаря).
- Для решения этой задачи мы разработали средство автоматического фейловера Overlord.
- Overlord написан на языке Go, работает в связке с ETCD и Envoy и не требует кворума для своей работы.

Программный комитет ещё не принял решения по этому докладу

"Mattermost" на стероидах: как мы запустили и развиваем корпоративный мессенджер

Распределенные системы
Devops / другое
Безопасная коммуникация, культура

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

1) Да будет свет - или как все начиналось: почему появилась необходимость в корпоративном мессенджере. Первая версия сервера 3в1 (БД, сервер Mattermost + сервер авторизации все вместе). Добавление инструментов. Привлечение IT-команд.

2) Первый блин не комом! Реакция пользователей: плюсы и минусы. Добавление функционала на основе Обратной Связи (плагины). Увеличение функционала – самописные плагины. Как мы придумали использовать скрытые сообщения (что дало: экономия, безопасность, сокращение времени решения задачи.)

3) А нам 1 год! Увеличение пользователей и устранение узких мест. Настройка отказоустойчивости (уменьшаем время простоя; делаем общий конфиг без синхронизации). Наработка автоматизаций (скрипт автообновления, скрипт автопроверки версий, автоочистка файлового хранилища, автоочистка каналов). Вторая версия сервера + s3 хранилище. Создаем свой сервер видеозвонков на базе LiveKit.

4) Что будет дальше? Выводы, что имеем сейчас. Графики доступности сервиса (было/стало), графики нагрузок на систему (было/стало). Новый функционал, который планируем внедрить: интеграция с внутренней HR-системой, интеграция с Outlook.

Доклад принят в программу конференции

Эксплуатация cilium в кластерах VK

Логирование и мониторинг
Непрерывное развертывание и деплой
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Эффективное использование облаков
Observability в enterprise
Надёжность продакшена
Логи, метрики, ошибки
DevOps / Кубер
Сеть
Михаил Петров

VK, Единое Облако

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

Доклад принят в программу конференции

Создаём отказоустойчивый деплой приложений в Kubernetes. Принципы, паттерны, приёмы.

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

Доклад принят в программу конференции

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

Отказоустойчивость
Менеджмент в эксплуатации
Управление инцидентами
Надёжность продакшена
DevOps / SRE
Сергей Реусин

СберМаркет

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

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

Доклад принят в программу конференции

Проактивное управление даунтаймом: стратегии и инструменты

Антикризисный менеджмент
DDoS
Управление инцидентами
Безопасность от планирования до эксплуатации
Безопасность инфраструктуры

Сегодняшний бизнес зависит от облачных технологий — потеря критически важного ИТ-сервиса зачастую прямо и незамедлительно приводит к сбоям в работе, потере пользователей и, как следствие, большим расходам. Более 80% клиентов уходят к конкурентам если получают негативный пользовательский опыт, в том числе из-за недоступности веб-сервиса.

Кому-то дешевле «полежать» часик-другой, чем разрабатывать регламенты, организовывать круглосуточный мониторинг и искать решения для стабильной работы своего проекта. В то же время в энтерпрайз-сегменте каждая минута простоя, например, в результате DDoS-атаки обойдется в среднем в 2 млн рублей.

В совместном докладе Кирилл Малеванов (Selectel) и Дмитрий Никонов (DDoS-Guard) расскажут, как оценить риски, избежать возможных потерь и какие практики стоит применить, чтобы даунтайм не означал «конец света».

Программный комитет ещё не принял решения по этому докладу

Мониторинг бэкэнда с нуля, или Куда смотреть и зачем

Бэкенд / другое
Надёжность продакшена
Логи, метрики, ошибки

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

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

Программный комитет ещё не принял решения по этому докладу

Автоматизация сетевой инфраструктуры ЦОД

Сетевое администрирование
Сеть
Анна Кошк

Ростелеком-ЦОД

На просторах интернета много информации о том, как автоматизировать сеть офиса или как за три секунды раскатить типовую конфигурацию на новое железо. Мы же прошли через автоматизацию сетевой инфраструктуры одного из самых старых ЦОДов России (наша площадка ОСТ открылась в 2009 году). Расскажу о том, что мы предприняли чтобы начать автоматически конфигурировать услуги на проде и при интеграции не допустить перерыва сервиса для более чем восьмиста клиентов, какие проблемы нам удалось решить и почему в какой-то момент приняли решение начать всё заново.

Доклад принят в программу конференции

Как мы начали использовать eBPF и какую пользу нам это принесло

PostgreSQL
Observability в enterprise
Логи, метрики, ошибки
Расширение кругозора

Начиная с 2019 года проекты на eBPF, связанные с observability, сетевыми технологиями и безопасностью, появляются как грибы после дождя. Стандартами де-факто стали cilium, Katran и Falco, и всё равно есть место для велосипедостроения - использования технологии в своих проектах, начиная с самого низкого уровня. В докладе мы расскажем, как технология позволяет нам лучше понимать, что происходит внутри наших ПАКов, а в случае необходимости - гибко и "бесплатно" рулить ими.

Программный комитет ещё не принял решения по этому докладу

Используй Силу, Люк: Single Pane of Glass в Мире SRE

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

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

Доклад принят в программу конференции

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

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

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

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

Доклад принят в программу конференции

MaaS - Мониторинг как сервис

Анна Журбенко

ГазпромБанк

MaaS - monitoring as service
Как узнавать о проблемах с сервисами до первого обращения клиента?
Как использовать мониторинг на пользу, не подглядывая в монитор соседа?
Как не "утонуть" в постоянно дребезжащих алертах?
Как мониторинг улучшает отношения между бизнесом и ИТ?

Доклад принят в программу конференции

Сменить 4 системы мониторинга за 4 года и остаться в живых

Логирование и мониторинг
Логи, метрики, ошибки

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

Доклад принят в программу конференции

Безопасность, информационная безопасность (6)

Актуальные угрозы безопасности в Large Language Model Applications

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

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

Доклад принят в программу конференции

Уязвимости платформы Hyperledger Fabric

Блокчейн-технология
Атаки
Безопасность
Безопасность инфраструктуры
Илья Дружинин

Positive Technologies

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

Программный комитет ещё не принял решения по этому докладу

Как собрать контейнер и не вооружить хакера

Технологии виртуализации и контейнеризации
Атаки
Безопасность

Всё, что вы положите в контейнер, может быть использовано против вас. Именно такой фразой можно описать Living off the Land (LotL) атаки. LotL – это атаки, при которых злоумышленник использует легитимные утилиты для выполнения вредоносных действий. При таких атаках злоумышленнику не потребуется установка специального «хакерского» софта, ему будет достаточно инструментов, добытых на местности. Многие стандартные инструменты детектирования становятся бесполезны против таких атак. В докладе разберём практические примеры LotL-атак в контейнерных инфраструктурах, а также обсудим, как от них защищаться.

Доклад принят в программу конференции

BrainSploit. Эксплойты социальной инженерии.

Soft Skills
Атаки
Безопасность
Антон Бочкарев

Третья сторона

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

Доклад принят в программу конференции

XXE-атаки: скрытые угрозы обработки XML

Java
Безопасность программного кода, SQL и прочие инъекции
Application security
.NET
Атаки
Безопасность

Работа с XML-файлами (и основанными на XML форматами) может нести неожиданные угрозы безопасности. SSRF? Пожалуйста. Утечка данных? Как скажете. Но в чём суть уязвимости и как защитить свои приложения от подобных проблем? Об этом и пойдёт речь.

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

Программный комитет ещё не принял решения по этому докладу

zkSNARKs - succinct zero-knowledge proofs for scalability and security

Доклад описывает возможности технологии zkSNARKs для масштабирования сервисов и применения zero-knowledge протоколов. Эта молодая технология сейчас находится на острие развития современной криптографии, ей занимаются в топовых университетах мира, а решения на ее основе позволяют доказывать исполнение вычислений на клиентской стороне с легкой, constant-sized верификацией на стороне сервера. Она очень хорошо ложится на блокчейн технологии, но и для client-server архитектур открывает множество новых возможностей. Например управление списком пользователей и их аутентификация вообще без наличия на сервере базы пользователей и challenge-response протокола. Мы обсудим устройство арифметических circuits и покажем практические примеры простых доказательств, опишем ограничения подобных решений и дизайн некоторых протоколов. Сама технология уже успешно используется в production, где используется для масштабирования, защиты финансовых активов и имеет множество потенциальных применений. Для понимания доклада плюсом будет понимание того, как строятся логические схемы и основы криптографии на элиптических кривых

Доклад принят в программу конференции

BigData и машинное обучение (16)

Универсальный транспорт для ML/DL вычислений

C/C++
Big Data и Highload в Enterprise
Рекомендации / ML
ML

1. Где в ML/DL нужно пересылать очень много данных с небольшой задержкой
2. Как совместить TCP, InfiniBand, разделяемую память и CUDA под одними абстракциями
3. Библиотка OpenUCX, ее особенности и подводные камни
4. Универсальный транспорт на С++ поверх OpenUCX
5. Внедрение в рекламе: aссинхронные ембеддинги

Программный комитет ещё не принял решения по этому докладу

Архитектура бесконечной персональной ленты Яндекс Маркета

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

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

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

Доклад принят в программу конференции

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

Рекомендации / ML
ML

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

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

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

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

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

Доклад принят в программу конференции

Mlops: как не потеряться в 10 тысячах фичах

Архитектуры / другое
Непрерывная интеграция
Hadoop
Machine Learning
Автоматизация разработки, доставки, эксплуатации
Автотесты
Инфраструктура
Инструменты

В подразделении билайн бизнес 12 продуктовых команд. Команды работают над широкой линейкой продуктов с использованием машинного обучения для B2B клиентов. Часть продуктов относится к компьютерному зрению и аудиоаналитике, где используются нейронные сети на отдельном GPU кластере. Другая часть продуктов использует неперсонализированную информацию об абонентах и основана в основном на классическом ML с вычислениями на Hadoop кластере.
В билайне используется концепция Data Mesh распределенного управления данными. Доменными единицами являются продуктовые команды, которые строят необходимые им витрины данных и занимаются их менеджментом. Некоторые команды собирают таблицы, которые могут насчитывать около 10 тысяч фичей. Большой популярностью для построения различных моделей пользуются, например, ГЕО фичи или графовые фичи. Фичи могут обновляться на ежедневной/еженедельной/ежемесячной основе.
В билайн бизнес на проде крутится порядка 100 ml-моделей с различным расписанием их использования: от ежедневного до ежемесячного. Каждая модель запускается на разном количестве абонентов (строк): от 10 млн до 200 млн. Итого в пике ежедневная нагрузка по Spark джобам на кластере доходит до обработки 1млрд. строк. В среднем же в сутки обрабатывается около 50 млн. строк.
Большой парк моделей и фичей требует внимательного тестирования и построения прозрачных связей между ними. В докладе прозвучит бриф нашего MLOps пайплайна. Акценты будут расставлены на том, как мы организовали процесс тестирования в MlOps цикле и построили эффективный lineage между моделями и фичами. Расскажем влияние появившихся технологий на процесс разработки и деплоя моделей. Подсветим положительные эффекты, которые мы получили.

Программный комитет ещё не принял решения по этому докладу

Жизненный цикл данных от авиателеграм до обучения моделей

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

Программный комитет ещё не принял решения по этому докладу

Рекомендации медиаконтента ВКонтакте: как мы строим персонализированную ленту "Для Вас"

Продуктовая разработка
Аналитика / другое
Оптимизация
Рекомендации / ML

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

Доклад принят в программу конференции

Как устроены процессы ML-разработки в команде Антиспама

Мы пройдемся по всему жизненному циклу ML-модели на конкретном примере - задачах команды Антиспам.

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

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

Мы в команде работаем в тесной связке из нескольких дата аналитиков, дата инженеров, дата саентистов, а также продактов. И для нас важно уметь:
-- быстро обмениваться данными и наработками и презентовать результаты друг другу;
-- оперативно обновлять алгоритмы в условиях сильной сезонности и дрифта признаков, быстро реагировать на приспособление спамеров к новым условиям;
-- выполнять инженерные задачи силами рядовых DS без привлечения DEVOPS инженеров или техлидов;
перенимать наработки соседних команд и интегрировать в свой проект и с минимальной консультацией с их стороны и с минимальными доработками - с нашей;
-- мониторить большое количество ML и продуктовых метрик (точность, полнота, скорость определения - в номерах, звонках, жертвах, минутах…) среди всех абонентов и в разрезе сегментов;
быстро тестировать новые версии модели не только на формальное качество классификации, но и на влияние на остальные процессы в команде;

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

Мы увидим, как рабочее место аналитика в JupyterHub с примонтированными туториалами для работы с данными и рекомендациями по проведению R&D и разработке, а также развитый Confluence со всеми How-To может упростить жизнь новому сотруднику и снизить порог вхождения в новый проект.

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

Мы посмотрим, как мы приспособили MLFLOW не только для хранения моделей и трекинга ML-экспериментов, но также для задач мониторинга и не только, какие рекомендации разработали по наполнению экспериментов, а так же как мы используем Argo Workflows для оркестрации задач и удобных разовых запусков без изменения кода и MR.

Программный комитет ещё не принял решения по этому докладу

Рецепт идеальной разметки в Computer Vision

Machine Learning

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

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

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

Доклад принят в программу конференции

Угадываем вкус покупателей: персонализация ранжирования каталога в Lamoda на базе Elasticsearch и CatBoost

Хочу поделиться успешным опытом Lamoda по внедрению персонализации в ранжирование каталога: рассказать про двухуровневую архитектуру, к которой мы пришли, используя Elasticsearch, Golang и CatBoost; про полученный бизнес-эффект и дальнейшие планы. Выбранная архитектура позволяет эффективно и гибко персонализировать десятки тысяч товаров под каждого клиента, а также дает возможность продуктивно работать над дальнейшим улучшением качества ранжирования.

Программный комитет ещё не принял решения по этому докладу

Data Sketches - как съесть слона целиком (даже если он бесконечный)

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Сервис по оптимальному управлению складскими запасами на площадках ПАО НЛМК

1) Постановка задачи оптимального управления складскими запасами, вводные от заказчика.
2) Сбор, хранение и обработка данных.
3) Модель прогнозирования потребления.
4) Оценка точности прогнозов + бизнес-эффекты.
5) Архитектура решения в production.

Доклад принят в программу конференции

Речевая аналитика на миллионах минут звонков в месяц

ML
Обработка данных

В нашей компании разрабатывается ряд продуктов, связанных с предоставлением услуг связи и ее организации. Рост бизнес-потребности в дополнительной аналитике звонков стимулировал начало разработки целого отдельного продукта под названием Речевая аналитика. Для его реализации потребовалось несколько лет работы трех отдельных команд, каждая из которых взяла на себя определенные обязательства по разработке решения для работы с входящим потоком звонков, их анализа и визуализации результатов. Корпоративные клиенты получают доступ к программному решению, функционал которого позволяет им проводить анализ аудио данных самостоятельно. На настоящий момент данный продукт обрабатывает миллионы минут аудиозаписей в месяц.
Команда анализа данных работала над моделями глубоких нейронных сетей, которые решают проблемы детектирования речевых данных в аудиосигнале (Voice activity detection) и перевода их в текстовый формат (Automatic Speech Recognition) с последующим подсчетом качественных и количественных метрик. Одним из вызовов перед командой была скорость обработки аудио данных: согласно требованиям к системе за 1 секунду необходимо обрабатывать не менее 200 секунд стерео файла. Пилотные наработки давали скорость 1 к 20, что не устраивало. В рамках доклада расскажем о том, как удалось выйти на нужные показатели: о пайплайне обработки аудиоданных, а также эксплуатации моделей машинного обучения, их дообучению и оптимизации. Особое внимание в докладе уделим технологиям и причинам, по которым их выбирали.

Программный комитет ещё не принял решения по этому докладу

Как CV помогает пользователю найти товар мечты по визуальному образу

Big Data и Highload в Enterprise
Machine Learning

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

“Хочу новую футболку, но не знаю какую…”

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

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

Доклад принят в программу конференции

Чистые метки для ML

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

Программный комитет ещё не принял решения по этому докладу

Быстрая обработка данных в data lake с помощью SQL

Оптимизация производительности
Обработка данных

Популярные распределенные 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), а так же многочисленные кэши: кэш метаданных, кэш данных и кэш промежуточных результатов запросов.

Доклад принят в программу конференции

Hadoop в Облаке: история миграции сотен петабайт

Михаил Марюфич

Одноклассники

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

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

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

Доклад принят в программу конференции

Нейронные сети, искусственный интеллект (18)

Генерация кода при помощи больших языковых моделей

Кодогенерация
Расширение кругозора
Лайфхаки

В докладе Александр разберет как LLM помогут разработчикам поднять свою производительность на 100% и более, автоматизировать рутинные задачи, как быть тимлидом копайлота и даже написать целый проект не написав ни строчки кода используя GPT Engineer.

Программный комитет ещё не принял решения по этому докладу

Побеждаем рутину в Data Science

Machine Learning
ML
Обработка данных
Евгений Смирнов

Альфа-Банк

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

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

Программный комитет ещё не принял решения по этому докладу

Переводчик с языка, на котором нельзя говорить и писать

Machine Learning

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

Доклад принят в программу конференции

Как мы учили LLM шутить

- Можно ли считать способность шутить признаком интеллекта?
- Если юмор это признак интеллекта и современный AI не обладает интеллектом, то получается современные LLM системы не должны уметь шутить. Рассмотрим примеры шуток от LLM;
- Подходы к обучению LLM с ограничением ресурсов. Как решить эту задачу на основе open source моделей и ограничений по ресурсам;
- подходы к finetunning базовой модели, краткое введение в PEFT (Parameter-Efficient Fine-Tuning);
- Где и как взять датасет? Рассмотрим разные подходы к составлению датасета для решения этой задачи;
- Рассмотрим результаты обучения и работы модели на основе разных датасетов;
- Выводы

Программный комитет ещё не принял решения по этому докладу

LLMops: Что есть кроме ChatGPT и как ты можешь развернуть это

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

Программный комитет ещё не принял решения по этому докладу

Новые возможности в HR tech. Решаем генеративные задачи с помощью: Transformer + LoRA + RLHF.

Марк Паненко

Работа.ру

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

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

Доклад принят в программу конференции

NeuroHD: охота на шакаллов или деплой и ускорение сеток в высоконагруженной инфраструктуре VK

C/C++
Python
ML

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

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

Доклад принят в программу конференции

Real-time распознавание лиц: методы обучения быстрых и точных моделей для работы на мобильных девайсах

Продуктовая разработка
Machine Learning
Оптимизация
ML
Обработка данных

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

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

Доклад принят в программу конференции

Движки распознавания речи ВКонтакте

Сафиуллин Али

ВКонтакте

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

Доклад принят в программу конференции

Как AI увеличивает применимость RPA

умные роботы
интеллектуальная автоматизация
тренды и тенденции
RPA-платформа Атом. РИТА
OCR

Программный комитет ещё не принял решения по этому докладу

Автоматизация технической поддержки через развитие собственного продукта цифрового ассистента

Трансформационные изменения
Типовые ошибки
Документация
Онбординг
Инструменты
Support
Команда

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

Программный комитет ещё не принял решения по этому докладу

Generative AI и LLM: Новый подход к разработке ML проектов

Будущее рынка разработки ПО
Проектирование информационных систем
Технологии “быстрых решений”, “быстрого прототипирования”

В докладе Евгений разберёт традиционный цикл разработки проектов ML и NLP и его оптимизацию с использованием Generative AI. Подробный кейс проекта покажет, как LLM может эффективно оптимизировать обработку больших объемов текстовых данных. Евгений также обозначит потенциал для расширения и модификации существующих решений на основе ChatGPT и акцентирует внимание на подводных камнях при реализации таких подходов. Обсудим ограничения языковых моделей и принципы их успешного преодоления на практике.

Программный комитет ещё не принял решения по этому докладу

Генеративные языковые модели

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

Доклад принят в программу конференции

Обучение больших нейронных сетей на HPC кластере AMD

Я расскажу про наш опыт работы с GPU от AMD. Поговорим о том:
- Какое желез предлагает AMD и почему оно хорошо
- Как AMD прорывается на рынок обучения нейросетей
- Про наш HPC кластер и его бенчмарки
- Про наш опыт обучения больших языковых моделей на этом кластере

Программный комитет ещё не принял решения по этому докладу

ReAct: Как научить LLM думать и действовать

Фреймворки
Python
Архитектуры / другое
Будущее рынка разработки ПО
Расширение кругозора

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

Программный комитет ещё не принял решения по этому докладу

Как мы отвечаем роботом на 1000 тематик в поддержке пользователей?

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

Доклад принят в программу конференции

Zero-cost I/O и fault tolerance в распределенном глубоком обучении

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

Программный комитет ещё не принял решения по этому докладу

Как мы запускали YandexGPT

Теории и техники анализа
Machine Learning
Управление разработкой
Обработка данных

В докладе Алексей расскажет, как Яндекс отреагировал на новый бум в языковых моделях и чат-ботах:
- как 3 года опыта в LLM помогали принимать важные решения
- как рос road-map проекта
- как отличаются метрики реального бизнеса, от метрик модели
- какие амбициозные цели стоят перед проектом и какие продукты уже базируются на YandexGPT

Программный комитет ещё не принял решения по этому докладу

Технологии будущего (2)

Prompt engineering: Путь к эффективной работе с ChatGPT

Коллаборативная работа
Митапы
Лайфхаки

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

Узнаем про safety layer и обсудим тему обхода ограничений (jailbreak), на примере DAN. В ходе митапа обсудим популярные плагины к ChatGPT и как добиться более эффективных промптов с их помощью.

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

Программный комитет ещё не принял решения по этому докладу

Добро пожаловать в реальный мир, робот!

Архитектуры / другое
Теории и техники анализа
Тестирование безопасности
Интеграционное тестирование
A/B-тестирование
Александр Чистяков

Яндекс Беспилотные Технологии

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

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

Программный комитет ещё не принял решения по этому докладу

Бэкенд, теория программирования (10)

Бои в гексагоне: как на архитектуре Ports & Adapters построить омниканальное решение

Перед командой стояла задача разрабатывать омниканальный банковский проект для платежей, с минимумом критических багов и быстро.
Это осложняется тем, что каждое действие пользователя скрывает за собой много операций - вызовы смежников, тяжелые запросы к БД. Плюс, как следует из слова "омниканальный" - одновременно существуют требования как предоставлять одинаковый опыт для пользователей, так и быть готовыми любую логику переписывать в несколько вариантов, потому что либо каналы технически устроены по-разному, либо новый функционал выкатывается неравномерно.
Чтобы избежать случайных ошибок и нежелательных побочных эффектов при разработке, сама архитектура должна направлять эти процессы и страховать команду от просачивания логики туда, куда не следует.
При дизайне решения выбрали гексагональную архитектуру и модульный монолит.
Такое решение содержит меньше неявных зависимостей, чем классический монолит, а развивается проще, чем микросервисы.
Этот выбор позволил создать систему, отвечающую высоким требованиям к продукту в банковской сфере, сохранив поддерживаемость и возможность быстро перейти на микросервисы в будущем, на стадии поддержки проекта.

Программный комитет ещё не принял решения по этому докладу

Eventual consistency в stateful сервисе

Дмитрий Исаев

ООО "Яндекс"

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

Программный комитет ещё не принял решения по этому докладу

Статические анализаторы в PHP и сложности их внедрения

PHP
Стандарты кодирования
Рефакторинг
Теории и техники анализа
Управление разработкой
Поддерживаемый код
Логи, метрики, ошибки
Расширение кругозора

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

Программный комитет ещё не принял решения по этому докладу

Магия JWT и ее разоблачение. Основные заблуждения при работе с технологией

Single page application, толстый клиент
Безопасность в браузере
Микросервисы, SOA
Методы и техника разработки ПО
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Теория
Расширение кругозора
HTTP/HTTPS
Типовые ошибки
Обзор
Образование

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Точки отказа в хайлоад системах. Backend

Платёжные системы, обработка платежей
Java
PostgreSQL
Асинхронное программирование, реактивное программирование
Логирование и мониторинг
Надёжность продакшена
Микросервисы
Типовые ошибки

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

Программный комитет ещё не принял решения по этому докладу

EventSoursing: как мы ускорили SQL проекции с 7 часов до 7 минут

EventSouring предлагает нам создавать два хранилища данных: append-only хранилище ивентов и read-only хранилище, оптимизированное для быстрого выполнения запросов. И иногда read проекцию нужно перегенерировать, но когда проект в проде уже несколько лет и для него накоплено много данных, этот процесс может быть долгим.
Я расскажу как мы переписали перегенерацию проекций, теперь она занимает минуты, а не часы.

Программный комитет ещё не принял решения по этому докладу

Как мы сделали систему для отложенных пушей для умных устройств с Алисой

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

Программный комитет ещё не принял решения по этому докладу

Как мы всё лучше и лучше познаём наш highload-сервис на Go

GO
Никита Деревянко

Яндекс Маркет

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

Из доклада вы узнаете:
- Что за чудо сервис мы сделали и почему он высоконагруженный
- Про указатели в Go, они всегда умные, но за их ум приходится платить
- Почему важно проверять контексты входящих запросов
- Что sync.Pool это ваш лучший союзник и самый страшный враг, если быть не осторожным
- Некоторые особенности работы с grpc и protobuf на Go

Программный комитет ещё не принял решения по этому докладу

Как устроена система сканирования робота Spectro

Бэкенд / другое
ML
Валерий Ильин

Яндекс Маркет

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

Программный комитет ещё не принял решения по этому докладу

Как делать бинарно-совместимые API на компилируемых языках?

API
C/C++

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

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

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

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

Доклад принят в программу конференции

Цифровая культура / CTO-трек (3)

Масштабирование OpenAPI в api-first компании

API
Проектные артефакты, инструментарий
Фиксация знаний

Мы в Flussonic два года назад резко перешли на api-first подход к построению систем и это было необходимо для возможности расти и развиваться. Мы внедрили OpenAPI 3.1 для коммуникации сложных систем на erlang, golang, python, rust, rails, C, nodejs. Репозиторий со схемами стал местом, где бизнес может договариваться с разработкой на простом и формальном языке. В нём сейчас 56 тыс строк кода в yml файлах и 140 тыс строк кода в результирующих json файлах.

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

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

Доклад принят в программу конференции

Нужны ли сейчас продуктовые экосистемы в российском ИТ?

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

Программный комитет ещё не принял решения по этому докладу

Как на практике оптимизировать расходы на облако с помощью FinOps

Эффективное использование облаков
Облака

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

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

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

Доклад принят в программу конференции

TechTalk (4)

Как перекачивать гигабайты данных из закрытого контура сети

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

Программный комитет ещё не принял решения по этому докладу

Точка компромисса между бизнесом и производительностью АС.

Абрамов Антон

АО "Газпромбанк"

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

Программный комитет ещё не принял решения по этому докладу

Опенсорс, как вклад в технологическую эволюцию

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

Программный комитет ещё не принял решения по этому докладу

Anti-Fraud платформа - технологии верификации

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

Программный комитет ещё не принял решения по этому докладу

Митапы (1)

5 вещей, которые чуть не убили антиспам

Большие проекты/команды
Аналитика / другое
Лайфхаки
Иванов Дмитрий

Вымпелком - ИТ

5 вещей, которые чуть не убили антиспам

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

В докладе я не планирую рассказать о сути продукта, процессе обучения нашей ML модели и тонкостях сбора обратной связи. Но хочется поделиться тем, с какими трудностями мы столкнулись и как мы их решали. Думаю, это будет интересно и с точки зрения обмена опытом, и с точки зрения развенчивания мифов о проекта формата «на 1 день данные собрали, на 2 день обучили, на 3 запустили»

Кейс 1. Данные

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

Кейс 2. Обучающая выборка

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

•Надо искать руками периоды активности спамеров
•Не по всем номерам мы видим достаточно трафика
•Этот процесс должен быть постоянный, 
а не разовый

Кейс 3. Формализация терминов

Понятие «спамер» очень растяжимо, и есть многие кейсы, когда вынести решение «блокировать или нет» не так просто

Помимо классических спамеров в мире существуют
•Белые спамеры: организации, у которых много ПОЛЕЗНЫХ звонков (различные клиентские службы)
•Курьеры, таксисты, доставщики
•Те, кого нельзя блокировать по закону: государственные службы, коллекторы и так далее
•Различные m2m устройства, которые нужны для технических функций

Кейс 4. Задержка источников

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

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

Кейс 5. Мы сильно влияем на спамеров

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


Итого:

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




Программный комитет ещё не принял решения по этому докладу

Производительность мобильных приложений (1)

Байт-код — Это Просто! Как сделать DI по настоящему быстрым

Java
Разработка библиотек, включая open source библиотеки
Технологии и языки для Android: Java, Kotlin
Оптимизация
Григорий Юрков

Яндекс Маркет

Два года назад мы в Яндекс Маркете начали разрабатывать свой DI фреймворк - Scout. Это легковесный фреймворк, который предоставляет выразительный Kotlin DSL. Он не генерирует код, а делает всю работу в рантайме. Недавний переход на эту библиотеку привел к замедлению нашего приложения, но мне удалось ее ускорить, применив технологию модификации байт-кода.

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

Программный комитет ещё не принял решения по этому докладу

Enterprise-системы (10)

Buy vs build

Управление разработкой
Бизнес-процессы
Трансформационные изменения

Начиная от установки в стойки и заканчивая обслуживанием приложений рынок вываливает огромное количество разных продуктов, которые способны помочь решить проблемы в тот же миг, уменьшить t2m и вообще улучшить состояние бизнеса. Инженеры в компаниях собираются в нелегальные банды и начинают писать свои продукты, платформы и даже могут выложить их в open source.
Как в таких случаях взять правильный вектор и выбрать верное решение, сохранить команду или наоброт, остаться на решениях vendor-lock мы и обсудим в рамках данного доклада на базе облачных платформ.
Поделюсь размышлениями о финансовой стороне вопроса в случае самописных решений и в случае покупных решений и расскажу про негативный опыт, связанный как с написанием своих систем, так и с опытом покупки решений.

Программный комитет ещё не принял решения по этому докладу

LogDoc: логи здорового человека

Логирование и мониторинг
Менеджмент в эксплуатации
Devops / другое
Логи, метрики, ошибки
Микросервисы
DevOps / Кубер

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

Программный комитет ещё не принял решения по этому докладу

Тернистый путь инструмента цифрового проектирования

Архитектурные паттерны
Стандарты кодирования
Архитектуры / другое
Совместная работа, система контроля версий, организация веток
Управление изменениями, управление требованиями
Проектирование информационных систем
Enterprise-системы
Теория

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

Доклад принят в программу конференции

Так ли легко добавить колонку в базе данных?

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

Программный комитет ещё не принял решения по этому докладу

Темные боги корпоративной архитектуры. Истории из недр варпа

Андрей Жуков

С7 ТехЛаб

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

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

Доклад принят в программу конференции

Как мы работали с интерфейсом через БД и к чему это привело

Дмитрий Переверзев

Банк ГПБ (АО)

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

Программный комитет ещё не принял решения по этому докладу

Total'ный контроль за сотрудниками через Telegram

Python
Бэкенд / другое
Архитектура данных, потоки данных, версионирование
Оценка сложности проекта
Бизнес на стыке онлайн и офлайн
Обслуживание клиентов, техническая поддержка, обратная связь
Общение с заказчиком, извлечение требований
Enterprise-системы
Оптимизация
Микросервисы

Федеральная сеть салонов красоты.
20 000 сотрудников во всех городах РФ. Отчет с фото каждого сотрудника нужно собрать и проверить за 10 мин до утренней планерки... или о том как telegram боты спасают топ менеджеров в 2023 году.

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

Доклад принят в программу конференции

Построение TelcoCloud – частное облако для телекома

Дмитрий Горохов

Инфосистемы Джет

Алексей Пантелеев

Инфосистемы Джет

Расскажем как мы построили частное облако для сетевых сервисов одного из крупнейших телеком-операторов РФ на open-source решениях, которыми будут пользоваться 30-40 миллионов абонентов по всей стране.

Программный комитет ещё не принял решения по этому докладу

Как выглядит процесс разработки k8s платформы enterprise-уровня в 2023 г.

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

Программный комитет ещё не принял решения по этому докладу

Обработка действительно больших потоков данных в 1С: опыт СберМаркета

Микросервисы, SOA
Архитектурные паттерны
Оптимизация производительности
Методы и техника разработки ПО
Архитектура данных, потоки данных, версионирование
Архитектуры / другое
Enterprise-системы
Обработка данных
Евгений Бартенев

Сбермаркет

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

Программный комитет ещё не принял решения по этому докладу

Тестирование, нагрузочное тестирование (2)

Профилирование микросервисов под нагрузкой.

Нагрузочное тестирование
Профилирование и отладка кода

Доводилось ли вам бывать в ситуациях, когда в вашем сервисе медленно, но верно подтекает память, а профилирование ничего не даёт? Приходилось ли принимать костыльное решение - перезапускать поды сервиса раз в несколько часов, чтобы не попадать на сбои из-за утечек? У нас было и мы нашли решение, не совсем обычное, слегка ортогональное, однако рабочее и с некоторых пор, помогающее нам в непростых ситуациях. Это решение гармонично дополнило возможности нашей платформы тестирования производительности. Приходите послушать наш доклад, X5 Digital занимательно поделится своим опытом - платформы экспресс-доставки из торговых сетей X5 . Мы динамично растем - у нас нагрузка - и нагрузка приносит не всегда простые и понятные вызовы.

Программный комитет ещё не принял решения по этому докладу

Нагружать может каждый

Ксения Бирюкова

Т1 Консалтинг

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

Программный комитет ещё не принял решения по этому докладу

Архитектуры и масштабируемость (48)

Высокая нагрузка или/и низкая задержка

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

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

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

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

Доклад принят в программу конференции

«Веслосипед» для сбора логов

Оптимизация производительности
Методы и техника разработки ПО
ClickHouse
GO
Логи, метрики, ошибки

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

Наша система построена на стеке - Golang+Kafka+Clickhouse. Система универсальна и позволяет качественно сопровождать ключевые ИТ сервисы X5 - от анализа событий кассовых операций до сбора логов защитного периметра WAF + NGFW.

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

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

Доклад принят в программу конференции

Как из Python и палок собрать детектор аномалий для highload

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

Доклад принят в программу конференции

Эволюция и мифы CQRS

Архитектурные паттерны

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

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

Программный комитет ещё не принял решения по этому докладу

Как построить OMS с помощью Temporal: опыт от нуля до десятков тысяч заказов в день

Отказоустойчивость
GO
Микросервисы

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

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

Доклад принят в программу конференции

Масштабирование незаконченной системы: от приёмки скоупа до внедрения паттернов распределенных систем и кратного роста нагрузки в 1 000 раз

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

Внутри доклада разберём по шагам, с чего начать и как масштабировать нагрузку сервиса в 1000 раз. Затронем аспекты управления командой разработки и передачи скоупа, тестирования, аналитики метрик нагрузки, рассмотрим применение паттернов распределенных систем.
— Расширение старой логики согласно концепции "test first and code later".
— Анализ метрик нагрузочного тестирования для эффективного распараллеливания операций, рефакторинга неоптимальных запросов, создания сценариев использования разных типов индексов.
— Обсудим применимость паттернов распределенных систем (Circuit Breaker, защита от состояния гонки, распределенные транзакции).
— Работа над ошибками или как принять скоуп от уходящей команды.

Программный комитет ещё не принял решения по этому докладу

Эволюция архитектуры транскодера

Дмитрий Лукшто

ООО "Дзен.Платформа"

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

Доклад принят в программу конференции

Как научить почтовый сервер Exim под нагрузкой 1 000 000 писем/мин переживать отказ ЦОД без простоя с помощью FUSE и Tarantool, а также развернуть такую систему в K8s

C/C++
Электронная почта
Tarantool
Отказоустойчивость
Распределенные системы
Поддержка и развитие legacy систем
Надёжность продакшена
Расширение кругозора

В Почте Mail.ru стояла задача: научить бэкенд на основе почтового сервера Exim с нагрузкой 1 000 000 писем/мин переживать отказ ЦОД без простоя и потери писем. Основная сложность была в том, что почтовый сервер использует локальный диск для хранения очереди писем в процессе доставки.

Для решения проблемы мы построили отказоустойчивую распределённую очередь на основе Tarantool и in-house объектного хранилища. Чтобы не менять логику почтового сервера, мы написали свою файловую систему в userspace на Tarantool и FUSE, которая инкапсулирует взаимодействие с распределенной очередью.

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

Программный комитет ещё не принял решения по этому докладу

Эволюция внедрения межсетевых экранов в облаке: от костылей до отказоустойчивых кластеров

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

Программный комитет ещё не принял решения по этому докладу

DRP & BCP для самых маленьких

Этапы проектирования и создания DRP & BCP с момента создания до роста проекта.
Как объяснить программисту особенности работы приложения в 2+ ЦОДах
“The Twelve-Factor App” в реальной жизни.
Проходим архитектурное собеседование с SRE командой.
Являются ли облака, k8s или серверная в офисе панацеей (лекарство у алхимиков, якобы помогающее от всех болезней) от всех бед?

Программный комитет ещё не принял решения по этому докладу

Надёжная аналитика: как мы собираем стату в мини-приложениях VK

Олег Мифле

ВКонтакте, VK

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

Доклад принят в программу конференции

Внутренняя платежная система Яндекса: что под капотом?

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

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

Доклад принят в программу конференции

Доклад про Цифровой Рубль

Максим

Газпромбанк

Что такое Цифровой Рубль
Кратко что такое Цифровой Рубль
Какие проблемы он решает для
государства
организаций
пользователей

Как задача выглядит для финтех организации
Постановка Задачи со стороны ЦБ
Финтех как посредник в операциях между пользователем и платформой Цифрового Рубля в ЦБ
Чем задача отличается от задачи добавления новой платежной системы
Добавляем третью форму рубля в проводки для Работы с бухгалтерскими книгами банка
Обеспечиваем безопасность персональных данных с учетом требований ЦБ, нашей безопасности, чтобы данные пользователей были в безопасности
Новые Юридические вопросы (Фин Мониторнг, Государство 115ФЗ, Юристы ГПБ - изменения в законодательстве)
Криптография (впервые работаем в МП с электро подписью), Классы защиты, новый Удостоверяющий центр


Архитектура Цифрового Рубля крупными мазками

Расскажу про сложность проекта и те слои которые прошила кросс-платформенная, кросс-функциональная команда ЦР
Мобильное приложение (SDK)
middleware
Бэкенд система Цифрового Рубля
Система интеграции с платформой Цифрового Рубля в ЦБ
Кратко расскажу как мы применили Vertical Sliced Architecture в реализации бизнес-процессов

Программный комитет ещё не принял решения по этому докладу

А знаете ли вы, что вы насчитали? XNumPy — расширение NumPy с оценкой точности вычислений.

Python
Алгоритмы и их сравнение
Теория
Игорь Нетай

АО НПК Криптонит

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

Доклад принят в программу конференции

Поставка данных, имеющих сложную иерархическую структуру, в Greenplum

Java
Микросервисы, SOA
Архитектура данных, потоки данных, версионирование
Хранилища
Обработка данных
Никита Рьянов

Тинькофф

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

В этом докладе я бы хотел рассказать о том, как мы организовали подобную поставку данных, используя формат данных Avro, Apache Flink, микро-gpfdist'ы и self-service, который позволяет всем этим управлять.

Доклад принят в программу конференции

Асинхронное взаимодействие в распределенных системах

Алексей Лосев

Яндекс Маркет

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

Доклад принят в программу конференции

На творчестве Линуса Торвальдса NGFW не построишь. Почему для создания файрвола следующего поколения не подходит сетевой стек ОС Linux?

Денис Кораблев

Positive Technologies

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

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

Доклад принят в программу конференции

Multi-tenancy в условиях виртуального хостинга

Бэкенд / другое
Поддержка и развитие legacy систем
Слабо связанная архитектура
Безопасность инфраструктуры


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

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

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

Внедрение чего-либо нового в подобной multi-tenancy всегда предъявляет специфические требования к решению:

1. Изоляция на уровне пользователей
2. Потребление ресурсов системы только на время использования
3. Малое потребление ресурсов

На примере нового файлового менеджера продукта виртуального хостинга расскажем как мы внедряем новые функции в условиях multi-tenancy виртуального хостинга

Программный комитет ещё не принял решения по этому докладу

Шардирование: с нуля до Яндекс.Диска

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

Доклад принят в программу конференции

Как мигрировать 600к приставок на новый бэк и ничего не сломать?

- Что делать, если нужно отказаться от вендорского backend-а, а у вас есть 600к абонентских устройств, которые никак не обновить?
- Как разобрать нагрузку от приставок, выделить "полезный" и "паразитный" трафик.
- Как выбрать решение, которое позволит бесшовно перекинуть абонентов на новый бэк.
- "Шеф, все пропало, клиент уезжает!" или новый бэк еще не готов полностью, а мигрировать пора. Что делать?

Программный комитет ещё не принял решения по этому докладу

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

Отказоустойчивость
Архитектуры / другое
Поддержка и развитие legacy систем
Микросервисы

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

Для обеспечения отказоустойчивости наших сервисов, было принято решение иметь возможность ротировать разные способы верификации в зависимости от внешних условий. Так, задача по замене Google Recaptcha на внутреннее решение только на создании паролей для внешних приложений была оценена примерно в человеко-месяц: разработка в старом проекте на фронтенде и на бекенде.
Если потребуется отказаться от внутреннего решения в пользу более универсального, это время потребуется потратить повторно.
А действий, требующих верификации, только в Почте более десяти.

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

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

Программный комитет ещё не принял решения по этому докладу

GraphQL: зачем на самом деле он нужен. Apollo Federation: дар бога.

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

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


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

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

Программный комитет ещё не принял решения по этому докладу

Облачные технологии как тренд 2023 года, или как и зачем бизнесу внедрять подход Cloud Native?

Сергей Калмаков

Лига Ставок

1. Что такое монолит и почему стоит от него отказаться (плюсы и минусы)
2. Как перейти с монолита на микросервисы? Где будут основные проблемы и боли? Как их максимально избежать?
3. Почему стоит выбрать микросервисную архитектуру/ приватное облако.
4. Зачем бизнесу Cloud Native? (Масштабируемость, устойчивость, time to market, решение ключевых проблем пользователя)
5. Как этот процесс повлиял на команду и культуру в вашей компании?

Программный комитет ещё не принял решения по этому докладу

Шардирование рекомендательной системы

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

Программный комитет ещё не принял решения по этому докладу

Как мы построили модерацию рекламы с нуля и достигли потока 1 млрд вердиктов в сутки.

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

Программный комитет ещё не принял решения по этому докладу

Сервис автоматической разработки нейронных сетей - ANNA

Демид Гаибов

Альфа-Банк

Расскажем как мы пришли к тому, что большую часть рутинной работы DS можно автоматизировать. Опишем каким образом мы готовим все для этого: подготовка данных (Hadoop, PySpark, Airflow), инфраструктура для обучения моделей и их применения (k8s, Jenkins, MLflow). Подробно обсудим сервис ANNA (Auto Neural Network Analytics, основной стек: FastAPI, Vue, Postgres, RabbitMQ), который позволяет обучать модели и выводить их в промышленную среду без участия DS, и все что требуется это выборка для обучения. Затронем вопросы применения всего этого в реальных условиях с ограниченным количеством ресурсов.

Программный комитет ещё не принял решения по этому докладу

Распределенная трассировка с Jaeger и Clickhouse

ClickHouse
Observability в enterprise
DevOps / SRE

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

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

Доклад принят в программу конференции

Масштабирование пропускной способности поиска Яндекса в 4 раза

Поисковые системы
Организация системы кеширования
Отказоустойчивость
Оптимизация производительности
Профилирование
Распределенные системы
Оптимизация
Микросервисы

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

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

Доклад принят в программу конференции

Проектирование БД: От NF к денормализации данных

Миграции данных
Базы данных / другое
Рефакторинг
Архитектуры / другое
Оптимизация

Когда я учился в университете нас учили проектировать БД с помощью нормальных форма(NF). Однако на работе я столкнулся с тем, что с ростом проекта, увеличения кол-ва данных этот подход работает медленно. Об этом я и хочу рассказать.

Я один из разработчиков edu.tinkoff.ru, которые строили платформу с самого начала.

Программный комитет ещё не принял решения по этому докладу

Сам себе вендор. Внедрение EVPN в VK Cloud

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Сетевое администрирование
Инфраструктура
Сеть

Облака - это не только независимая инфраструктура где-то в интернете. Это еще и непосредственные физические сетевые стыки с крупными клиентами прямо в их ЦОДах. Чаще всего, сети - это ответственность сетевых инженеров. А у них, обычно, все построено на вендорном железе. Но что делать в том случае, если привычных всем вендоров больше нет?
Поговорим о проблемах вендорных решений, использовании их на примере такой задачки как организация внешних стыков облака. Расскажем о том, как сделать то, что предоставляют вендоры из подручных материалов. Представим свою реализацию EVPN VTEP из стандартных opensource инструментов - OpenVSwitch, gobgp, Python.

Доклад принят в программу конференции

Лайфхаки проектирования высоконагруженных сервисов

Перед нами стояла задача добавить в Сбербанк Онлайн отдельный высоконагруженный (до 4000 tps) сервис по работе с депозитными и инвестиционными продуктами клиента. На примере данного сервиса расскажем и покажем, какие подводные камни возможны при проектировании высоконагруженных сервисов, какие лайфхаки следует применять, чтобы снизить нагрузку на бэкенд, и какие способы увеличения производительности бэкенда следует применять.

Программный комитет ещё не принял решения по этому докладу

Авито.Автозагрузка: от 4млн. до 80млн. активных объявлений. Как мы меняли архитектуру для поддержки роста х20

Архитектурные паттерны
Оптимизация производительности
Рефакторинг
Архитектуры / другое
Поддержка и развитие legacy систем

Автозагрузка это инструмент, позволяющий клиентам автоматизировать работу со своими объявлениями. Он состоит из множества сервисов и входит в топ-10 потребителей ресурсов в компании.
За все время существования мы привыкли к линейному росту - каждый год продукт увеличивался в 1,5-2 раза, но в 2021 году все изменилось. Для запуска важных продуктовых инициатив нам требовалось поддержать рост х20 и несмотря на то, что мы имели неплохой “запас прочности”, к таким цифрам мы не были готовы.

На Saint Highload++ 2023 я уже рассказывал, как мы готовили к росту один из наших сервисов - с какими проблемами столкнулись и какие архитектурные решения использовали для их устранения (https://highload.ru/spb/2023/abstracts/10416).

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

Программный комитет ещё не принял решения по этому докладу

Зачем делать прожорливый софт. Архитектурные принципы построения распределённых систем

Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Методы и техника разработки ПО
Разработка библиотек, включая open source библиотеки
Инструменты

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

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

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

Программный комитет ещё не принял решения по этому докладу

Создание плагина к Trino (PrestoSQL) для высоконагруженной обработки и массовой аналитики данных в Apache Superset

В докладе поделимся опытом разработки и массового развертывания собственного плагина к Trino (PrestoSQL) на Java для эффективной замены Data Warehouse и построения масштабируемой системы BI-аналитики в Apache Superset на базе раcпределенного ANSI SQL движка запросов.

Программный комитет ещё не принял решения по этому докладу

Как эффективно ранжировать весь товарный рунет

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

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

Доклад принят в программу конференции

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

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

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

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

Доклад принят в программу конференции

Слишком…много…асинхронщины…На что обращать внимание при работе с фичей из десятка сервисов, обрабатывающих 15 000 асинхронных задач в секунду

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

* Сложность отладки и поиска проблем асинхронных задач
* Почему не нужно пытаться брать слишком много задач на каждую ноду
* Как быть если асинхронность добавляется еще и на клиенте
* Почему в таких случаях не стоит пользоваться вашей основной базой данных
* Как держать ваше состояние консистентным без возможности сервисам сообщать о своем состоянии друг другу
* Зачем нужно иметь возможность конфигурировать выполнение таких задач

Программный комитет ещё не принял решения по этому докладу

SberAds: современные технологии в legacy продукте

C/C++
Бэкенд / другое
Tarantool
Базы данных / другое
Отказоустойчивость
Стандарты кодирования
Масштабирование с нуля
Логирование и мониторинг
Поддержка и развитие legacy систем
GO
Observability в enterprise
DevOps / Кубер

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

В докладе я хочу осветить как нынешний SberAds вырос из кодовой базы, созданной еще в begun.ru, а затем долгое время жившей в Рамблере. Сейчас, когда у нас огромные планы роста, мы модернизируем наш технологичесий стек. Я расскажу как мы:
- стали переходить на Go;
- перемещаем старые сервисы в Kubernetes;
- внедряли istio и какую пользу получили от этого;
- интегрировали jaeger;
- стали использовать tarantool;
- заменили самописные "сокеты на стейройдах" на kafka;
- стандартизировали мониторинги;
- и, самое главное, стали горизонтально масштабируемыми.

Программный комитет ещё не принял решения по этому докладу

Контроль управление api компании через apigateway - достойное решение или лучше разработать самим?

Всё чаще интеграции в компаниях реализуются посредством API с использованием форматов, вроде JSON или SOAP. В мире микросервисной инфраструктуры, часто, микросервисы имеют свой SWAGGER с описанием всех методов и бизнес функций сервиса. Это не плохо, когда таких сервисов десятки и можно превентивно управлять их жизненным циклом, разделяя окружения по namespace k8s или кластерам. В данном случае у Вас каждый микросервис - это независимая единица, которая имеет свой жизненный цикл и может быть опубликована для партнёров через точку балансировки.

А что делать, когда сервисов становиться больше? Что делать, когда бизнес заказчики хотят не просто публикуемый endpoint сервиса на балансировщике, но и управлять этой публикацией, параметрами подписок партнёров, добавляя документацию, контакты, условия работы с сервисом? И тут мы подходим к интересному классу инструментов, который называется - api gateway.

Рассказ пойдёт о том, как мы решая проблемы бизнеса по публикации управляемого api сервисов для партнёров, внедрили единый инструмент управления API и стали его использовать и для других нужд.
Каких спросите Вы? Приходите на доклад и узнаете!

Программный комитет ещё не принял решения по этому докладу

От CRM к DataLake с K8s и Микросервисами

Вильмов Андрей

ООО ПерилаГлавСнаб

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

Программный комитет ещё не принял решения по этому докладу

BPMN сервис. Как на сервисе весом в 10ТБайт ежедневно обрабатывать 1Тбайт пользовательских данных и спать спокойно

API
Python
Базы данных / другое
Отказоустойчивость
Оптимизация производительности
Распределенные системы
Методы и техника разработки ПО
Масштабирование с нуля
Критерии выбора технологий для проекта
Проектирование информационных систем
ETL
Оптимизация
Обработка данных
Микросервисы
Инструменты
Методологии

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

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

Программный комитет ещё не принял решения по этому докладу

5 новых способов использовать данные в вашей Kafka

Java
Архитектурные паттерны
Распределенные системы
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
ETL
Обработка данных
Andrey Serebryanskiy

Raiffeisen Bank

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

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

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

Программный комитет ещё не принял решения по этому докладу

Петабайтный стейт процессингов Метрики в YDB и S3

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

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

Доклад принят в программу конференции

Внутри S3

PostgreSQL
Отказоустойчивость
Распределенные системы
Масштабирование с нуля

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

Программный комитет ещё не принял решения по этому докладу

Как подружить Zeus с Prometheus. Мониторинг Богов

Владислав Зенов

ПАО Росбанк

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

Программный комитет ещё не принял решения по этому докладу

Как нам помогает Low code в разработке Control plane PaaS облака

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

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



* Что за облако и для кого
* Наша технология
* Технология 1С:Элемент для создания веб и мобильных приложений
* Что мы получаем
* Поддерживаемость, которую дает платформа
* Без boilerplate и вообще велосипедов решенные куча задач
* С пагинацией
* С правами доступна
* С поиском
* С BI (!)
* Причем, не только “business” , но и вообще
* С локализацией
* С работой на мобильных
* И… много чего еще
* Что классного
* Получаешь фичи вместе с платформой — это магия
* Сама технология обкатывается на большом сложном приложении
* Что сложного
* Сложно с многопоточностью
* Привыкаешь к подходу “сначала сделаю в платформе, потом тут” — это не всегда хорошо
* Не совсем целевая задача — много где первопроходцы

Программный комитет ещё не принял решения по этому докладу

Multi-tenancy в условиях виртуального хостинга

Системы прав доступа
Бэкенд / другое
Критерии выбора технологий для проекта
Поддержка и развитие legacy систем
Слабо связанная архитектура
Инфраструктура
Безопасность инфраструктуры

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

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

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

Внедрение чего-либо нового в подобной multi-tenancy всегда предъявляет специфические требования к решению:

1. Изоляция на уровне пользователей
2. Потребление ресурсов системы только на время использования
3. Малое потребление ресурсов

На примере нового файлового менеджера продукта виртуального хостинга расскажем как мы внедряем новые функции в условиях multi-tenancy виртуального хостинга

Программный комитет ещё не принял решения по этому докладу

Алиса 6 лет спустя

API
Java
C/C++
Архитектуры / другое
ML

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

Доклад принят в программу конференции

Импортозамещение (3)

Миграция витрины данных с СУБД Teradata в СУБД Greenplum

PostgreSQL
Базы данных / другое
Хранилища
Обработка данных

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

Доклад принят в программу конференции

Веб-сервер Angie год спустя: новые возможности и планы на будущее

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

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

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

Доклад принят в программу конференции

Отказоустойчивая виртуализация на отечественных решениях: ожидание и реальность. Реальный опыт построения метро-кластера на отечественной СХД и виртуализации

Дмитрий Горохов

Инфосистемы Джет

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

Программный комитет ещё не принял решения по этому докладу

Оффтоп (3)

Это всё, что останется после меня: проблемы наследования кода и передачи прав на него

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

Доклад принят в программу конференции

От дощечки к компьютеру. Путь от ткачества к ЭВМ

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

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

Доклад принят в программу конференции

Математический хайлоад: большие, очень большие и немыслимо большие числа

Обработка данных
Расширение кругозора
Обзор
Образование
Александр Кирсанов

VK, Вконтакте

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

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

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

Доклад принят в программу конференции

Хардкор (2)

Расширение возможностей отладчика GDB при помощи Python

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

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

Доклад принят в программу конференции

Exception Handling: сквозь мультивселенные интероперабельности

Tarantool

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

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

Доклад принят в программу конференции

Platform Engineering (9)

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

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

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

Доклад принят в программу конференции

Высоконагруженная VDI из OpenSource для платформы киберучений «CyberCamp» в облачном Kubernetes

Отказоустойчивость
Оптимизация производительности
Распределенные системы
Масштабирование с нуля
Технологии виртуализации и контейнеризации
Управление конфигурацией
Работа с облачными сервисами
Эффективное использование облаков
Облака
DevOps / Кубер
Безопасность инфраструктуры
Инфобезопасность
Семён Барышников

Инфосистемы Джет

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

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

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

Доклад принят в программу конференции

Межсервисная авторизация в Авито.PaaS

Системы прав доступа
GO
Безопасность инфраструктуры

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

Доклад принят в программу конференции

Управление ожиданиями пользователей от вашей платформы

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

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

Доклад принят в программу конференции

Как сделать платформу удобной или Авито PaaS спустя 5 лет

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

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

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

Доклад принят в программу конференции

Как мы управляем трафиком тысяч подов в мультикластерной среде Kubernetes с помощью Service Mesh.

Распределенные системы
Технологии виртуализации и контейнеризации
DevOps / Кубер
Сеть

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

Доклад принят в программу конференции

Внутренняя платформа для разработки и разработчиков: за что платит бизнес?

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

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

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

Доклад принят в программу конференции

Опыт пилотирования контейнерных платформ

Степан Чернов

Инфосистемы Джет

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

Программный комитет ещё не принял решения по этому докладу

Проще, удобнее, быстрее: переход на NX монорепозиторий при разработке UI-кита

TypeScript
FrontOps
Поддерживаемый код
Практики программирования
Автоматизация разработки, доставки, эксплуатации
Кодогенерация

1. Как полирепозиторный подход к организации кода приводит к dependecy hell в бизнес-приложениях и почему
это проблема, с которой нужно бороться?
2. Как снизить порог вхождения в разработку внутренней библиотеки компонентов для новых сотрудников?
3. Как монорепозиторный подход к организации кода помогает облегчить поддерживание большой кодовой
базы?
4. Как использование NPM Workspaces позволяет снизить количество потребляемой ПЗУ при установки
зависимостей большой кодовой базы?
5. Почему использование NX в качестве системы сборки это отличный выбор?

Программный комитет ещё не принял решения по этому докладу

Open Source (13)

Open-source экосистема Китая: история, настоящее и будущее

Олег Сиротюк

ЛИЧИ Технологии

Компании Китая начали использовать 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 сообществами в мире и основой национального ИТ-суверенитета Китая.

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

Программный комитет ещё не принял решения по этому докладу

Качество и контроль в большом OpenSource проекте

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как разрабатываются свободные проекты в команде ALT?

Разработка библиотек, включая open source библиотеки
Инфраструктура
Профессиональное развитие инженера
Команда
Евгений

Синельников

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

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

Программный комитет ещё не принял решения по этому докладу

Open-Source AppSec Review: как сделать приемку, внедрение и харденинг open-source решения

Безопасность инфраструктуры

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

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

+ как сделать ревью и приемку open-source решения
+ как сделать его харденинг
+ какие решения можно использовать для сканирования на уязвимости
+ дадим чек-лист по приемке open-source компонента на "боевое дежурство"

Программный комитет ещё не принял решения по этому докладу

Как мы превращаем исследовательские проекты в области AI/ML в открытые фреймворки и библиотеки: опыт Университета ИТМО

Разработка библиотек, включая open source библиотеки
Митапы
Управление разработкой

Фреймворки и библиотеки с открытым кодом уже стали индустриальным стандартом в области AI/ML. Поэтому команды исследователей все чаще становятся участниками open-source сообщества - встречая при этом на своем пути множество трудностей.

Я расскажу о том, как на протяжении нескольких лет помогаю превращать результаты научных исследований в полноценные открытые инструменты. При этом речь пойдет не только о научных разработок лабораторий Университета ИТМО, но и инициативных студенческих pet-проектах. Обсудим как о технические аспекты вопроса, так и о нюансы развития сообщества открытого кода в академической среде.

Программный комитет ещё не принял решения по этому докладу

Опенсорс для компаний и разработчиков на примере Boost, C++, userver

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

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

Программный комитет ещё не принял решения по этому докладу

Дракон наносит ответный удар: построение высоконагруженной системы контейнерной виртуализации на китайских СПО решениях iSula и NestOS

Технологии виртуализации и контейнеризации
Дмитрий Варенов

Личи Технологии

Владимир Павлов

Личи Технологии

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

Мы расскажем вам, про:
1. Систему контейнерной виртуализации iSula и результаты ее нагрузочного тестирования в сравнении с Docker и Podman при 10/100/1000 последовательном и параллельном запуске контейнеров.
2. Особенности специализированного «облачного» дистрибутива NestOS для контейнерной виртуализации. Из отличительных особенностей данного дистрибутива стоит отметить его минималистичность. Так, размер iso образа NestOS составляет всего чуть более 700 Мб, а установленная система занимает меньше 10 Гб.

Программный комитет ещё не принял решения по этому докладу

Как вложиться в open source и не прогореть?

Оптимизация производительности
Распределенные системы
Хранилища

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

Программный комитет ещё не принял решения по этому докладу

Один пайплайн, чтобы править всеми!

Непрерывное развертывание и деплой
Непрерывная интеграция
Евгений Харченко

Райффайзен Банк

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

Программный комитет ещё не принял решения по этому докладу

Несравнённый опенсорс

Методологии и процессы разработки ПО; Сроки и приоритеты
Аудит
Метрики
Методологии

Сегодня OSS привлекает бескрайним разнообразием доступных решений, однако внешние зависимости всегда несут последствия для конечного проекта / продукта / компании. Чем руководствоваться, как оценивать риски, затраты и профит заимствований в суровом мире энтерпрайза? Формализуем выбор алгоритмах и моделях.

Программный комитет ещё не принял решения по этому докладу

(Не)удачный эксперимент по выращиванию культуры open source

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Дракон наносит ответный удар: создание специализированных дистрибутивов ОС для Embedded/Edge устройств на китайских СПО решениях

Аппаратное обеспечение
Железо
Инфраструктура
Дмитрий Варенов

Личи Технологии

Владимир Павлов

Личи Технологии

В 2021 году Китай опередил США по плотности внедрения технологий автоматизации и роботизации с более чем 243.300 установок/проектов показав рост в 44% по сравнению с 2020 годом. Примечательно, что все эти проекты реализованы не только на отечественной аппаратной базе но и программной и , в большинстве случаем, речь идет о кодовой базе проекта openEuler.

В нашем докладе мы расскажем о ведущих решениях СПО из Китая, которые используются для разработки специализированных дистрибутивов операционных систем для Embedded и Edge устройств. Также мы поделимся практическим опытом создания дистрибутивов для устройства Outdoor Box Nano от российского вендора Combox Technology и специализированного одноплатного компьютера FriendlyELEC NanoPi M4.

В докладе мы рассмотрим:
1. Технологические возможности кодовой базы дистрибутива OpenScaler для создания Embedded и Edge устройств. Мы расскажем о поддержке фреймворка Yocto, который позволяет создавать дистрибутивы операционных систем размером от 5 МБ и поддержке ROS/RTOS а также DsoftBus.
2. Представим процесс создания специализированного установочного IMG файла дистрибутива. Расскажем о шагах, необходимых для его создания.
3. Обсудим особенности установки специализированного дистрибутива и решения возникающих проблем В частности с выбором варианта загрузки, как Android или как PC. Настройки 3D ускорения и другие аспекты, такие как ядро, DTS и прошивки.
4. Наконец, мы представим законченное устройство, созданного с использованием специализированного дистрибутива. Продемонстрируем его функциональность и возможности.

Программный комитет ещё не принял решения по этому докладу

Open source как инструмент формирования сообщества

Антон Кутепов

Positive Technologies

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

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

Программный комитет ещё не принял решения по этому докладу

Golang Conf: Hardcore (3)

Что стоит за дженериками в Go

GO
Илья Горкун

Тинькофф

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

Доклад принят в программу конференции

database/sql: плохой, хороший и злой. Опыт разработки драйвера для распределенной СУБД YDB.

Базы данных / другое
Организация доступа к базам данных, ORM, собственные драйвера
Распределенные системы
Разработка библиотек, включая open source библиотеки
GO
Логи, метрики, ошибки

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

Доклад принят в программу конференции

Выжимаем из Go максимум производительности

Оптимизация производительности
GO
Оптимизация
Никита Галушко

VK, Вконтакте

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

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

Доклад принят в программу конференции

Golang Conf: Architecture (7)

Как мы разработали ядро реестра национальной доменной зоны

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

Доклад принят в программу конференции

ETL на Kafka + Confluent, проблемы и их решение с помощью Go

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

Доклад принят в программу конференции

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

GO
Микросервисы

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

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

Доклад принят в программу конференции

200 интеграций на 5 разработчиков.

Денис Божок

Островок. ру

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

Доклад принят в программу конференции

Магнит tech: сервисы остатков и цен на Go. Как справиться с большими потоками данных, быть гибким и консистентным.

PostgreSQL
Архитектурные паттерны
ClickHouse
GO

В докладе расскажем, как мы делали систему управления остатками и ценами:

- Какие технические сложности возникают при больших объемах данных (~ 500000000 строк, 150к/рпс на запись);
- Монолит vs микросервисы. Что выбрали и с каким сложностями столкнулись;
- Postgres vs Tarantool. Не самый очевидный выбор;
- Работа с Kafka: конфигурация, графики, семантика "exactly-once", драйвер kafka-go от segmentio;
- Согласованность в конечном счете — когда и зачем ее можно применять, как достичь;
- Извечный вопрос: предподготовить данные или рассчитать на лету? Мы выбрали гибридный подход;
- На какие метрики ориентировались: технические и бизнесовые;
- Покажем наши дашборды, расскажем, как мы мониторим асинхронную систему и проводим нагрузочное тестирование, графики ТТХ, нагрузки, таймингов;

Доклад принят в программу конференции

Go в Domain Driven Design

Архитектурные паттерны
Методы и техника разработки ПО
GO

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

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

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

Доклад принят в программу конференции

Сложное делаем понятным. Тактические паттерны Domain Driven Design в Go.

Методы и техника разработки ПО
GO

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

В докладе я расскажу о нашем опыте использование тактических паттернов DDD (Factory, Value Object, Entity, Aggregate, Repository), как мы к ним шли, что нам это дало при решение продуктовых задач.

Доклад принят в программу конференции

Golang Conf: Best practices (5)

Особенности разработки open source приложения для real-time стриминга IP-камер в разных форматах

GO
Оптимизация

Расскажу с какими особенностями языка 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: блеск, нищета и импортозамещение

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

Доклад принят в программу конференции

FerretDB - mongoDB снаружи, PostgreSQL внутри

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

Доклад принят в программу конференции

Как научить сервис сообщать об ошибке, чтобы это было понятно пользователям, машинам и программистам

API
Разработка библиотек, включая open source библиотеки
Микросервисы

Никаких happy path! Рассказ о том, как нам перестало хватать баннера “Что-то пошло не так” и как мы учились сообщать пользователю об ошибках во время выполнения запроса в системе хранения данных. Мы рассмотрим средства для работы с ошибками в Go, чем они хороши и что делать, если на пути встает сериализация.
Внедрили свой формат ошибок для общения между сервисами, оформили ее в библиотеку и решили следующие проблемы:
- как определять ошибку, если HTTP кодов уже не хватает;
- как добавить в ошибку параметры, чтобы показать детали проблемы, и как ее локализовать;
- как интерпретировать ошибки одного API для другого и не сойти с ума;
- как по ходу дела приручить панику, заложить стандарт для ошибок и отрефакторить кучу кода.

Доклад принят в программу конференции

Кодогенерация и как ее использовать эффективно

GO
Автоматизация разработки, доставки, эксплуатации
Типовые ошибки
Лайфхаки
Инструменты

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

Доклад принят в программу конференции

Golang Conf: Technologies (2)

Как создать отказоустойчивый и масштабируемый конвейер обработки больших файлов с помощью Cadence

Фреймворки
GO
Обработка данных

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

Доклад принят в программу конференции

Скрипты в приложениях. Как и зачем пользователям позволять писать код?

Прочие языки
GO

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

Доклад принят в программу конференции

Golang Conf: Обзор текущего состояния языка (2)

Эволюция Go: Как (не)изменилась наша реальность.

Бэкенд / другое
GO

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

Доклад принят в программу конференции

Deep-dive в планировщик Go или зачем мне воровать горутины?

GO

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

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

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

Доклад принят в программу конференции

Golang Conf: Go для высоконагруженных систем (3)

Работа с аренами - почти избавляемся от GC

GO

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

Доклад принят в программу конференции

Нет времени объяснять, программируй! История о том, зачем исправлять «фатальные недостатки»

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

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

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

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

Доклад принят в программу конференции

Шардируем Postgres не своими руками

PostgreSQL
Базы данных / другое
Организация доступа к базам данных, ORM, собственные драйвера
Отказоустойчивость
Профилирование
Распределенные системы
Администрирование баз данных
Тестирование новых продуктов
Хранилища
Обработка данных
Инфраструктура

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

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

Доклад принят в программу конференции

Golang Conf: Tooling (2)

Бойлерплейт как инструмент стандартизации Go проектов

⁃ Кому нужен ещё один генератор микросервисов
⁃ Единый интерфейс сервисов
⁃ UberFx и хуки слева и справа
⁃ Логи, рефлекты, конфиги
⁃ Сборка, дистрибуция.. профит 🤌

Доклад принят в программу конференции

Как и зачем писать свои плагины для GoLand

PHP
GO
Инфраструктура
Расширение кругозора
Лайфхаки
Александр Кирсанов

VK, Вконтакте

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

Доклад принят в программу конференции

Golang Conf: Career (4)

Собеседования на senior разработчика: проверяем softskills вопросами на hardskills

Teamlead
Коммуникация
Личное развитие
Техинтервью

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

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

Вы узнаете:
- Что проверяют на “простых” вопросах.
- Как задачки позволяют понять — впишется разработчик в команду или нет.
- Какие черты характера можно определить на вопросах по устройству многопоточности в го.
- Все это приправлено вагоном историй и баек из более чем 50 собеседований за 2 года на различные позиции.

Доклад принят в программу конференции

Как стать сеньором

GO
Soft Skills
Личное развитие
Василий Романов

VK, Облако Mail.ru

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

Доклад принят в программу конференции

Мастер-класс "Бинарные деревья или как увеличить шансы на прохождение алгоритмической секции в Тындексе"

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

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

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

Golang Conf: Testing (3)

Из pytest в go. Тестовое окружение на фикстурах.

Приёмочные и функциональные тесты
GO
Тимофей Кулин

Яндекс, YDB

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

- значительная часть теста может отводиться на подготовку окружения
- фикстура - инструмент для получения окружения "без подготовки"
- покажу как выглядят фикстуры в pytest и go
- расскажу о возникших задачах реализации и принятых решениях

Доклад принят в программу конференции

Как протестировать код на Go с базой данных?

Бэкенд / другое
PostgreSQL
Интеграционное тестирование
GO

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

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

Доклад принят в программу конференции

Fuzzing тестирование. Практическое применение.

API
Бэкенд / другое
Юнит-тестирование
GO

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

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

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

Доклад принят в программу конференции

Резерв (3)

АйТи независимость или что вынуждает нас делать свой гитлаб на Go и как оно получается

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

Доклад принят в программу конференции

Уязвимости чейнкодов Hyperledger Fabric написаных на go

Базы данных / другое
Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Безопасность программного кода, SQL и прочие инъекции
Блокчейн-технология
Смарт-контракты
Атаки
Безопасность
Илья Дружинин

Positive Technologies

Уязвимости chaincode написаных на Go влияющие на безопаность бизнес приложения на основе блокчейна Hyperledger Fabric
Архитектурные особенности исходного кода чейнкодов и Hyperledger Fabric

Доклад принят в программу конференции

Прагматичная архитектура: как проектировать go-приложение, руководствуясь чисто практическими соображениями

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

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

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

Что мы сделаем: возьмем реальную задачу и разработаем для неё архитектуру, попутно объясняя, откуда возникают те или иные требования и как формируются те или иные решения. Какую пользу принесут нам эти решения сейчас и в перспективе, и какими проблемами чреваты.

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

Доклад принят в программу конференции