Ретроспектива технологий и архитектурных паттернов (1)

Postgres от начала веков и до наших дней

Олег Бартунов

Postgres Professional

Иван Панченко

Postgres Professional

СУБД возникли гораздо раньше, чем люди это осознали. Мы начнём с самых дальних предпосылок, чтобы правильно проследить, как человечество дошло до концепции СУБД вообще и Постгреса в частности, как развивался и какими технологиями питался Постгрес. Из доклада слушатель узнает:

* Когда была создана первая база данных, и когда людям потребовалась СУБД;
* Как менялись представления человечества о том, какой должна быть СУБД, и почему язык SQL возник именно тогда, когда он возник;
* Какие были периоды дикого хайпа вокруг тех или иных фич СУБД, и во что они вылились после;
* Как Стоунбрейкер пришел к идее Постгреса и зачем;
* Кто основные контрибуторы в постгрес и в чём их вклад;
* Меняют ли технологии СУБД мир, и если да, то как;
* Чем отличается сообщество Постгреса сейчас о того, каким оно было в прошлом веке, и почему, насколько это применимо для других сообществ СПО;
* В чем причина(ы) роста популярности Постгреса;
* И наконец, история от самого известного российского постгресиста - что значит постгрес для него лично. В какой степени он сделал постгрес, а в какой - постгрес сделал его.

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

Фейл-секция (2)

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

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

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

Как понять, что проекту плохо если ты инженер

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

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

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

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

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

Системное администрирование (1)

Веб интервейс для управления балансерами нагрузки

Балансировщик нагрузки - инструмент мощный, но при этом сложный. В своём докладе я расскажу, как можно упростить работу с балансировщиками с помощью веб-интерфейса.
Веб-интерфейс существенно снижает порог вхождения для начинающих пользователей, а тем, у кого же есть опыт работы с балансировщиками через командую строку , очень облегчает работу. Мой продукт — Roxy-WI — практически не имеет аналогов.
Я расскажу, как можно через веб-интерфейс управлять HAProxy, Nginx и KeepAlived.
Покажу, как реализованы следующие функции:
- мониторинг доступности
- сохранение логов, действий
- настройка групп доступа (разрешений, разные роли)
- статистика всех серверов
- создание конфигураций серверов
- просмотр и фильтрация логов в в одном месте
- уведомления о событиях в телеграмм
- установка и настройка кластера высокой доступности.
В заключение разберу несколько практических кейсов и расскажу о планах по дальнейшему развити продукта

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

Архитектура и деньги (1)

FinOps нирвана: как зарабатывать деньги в облаке

- В облаке решения рядовых инженеров (выбор правильного или неправильного AMI образа, правильного или неправильного типа узлов Kubernetes кластера и т. д.) могут влиять на маржинальность бизнеса, и бизнесу необходимы инструменты для определения эффективности их IT.
- FinOps — это методология и основанные на ней практики и инструменты для повышения эффективности IT инфраструктуры.
- Основной целью FinOps является максимизация ценности облака для бизнеса.
FinOps позволяет сместить фокус с «мы тратим X тысяч/миллионов рублей в месяц на облако» в сторону «X тысяч/миллионов рублей в месяц на облако позволяют зарабатывать моему бизнесу Y тысяч/миллионов рублей в месяц». Внедрение FinOps позволяет принимать взвешенные и обдуманные решения с понятым бизнес результатом, выраженном в изменении тех или иных бизнес метрик.
- Внедрение FinOps позволяет организациям достичь:
- Контроля над облачными расходами. Первая фаза внедрения FinOps подразумевает настройку системы мониторинга за расходами и распределение облачных расходов по ключевым бизнес юнитам, чтобы понимать «маржинальность» каждого из них, определять тренды и аномалии.
- Оптимизации облачных расходов. Вторая фаза внедрения FinOps включает в себя:
- оптимизацию использования числа используемых расходов (путем, например, удаления неиспользуемых ресурсов).
- оптимизацию стоимости используемых ресурсов (например, за счет резервирования мощностей или получения скидок от облачного провайдера).
- Определение зависимости ключевых бизнес метрик и метрик юнит-экономики от стоимости облачной инфраструктуры: например, как связаны общая выручка и число Monthly Active Users (MAU) с облачным потреблением?

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

Энергетика и транспорт (2)

Аналитика по самолетам S7: pets vs cattle

Для вас полеты это поиск билетов, электронный check In, "пристегните ремни" и паспортный контроль. Для нас, программистов в авиакомпании, это полное техобслуживание самолетов раз в два года, проверки раз в два дня, штрафы в сотни тысяч долларов за задержку в десять минут. Мы не может делать А/Б тесты и "быстро двигаться, ломая штуки". А бизнес хочет, чтобы мы как можно точнее предсказывали время обслуживания самолете по совсем скромному количеству исторических данных.

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

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

Face Pay

Face Pay – сервис полностью бесконтактной оплаты проезда с помощью распознавания лиц в Московском метрополитене. Технологическим партнером проекта выступила компания VisionLabs, один из лидеров в области компьютерного зрения и машинного обучения.
Face Pay позволяет оплатить проезд, не используя при этом никакие физические носители. Пассажиру нужно пройти регистрацию в мобильном приложении «Метро Москвы» или «Московский транспорт», привязать фотографию своего лица, карту «Тройка» и банковскую карту. Чтобы оплатить проезд, нужно встать на специальный черный стикер перед турникетом и посмотреть в камеру, установленную на турникете. Турникет откроется, а деньги спишутся с привязанной к сервису банковской карты.
Face Pay – первый в России и в мире сервис по оплате проезда с помощью биометрии, запущенный в таком масштабе. Сервис доступен на всех 250 станциях метро, а с 16 марта 2022 года - на станции «Кутузовская» Московского центрального кольца.
В докладе мы расскажем, как происходила разработка уникального сервиса, какие особенности в тестировании подобных решений, в чем заключалась адаптация технологий компьютерного зрения для сложных условий работы, а также о перспективах внедрения Face Pay на других видах транспорта.

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

Аппаратное обеспечение, инфраструктура (3)

Multi-tenant Kubernetes

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

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

Эксплуатация голоса в Марусе. С какими проблемами мы столкнулись и причем тут GPU.

За три года эксплуатации Маруси мы разрослись до порядка двухсот серверов, внутри которых более тысячи видеокарт. Как мы их используем? Что за аббревиатуры ASR и TTS? Какие проблемы мы получили и как их решили?

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

Могут ли данные управлять аппаратной конфигурацией датацентра?

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

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

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

Как это работает, чего мы достигли и с какими сложностями мы столкнулись мы расскажем на нашем опыте решения сложной задачи построения платформы обработки данных с Большого Адронного Коллайдера (LHC) в Открытом Институте Ядерных Исследований в г. Дубна.

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

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

Архитектура надёжной In-Memory СУБД на примере Tarantool

База данных в оперативной памяти или in-memory db — понятие не новое. На сегодняшний день сложилась довольно сильная ассоциация подобных решений со словами «кэш», «неперсистентный» и «ненадёжно».

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

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

Цель моего доклада — показать, что in-memory технологии уже достаточно зрелые и надёжные, чтобы быть быть основным хранилищем данных в вашем продукте.

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

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

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

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

Ускоряем хранимые процедуры на Postgres pl/pgSQL по гистограммам или жизнь после импортозамещения

