Доклады

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

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

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

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

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

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

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

Я расскажу про технические и архитектурные решения, которые принципиально отличают StatsHouse от существующих OpenSource-решений — в том числе его уникальную Бесконечную® Масштабируемость™. И еще — сделаю пока секретный анонс.

На докладе расскажу о технических сложностях, с которыми мы столкнулись при разработке своего хранилища.
Задачи, которые решали:
* эффективная утилизация больших HDD (меньше iops на терабайт хранилища);
* переезд на более cost-effective серверную платформу (сокращение количества занимаемых юнитов в ДЦ);
* обеспечение SLA 99.999% доступности данных в течение года;
* переживание отключения ДЦ (ряда/стойки/сервера) без ручного вмешательства;

Архитектура потребовала распила письма на несколько составляющих и 2 вида индексов, чтобы хранилище смогло утилизировать диски в 18 ТБ полностью. Индексы не помещаются в память, поэтому применяются разные приемы для ускорения их загрузки в кэш. Для обеспечения более линейной записи группы юзеров объединяются в шарды, внутри которых ведется один xlog на всех. Собственное BLOB-хранилище с кворумной записью.
И другие приемы.

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

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

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

Мы — команда, которая долгое время принимала участие в разработке и поддержке NGINX. Сейчас мы делаем свой fork.

В докладе мы расскажем про drop-in replacement NGINX, веб-сервер Angie, фичах, необходимость которых давно назрела, но по ряду причин они не были занесены в сервер, и покажем, что уже сделали.

Будет интересно :)

Выносим сервис расчёта цен для 20 тысяч магазинов из SAP, чтобы:
* снять с SAP нагрузку (100% загрузки серверов с 21 до 3 часов) — мешает другим процессам, требует постоянной поддержки из-за частого достижения потолка ресурсов, работает на пределе возможностей SAP;
* вывести из зоны риска остановки mission critical процесс.

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

В докладе на примере ВКонтакте — проекта с 16-летней историей, 100 млн пользователей в месяц и 8 млн строк кода бизнес-логики — рассмотрим принципы построения техстратегии и методы принятия стратегических решений.

А также разберём, как техстратегия и архитектура влияют друг на друга и что у нас получается в результате:
* как строить техстратегию на несколько лет вперед;
* портерианский и ресурсный подходы к стратегированию;
* требования, которые мы предъявляем к архитектуре, и их связь с time2market;
* как обеспечиваем отказоустойчивость и балансируем нагрузку;
* как эксплуатируем систему с более чем 20 000 серверов;
* какие решения позволяют делать 3,5 тысячи деплоев в год с winrate 97,7%;
* как устроена система сборки, которая позволяет собрать 8 млн строк кода и раскатить на 10 000 серверов за 7 минут;
* и как, собственно, сейчас выглядят техстратегия и архитектура ВКонтакте.

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

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

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

За 2 месяца внедрили пилот на базе открытого KeyCloak и начали постепенно масштабировать его на всю страну. При 300000 сессиях получили даунтайм при обновлениях: пользователи не могли войти в систему около 15 минут. Мы снизили время простоя настройками кэширования и модификацией схемы базы данных до 3 минут, но дальше нас ждал первый миллион сессий…

Сейчас биллинг Yandex Cloud обрабатывает около 4,2 миллиарда метрик от сервисов в сутки, а задержка с момента, когда что-то случилось, до того, как это отразится в детализации, составляет единицы минут.

Расскажу, как мы проектировали биллинг, какие вопросы задавали сами себе, какие архитектурные решения выдержали проверку временем, а какие нет. В частности, рассмотрим:
* как строить объектную модель;
* масштабируемость: что будет, если пользователей, продуктов или данных станет больше в 100 раз (спойлер: так и вышло);
* механизмы доставки данных о потреблении: push, pull, message queue;
* OLTP для потоковой обработки и OLAP для тяжёлой аналитики.

Lakehouse — это современная архитектура построения аналитических платформ компаний, которая совмещает лучшие качества data warehouse и data lake. Одним из популярных продуктов для построения lakehouse-систем является Presto — массивно-параллельный распределенный SQL-движок для выполнения федеративных запросов.

В данном докладе мы обсудим основные сценарии использования и построения lakehouse-архитектур, после чего посмотрим, как техническая реализация Presto помогает создавать масштабируемые корпоративные аналитические платформы:
* дезагрегация storage и compute, которая позволяет масштабировать вычислительные ресурсы без перемещения данных;
* коннекторы к большому количеству целевых систем с возможностью гибких pushdown-вычислений;
* продвинутая работа с сырыми данными с использованием современных технологий Apache Iceberg и Delta Lake;
* кэширование сырых данных на воркерах для уменьшения latency и стоимости работы с object storages;
* высокопроизводительный массивно-параллельный компилируемый SQL-движок.

В докладе будет рассказано об архитектуре сервиса, который позволяет отправлять пуш-уведомления на мобильные устройства с минимальной задержкой, подобно Google Firebase. Расскажем, как сделали сервис надежным (горизонтально масштабируемым на базе Redis Cluster и Scylla, устойчивым к DDoS через публичные API), как можно держать в фоне открытый Web Socket на Android, пользуясь доступными возможностями ОС. Покажем, как пользоваться нашими публичными API и SDK, поделимся опытом интеграции в "Почту Mail.Ru" на Android и бэкенде.

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

