Доклады

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

В рамках выступления вы узнаете о предпосылках и целях внедрениях процессов безопасной разработки.
Мы посмотрим на эволюцию цифровых угроз, а также определимся с основными интересами стейкхолдеров в парадигме DevSecOps. Поговорим о методологии и инструментах построения безопасной разработки, а также о важности бесшовной оркестрации процесса. Развеем мифы построения AppSec в формате сервис и наконец разберемся, кто же важнее — Dev / Sec или Ops.

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

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

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

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

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

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

Расскажем:
* как запускать Spark driver в K8S в режиме --master yarn --deploy-mode client,
* как организовать персональные окружения для команд аналитиков/разработчиков,
* о контроле за использованием ресурсов и возможности их гарантировать,
* о том, как это все мониторится.

Поделимся, какие проблемы мы решили:
* проблемы сетевой связности при работе Spark Driver в K8S,
* доступность Spark UI,
* перенос пользовательских данных при переходе между командами.

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

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

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

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

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

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

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

А теперь, когда кликбейтный заголовок сработал, вот о чём будет доклад:
* Что такое Container Runtime, и какие они бывают.
* Что такое MicroVM, какое отношение к контейнерам они имеют и какие проблемы решают.
* Как мигрировать на MicroVM так, чтобы пользователи не заметили.
* Когда MicroVM подходят, а когда нет.
* Что там с производительностью и оверхедом MicroVM.

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

Рассмотрим, какая бывает мультитенантность, подходы к ее построению, чем отличаются и когда лучше использовать.
* Cluster-as-a-Service
* Namespace-as-a-Service
* Controlplane-as-a-Service

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

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

GPU — вещь капризная: видеокарты горят, вылетают из системы, отвечают с ошибками. Что делать с ними, когда ответ "переустанови драйвер" перестает работать? А если они просто исчезают? А если их еще при этом сотни?

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

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

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

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

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

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

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

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

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

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

Я расскажу про практики оптимизации производительности запросов в ClickHouse. Детально рассмотрим нашу CI/CD-инфраструктуру и как с ее помощью мы тестируем на регрессии, выявляем медленные запросы, находим места, которые стоит оптимизировать в первую очередь. Покажу, как мы тестируем производительность ClickHouse, используя различные компиляторы и версии библиотек. Расскажу про дизайн высокопроизводительных систем, про выбор библиотек и различные трюки, которые помогают ускорять производительность на ровном месте.

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

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

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

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

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

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

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

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

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

С ростом продукта и развитием data-driven-подхода мы хотим обеспечивать наших коллег простым и удобным способом автоматизировать трансформацию и батч-транзит данных между системами с целью изучать их и проводить продуктовую/бизнес-аналитику.

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

* Автоматизация расчетов для нового интересного отчета за 15 минут.
* Простой способ обеспечить Data quality.
* 20+ видов интеграций с информационными системами для отправки и получения данных.
* Прозрачный Data lineage.
* Возможность запустить любой код как часть графа задач.
* Удобный инструментарий для запуска задач и мониторинга.
* Около 2000 ежедневных задач на обработку нескольких петабайт данных в месяц, обновление 300 отчетов в Tableau для сотен пользователей, отправка информации во внешние аналитические системы и рекламные кабинеты.

Предметная область нашей работы предполагает изучение DDoS-атак, бот-активности и методов их реализации. В данном докладе я расскажу:
* о путях развития DDoS с важнейшими временными вехами как с точки зрения техники, так и в публичном восприятии проблемы: Panix, Sony, XboxLive/PSN, Mirai, memcached, а также значимые случаи в Рунете;
* о том, как параллельно с DDoS возникал и развивался инструментарий для парсинга веб-страниц и API, создавались боты для скрэпинга и росла их массовость;
* о технологиях и новшествах, которые улучшают нашу жизнь в Интернете и одновременно открывают новые пути для DDoS и бот-атак.
* об уроках, которые преподнесла история, и выводах, которые удалось сделать из 11-летнего опыта в данной сфере.

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

Как так получилось, что развлекательное видео смигрировало почти 13 лет назад с кодеков mpeg2 и mpeg4 на H264 и на этом остановилось фактическое развитие, несмотря на наличие альтернатив типа AV1 и H265?

При этом транспорты видео совершили миграцию с UDP к TCP, а сегодня переезжают обратно на UDP?

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

В докладе рассмотрим, как эволюционировали архитектуры нагруженных проектов: от общих принципов до подходов к реализации отдельных паттернов и выбора инструментов. Разберём, как это отражалось на архитектуре ВКонтакте, и посмотрим, как развивался проект с 15-летней историей, кодовой базой в восемь миллионов строк и ежемесячной аудиторией в 100 млн пользователей:
* эволюция архитектур;
* как устроена архитектура ВКонтакте;
* как мы эксплуатируем систему с более чем 20 000 серверов;
* где и как мы храним данные пользователей;
* как доставляем данные;
* зачем нам свой компилятор;
* баланс uptime и time-to-market;
* какие решения позволяют делать релизы vk.com раз в час в автоматическом режиме из мастера;
* как устроена система сборки и деплоя, которая позволяет собрать 8 млн строк кода и раскатить на 10  000 серверов за 7 минут.