Доклад посвящен особеностям настройки БД и хранимых процедур после успешного перехода с Oracle PL/SQL на Postgres pl/pgSQL, о котором я рассказывал на прошлогодней конференции.
С тех пор накопился опыт лечения детских болезней в области производительности БД, плавно перетекающий в профилактику и лечение хронических заболеваий в этой же области.
В докладе с цифрами и фактами рассматривается опыт борьбы за производительность БД и рассказывется, как в случае использования хранимых процедур управлять производительностью.
Кроме того, при переходе с Oracle на Postgres обнаружены новые типы лежащих на этом пути граблей отложенного действия, о которых тоже будет с удовольствием рассказано.

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

Как сэкономить на масштабировании, переехав с Cassandra на Scylla DB

Наш сервис вычисляет инференс моделей машинного обучения в транзакционном режиме. Как БД для наших сервисов мы использовали Cassandra:12 нод по 10 ядер и 32 ГБ памяти. Немного цифр: среднее число запросов 600RPS, в пиковых нагрузках — 800RPS, ежедневная загрузка данных 500ГБ, нагрузка на базу от 50 000 до 100 000 RPS, желаемое время ответа БД меньше 100мс.

В начале 2020 мы столкнулись с пределами масштабирования: перестало хватать кластеров, появились всплески latency (из-за garbage collection), фантомные данные, увеличилось время загрузки (11-12 часов). У нас был выбор: масштабироваться за счет железа, но с каждым разом это будет все дороже и есть предел, или мигрировать. Мы выбрали миграцию базы с Cassandra на Scylla DB и думали, что мигрируем за пару спринтов...

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

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

Как выжить под нагрузкой, имея 100ТБ в нешардированной MongoDB

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

Взяв за основу реальный проект очень большой track & trace системы, я покажу, что именно происходит с системой класса big data, в которой по разным причинам откладывали переход на использование шардированной архитектуры хранилища под нагрузкой. И самое главное, как выжить в этих условиях, меняя архитектуру решения на лету без downtime (DT).

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

Нагрузочное тестирование СХД и особенности генерации тестовых данных из опыта компании Dell

В процессе тестирования СХД крайне важно эмулировать реальную работу пользователя. При этом надо убедиться не только в отказоустойчивости системы при высоких нагрузках, но и в корректности обработки данных и работы СХД в целом. Для многих СХД активно используются популярные инструменты нагрузки и генерации данных. Однако существуют такие СХД, сложность которых требует собственной автоматизации генераторов данных, например, СХД Dell EMC PowerMax. Такой процесс автоматизации построен на общих подходах к тестированию данных на СХД, учитывая при этом уникальные сценарии тестирования конкретной системы.

Чаще всего пользователи используют СХД Dell EMC PowerMax в качестве файловой системы или для работы с БД. В связи с этим мы определили две соответствующие группы разрабатываемых генераторов данных.

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

Во вторую группу генераторов данных мы отнесли генераторы с проверкой консистентности данных, так как консистентность на уровне дисковых устройств - это одно из важнейших качеств данных, которое мы стремимся контролировать в рамках СХД Dell EMC PowerMax.

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

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

Оптимизация производительности запросов в ClickHouse

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

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

Транзакционные очереди в PostgreSQL

Сергей Волков

Яндекс, Толока

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

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

OK S3: Строим Систему Сами

Вадим Цесько

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

Одноклассники уже длительное время эксплуатируют собственные распределённые отказоустойчивые хранилища данных. Для хранения и обработки почти эксабайта бинарных данных (видео, фото, музыка и др.) используются one-blob-storage и one-cold-storage. В качестве транзакционных хранилищ развёрнуты десятки нагруженных кластеров NewSQL на базе Cassandra, распределённых по трём или пяти датацентрам. Мы успешно переживаем аварии вплоть до выхода из строя датацентра без деградации обслуживания, в том числе в час пик.

Помимо своих систем мы эксплуатируем множество готовых продуктов для хранения артефактов сборки и тестирования, библиотек, образов, пакетов, логов, бекапов и т.д. Единственным общим знаменателем в качестве подключаемого бекенда хранения для всех этих сервисов является Amazon S3. S3 предоставляет высокоуровневый API для работы с объектами, а также обладает развитой экосистемой инструментов и SDK для многих языков.

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

Описанные в докладе решения и опыт могут оказаться полезными архитекторам и разработчикам распределённых сервисов хранения данных, особенно S3-подобных и/или на основе Cassandra, вне зависимости от используемых языков и платформ.

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

Векторный поиск в ClickHouse

Как сделать быстрое еще быстрее?

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

В этом докладе Вы узнаете:
1) Индексы в ClickHouse
2) Новый вид индексов
3) Преимущества и недостатки новых видов индексов

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

Оптимизация стоимости хранения данных в объектном хранилище, или когда больше == меньше

Объектное хранилище Dispersed Object Store (DOS) родилось в недрах корпоративной почтовой системы Mailion. Для корпоративной переписки характерно большое количество частично или полностью совпадающих писем. Дедупликация писем и их фрагментов на уровне объектного хранилища позволяет многократно снизить потребление дискового пространства и IO. При этом в DOS реализована не только дедупликация, но и другие механизмы, снижающие избыточность данных (чанкинг и компрессия). Оборотной стороной этих механизмов является рост накладных расходов: увеличивается количество метаданных, хранящихся на SSD, растёт утилизация CPU. Встаёт вопрос определения оптимального баланса аппаратных ресурсов. Что выгоднее – включить максимальный уровень сжатия и дедупликации данных, чтобы сэкономить диски, но при этом потратиться на топовый CPU, или отключить все вычислительно сложные оптимизации, но расплатиться за это покупкой большого количества медленных дисков?

Ответить на этот вопрос не так просто: разные аппаратные ресурсы компьютера имеют разную цену, в то же время алгоритмы дедупликации и компрессии обладают большим объёмом настроек, сложным образом определяющих финальную стоимость хранения данных. Мы воспользовались методами black-box оптимизации, чтобы определить комбинацию параметров, соответствующую минимальной стоимости хранения. В зависимости от значения параметров она может изменяться в диапазоне от $70 до $600 за отказоустойчивое хранение 1 ТБ записанной информации. При этом стоимость максимизируется как раз при тех настройках, которые интуитивно кажутся более логичными и правильными.

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

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

Распределенные графовые СУБД - будущее для аналитики на Больших Данных?

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

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

Роутинг и шардирование в PostgreSQL для случая MDM системы

В докладе мы рассмотрим способы построения кластера СУБД для MDM платформы Unidata и поговорим о различных стратегиях роутинга и шардирования.

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

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

Чтобы ответить на оба этих вопроса мы реализовали несколько альтернативных алгоритмов каждого типа и провели экспериментальное исследование.

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

Разработка высокопроизводительного RAID в SPDK

Петр Конопляник

ООО «Рэйдикс»

SPDK, набор инструментов для разработки подсистем хранения данных высочайшей производительности, был представлен несколько лет назад. Но до сих пор не существует готового способа для достижения доступности данных: у нас есть только ISA-L для EC, но нет готовых BDEV, которые хотя бы сделали реплику данных.
Мы расскажем о своем опыте разработки RAID bdev, созданного специально для дезагрегированных инфраструктур ЦОД, сделаем обзор существующих компонент, и расскажем почему их невозможно использовать.
Вас также ждет увлекательных рассказ о тех подводных камнях, на которые может напороться каждый кто взялся за SPDK.

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

Централизованный self-service ETL. О системе автоматизации, умеющей эффективно и дешево двигать данные между десятками систем.