В этом докладе я расскажу, как устроен YDB Topic Service, чем похож и чем отличается от других популярных продуктов, в частности Apache Kafka®. Также я расскажу про реальное применение этой технологии в инфраструктуре и сервисах Яндекса, на инсталляции масштаба тысячи хостов и десятков ГБ/с на запись.

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

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

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

Никогда такого не было, и вот опять! Спустя 15 лет после появления S3 пользователям всё ещё нужны кластерные ФС под сценарии использования, близкие к тому, на что обычно рассчитано S3. А именно: большую/бесконечную ёмкость, низкую стоимость хранения, крупноблочный доступ, масштабируемость.

А можно ли сделать из S3 ФС? Обычный ответ: можно, но будет очень медленно. Казалось бы, файл — это «именованная последовательность байтов» и объект в S3 — тоже. Однако ФС плохо работает как S3, а S3 обычно плохо работает как ФС. Но почему?

Наш ответ в том, что если половина этой проблемы — действительно архитектурные вопросы различий между ФС и S3 (о которых мы, кстати, тоже поговорим, например, рассмотрим вопрос «а что, вообще, такое POSIX-совместимость ФС?»), то оставшаяся половина — исключительно вопросы реализации, которые оказалось не так уж сложно решить.

И решены они в GeeseFS https://github.com/yandex-cloud/geesefs. GeeseFS — это ещё одна утилита для монтирования S3 через FUSE в виде локальной ФС, но, в отличие от всех остальных реализаций, достаточно POSIX-совместимая и достаточно быстрая, чтобы её можно было использовать без слёз. 🙂

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

Что реализовано в части нашей S3-ФС уже сейчас, что запланировано на будущее, а также как другие решают ту же задачу (скрещивания ужа и ежа) — обо всём этом мы и поговорим в докладе.

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

Сотни хранимых процедур с кучей бизнес-логики, десятки терабайт данных, высокая связность с другими системами — разве могут быть варианты, кроме Oracle?

Да, конечно! Этот доклад — о проекте миграции систем промышленных масштабов с Oracle на отечественную СУБД PostgresPro.

Замена СУБД — непростая задача: нужно заменить фундамент, но так, чтобы не рухнули стены. В докладе расскажу о том, как мы переносили бизнес-логику из Oracle PL/SQL на PLPG/SQL на примере системы, которой пользуются граждане нашей страны.

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

Чтобы все это эффективно работало, необходимо балансировать read- и write-нагрузку между серверами и дисками. Для этого нужно учитывать множество факторов: ломающееся железо (от отдельных дисков до ДЦ целиком), разную "горячесть" данных разных сервисов (от cold до hot), сторонние источники нагрузки в лице фоновых процессов, гетерогенность железа (от 1-гигабитных старых серверов до 50-гигабитных новых) и т.д.

В докладе расскажу, как устроена балансировка read- и write-нагрузки в системе хранения; какие подходы работают, а какие нет; какие трудности могут возникать в процессе эксплуатации и какие особенности есть в multitenancy-хранилищах.

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

Мы хотим рассказать про свой опыт в решении проблем и попробуем ответить на вопросы:
* почему index scan / index only scan могут тормозить при адекватном плане запроса?
* что за странные ожидания LWLock'а SubtransControlLock или ClientRead видны в pg_stat_activity?
* высокая system-time-утилизация CPU в системе процессами PostgreSQL. Кто виноват?

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

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

Проблемы эксплуатации MySQL в облаках.

* Что нужно автоматизировать в управляемой базе данных?
* Обзор существующих решений и их фатальные недостатки.
* Архитектура и возможности новой HA-утилиты mysync.
* Плюсы и минусы синхронной репликации.
* Как пользователи пытаются выстрелить себе (и нам) в ногу и что с этим делать?
* Направления развития проекта.

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

В своем докладе я расскажу про наш переход из batch в streaming. Предпосылками для перехода были следующие факты:
* Быстрый учет изменений и событий продуктово важен. В том числе виден на экспериментах в ключевых метриках (отдельные ускорения могут давать до нескольких процентов денег/конверсий).
* Дальнейшее ускорение требовало экспоненциального роста потребляемого CPU (десятки тысяч ядер), либо упиралось в ограничения MapReduce-модели.
* Сложность поддержки большого количества железных машин (~1000 хостов) и самописных систем синхронизации
Сегодня наша контент-система обрабатывает миллионы событий и изменений в секунду, а суммарный размер стейтов со всеми репликами занимает несколько петабайт.

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

Скала^р — это производитель ПАК-ов, которые мы называем Машинами

Одна из наших Машин — МБД.П — это как Oracle Exadata, только про PostgreSQL.
Мы расскажем, как устроена наша Скала МБД.П, как мы пришли к такой конфигурации, каких показателей производительности и надежности удалось добиться.

А ещё Скалой надо управлять не только инженерам высочайшей квалификации, но и пользователям, и мы придумали систему управления для нее — Спектр (не спрашивайте, почему так;-)
Сначала мы хотели делать его как <s>Oracle Enterprise Manager только без глюков и с комьюнити-версией</s>, но потом поняли что архитектура решения не всегда получается с первого раза и без ошибок.

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

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