Также затрону проблемы, которые можно более эффективно решать не на уровне архитектуры.

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

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

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

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

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

Обзорно поговорим про историю и современность технологий "просто" поиска (матчинга документов об слова), ранжирования наматченного, сжатия индексов, нехитрой прикладной лингвистики. Пробежимся по нескольким десяткам важных ключевых слов, и по топ-3 победивших на сегодня (и нет, это не Google плюс Elastic плюс хзчто, это IF плюс BM25 плюс PFD).

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

В сентябре 2019 г., на выходных, мы культурно выпивали всем Dodo Engineering на турбазе под Владимиром. В это время облачный провайдер обновил минорную версию MySQL.

История о последствиях и инженерных решениях, сдобренная анекдотами из жизни в облаке.

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

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

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

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

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

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

Иногда такое "не то" способно завести проект в тупик, а если и не весь проект, то карьеру инженера в этом конкретном проекте.

Как выглядит такое "не то", как его можно распознать, и как эти риски можно митигировать?

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

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

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

Компания ЦФТ поставила амбициозную цель: банковская система должна обладать свойствами DBI (Database Independent), то есть одинаково работать с любой СУБД. Банковская система ЦФТ-Банк существует более 20 лет, за это время более 2 000 разработчиков привнесли в проект более 15 000 000 строк кода. Несмотря на сжатые сроки, большая часть системы уже адаптирована для работы с Oracle и с PostgreSQL. В ходе обсуждения мы затронем некоторые препятствиях на нашем пути.

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

1. Нанимать или обучать.
2. Средний порог входа.
3. Общение — залог успеха.

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

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

Каждый день витрину Ситилинк смотрят 1,6 миллиона покупателей. Кэшировать товары на витрине нельзя — там цены! Поэтому мы выбрали, развернули и научились использовать Tarantool, чтобы обеспечить чтение и запись более 100 тысяч элементов в секунду с задержкой всего в 30 мс.

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

В докладе мы расскажем, как проектировали, разрабатывали и запустили на сотни тысяч компаний облачную 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-коннектора, пользе и действительном предназначении облачных кластерных колоночных БД и их ближайших перспективах.

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

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

Команда продуктовой разработки Яндекс Go прошла путь от "нескольких человек, пишущих в монолит" до "команды, в которой больше 50 человек, которая развивает микросервисную архитектуру продукта и запускает десятки параллельных продуктовых экспериментов". Этот путь сопровождался поиском и внедрением решений, ускоряющих разработку, позволяющих масштабироваться и увеличивающих надежность системы. Об этих решениях и будет доклад:
* когда и как мы перешли от монолита к микросервисам;
* как и когда мы используем api gateway (и его разновидность backends for frontends);
* как мы запускаем и отслеживаем результаты продуктовых экспериментов.

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

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

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

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

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

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

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

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

Обсудим опыт создания облачной платформы со своими СУБДaaS, LBaaS, мониторингом со встроенным анализом первопричин, ну и, конечно, то, как наш фреймворк для создания приложений интегрирован с облачной инфраструктурой (например, зачем менеджмент пользователей приложений — часть облачной инфраструктуры).

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

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

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

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

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

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

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

Мы расскажем, как устроена единая платформа для экспресс-доставки в Яндексе.

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

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

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

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

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

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

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

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

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

В своем докладе, я расскажу про техническую реализацию платформы А/B-тестов в компании Озон.

А именно:
* об эволюции A/B-тестов в компании. О том, как мы шли от простого к сложному длиной в несколько лет;
* как построена архитектура платформы A/B-тестов в общей экосистеме Ozon;
* как мы обеспечили интеграцию любого сервиса в компании: для подключения одного сервиса к нашей платформе нужно не больше 2 минут! Да-да, мы засекали. Интегрировано более 150 сервисов, причем каждый сервис работает с уникальным набором атрибутов для тестирования;
* и даже секрет молниеносного ответа при высоком RPS. Каждый запрос на сайт Ozon.ru идет в платформу A/B-тестов, а вы этого даже не замечаете.

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

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

Добавив высокие требования к качеству и безопасности данных, имеем отличное решение для работы с банковскими данными. 5000 RPS при 10 мс на ответ на 40 Тб данных и это не предел — это сделано в нашем банке и хочется поделиться этим опытом.

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

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

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

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

В нашем случае мы попали в ситуацию, когда мы имеем инструменты, попадающие не только под vendor lock и узкую компетенцию, но и санкции. Речь про так называемую шину данных или ESB, состоящую из брокера очередей на базе ESB IBM MQ и интеграционного слоя на базе Red Hat JBoss Fuse.

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

Собрав всю силу и необходимые компетенции, мы выбрали инструменты Apache Kafka в качестве брокера очередей и Apache Сamel в качестве интеграционного слоя для построения потоков данных.

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

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