С ростом продукта и развитием data-driven подхода, мы должны обеспечивать наших коллег простым и удобным способом автоматизировать трансформацию и батч-транзит данных между системами, с целью изучать их и проводить продуктовую/бизнес аналитику. Идея отделить в организации ETL-процессов декларативную часть от функциональной позволили нам достичь следующих результатов:
- Автоматизация расчетов для нового интересного отчета за 15 минут.
- Подключение к новым инстансам источников данных за считанные часы (пока там эти сисопсы креды в vault запихают).
- Data quality: проверка данных - это просто еще одна задача, которая падает если цифры не совпадают. Каждый пишет сам под свои витрины.
- Data lineage: вся трансформация и движение данных представлены декларативно, с явно указанными зависимостями между задачами.
- Около 2000 ежедневных задач на обработку петабайта данных в месяц (и нет, это не одна таблица), обновление 300 отчетов в Tableau для сотен пользователей, отправку информации во внешние аналитические системы и рекламные кабинеты. Для поддержки всего этого хватает одного дата инженера.

Мы не забыли и про всякие удобства, потому что без этого никто нашим инструментом пользоваться не будет:
- Continuous deployment, чтобы каждый мог потестить свои задачи сразу на живых данных.
- Slack-бот для взаимодействия с Airflow. Чтобы запустить какие-то зависимости, или целые подграфы задач.
- Получай данные там, где тебе нужно. Хочешь в Tableau, хочешь в гугл-спредшит, хочешь в slack.
- А ведь можно вообще не какой-то SQL запустить в BigQuery, а, скажем, процесс в контейнере

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

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

Как в MongoDB сделать распределённую очередь

Сергей Волков

Яндекс, Толока

Распределённая очередь на базе MongoDB используется в Яндекс Толоке как буффер для эффективной записи в ClickHouse. Она обрабатывает 1000 RPS на вставку и через неё прошло 1.5 ТБ данных. В докладе спроектируем распределённую очередь и отметим сильные стороны MongoDB. И представим нашу opensource-библиотеку для Java.

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

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

Индивидуальный коучинг в высоконагруженных проектах

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

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

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

Когда свой велосипед лучше чужого Феррари: Цифровизация бизнеса на базе Jira

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

Для трекинга задач команд департамента разработки мы уже давно используем Jira. Сейчас она стала для нас ядром экосистемы инструментов для автоматизации бизнес-процессов, но так было не всегда. 
Чтобы соблюдать баланс между созданием классных продуктов, умением планировать разработку обещанных фичей клиентам, доводить до финала долгие сделки и прозрачно анализировать самые прибыльные продукты и модули - нам нужно было выйти за пределы фиксации тасок в Jira и коннекта их с Git. 
Так тривиально, но не классически у нас появилась команда автоматизации бизнес-процессов, которая с руководителями направлений (да и всеми заинтересованными в развитие процессов членами команд) строит экосистему инструментов управления компанией на базе Jira. 

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

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

Эволюция R-Vision: как мы увеличили количество команд в четыре раза и с какими проблемами столкнулись.

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

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

GraphQL: Как не развестись после Honeymoon или что вас может ожидать при внедрении новой технологии в растущей команде?

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

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

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

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

Объединение DevOps, SRE, Dev, QA в единый DevOps процесс в банке.

Существует мнение, что DevOps работает только в формате небольшой компании и масштабировать очень сложно и вообще это не применимо к крупным энтерпрайз организациям или необходимо сразу создавать DevOps отдел.
В ходе данного доклада хочется раскрыть данную тему и поделиться положительным опытом, на темы:
- как мы выстроили работу DevOps, SRE, дежурной application службы без создания DevOps отдела
- как в эту схему вписали Dev и Qa , какую роль они играют
- как масштабировать данную систему при количестве инженеров 50+ и 150+ команд
- как быстро можно расти в данной схеме и не стать винтиком системы
- как проводить онбординг, стажировку
- как учитывать пожелания инженеров и облегчить найм

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

Безопасность (5)

OpenSource как источник атаки. Чем опасно? Как лечить?

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

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

Как найти злоумышленника в большом потоке данных

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

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

Формальная верификация при разработке ПО

С каждым годом тема формальной верификации все прочнее укрепляется в разных областях технологического бизнеса России. Формальная верификация - инструмент, позволяющий доказать соответствие предмета верификации его формальному описанию.
В докладе поговорим о плюсах и минусах формальной верификации, о том, как ее применяют при разработке ПО в области информационной безопасности. Обсудим задачу создания и доказательства формальной математической модели для прохождения сертификации во ФСТЭК.
В заключение рассмотрим более общие задачи, которые можно решать с помощью формальной верификации, а также сравним такие существующие инструменты, как Event-B, CPN Tools, TLA+, COQ.

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

Безопасные вычисления в высоконагруженных системах — что можно позволить себе с Intel® SGX в облаке

Все мы знаем поговорку «нет никакого облака — есть серверы в дата-центре».

Покажем, как добавить в ваши сервисы, размещенные у провайдера, новый уровень безопасности — создадим изолированный анклав в СPU с помощью технологии Intel® Software Guard Extensions (Intel SGX), к которому не имеет доступа ни гипервизор, ни сисадмин, ни сотрудник ЦОД. Это нужно для безопасного управления ключами, размещения критических функций в облаке и совместной децентрализованной обработки данных без раскрытия датасетов и моделей.

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

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

Шлагбаум на рельсы DevSecOps

Шлагбаум на рельсы

A: А давай сделаем Quality Gate на основании проверок SAST?
B: И заставим ВСЕХ его проходить!
C: И сделаем его блокирующим... 😈

Увлекательная история о том, как приручить инструменты Application Security в энтерпрайзе, заставить их работать с сотнями миллионов строк кода, поставить блокирующий релизный Quality Gate в производственном процессе и не остановить работу Банка.

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

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

Прогибаем разработку в промышленности

Вадим Щемелинин

СИБУР Диджитал

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

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

Демократизируй это. Как управлять тех. стеком в группе компаний.

Леруа Мерлен - международная компания, с офисами по всему миру: Франции, Италии, Бразилии, но это не значит, что мы пользуемся только теми технологиями, которые спускаются нам из других стран.
Наоборот, я своем докладе я расскажу:
Как разработчик из Москвы/Перми/Санкт-Петербурга может повлиять на тех стек, которым пользуются коллеги из Рио-де-Жанейро или Мадрида.
Как мы демократизировали обращение с технологиями не только на уровне российского бизнес юнита, но и на глобальном уровне.
Какие у этого есть плюсы и какие подводные камни.

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

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

Высоконагруженный агрегатор событий - практика проектирования

1. Проектирование агрегатора - общая схема агрегатора и выбор инструментария;
2. Выбор языка программирования для создания коннекторов агрегатора;
3. Производительность нормализатора Vector (требования к ресурсам, масштабирование, LUA или VRL);
4. Тестирование общей производительности агрегатора;

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

Нагрузочное тестирование синтеза и распознавания речи в SberDevices

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

TOC:
* Проблемы метрик: что такое "быстрый ASR/TTS"?
* Как подружить скорость и стабильность?
* Как оценивать софт, который очень по разному работает на немного разном железе?
* Что может влиять на результат, если шаг вашей шкалы - десятки миллисекунд?
* Как организовать performance QA если количество возможных сочетаний фич и настроек вашего продукта постоянно растет?

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

Ваше первое нагрузочное тестирование бэкенд-сервиса.

Антон Паршин

"Центр Финансовых Технологий"

Ваше первое нагрузочное тестирование бэкенд-сервиса.
--------