Мы расскажем, как уже давно пытаемся в Yandex Cloud начать горизонтально масштабировать PostgreSQL.
Stateless Postgres Query Router — новая система для горизонтального масштабирования PostgreSQL через шардирование — роутинг запросов по диапазонам. Система работает по протоколу Postgres, предполагает управление перемещением данных между шардами. Поддерживает работу как в сессионном, так и в транзакционном режиме пуллинга запросов.

Cassandra является основным хранилищем (мета)данных в Одноклассниках. У нас развёрнуты сотни высоконагруженных кластеров из сотен узлов и тысяч клиентов, распределённых по нескольким дата-центрам. Мы используем и активно развиваем собственный форк Cassandra 2.x. Помимо фиксов множества багов и многочисленных оптимизаций, мы реализовали глобальные индексы (которые работают), поддержали партиционированные транзакции (NewSQL), полностью автоматизировали эксплуатацию в production и многое другое. Но в этом докладе мы сконцентрируемся на подходе FatClient, который используется в наших системах повсеместно.

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

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

Мы создали агент и назвали его rdsync по аналогии со своими другими решениями (pgsync — для PostgreSQL, mysync — для MySQL). Пропатчили Redis, чтобы можно было делать failover/switchover безопасно. Обложили это всё множеством функциональных и jepsen-тестов. Сделали отдельный демон, который может повторять протокол sentinel с точки зрения взаимодействия с клиентами (https://redis.io/docs/reference/sentinel-clients/).

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

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

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

Итак, на практике мы ожидали от Raft следующего.

Во-первых, кластер должен оставаться доступным и на запись и на чтение при частичной потере связности в сети. Канонический Raft не даёт таких гарантий, и это привело к инциденту в Cloudflare в 2020, когда одна из реплик не видела лидера и на протяжении 6,5 часов постоянно устраивала новые выборы, не давая лидеру поработать хоть сколько-нибудь.

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

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

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

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

В этом докладе я на примере In-Memory-СУБД Tarantool в памяти расскажу, как устроены снимки данных и MVCC, как и почему эволюционировали эти алгоритмы, во что обходится поддержание этих структур пользователю, как правильно использовать и что ожидать от этих механизмов.

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

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

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

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

Клиент-серверное взаимодействие высоконагруженных приложений и распределенных баз данных имеет ряд особенностей. Так, необходимо оперативно выяснять и отслеживать изменения топологии кластера базы данных, балансировать запросы по узлам (нодам) этого кластера, корректно обрабатывать возникающие ошибки.
Драйвер распределенной базы данных существенно отличается от драйверов традиционных (нераспределенных) баз данных. Главная отличительная особенность распределенных баз данных - необходимость работать со множеством нод СУБД. Для равномерной нагрузки на ноды БД в YDB используется как клиентская, так и серверная балансировка. Для баз данных, работающих в режиме 24/7 и допускающих различные сценарии отказа, драйвер должен быть готов к ошибкам разного рода. Это влияет на то, каков должен быть драйвер распределенной базы данных. В докладе мы расскажем про наш опыт разработки драйверов для распределеной БД на разных языках, про проблемы, с которыми сталкивались и решали или митигировали, а также про вынесенные уроки и принятые решения.

Многие системы, стараясь описать свое поведение в ненадежной сети, прибегают к терминам CAP-теоремы и описывают себя либо как AP, либо как CP.

Алгоритм Raft является классическим примером CP — обеспечивает линеаризуемость в случае разделения сети, но это в определенных случаях приводит к временной потере доступности и на запись, и на чтение до восстановления связности.

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

Отсюда возникает необходимость переключения между надёжностью и доступностью: если пользователь видит, что один из двух ЦОД-ов неработоспособен, он может решить продолжить обслуживать запросы в живом ЦОД-е без участия второго ЦОД-а, то есть превратить CP-систему в AP. Мы дали пользователю такую возможность в реализации Raft в Tarantool и столкнулись с условиями потери консистентности данных, с которыми бы никогда не встретился канонический Raft.

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

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

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

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

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

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

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

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

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

Решились! Нашли время, ресурсы и провели исследование одноглазого монстрика в диких условиях кровавого энтерпрайза. Что из этого вышло — опыт, лайфхаки и выводы о целесообразности использования Сциллы — в моём докладе.

Спойлер: зверушка у нас прижилась :)

В последние годы алгоритмы распределённых транзакций значительно эволюционировали — Spanner, Calvin, Ceasar, Tempo. В докладе я расскажу про ограничения, которые пытаются преодолеть авторы протоколов, и остановлюсь на протоколе Accord, который недавно был предложен в экосистеме Cassandra. Протокол работает без выделенного лидера и позволяет избежать большого числа конфликтов при обновлении "горячих" данных, что делает его пригодным для наиболее высоконагруженных сценариев.

"GraphQL очень простая технология: бери и делай, что там сложного?", — такую фразу я слышал от большинства senior-разработчиков, с которыми обсуждали GraphQL. С точки зрения самой технологии это действительно так (ну да, бери и делай:), однако наш многолетний опыт работы показал, что с точки зрения управления командой это не совсем так.