Расскажу про:
* то, как мы пришли к тому, что у нас нет ни одной команды в компании, которая не работает в Jira, и почему все остались живы;
* расскажу про CRM-систему на базе Jira;
* покажу, как мы автоматизировали процессы подразделений бэк-офиса;
* расскажу про то, как построили “сервис”, позволяющий проводить быстрые изменения внутри любых команд и процессов;
* посчитаем, какой профит мы получаем из “бесшовной” связи команд разработки с остальными частями компании, работая в единой экосистеме инструментов.

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

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

Сегодня коммуникационными роботами на базе NLU уже никого не удивишь: есть и коробочные решения вроде DialogFlow от Google, и OpenSource-фреймворки вроде Rasa, да и каждый уважающий себя ML-инженер хоть раз да и файн-тюнил BERT'а на задачу текстовой классификации. Нам в Voximplant захотелось собрать лучший опыт и дать возможность использовать state-of-the-art-модели и подходы людям, далеким от машинного обучения — и все не покидая браузера в рамках облачной платформы. И, естественно, это оказалось не так-то и просто.

В рамках этого доклада Артем Бондарь, Head of AI компании, расскажет о тонкостях создания облачного AutoML-решения, какими трюками мы добивались низкой стоимости, сохранив возможность использовать тяжелые нейросети, кастомизированные под каждого клиента, как мы работали с разными языками и как мы подошли к задаче few-shot-learning, пряча от клиента под ковер всю игру с гиперпараметрами.

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

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

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

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

В конце ретроспективно взглянем на то, что у нас получилось сделать всего за 2 года.

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

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

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

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

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

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

Я расскажу про то, как дошли до формулирования принципов и правил платформы МБ, без которых дальнейшее развитие было бы невозможно. Отдельно я расскажу про две текущие задачи, которые приводят к очередному организационному редизайну и изменениям в архитектуре:
1) выделение сквозных кросс-функциональных команд, условно, МБ <-> API <-> backends;
2) улучшения архитектурных подходов в интеграции МБ и API.

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

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

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

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

В докладе планируется кратко ввести в курс истории интернационализации интернет-идентификаторов, рассказать о текущей работе экспертных сообществ (таких, как IETF, Unicode Consortium, W3C, ICANN и т.д.) и разработанных ими отраслевых стандартах, коротко напомнить о работе системы доменной адресации и почтового взаимодействия, а также раскрыть особенности и проблемы с внедрением поддержки IDN и EAI.

В основной части доклада будет дан обзор доступных готовых решений, таких как: почтовые сервисы Microsoft Live, Gmail; почтовые программные продукты от Apple, Microsoft, Communigate Pro, Xgen Plus и др.; программные библиотеки и фреймворки популярных языков программирования, а также будет рассказано о реальных кейсах реализации корректной работы с IDN- и EAI-технологиями в почтовых системах различного масштаба.

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

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

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

Face Pay — первый в России и в мире сервис по оплате проезда с помощью биометрии, запущенный в таком масштабе. Сервис доступен на всех 250 станциях метро, а с 16 марта 2022 года — на станции «Кутузовская» Московского центрального кольца.

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

AliExpress Russia is the largest online platform in Russia and CIS countries for selling consumer goods from Russia, China, Turkey, Italy, and many other countries. Every day more than 8.8 million users visit our website and App and choose the best among more than 2 billion goods. We have 600 developers in our team, and inside — the latest tools and the power of Chinese systems, several thousand of servers, modern microservice architecture, and advanced development processes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI maturity index — не еще один индекс в ИТ-отрасли, а международный опыт систематизации внедрения Data Science-подходов в бизнес-процессы.

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

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

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

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

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

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

Основная проблема с выкатыванием обновления на работающее приложение возникает тогда, когда меняется контракт между частями приложения — путь API, структура данных в REST-запросе, тело message в Kafka и т.п. И нам нужно обеспечить плавность перехода от предыдущего контракта к новому.

Service Mesh в данном контексте является "системным интегратором", который, помимо управления непосредственно REST-взаимодействием, также управляет другими средами — Messaging и DB. Особенностью решения является то, что управление версиями происходит за счёт фреймворка с минимальным участием со стороны прикладных микросервисов — они зачастую могут и не знать, что работают в мультиверсионной среде.

Первая часть: https://www.youtube.com/watch?v=XtvwZqdtfgI

Долгие годы крупнейшие Enterprise-компании строили свои решения на базе иностранных ИТ-вендоров — Oracle, SAP, IBM и так далее. С уходом этих вендоров все стали метаться в поисках импортозамещения. Сейчас к нам приходит достаточно много таких компаний за нашим опытом замены высоконагруженной шины данных. Глядя на подходы к “импортозамещению”, кажется, что такие попытки обречены на провал. С другой стороны, внутри всего Сбера мы смогли успешно заменить иностранную шину данных.

Поговорим о том, как не провалить импортозамещение — почему есть успешные и неуспешные кейсы. Обсудим, почему мы решили “импортозамещать" свою шину данных еще до того, как это "стало модным”, что выбрали в качестве альтернативы (spoiler: Service Mesh) и с чем мы столкнулись в процессе разработки и внедрения. Разберем, почему заявленные преимущества Service Mesh, такие как “горизонтальное масштабирование” и независимость команд разработки не работает “из коробки” и что с этим делать.

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

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

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

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

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

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

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