Когда возникает необходимость проводить нагрузочное тестирование?
Как собрать требования, когда это ваш "первый" раз.
Выбор окружения и стратегии тестирования. Грабли, на которые не стоит наступать.
Выбор подходящего инструмента (кто такой этот ваш jmeter и почему он отлично подходит для "пробы пера").
Метрики. Prometheus и Grafana
Проведение нагрузочного тестирования и анализ результатов. Что дальше?

--------
Полезные ссылки и литература.
Q&A.

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

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

Машинное зрение и обучение на металлургическом производстве

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

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

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

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

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

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

Как собрать облачную платформу для NLU-powered голосовых роботов и не облажаться

Сегодня коммуникационными роботами на базе NLU уже никого не удивишь: есть и коробочные решения вроде DialogFlow от Google, и опенсорс фреймворки вроде Rasa, да и каждый уважающий себя МЛ инженер хоть раз да и файн-тюнил BERT'а на задачу текстовой классификации. Нам в Voximplant захотелось собрать лучший опыт и дать возможность использовать state-of-the-art модели и подходы людям далеким от машинного обучения - и все не покидая браузера в рамках облачной платформы. И естественно это оказалось не так-то и просто. В рамках этого доклада Артем Бондарь - Head of AI компании расскажет о тонкостях создания облачного AutoML решения, какими трюками мы добивались низкой стоимости, сохранив возможность использвоать тяжелые нейросети, кастомизированные под каждого клиента, как мы работали с разными языками и как мы подошли к задаче few-shot-learning, пряча от клиента под ковер всю игру с гиперпараметрами.

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

Ускорение процесса верификации пользователей: как мы внедряли автоматическую проверку фотографий и документов при верификации для улучшения качества заявок и снижения нагрузки на KYC

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

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

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

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

Эксплуатационные испытания биометрических алгоритмов для Единой биометрической системы

Наталья Бессонова

ПАО Ростелеком

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

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

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

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

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

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

Как просто интегрировать ML-решение на базе компьютерного зрения с реальным устройством (кейс ECOBOT)

В своем докладе мы расскажем о том, как подружить ML-решение с реальным устройством, опираясь на кейс ECOBOT.

Задача

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

Решение

Чтобы решить задачу, мы выбрали подход, основанный на Robot Operating System, позволивший, во-первых, сделать симуляцию системы, а во-вторых, представить уже реальную систему в виде совокупности взаимодействующих друг с другом нод:
- нода захвата изображений с камеры,
- нода детекции и распознавания мусора (на базе нейронных сетей),
- нода преобразования пиксельных координат в реальные,
- нода взаимодействия с аппаратной частью ECOBOT.
Программный комплекс работает на Jetson Nano.

Оценка

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

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

Распознавание речи для субтитров в VK Видео

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

Вконтакте

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

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

DevOps и эксплуатация (13)

Бесшовное внедрение практик безопасности в DevOps конвеер, или Как обеспечить безопасность беспрерывной разработки

Андрей Иванов

Swordfish Security

- Какая часть является главной в магическом сокращении DevSecOps: DevOps (разработка и эксплуатация, встроенные в бизнес-процессы организации) или Sec (все, что связано с безопасностью)? Как понять, что в вашей организации пришло время для DevSecOps и как к нему подготовиться?
- Основные принципы и концептуальная схема DevSecOps. Выделяем главное и даем практические рекомендации
- Поговорим об основных практиках информационной безопасности в разработке (Sec) и о том, когда и в какой последовательности их внедрять.
- Бесшовное внедрение - миф или реальность? Как его осуществить?
- Кейс крупного банка по успешному внедрению DevSecOps.

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

Развитие и жизненные циклы пайплайна

- зачастую внедрение и развитие практик CI/CD сталкивается с проблемами и сопротивлением команд
- часто это вызвано тем, что делается упор на выбор инструментов, а не на понимание и удовлетворение потребностей команды
- каждый pipeline проходит через 3 этапа, на каждом из которых закрывается одна из базовых потребностей команды, требуется ограниченный набор инструментов, применение которых даёт максимальный результат
- разберём каждый из этапов развития, требуемые инструменты, критерии завершения и особенности прохождения

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

Как мы защищам миллионы клиентов при перегрузках при помощи динамического троттлинга в высоконагруженных системах

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

Динамический троттлинг – наш подход к вопросу защиты сервисов от перегрузки. Механизм автоматически подстраивает объем пропускаемого трафика, реагируя на изменение состояния бэкендов.

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

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

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

Общий флоу разработки в Ozon. Как сделать жизнь разработчиков проще?

1) Рассказ о том, как раньше жили разработчики в Ozon и почему жить было не так просто.
2) C чего начали проектировку общего flow разработки.
3) Как все устроено внутри архитектурно.
4) Как внедряли flow и с какими проблемами столкнулись при разработке и внедрении.
5) Что изменилось и что стало лучше?
6) Сделаем выводы, что стоит использовать, а на какие грабли лучше не наступать.

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

Надёжность высоконагруженных C++ приложений в Яндекс.Маркет

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

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

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

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

DevSecOps:Практики безопасной разработки в постоянно меняющихся условиях

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

Теоретические ингридиенты:Зачем нужен DevSecOps и что он дает, как построить процессы безопасной разработки в крупной компании (800+ разработчиков), с одной стороны не ломая сложивщиеся процессы, а с другой, - траснформируя сложившуюся культуру разработки, как обеспечить соответствие практик разработки требованиям регуляторов ФСБ ,ФСТЭК для ускорения прохождения сертификации и без большого удорожания процесса.

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

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

Как мы засунули 200+ датасаентистов в кластер k8s и перестали волноваться

Создали удобное рабочее окружение для 200+ датасаентистов для работы co spark при помощи jupyterhub и k8s.
А еще она легко масштабируется, управляется и тарифицируется в мультитенант среде.
Расскажем как мы это сделали и какие проблемы решили.



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

Dashboard as a code, или путь от правок в UI до grafonnet

Антон Быстров

Percona/Simbirsoft

Почему править дашборды в UI это не наш путь?
Краткий обзор и сравнение различных путей реализации dashboard as a code
Введение в jsonnet
Работа с grafonnet

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

Как мы в Ситимобил пишем, собираем и обрабатываем 100 ТБ логов в день

Сергей Фролов

Ситимобил

- Почему так много и зачем нам это нужно
- Особенности логов
- Флоу доставки логов - от лог-файла до Kibana
- Filebeat - лучше всех
- Kafka - отказоустойчивый брокер и буфер перед Elasticsearch
- Батарея Logstash
- Elasticsearch - сердце ELK-стека
- "Единый Логин" (FreeIPA + Authelia + NGINX)
- Всюду SSL
- Алертинг (ElastAlert, Grafana)
- Как все это мониторится
- Для чего еще используем эластик (кроме логов)

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

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

Чемакин Алексей

ООО "Р-Вижн"