"А стал бы ты использовать GraphQL ещё раз в новом проекте?", — это второй по популярности вопрос, на который раньше у меня не было четкого ответа. "И да и нет", — отвечал я... Но всё-таки: да или нет?

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

3 года назад перед нами встала задача перехода на микросервисную платформу.
Мы мигрировали сервис за сервисом, ускорялся ТТМ. Но нагрузка на legacy не падала.
 
Расскажу, как не оказаться в ситуации, когда 60% проекта завершено, а нагрузка на legacy продолжает расти, какие метрики для проекта выбрать на старте и с какими сложностями мы столкнулись в проекте.

1. Сколько стоит входной билет в создание собственной сборки.
2. Какие потребовались перфоманс-доработки, когда у тебя несколько тысяч серверов под Hadoop.
3. Тележка сложностей, с которыми столкнулись по дороге к проду.

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

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

VML — это инструмент для простой и прозрачной работы с виртуальными машинами qemu. VML может инициализировать образы с помощью cloud-init. Виртуальные машины с ALT, Arch Linux, Centos, Debian, Fedora, openSUSE и Ubuntu можно создать всего одной командой.

Изначально VML разрабатывался для тестирования облачных образов, но потом оказался полезен и при решении других задач. Одна из основных фич — древовидность. Практически все команды можно запустить сразу на группу виртуалок. Запустить новую виртуальную машину почти так же просто, как сказать "Я люблю Linux" — нужно всего 3 слова...

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

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

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

* API management — что это такое и с чем его едят.
* Зачем это, вообще, надо.
* Публичные API.
* Обзор решений для API management.
* Наш опыт с Gravitee GW — чего оно умеет, и какие проблемы помогло решить.

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

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

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

В СДЭК вместе с Кроликом мы прошли тернистый путь от 1 ноды до крупного кластера. Мы поделимся нашим опытом использования инструмента и расскажем:
* как мы живем с хайлоад-кластером из 8 нод;
* почему мы отказались от HA-cluster;
* почему мы не используем Kafka?
* какие опасности вас могут ждать, если вы хотите делать распределенный кластер между ЦОД-ами;
* отказоустойчивость или скорость — а можно все вместе?
* почему в Exchange мы отказываемся от Topic и уходим на Fanout?
* история наших факапов, и как PHP сжег кролика;
* что нового появилось в RabbitMQ за последний год.

Цель инфраструктурной команды — улучшить надежность и отказоустойчивость, уменьшить time to market, снизить когнитивную нагрузку. Для этого многие компании реализуют свою домашнюю платформу (PaaS).

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

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

Поделимся тем, как мы используем графы в задачах мониторинга и observability и как Root Cause Analysis в мониторинге помогает командам эксплуатации.

Как и многие другие вендоры ПО, 1С давно предлагает свои продукты в облачном варианте. Это, в первую очередь, наши облачные сервисы 1С:ГРМ (Готовое Рабочее Место) и 1cFresh. Предоставление облачных сервисов требует наличия соответствующей инфраструктуры — прежде всего серверов, на которых размещаются виртуальные машины с приложениями, и софта, управляющего физическими и виртуальными машинами.

Представим, что команда DevOps делает не только всё, что связанно с CI/CD, но и сильно выходит за эти рамки.

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

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

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

Как мы собрали сервис онлайн-тестирования за 2 месяца и провели "Экологический диктант" для 72 стран мира.

В 2021 году состоялся публичный OpenSource-релиз платформы для автоматизации обслуживания Kubernetes-кластеров — Deckhouse. До этого платформа более трех лет развивалась исключительно как внутренний DevOps-инструмент «Фланта». Deckhouse аккумулировала технологический опыт и лучшие практики, полученные нами в многочисленных и разнообразных highload-проектах. Сейчас Deckhouse — это платформа Enterprise-уровня, которая сертифицирована в CNCF и входит в единый реестр российского ПО.

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

Какие вопросы рассмотрим в ходе доклада:
* процессы разработки, тестирования и управления релизами Deckhouse;
* интеграция со сторонними решениями для мониторинга, работы сети, безопасности и с другими необходимыми компонентами;
* как мы приносим исправления и доработки в код сторонних решений вроде Cilium и KubeVirt;
* наш ​​вклад в развитие «ванильного» Kubernetes;
* как организована техническая поддержка;
* как мы сопровождаем пользователей — команды клиентов и внутренние DevOps-команды «Фланта»;
* планы по развитию платформы.

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

В Tarantool за поддержку языка Lua отвечает LuaJIT, который включает в себя как среду исполнения языка, так и трассирующий JIT-компилятор. Мы решили использовать фаззинг-тестирование для LuaJIT, потому что стандартное тестирование не позволяет выявить все проблемы во время разработки. Несмотря на популярность рандомизированного тестирования и множество доступных инструментов для фаззинга, нам пришлось изучить методы, показавшие эффективность при тестировании других компиляторов, и разработать собственные инструменты. Мы попробовали фаззинг без грамматики, фаззинг с грамматикой на основе LibFuzzer и LibProtobufMutator, собственный мутатор для Lua-программ и проверку оптимизаций с помощью SMT-решателя.

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

Почему, если кто-то участвует в “созвоне” из автомобиля, то его плохо слышно? В чем особенность использования динамиков вместо наушников, когда вы находитесь на звонке? Что происходит со звуком участника звонка, если у него плохой интернет? Можно ли измерить качество звука в цифрах?

На эти и другие вопросы я постараюсь ответить в своем докладе на примере нашего сервиса.

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

Мы делаем СМЭВ. СМЭВ — это платформа, которая обеспечивает надежную передачу различных данных между примерно ~5к систем участников обмена по ~2к прикладных протоколов с интенсивностью 10к обменов в секунду. СМЭВ — это единственный способ взаимодействия систем государства для целей госуслуг и госфункций.

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

Дадим описание других систем экосистемы СМЭВ. Личный кабинет участника СМЭВ — все околосмэвовское можно делать в нем. Боты телеграм. ЕСНСИ — облачная платформа для распространения условно постоянной информации. Клиентское ПО — Адаптеры СМЭВ, Витрина данных.

Расскажем про то, какие мы в СМЭВ все открытые и готовые помочь, подсказать. Про нашу базу знаний info.gosulugi.ru, про телеграм-канал. Про то, как призвать нас на помощь, если что-то непонятно.

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

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

Также поговорим о:
* проблемах и потребностях, которые возникают на пути развития архитектуры по управлению клиентскими данными, и способах их решения;
* почему искать клиента в системах банка по ФИО-ДУЛ-ДР — неправильно, и как с этим бороться;
* какие паттерны обмена клиентскими данными между АС используют в Сбере и почему не всегда работает классический pub-sub;
* как побороть ошибки «исторического наследия» в управлении клиентскими данными за счет внедрения архитектурных стандартов.

* Рассмотрим подходы к выстраиванию безопасности K8s с использованием OpenSource в высоконагруженных кластерах.
* Поговорим про обеспечение безопасности K8s в облачных средах.
* Расскажу, как безопасно развернуть платежную инфраструктуру в кластере.
* Коснемся вопросов 0-trust внутри K8s.
* Погрузимся в IaaC и GitOps с точки зрения обеспечения безопасности K8s.
* Оценим 0-touch prod с позитивных и негативных сторон.
* Разберем применение OpenSource Runtime Security.

Как упростить жизнь программистам, DevOps и security-инженерам, не зная об этом?
А находить уязвимости в системе, ничего не зная о безопасности?
В конце концов, как уничтожить звезду смерти Netflix?

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

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

Поговорим об immutable infrastructure, специализированных Container-Optimized OS, минималистичных образах для микросервисов и многом другом!

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

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

В докладе рассмотрим набор техник, про которые редко говорят на конференциях. Мы не будем заострять внимание на SAST, DAST, DevSecOps, а обсудим другие вопросы: security-амбассадоров, бюджет ошибок безопасности, построение адекватного процесса взаимодействия ИТ и ИБ, постоянную оценку рисков.

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

За последние несколько лет с рынка исчезло некоторое количество компаний (ну, или они перестали быть активными). Например, SolarWinds — разработчик ПО для IT-подразделений. В ряде случае причиной исчезновения стало не что иное, как компьютерный инцидент. При этом мало кто понимает причины возникновения таких инцидентов, какова в них роль программистов и могли ли именно они в данном случае спаси свои компании.

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

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

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

В докладе будут рассмотрены следующие темы:
* Reverse-shell, или Как заставить сервер подключиться к вашему ПК и предоставить вам оболочку.
* Docker Escape на практике: опасность привилегированных контейнеров и практическая демонстрация побега при помощи добавления самописного модуля в ядро.
* RBAC, права в K8s и к чему приводит выдача слишком широких полномочий Pod'ам.
* Практический захват кластера из Pod'а и запуск криптомайнеров.
* Основные ошибки при написании манифестов для сервисов.

Доклад будет интересен как DevOps- и DevSecOps-специалистам, так и всем увлекающимся пентестами и машинками на HackTheBox, бывшим и действующим игрокам в CTF.

Мы в «Лаборатории Касперского» провели анализ самых популярных тактик, техник и процедур (TTPs) восьми самых активных групп шифровальщиков: Conti/Ryuk, Pysa, Clop (TA 505), Hive, Lockbit 2.0, RagnarLocker, BlackByte и BlackCat. Эти группы ведут свою деятельность по всему миру, в том числе в США, Великобритании, Германии. За исследованный нами период — с марта 2021 по март 2022 года — операторы этих групп пытались атаковать более 500 организаций в разных отраслях, среди которых промышленность, разработка ПО, строительство. Оказалось, что различные семейства этого вида ПО совпадают более чем наполовину в своих TTPs на протяжении всех этапов цепочки атак.

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

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

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