* Коробочный продукт. Разные заказчики, много фиче-реквестов, разные готовности клиентов к обновлениям. Монорепа. Три мажорные релизные ветки на поддержке.
* Наша разработка без gitflow. Релизные ветки. Тестовые ветки. Фиче-ветки. Проблемы с git конфликтами.
* Переход на gitflow, что нужно учесть. Плюсы и минусы.
* Выбор CI/CD систем для автоматизации. Jenkins, Gitlab CI, свои сервисы, интеграция со Slack.
* Автоматизация разворачивания стендов для тестирования фиче-веток (Jenkins + свои микросервисы на Node.js). Связывание жизненного цикла задачи в Jira и жизненного цикла стенда для тестирования.
* Автоматизация работы с пресетами данных приложения как с пререквизитами для тестов и автотестов.
* Динамически изменяющиеся формы в Jenkins, Groovy.
* Выбор между Яндекс Облаком и своим ЦОД на основе коллокейшна и VMWare.
* Тулза для автоматической каскадной проливки фиче ветки в релизные ветки, с взаимодействием с разработчиками по разрешению git конфликтов.
* Ускорение процессов сборки и деплоя тестовых стендов за счет локального docker-реестра и поддерживания docker - кэшей в горячем состоянии.
* Легкость диагностики сборка какого из 50 сервисов сломалась, за счет Jenkins blue ocean и Parallel Stage execution.

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

Экодиктант 2021: highload проект с 0 за 2 месяца

Как мы настроили и отправили почти 10 миллионов писем за одну неделю с двух холодных доменов в рамках проводимого мероприятия Экодиктант 2021.

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

Неинвазивная интеграция кластера K8s и Calico через BGP в устоявшуюся сетевую топологию стабильной компании

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

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

Контейнеры мертвы. Да здравствуют виртуальные машины!

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

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

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

Решение проблем производительности микросервисов при работе с IBM MQ

Сергей Богданов

Газпромбанк

I. Программирование микросервисов по стандартным шаблонам
II. Проблемы
Однако сочетание spring boot с IBM MQ спровоцировало проблемы в процессе промышленной эксплуатации под нагрузкой с периодичностью раз в месяц:
1) множество TCP-соединений "положило" сервис
(наши сервисы сделаны на spring boot)
2) при этом перестают учитываться сообщения, а на сервисе растет их очередь
III. Как мы пытались диагностировать проблему
- Локализация проблемы и дополнительная диагностика
- То, что мы нашли - нас очень удивило
IV. Мы устранили проблему и неожиданно наткнулись еще на одну проблему

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

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

Глеб Сахнов

Сбербанк

В докладе расскажу почему разработчикам CPU-интенсивных приложений важно понимать принципы работы процессорного кэша.
Рассмотрим предпосылки появления кэша в CPU и почему он работает. На реальных примерах кода увидим многократное ускорение алгоритмов при реализации в cache-friendly манере. Рассмотрим что такое false sharing и причины его возникновения в многоядерных процессорах. Поговорим о том как распознать проблемы с кэшэм в многопоточных приложениях. Покажем как можно измерить эффективность использования CPU-кэша в linux.
Бонус: приведем пример ускорения алгоритма с использованием branch-prediction.

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

Как сделать сервис нотификаций без создания хайлоада самому себе

Максим Исаченко

СберМаркет

Возникла задача в разработке сервиса для для отправки push нотификаций.

Для решения разделили на 2 отдельных сервиса: notification service отвечает за приём пушей для отправки и имеет ручки для обработки callback-ов от мобилки, второй- push sender, его обязанности- отправка пуша на мобильное устройство и сигнализирование в случае проблем.



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

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

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

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

Service Mesh на стероидах (часть 2): Zero Deployment Downtime в корпоративных приложениях

Представляю вторую часть триптиха на тему "Service Mesh в Enterprise-grade приложениях". В первой части я рассказал об основных принципах построения управляемого многоуровневого Service Mesh и дал основные паттерны его использования для обеспечения версионирования и структурирования приложений. Вот тут можно посмотреть запись https://www.youtube.com/watch?v=XtvwZqdtfgI.

Вторая часть будет посвящена техникам ВlueGreen и Canary деплоймента для обеспечения Zero Deployment Downtime а так-же одновременного тестирования нескольких независимых фич.

В докладе я расскажу:
• что из себя представляет версия контракта на техническом уровне и как система ее узнает
• принципы мульти-версионности в REST, Messaging, DB
• как воедино связывается работа с версиями в разных "средах" (REST, Messaging, DB)
• унифицированный жизненный цикл версий (deploy, promote, rollback)
• дискавери контрактов- как микросервис может определить контракт своего пира, и подстроиться под него
• границы использования мульти-версионности для обеспечения Zero Deployment Downtime всё-таки это не silver bullet, и по опыту- работает не всегда.

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

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

Евгений Лукин

Synapse Service Mesh

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

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

1С:ERP - автоматизируй все!

Речь в докладе пойдет об 1C:ERP - современной и полнофункциональной ERP-системе от компании 1С.
Расскажем о возможностях системы, поговорим о планах развития, а также покажем примеры крутых проектов внедрения!

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

Грабли дизайна кода от большого ума

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

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

Блокчейн в корпоративной архитектуре - дань моде или необходимость?

Васин Денис

Waves Enterprise

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

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

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

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

Импортозамещение почтового сервера

Компания МойОфис разрабатывает сразу несколько почтовых решений и имеет большой опыт работы на российском рынке. Я отвечаю за внедрение продуктов компании и хочу поделиться опытом, накопленным за последние 5 лет. На примере продуктов МойОфис я расскажу о процедуре миграции почтовых серверов. Проиллюстрирую основные сценарии "переезда“ с одной почтовой системы на другую. Мы поговорим об инструментах миграции разных типов данных: письма, календари, адресная книга. Не оставим без внимания проблемы, с которыми мы сталкиваемся на практике и пути их решения.

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

Аналитика микросервисов. Практический опыт аналитика в enterprise

Разномазов Валерий

Южный федеральный Университет

В докладе будет рассказано о практическом опыте работы аналитика на проектах российских банков уровня ТОП-5. В условиях Agile сопровождать "монолит" стало проблематично и в последнее время все чаще крупные банки (как в прочем и многие крупные компании) переходят к микросервисному архитектурному стилю. В связи с этим к аналитикам начали предъявляться новые требования. Аналитик больше не "технический писатель", занимающийся документацией и подготовкой маппингов для адаптеров.Теперь он больше "солюшн архитектор" и центральная фигура в команде, отвечающая как за выбор решения, так и за постановку задач разработке. В докладе будут рассмотрены следующие темы: Что же такого в микросервисах с методологической точки зрения и какие артефакты требуют внимания при анализе. Микросервисы - всегда хорошо и есть ли кейсы, когда все же лучше оставить монолит? DDD, онтология как лучшие практики. Как выбрать и описать решение, чтобы оно не стало препятствием для последующих доработок и интеграции.

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

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

Высоконагруженный блокчейн в mission critical системе

Иван Косарев

ООО Веб3 Технологии

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

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

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

Вадим Михайлов

Координационный центр доменов .RU/.РФ

В докладе планируется кратко ввести в курс истории интернационализации интернет идентификаторов, рассказать о текущей работе экспертных сообществ (таких как IETF, Unicode Consortium, W3C, ICANN и т.д.) и разработанных ими отраслевых стандартах, коротко напомнить о работе системы доменной адресации и почтового взаимодействия, а также раскрыть особенности и проблемы с внедрением поддержки IDN и EAI. В основной части доклада будет дан обзор доступных готовых решений, таких как: почтовые сервисы Microsoft Live, Gmail; почтовые программные продукты от Apple, Microsoft, Communigate Pro, Xgen Plus и др.; программные библиотеки и фреймворки популярных языков программирования, а также будет рассказано о реальных кейсах реализации корректной работы с IDN и EAI технологиями в почтовых системах различного масштаба. В завершении предлагается дискуссия с участниками конференции об объективных и мнимых факторах, сдерживающих внедрение IDN и EAI, о практической применимости международных подходов и существующих решений.
Докладчик Михайлов Вадим, консультант по инфраструктуре Координационного Центра национальных доменов .RU/.РФ.

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