Недавно Яндекс запустил поиск по товарам (https://yandex.ru/products), который позволяет находить актуальные предложения во всех интернет-магазинах. Он ищет товары и в крупных маркетплейсах (Ozon, Wildberries, Яндекс Маркет), и в маленьких с десятком-сотней товаров, которые невозможно найти без поиска.

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

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

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

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

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

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

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

Датасет, код обучения моделей и сами модели доступны в OpenSource! 💪

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

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

* Основные проблемы в Python с точки зрения промышленного сервиса с компьютерным зрением.
* Обзор существующих решений: DALI & Triton, Cython, Julia, С++, Numba, etc.
* Батчинг.
* Разрешение критических боттлнеков в проде и случайное ускорение тренировок.
* Результаты.

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

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

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

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

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

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

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

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

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

На примере продуктов МойОфис я расскажу об эволюции почтовых решений в компании. В частности, проиллюстрирую, как менялись, развивались наши подходы к хранению и синхронизации данных. Путь от Dovecot dsync, OpenStack Swift до GlusterFS и DOS, собственного объектного хранилища. Также не оставим без внимания проблемы, с которыми мы сталкиваемся, и пути их решения.

Статьи в интернете описывают low-code- и no-code-технологии как инструменты для решения небольших локальных задач, прототипирования, привлечения citizen-разработчиков. Однако, есть и другое направление в low-code — платформы для создания серьёзных, масштабных, комплексных приложений.

Почему это интересно? В крупных компаниях часто возникает идея разработки собственного фреймворка, ORM, генератора отчётов и других инструментов унификации разработки. По сути, начинается внедрение элементов low-code.

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

На примере успешной low-code-платформы объясним:
• как выстраивать стратегию low-code;
• как использовать преимущества low-code-подхода при движении к highload;
• как не растерять преимущества low-code по пути к highload.

Архитектура системы распределённой обработки платежей.

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

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

Стандарты, стандарты, стандарты! О важности следования практикам, принятым в организации.

Проникновение флеш-плеера вместе с H264 почти 15 лет назад, а потом и появление HLS привели к тому, что массовая доставка видео в интернете перешла на TCP-протоколы: RTMP, HLS, DASH (и даже HDS).

Последние годы мы видим обратную тенденцию с возвращением на UDP-протоколы: WebRTC, SRT и эксперименты с WebTransport over HTTP/3.

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

У Почтатеха есть микросервисное приложение для бизнеса otpravka.pochta.ru, которое изначально не было спроектировано под высокую нагрузку. Со временем оно стало популярным и обросло дополнительными функциями. Это вызвало кратный рост нагрузки, особенно перед новогодними праздниками. Радикально изменить архитектуру приложения мы не готовы — опасаемся утратить стабильность. Поэтому занимаемся локальной оптимизацией.

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

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

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

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

Техтолк о том, как API-сервер K8s ложится под запросами prometheus, который пытается собрать 40 миллионов метрик. И про опыт СберМаркета по этому поводу.

1. Что такое СберМаркет.
- Что делает приложение СберМаркета.
- Как повысилась нагрузка и её профиль.
2. Способы удержания нагрузки.
- Тюнинг базы.
- Адаптация базы с последующим разделением на слоевые реплики.
- Разделение базы на Master/Slave и адаптация приложения под такую архитектуру.
3. Планы на будущее.

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

1. Что такое ДБО?
2. Тюнинг системы и этапы ее развития.
3. Предоставление качественного сервиса.
4. Потенциальные проблемы блокировки приложения ДБО в зарубежных маркетах.

В рамках данного техтолка вы узнаете, какими “секретными практиками” пользуются команды в Мир Plat.Form, чтобы поддерживать качество и скорость разработки на высоком уровне.

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

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

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

Как с этим живем и эффективно справляемся в Газпромбанке — подробнее в техтолке.

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

1. Зачем и когда автоматизировать?
2. Подводные камни:
* слишком ранняя автоматизация;
* несфокусированная автоматизация;
* поддержка и эксплуатация;
* недостаточная коммуникация;
* имитация ручного тестирования.

* Почему происходят аварии/проблемы.
* Что происходит во время аварии, как и что чувствует инженер.
* Почему люди идут в инженеры.
* Какие требуются компетенции для инженеров.
* Что стоит изучить (книги, инструменты).
* Рост специалиста от новичка до эксперта.

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

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

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

На чём мне запускать приложения, если WebLogic и WebSphere более недоступны? Если взять случайный образ с DockerHub, кто, вообще, гарантирует, что нас не сломает первый встречный? Что делать со стоимостью миграции на российские облака (вы видели чек?).

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

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

Основные компоненты, которые мы использовали в legacy-системах — SAS RTDM, Viya, ID, MA, MO, EG. Каждый из перечисленных компонентов покрывает ту или иную потребность системы, например:
1. исполнение ML-моделей (MA);
2. ETL (DI, EG);
3. оптимизация x-sell-предложений (MO);
4. low-code-инструменты настройки бизнес-логики (RTDM, Viya, ID).

В докладе расскажу об импортозамещении компонентов RTDM, Viya, ID. На вышеперечисленных движках в промышленной эксплуатации работают highload-процессы под нагрузкой ~50 000 TPS и c доступностью 99,99% (53 минуты простоя в год). Максимально схожими движками по функционалу являются системы класса BPMS: Camunda, jBPM, Kogito и другие. Взяв за основу наши функциональные и нефункциональные требования, покажу, почему мы выбрали jBPM, погрузимся в архитектуру решения, а также разберем баги, с которыми мы столкнулись, и методы их исправления.

"ХХХ вышел из чата" — какие вендоры ушли, какие остались, как с этим дальше жить.
Дата-центры, серверное и сетевое оборудование, офисное IT-оборудование, программное обеспечение. Изменения в IT-инфраструктуре после февраля 2022.

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

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

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

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

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

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

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

В докладе мы поделимся опытом, как по крупицам собрать информацию и восстановить протокол, используя документацию от других протоколов, утилиты от производителя, симулятор ПЛК, коды ошибок, полный перебор и другие методы. Покажем, как анализ протокола помог выявить целый набор уязвимостей: CVE-2022-25161, CVE-2022-25162, CVE-2022-25155 и др. Мы расскажем о них и покажем, как их вызвать, в многочисленных демонстрациях.

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

В рамках доклада разберем с вами:
* какими способами лицензируется софт?
* какие плюсы и минусы у того или иного подхода?
* как ломают лицензии? [Основано на реальных событиях]
* и как, в конце концов, написать невзламываемую лицензию? И не "поломать" при этом пользователей...

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

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

Зона консультаций по IT-бренд для не it компаний. Ответим на вопросы как создать it бренд банкам, гос компаниям, промышленным компаниям. Поделимся кейсами
Расскажем, как вовлекать разработчиков в IT-бренд, мотивировать писать статьи на Хабр.

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

Готовы поделиться экспертизой по коммуникации на IT-аудиторию:

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

И про то как их оценить:

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

* Импортозамещение инженерного оборудования (ИБП, батареи, кондиционеры, АВР и пр.);
* схемы построения инженерной инфраструктуры серверных/ЦОД с учетом требования по бесперебойной работе;
* этапы строительства и проектирования ЦОД;
* подбор помещений/участков для строительства серверных/ЦОД;
* основные ошибки при проектировании и строительстве серверных/ЦОД, на которые стоит обратить внимание;
* виды дата-центров: модульные/классические, отличия и преимущества.

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

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

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

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

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

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

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

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

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

Расскажем и покажем, как совместить C++ и простоту использования, высокую скорость разработки, эффективность и безопасность.

До событий основным инструментом создания платформ управления контейнерами являлся продукт Red Hat OpenShift Container Platfrom. Теперь продажи этого, как и любых других западных решений, невозможны, и стоит вопрос выбора замены либо альтернативы. В этом докладе мы поговорим, какие пути и возможности есть с т.з. компаний сегмента Enterprise, для которых характерны высокие требования к функциональности и стабильности продукта, а также надежности поддержки решения.

Основные тезисы доклада:
1. Для кого эта тема актуальна, кто и почему раньше выбирал OCP при наличии бесплатного kubernetes.
2. Какие возможны варианты замены OCP, в принципе. Два основных пути — OKD и ванильный kubernetes.
3. Что вас ждет в варианте OKD:
* чем отличается OKD от OCP не по слайдам вендора, а на практике;
* как правильно мигрировать с OCP на OKD, какие подводные камни ждут на пути.
Рассматриваем на примере проекта, раскрываем тезисы на примере практических проектных кейсов.
4. Зачем это нужно, если есть ванильный kubernetes?
На примере того же проекта поговорим, почему это было важно в нашем случае и что, возможно, следует учесть слушателям при таком кейсе:
* платформа контейнеризации и операционная система как одно целое (immutable CoreOs);
* наличие специфичных разработок для платформы (таких, как инфраструктура мониторинга STF), которые были важны Заказчику и которые существуют в адаптированном виде под OCP/OKD.
5. Поговорим на эту тему чуть шире — для enterprise в настоящий момент актуальна не только замена OCP, но также и замена подлежащей под ней платформы виртуализации. Если ранее 90% всех внедрений было поверх VMware, то теперь актуален переход на KVM-подобные гипервизоры. Здесь поговорим про наш опыт развертывания OKD на подобных решениях. Цель: дать информацию о том, что для компаний можно предоставить единый программный стек инфраструктуры, начиная от уровня гипервизора до уровня контейнерной оркестрации, на свободных opensource-технологиях, но при этом с достаточным уровнем надежности. Обсудим вопросы совместимости.
6. А что есть из отечественного, и что оно умеет по сравнению с OpenShift? Обзор решений, экспертное мнение.

Секрет промышленности:
Как можно добиться противоположного: скорости и качества.

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

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

Основные вопросы:
* Что такое QA?
* Что такое качество?
* Как и зачем измерять качество?
* Как масштабировать качество и принципы работы на десятки и сотни проектов.
* Инструменты достижения качества.

Почему DevOps — это один из ИНСТРУМЕНТОВ QA?

Итак, вы решили идти в ногу со временем и добавить в свой кластер Kubernetes первый Service Mesh. От друзей вы слышали, что Istio требует много памяти, прокси в Linkerd очень быстрые, но никто не проверял. А еще все почему-то говорят про Cillium, хотя это CNI-плагин. Настало время все это обсудить!

В докладе мы разберем:
1. что такое паттерн Service Mesh и зачем, в принципе, он может понадобиться;
2. все существующие архитектурные подходы к реализации Service Mesh;
3. самые популярные OpenSource-реализации Service Mesh: Istio, Linkerd, Cillium, NGINX Service Mesh и др. Проверим Control&Data planes, познакомимся с User API, узнаем все про возможности расширения и кастомизации;
4. опыт эксплуатации и типовые проблемы Service Mesh в большом и нагруженном продакшне.

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

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

Для построения цифровых продуктов компании необходимо обладать технологической компетенцией, которая дает качественные процессы разработки, тестирования, эксплуатации, работающие на базе принципов Cloud Native, API first, CI/CD, Infrastructure as Code.

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

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

Поговорим про:
* Kubernetes как основу автоматизированной оркестрации ресурсов и приложений;
* CI/CD-стандарты разработки, которые снимают сложности и барьеры с разработчиков, создают изолированные пространства разработки и позволяют быстро включать разработчиков разного уровня компетенции в процесс;
* ключевые стандарты и подходы, которые делают разработку качественной, быстрой и безопасной;
* как эти стандарты имплементируются на опыте Экспресс 42 и могут быть имплементированы у вас.

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

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

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

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

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

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

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

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

Рассмотрим фреймворки для создания программного обеспечения дронов и системы имитационного моделирования. Познакомимся с автопилотами и применяемыми датчиками дронов.

* Краткий обзор беспроводных технологий передачи информации, их место и задачи в мире IoT;
* особенности технологий LPWAN беспроводной передачи данных;
* почему так сложно сделать умные вещи и подключить их к интернету;
* зачем мы написали свою платформу интернета вещей и чем нам не угодили готовые платформы;
* как профили устройств упрощают сопровождение;
* как мы внедряли IoT в 52 регионах России для мониторинга птичников;
* зачем мониторить показатели температуры и влажности воздуха в птичниках и на складах;
* использование датчиков сухих контактов для мониторинга работы автоматики;
* датчики температуры и влажности почвы — почему их так мало применяют?
* как датчики интернета вещей позволяют снизить себестоимость продукции и сэкономить на поддержке.

Агротех — одно из самых перспективных направлений в РФ и мире.
Создавать продукты для агротеха долго и сложно.
Поделимся нашим опытом создания прорывного решения с CV и беспилотниками для агротеха.

Рынок систем отчётности и BI огромен. Часто даже в рамках одной компании одновременно эксплуатируется несколько таких систем, и «Магнит» — не исключение. Но рано или поздно появляется потребность в единой платформе отчётности, которая охватит львиную долю ваших задач и пользователей. Специфика компании диктует свои правила: появляются нестандартные запросы, ограничения и краеугольные камни. Это может быть эффективная работа с несколькими базами данных, информационная безопасность, управляемость, скорость разработки, обработка больших объёмов данных, ориентированность на конкретные пользовательские сценарии. Часто компании заходят в тупик — готового решения, в точности соответствующего критически важным требованиям, не существует.

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

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

Т.е. рассказ будет о том, как делать не надо.

Data Lakehouse, Cloud Data Platform, Data Mesh, Data Fabric — громко звучащие слова, которые у всех на слуху и профессионально интересны каждому специалисту в области работы с данными. Но что, если желание "пощупать и внедрить", которое обычно разбивается о будни поддержки текущих решений, вдруг воплощается в рабочую реальность? Бойтесь своих желаний, ведь именно так произошло в toloka.ai — перед командой платформы данных была поставлена задача: "Azure. Modern Data Stack. Завтра".

В рамках нашего доклада мы пройдем все стадии нашей работы с Modern Data Stack — выбирай, страдай, люби — и затронем следующие вопросы:
* что такое современная платформа данных и на каких китах она держится?
* как не утонуть в мире Modern Data Stack-решений?
* какие подводные камни интеграции разных систем вас ожидают?
* какие инструменты (из тех, что мы попробовали) “must have”, а что можно пробовать заменить?
* как изменилась (и изменилась ли) работа аналитиков?
* что стоит, а что не стоит повторять, если вы пойдете по той же дорожке?

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

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

Этими вопросами мы и задались, поэтому хотим поделиться нашим опытом технического развития быстрорастущих продуктов:
* как сохранять баланс развития и техдолга при масштабировании в 10 раз? С какими проблемами мы столкнулись и как их решали;
* о чем можно было подумать в начале разработки, чтобы сделать переход от MVP к реальности проще.

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

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

Аналитика ВКонтакте очень активно использует ClickHouse. Не будет преувеличением сказать, что эта СУБД выступает в качестве ключевого компонента нашего DWH: бэкенд пишет риалтайм click stream, сотни дэшбордов читают данные, десятки аналитиков пишут запросы. Благодаря развитому сервисному слою, все это работает параллельно на одних и тех же серверах.

В докладе мы коснемся части этого слоя, а именно инструментов для работы с данными поверх ClickHouse. Проследим эволюцию этих инструментов от ETL-утилиты до MapReduce-фреймворка, доступного всем коллегам. С помощью этого фреймворка аналитики решают задачи, требующие batch-обработки больших объемов данных, без написания ТЗ на подготовку датасетов и без привлечения дата-инженеров. Это значительно уменьшает time-to-market в аналитике и в конечном счете упрощает DWH-инфраструктуру, что особенно актуально для быстрорастущих компаний среднего размера. Попутно коснемся устройства пайплайна АБ-экспериментов, способного работать с самыми тяжелыми логами в масштабах сотен одновременно запущенных экспериментов.

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

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

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

https://github.com/avito-tech/go-transaction-manager/