Алгоритмы бесконфликтного слияния состояний

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

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

Что есть в Китайских облаках

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

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

В Китае есть своя собственная огромная вселенная облачных сервисов. Часть из них похожа на сервисы Американских компаний а часть из них уникальна. Есть и свои уникальные технологии для разработки и тестирования приложений и построения IoT систем. Давайте посмотрим что из этих уникальных сервисов может нам пригодиться.

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

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

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

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

Так же хочется рассказать про компоненты для создания игровых сервисов.

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

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

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

Как забыть про проблемы с производительностью? Tarantool в качестве СУБД для каталога товаров.

В докладе будет идти речь про применение СУБД Tarantool для одной из самых нагруженных частей проекта Ситилинк - каталога товаров. Мы расскажем наш путь для достижения стабильной производительности в выдаче до 1.2M сущностей/мин на чтение и до 1M изменений/мин на запись со средним временем ответа менее 30ms. Затронем вопросы отказоустойчивости, мониторинга, деплоя, версионирования, а также подводные камни и правила к которым мы пришли за три года работы с tarantool.

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

Какие архитектурные решения в Яндекс Go позволяют запускать десятки параллельных продуктовых экспериментов

Олег Ермаков

Яндекс Go

Команда продуктовой разработки Яндекс Go прошла путь от "нескольких человек, пишущих в монолит" до "команды, в которой больше 50 человек, которая развивает микросервисную архитектуру продукта и запускает десятки параллельных продуктовых экспериментов". Этот путь сопровождался поиском и внедрением решений, ускоряющих разработку, позволяющих масштабироваться и увеличивающих надежность системы. Об этих решениях и будет доклад:

- когда и как мы перешли от монолита к микросервисам;
- как и когда мы используем api gateway (и его разновидность backends for frontends);
- как мы запускаем и отслеживаем результаты продуктовых экспериментов;

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

Гибридная архитектура: разделяемый на микросервисы монолит

Пусть нам дана задача разработать решение, способное работать 24/7, под большой нагрузкой, динамически реагировать на эту нагрузку со всеми вытекающими. И как результат мы выбираем микросервисную архитектуру.

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

И тут возникает проблема: микросервисная архитектура пусть даже в докерах или как-то ещё задеплоенная на один сервер хорошо работать не сможет.

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

Попутно:
- автозамена вызоыва через RMQ на прямой
- автозамена вызова через HTTP на прямой
- автосокращение используемой памяти в 6 раз
- снижение нагрузки на CPU в 2 раза
- разные деплои: один для слитого варианта, один для раздельного - на Kubernetes
- и прочее-прочее-прочее.

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

Микросервисы через боль и превозмогание

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

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

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

1С: Paas & ICON

Бизнес-приложения и облака - такой связкой уже никого не удивишь. Но что делать, если у тебя не одно приложение и один клиент с парой десятков пользователей - а тысячи приложений и десятки тысяч пользователей в единой инфраструктуре?

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

Экспертные системы для металлургии: пятилетка за год

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

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

Как вырастить поисковый индекс в 3 раза, трафик в 2 раза и сэкономить 30% CPU

Алексей Салмин

Яндекс Поиск

В этом докладе я расскажу краткую историю развития ядра веб-поиска Яндекса за последние несколько лет. Основной задачей команды, которая разрабатывает наш движок, можно назвать экономию ресурсов. Экономия не является самостоятельной целью, но при этом имеет огромное значение: она позволяет на том же железе наращивать поисковую базу, внедрять новые фичи и модели в ранжирование, принимать растущий пользовательский трафик. С конца 2017 года мы прошли интересный путь: входящий трафик и поисковая база выросли в несколько раз, и при этом мы не только не нарастили потребление CPU и RAM, но и смогли передать десятки процентов мощностей на другие проекты поиска. Конечно, это сравнение неполное, т.к. за это время мы проапгрейдили сеть и диски, но интегральное потребление именно по CPU и RAM у нас не растет.

Вы узнаете, как снизить потребление CPU с помощью:
* сжатия (sic!);
* микросервисов (sic!);
* асинхронного IO (???);
* заменой горизонтального шардирования на вертикальное и наоборот.
И другие интересные технологические решения: erasure-recovery в реальном времени, key-value storage на десятки миллионов RPS, e2e-сжатие со словарем, батчевание применения нейросетей и деревьев.

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

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

Граф компонентов: как отобразить 100 компонентов и 500 связей.

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

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

Внедрение OpenSource решений в АСУТП

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

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

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

Как мы запустили систему из 10'000 серверов за 4 месяца

Немного об умных домах, городах и квартирах или зачем такое количество серверов
Мини-сервер, все равно сервер и он приносит свои сложности
Процесс обновления на лету - радости работы 24/7
Как не убить "стаю" в один клик, или о процессе тестирования и релиза.
Затачка усложняется, или как работать с 100К, 1M и далее серверов.

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

От 0 до 200 000 000 игроков — об эволюции бэкэнда за 40 мин

War Robots — мультиплеерный 3D-шутер. Недавно ему исполнилось 8 лет, и за время существования проекта архитектура претерпела множество изменений. Поначалу она была очень простой и строилась на облачных решениях: на бэкенде был всего один сервис, который отвечал за работу с профилями игроков, а сама игра была реализована с помощью облака Photon. Но уже тогда в качестве хранилища данных была выбрана Cassandra, что сделало архитектуру проекта довольно нестандартной.

Со временем многократно выросли нагрузки, количество игроков перевалило за 200 000 000, размер хранилища вырос до 80 ТБ (!) данных, серверов стало более 150, да и команда прокачалась и выросла. Ещё нам пришлось два раза переезжать всем хранилищем данных на новое железо, и об этом мы тоже поговорим.

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

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

Необходимость и боль перехода с IBM MQ + RHEL JBoss Fuse на Apache Kafka + Apache Camel

Александр Крылов

Росгосстрах

В мире enterprise имея лицензии и деньги можно строить дорого и хорошо, но иногда возникаем момент, когда не всё можно и нужно перекрывать ими. Сказ пойдёт о боли, которую мы получили на стеке для ESB IBM MQ + RHEL JBoss Fuse при необходимости масштабироваться, и как мы побеждали этих вестников плохого.

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

"Peer or not to peer" или ордеринг транзакций в публичных блокчейнах

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

Публичные блокчейны с точки зрения алгоритмов удобно рассматривать как распределенные системы master-master репликации, где цепочка блоков является аналогом Write Ahead Log, а публикация и финализация блоков является аналогом commit-ов для транзакций. Но одним из серьезных отличий от централизованных БД является то, транзакции совершенно свободно принимаются и процессятся откуда угодно, без всяких авторизаций, отильтровываются и ранжируются с использованием системы комиссий, связанной одновременно со сложностью исполнения транзакций и с размером оплаты. Процесс распространения транзкций по сети и доставки их до производителей блоков и их последущее ранжирование в блоках - это уже сам по себе крайне интересный механизм, но в последние пару лет появление многочисленных DeFi протоколов вызвало настоящие войны за ordering и скорости получения и доставки транзакций среди трейдеров, что привело к еще большему его усложнению и появлению вторичного рынка ordering-а транзакций с объемами в миллионы долларов ежедневно, в котором участвуют трейдеры, майнеры и производители блоков.

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

Распределенный высоконагруженный BI-движок для Google Data Studio и Microsoft Power BI — как сделать массовую облачную BI-аналитику доступной для человечества

В докладе мы расскажем, как проектировали, разрабатывали и запустили на сотни тысяч компаний облачную BI-аналитику для инструментов Google Data Studio и Microsoft Power BI. Поговорим об ошибках, подводных камнях, выборе column-ориентированных хранилищ от Druid и Pinot до ClickHouse и Amazon RedShift. Затронем инструменты BI-визуализации от Apache Superset до Amazon QuickSight и Яндекс DataLens. Не обойдем стороной вопрос гетерогенной репликации данных, CDC-репликации и приручения Kafka и Amazon Kinesis. Разберем основы создания простых и полезных, но, главное, быстрых облачных BI-отчетов для компаний-пользователей CRM Битрикс24. Обязательно поговорим о рынке BI-коннекторов, архитектуре нашего BI-коннектора, пользе и действительном предназначении облачных кластерных колоночных БД и их ближайших перспективах.

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

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

Кратко расскажем про конвейер обработки событий аппметрики:
⁃ Какие задачи он решает
⁃ Общая архитектура: примерно 50 микросервисов, передающие информацию через ClickHouse и ZooKeeper
⁃ Нагрузка в числах — 250 миллиардов событий в день, до 7 миллионов RPS в пике
⁃ Зачем нужен сервис дедупликации

Непосредственно про сервис дедупликации:
⁃ Как была устроена прошлая версия сервиса: физические сервера с состоянием в оперативной памяти, сохраняемым на диск и самодельной репликацией
- Подходы к реализации новой версии, которые рассматривали
⁃ Почему выбрали именно YDB для реализации новой версии сервиса
⁃ С какими трудностями столкнулись и как их преодолели: большой поток событий, необходимость транзакционной обработки событий, удаление старых данных из базы
⁃ Как уменьшили нагрузку на YDB в 10 раз, добавив фильтр блума в виде отдельной таблицы YDB
⁃ Что еще предстоит сделать

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

Архитектура рисуется с обратной стороны!

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

Это подход не инженерный, а крафтовый или если хотите ремесленно-художественный.

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

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

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

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

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

И все это на реальном опыте компании ДомКлик, проблемах и решениях, которые применялись в практике быстрорастущего проекта.

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

Пайплайн для расшифровки речи в миллионах видео в сутки: инфраструктура автоматической генерации субтитров в VK Видео

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

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

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

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

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

Командная разработка сервисов на основе Apache NiFi

При командной разработке любых сервисов мы все привыкли хранить код в Git либо других распределенных системах контроля версий и иметь все преимущества для параллельной неблокирующей разработки. Но как хранить и ревьювить код, ветвиться и свободно переключаться по веткам, если мы проектируем сервис на основе фреймворка Apache NiFi, дающего крутые возможности построения универсальных ETL-систем, но не имеющего удобного текстового представления для разрабатываемого сервиса? А если разработчиков несколько и они все не должны мешать друг другу?

В докладе мы расскажем, как используем Apache NiFi, как разрабатываем на нём и храним код в Git, при этом обеспечивая параллельную разработку большим командам, а также реализуем все плюшки CI/CD для наших сервисов на основе NiFi.

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

Сверхскорость. Единая платформа экспресс-доставки Яндекса

Сергей Хорошеньких

Яндекс Доставка

Мы расскажем, как устроена единая платформа для экспресс-доставки в Яндексе.
Слово “экспресс” означает, что заказ нужно доставить вскоре после его создания (естественные примеры — заказы в Яндекс Лавке или Яндекс Еде).
Более подробно задача формулируется так: в системе регулярно появляются заказы, которые нужно в реальном времени назначить на курьеров, причём один курьер может везти сразу несколько заказов.

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

Без AB-результат XЗ или как мы построили платформу AB-тестов в Ozon

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

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

Продукт-оунер сжато расскажет про:
2 обязательных требования, без которых нельзя построить конкурентную платформу AB-тестов.
3 разрушительных ошибки, которые нельзя допускать при разработке крутой AB-платформы.
И
Как построить централизованный процесс AB-тестирования в большой компании.

Руководитель отдела разработки платформы AB-тестов расскажет про:
- Эволюцию AB-тестов в компании Ozon, как мы шли от простого к сложному длиной в несколько лет.
- Как построена архитектура платформы AB-тестов в экосистеме Ozon.
- Как мы обеспечили быструю интеграцию всех сервисов компании (для интеграции нужно не больше 2-х минут, мы засекали) при том, что каждый сервис работает с уникальным явным набором тестируемых атрибутов.
- И даже раскроет секрет выдерживания большого RPS (каждый запрос на сайт Ozon идет в платформу AB-тестов) и молниеносного ответа.

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

Одна платформа, чтобы править всеми

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

В своем докладе я расскажу про нашу платформы:
⁃ что это такое и зачем она нужна?
⁃ конвенции и стандарты
⁃ на чем мы пишем сервисы: языки и фреймворки
⁃ как мы их запускаем: CI/CD и прочие прелести
⁃ как сервисы находят и общаются друг с другом: service discovery, балансировка и gRPC
⁃ как следим за тем, что все работает: мониторинг, логи, трейсинг
⁃ все-as-a-service: S3, kafka, cache и т.д.

И многое, многое другое.

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

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

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

В проекте Modin (распределенный pandas) мы поддерживаем ряд программных технологий распределения вычислений в бэкэндах. Появилась проблема поддержки фронтенд функциональности сразу на всех бэкэндах и необходимость добавления поддержки MPI технологии.
Мы разработали универсальный python API для работы с фрэймворками Ray, Dask, MPI и стандартным Python multiprocessing, который вылился в отдельный проект Unidist.
В докладе познакомимся с распределенной структурой данных Modin DataFrame и принципах её параллельной обработки. Выясним, как ряд фрэймворков для распараллеливания вычислений унифицирован в библиотеке Unidist. Рассмотрим реализацию task-based подхода на технологии MPI.

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

Оптимизация параметров запуска Spark jobs (ака Автоматический тюнинг параметров Spark)

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

Мы используем Apache Spark на YARN: каждый день запускаем несколько тысяч расчетов по расписанию — больше сотни в день тяжёлых и 4000 полегче. Тяжёлые расчеты могут длиться несколько часов.

К концу 2020 потребляемые ресурсы увеличились втрое: все больше контейнеров висит в пендинге, перекосы в кластере. Что делать, чтобы модели не сжирали кластер и могли существовать друг с другом, когда их тысячи? Разработать и внедрили систему (ML-Batch), которая позволяет каждой модели выдавать оптимальные ресурсы и контролировать их без человека.

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

Как построить CI/CD для задач машинного обучения. Tips & Tricks

В докладе я расскажу, как можно построить CI/CD для задач машинного обучения на примере переноса пайплайна обучения в облако AWS.
Поделюсь, как выбрать подходящие типы инстансов, настроить взаимодействие с AWS через Terraform, как создать свой кастомный образ и как настроить взаимодействие с GitHub.
Дам советы и расскажу о трудностях, с которыми столкнулись в процессе (и которые удалось преодолеть).

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

Как мы подружили биореакторы и ML

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

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

Несмотря на большое количество вендоров, которые предлагают свои продукты на разных стадиях автоматизации производственного процесса, мы выбрали open-source решения. Будут затронуты вопросы взаимодействия с программно-техническими средствами АСУТП, MLOps архитектура, а также рассмотрен конкретный пример применения методов машинного обучения для создания виртуального датчика процесса культивирования в биореакторе.

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

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

Fast Data QA: как быстро развернуть на новом проекте процесс качества данных

Узнать что такое Data Quality и как это считается
Зачем оно вообще вам нужно и какие инструменты есть
Посмотреть на типовой случай имплементации в AWS

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

Кто такой MlOps инженер

Я хочу определить ответственность роли MlOps инженера.

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

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

Выкатили в highload production сервис рекомендаций с Bert-like моделью. Что было дальше?

Марк Паненко

Работа.ру

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

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

«ML свадьба» между миллионами товаров, и как выдержать нагрузку в потоке

В докладе мы расскажем о том, как нам удалось построить крутой real-time алгоритм матчинга для товаров на огромной e-commerce площадке. Задача была не из простых и заслуживает целый доклад.

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

Нам удалось сохранить высокие нагрузки отказавшись от batch-подхода при онбординге большого количества новых товаров, которые у нас представлены в виде длинных векторов. Речь пойдет об используемых технологиях, а также ML/DL подходах, которые мы используем при сопоставлении и ранжировании товаров.

Основные пункты доклада:

1. Про нашу задачу и цель
2. Стэк и технологии
3. Метрики и мониторинг на всех уровнях
4. Про ML и используемые SOTA подходы
5. Как мы боремся с деградацией наших моделей
6. Нагрузки и поток данных, с которым нам приходится работать

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

Как работать с дубликатами пользователей

Дубликаты пользователей как граф, где хранить графы, примеры распределенных систем хранения графов, Nebula Graph, машинное обучение на графах

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

AutoML, или как ускорить работу над моделями в несколько раз

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

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

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

Подготовка данных поиска яндекса, какую библиотеку и процессы для этого мы сделали.

Это рассказ от команды подготовки данных Поиска Яндекса, про то как мы построили процессинг обрабатывающий потоки в 5GB/s, как именно мы к нему пришли. Почему мы остановились на гибриде между лямбда и каппа архитектурами, почему наши аналитики в запросах в поле FROM вместо таблицы указывают библиотеку. И как это помогает учитывать изменения бизнес-логики без изменения кода у потребителей наших данных.

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

Построение Data Catalog как Unboxing Big Data проектов

Проблема прозрачности процессов работы с данными особенно актуальны для BigData.

Проблемы legacy-проектов в Big Data - это общие проблемы для больших проектов с долгой историей, такие как отсутствие актуальной документации, сложность системы в целом и так далее.

Однако для Big Data это дополнительно все осложняется еще следующим:

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

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

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

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

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

Предугадывая High Load

Observability платформа - это теневая сторона любого высоконагруженного решения со своей экосистемой, жизненным циклом, источниками данных и пользователями. Так почему бы не применить техники продвинутой аналитики, например ML, к observability платформе также как мы уже давно применяем к бизнес приложениям? Этот доклад подсветит трэнды в анализе мониторинг данных и примеры того как high load система от этого выигрывает.

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

Online feature store in Db-in-memory

Антон Шишкин

ООО СКБ ЛАБ

1. Задачи, решаемые при реализации Online Feature Store.
2. Варианты решений.
3. Возможные компромиссы.
4. Опыт использования Db-in-memory для Online Feature Store.

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

Мы точно знаем, как ты провел лето.. и зиму, и весну, и осень

Основные тезисы:

0) Очень кратко про стриминг, где он, что и как
1) Старт проекта и поиск первых заказчиков. Custdev и все что с этим связано
2) Почему именно стриминг данных решает нашу задачу и как мы к нему пришли (формирование проблемы, с которой мы встретились) (нужен был онлайн движок со скоростью отклика не больше 6 сек)
3) Сбор команды, влияние HR бренда и тотальные проблемы поиска highload специалистов.
4) Специфика environment банка, использование opensource техстека и какие проблемы мы решали на пути к реализации
5) Модели, которые используются в нашем контуре
6) MVP, первые результаты и чем собственная разработка лучше IT консалтинга.
7) "Аппетит приходит во время еды" или какие еще заказчики начали активно появляться после первых успехов
8) Планы дальнейшей экспансии стриминга, как продукта (расскажу про AI советник, антифрод с планируемым SLA <100 мс)

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

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

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

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

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

За три месяца, силами небольшой команды, удалось автоматизировать порядка 10% чатов, имея несколько сотен тысяч чатов в месяц, неразмеченные датасеты с миллионами строк и 5 языков поддержки. Также в результате мы получили обоснованное понимание по дальнейшим направлениям автоматизации. Помимо метрики процента закрытия чатов ботом, мы также ориентируемся на метрики: точность распознавания темы чатов, закрывающая способность реплики бота, SAT рейт и др. В докладе будут подробно описаны этапы разработки решения, проработки сценариев, определения направлений для автоматизации, решения вопросов производительности, построения аналитики, мониторинга и др

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

Свой распределённый S3 на базе MinIO - практический опыт наступания на грабли

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

АО "Базис-Центр+"

Любому проекту - нагруженному или нет - требуется где-то хранить свои данные. И, если это не тестовая среда, хранилище должно быть надёжным, отказоустойчивым и достаточно быстрым для решения задач, перед ним стоящих. При планировании такого проекта на ум любого архитектора (включая меня) сразу приходят S3-совместимые хранилища вроде Amazon AWS, Google Cloud Storage, Yandex Object Storage и т.п. Они удобны, распределены по нескольким, географически удалённым друг от друга, дата-центрам и не требуют никакого обслуживания. Однако при действительно больших объёмах данных даже приблизительно ожидаемые цифры, выдаваемые калькулятором стоимости, способны повергнуть в шок любого финансового директора. И тогда ключевой фразой для гугления становится "своё s3 совместимое хранилище". Пару лет назад настала моя очередь вбивать её в поисковик. Я пересмотрел несколько коммерческих и open source решений, пообщался с их разработчиками, несколько проестировал и одно внедрил. В основной части доклада я хочу поделиться своим опытом внедрения, предостеречь от совершённых ошибок, возможно разрушить некоторые надежды. А в выводах резюмировать - стоит ли игра свеч, пошёл бы я снова по этому пути и сколько на самом деле стояn бесплатные решения. И главное - с конкретным цифровым выражением материальных, моральных и физических затрат.

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

RePlay - библиотека построения рекомендательных систем

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

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

Как заработать 500 иксов, не ходя в казино, или зачем мы анализируем 2 ТБ блокчейн данных каждый день.

Тезисы - кратко:

1. Проблематика. Зачем что-то вообще анализировать? Блокчейн - открытый источник вкусных данных для принятия взвешенных решений.
2. Как мы обрабатываем терабайты данных из EVM-совместимых блокчейнов в режиме реального времени. Сигнатурно-предиктвный подход к анализу.
3. Поиск инсайтов в море шума для принятия взвешенных решений на основе данных.

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

Геолокация по WiFi/GSM в больших городах на базе ML для 30-ти миллионов пользователей

Геолокация при помощи триангуляции по сотовым вышкам в прошлом! Крупные города содержат миллионы WiFi точек. Современные статистические методы позволяют рассчитывать честные двумерные карты сил сигналов, а современные инженерные приёмы — строить сотни миллионов таких карт и использовать для позиционирования десятков тысяч пользователей в секунду. Наш подход позволил улучшить точность геолокации по WiFi/GSM более чем в 2 раза, там, где GPS не точен или не доступен.

В докладе расскажем как симбиоз data science и инженерных решений позволил построить экономную по аппаратным ресурсам систему силами небольшой команды для 30+ М пользователей c нагрузочной ёмкостью 10K+ RPS.

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