Доклады

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

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

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

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

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

(Проблема как обслуживать поставщиков с командой в 5 человек).

В докладе расскажем, как мы делали систему управления остатками и ценами:

- Какие технические сложности возникают при больших объемах данных (~ 500000000 строк, 150к/рпс на запись);
- Монолит vs микросервисы. Что выбрали и с каким сложностями столкнулись;
- Postgres vs Tarantool. Не самый очевидный выбор;
- Работа с Kafka: конфигурация, графики, семантика "exactly-once", драйвер kafka-go от segmentio;
- Согласованность в конечном счете — когда и зачем ее можно применять, как достичь;
- Извечный вопрос: предподготовить данные или рассчитать на лету? Мы выбрали гибридный подход;
- На какие метрики ориентировались: технические и бизнесовые;
- Покажем наши дашборды, расскажем, как мы мониторим асинхронную систему и проводим нагрузочное тестирование, графики ТТХ, нагрузки, таймингов;

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

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

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

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

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

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

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

В Авито делаю выкуп телефонов. Заявка на выкуп имеет, 5 смежных сущностей, около 20 состояний и более 40 возможных переходов на пути от продавца к покупателю через наших партнеров. Для устойчивого роста с таким клубком мы приняли DDD для себя.
В докладе я расскажу о наше опыте использование тактических паттернов DDD (Factory, Value Object, Entity, Aggregate, Repository), как мы к ним шли, что нам это дало при решение задач.

- Есть легаси энтерпрайз система учета товаров, написанная на Oracle EBS
- Из новой системы с ней сложно и неудобно взаимодействовать
- Из этой системы надо перетаскивать большое количество обновлений по продуктам (10-ки млн в день)
- Построили ETL на основе Kafka + Confluent + kSQL и микросерверную архитектуру на Go вокруг этого ETL
- Сделали это маленькой командой, пытаясь сэкономить время разработки и не нанимая Java-разработчиков
- Много раз пожалели о выборе технологий
- Столкнулись с проблемами, которые не решаются из-за низкой популярности инструментов
- Строим альтернативу на обычных консьюмерах, написанных на Go, отказываемся от kSQL
- От Kafka не отказываемся, она подходит для наших целей. Используем Source-коннекторы для забора данных в любом случае

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

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

В докладе я расскажу особенности построения архитектуры и тонкости применения языка Golang при разработке open source приложения для стриминга видео в реальном времени: https://github.com/AlexxIT/go2rtc

Для разработчиков уровня Senior вряд ли будет что-то новое. А остальным может быть интересно послушать особенности эффективной работы с сетью, применение интерфейсов Reader/Writer, захват сетевого подключения при обработке исходящего или входящего HTTP запроса и прочее.

Расскажу про типовые ошибки и невероятно полезный инструмент для эксплуатации GRPC.

Это небольшая экскурсия по FerretDB - прокси-серверу с открытым исходным кодом, написанному на Go, который преобразует запросы проводного протокола MongoDB в SQL, используя PostgreSQL в качестве ядра базы данных. Посмотрим, что он уже умеет, как подключить, немного заглянем во внутрь.

Поговорим об интеграционных тестах с базой данных на примере PostgreSQL, как их готовить и с чем их есть.

Никаких happy path! Я расскажу, как нам перестало хватать баннера “Что-то пошло не так” и мы учились сообщать пользователю об ошибках во время выполнения запроса в большом и сложном продукте — системе хранения данных (СХД). Тогда мы внедрили свой формат ошибок для общения между сервисами и решили проблемы:
- Как определять проблему, если HTTP кодов уже не хватает?
- Как добавить в ошибку параметры, чтобы показать детали проблемы, а не общее сообщение?
- Как показать ошибку на другом языке, если в сообщении содержатся параметры и текст всегда отличается?
- Как сделать так, чтобы пользователь видел ошибки подробно, но не пропускать лишних деталей из сервиса?
- Как интерпретировать ошибки одного API для другого и не сойти с ума?

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

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

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

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

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

- Проблема проверки методов валидации данных с карточки товара, в которую клиенты могут написать все, что захотят (могут скопировать текст с docx или pdf файла и ненужные байты попадут в текст карточки товара из-за чего может неверно сработать код программы или вовсе упасть с паникой). Также проверки данных на sql инъекцию.
- Для решения данной проблемы были созданы fuzzing тесты, которые помогают отлавливать различные кейсы для методов валидации КТ и устранять ошибки до выхода в продакшен среду.
- В итоге мы получили:
1. Меньше обращений с тех поддержки, где в информации о карточки товара появились непонятные символы, которые пользователи случайно добавляли к карточке товара при неверном копировании данных со своих источников.
2. Счастливые QA (валидация и нормализация работают без помех)
3. Счастливые ИБ-шники (с fuzzing тестированием стало проще проверять каждый sql запрос на уязвимость к sql инъекциям).

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

Уязвимости chaincode написаных на Go влияющие на безопаность бизнес приложения на основе блокчейна Hyperledger Fabric
Архитектурные особенности исходного кода чейнкодов и Hyperledger Fabric

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

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

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

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

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

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

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

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

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

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

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

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

- Внутри теста остаётся только код самого теста
- Тест работает в парадигме уже созданного окружения
- Настройка окружения - ленивая, создаётся только то что нужно
- Настройка окружения умная - можно переиспользовать части окружения между тестами (по желанию).
- Особенности реализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В компании с быстрорастущим объемом данных ориентироваться в них становится сложнее и сложнее. В этой ситуации помогают каталоги данных, однако, информация в них, как правило, заполняется пользователями собственноручно и/или из ERM-связей небольших БД. Мы же во внутреяндексовом DataCatalog научились автоматически на основе логов ETL операций и adhoc расчетов собирать Data Lineage системы YTsaurus, наладив контакты между поставщиками и потребителями и обеспечив поиск нужных сущностей данных.

Расскажем, как повторить наше решение в другой логирующейся MapReduce/Spark системе, а также ответим на главные вопросы при каталогизации:
- Что делать, если в MapReduce системе данные пишутся во временные таблицы, которые не интересны конечному пользователю?
- Как оптимально обрабатывать большие объемы данных, чтобы не потерять целостность метаинформации?
- Что делать, если в системе есть символические ссылки и почему это вообще проблема?

YTsaurus — opensource платформа для хранения и обработки больших данных от Яндекса. Сердцем кластера YTsaurus является мастер-сервер, занимающийся обслуживанием метаданных, репликацией чанков, авторизацией пользователей и многим другим. Для отказоустойчивости, мастер YTsaurus построен по модели Replicated State Machine, как и другие известные сервисы координации и управления метаданными: etcd, ZooKeeper, Consul.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) Какие бывают CI системы.
2) Причины перехода с Jenkins на GHA.
3) Проблемы с которыми столкнулись при переходе на GHA.
4) Итоги, оставшиеся проблемы, подсчитанные качественные результаты перехода.
5) Дальнейшее развитие, которое нам открылось.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из антипаттернов наблюдаемости является wall of dashboard. Во многих компаниях существует огромное количество дашбордов, но все ли они полезны? Можно ли, посмотрев на них, понять работает ли система? Скачал дашборд с сайта графаны и поставил себе, таков путь инженеров? Нет :)

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

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

Мы расскажем, как при помощи динамического выделения стендов/ресурсов на базе технологий node autoscaler, hpa, самописного плагина для автоматического развертывания стендов можно повысить эффективность разработки, сэкономив до 30% стоимости, при условии сохранения темпов роста, количества разрабатываемых фич и партнеров и сделать так, чтобы разработчики (в том числе и ML/DS) могли проводить свои эксперименты, не мешая друг другу в облаке Cloud.ru.

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

Результат: суммарная экономия до 30% на всех стендах.

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

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

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

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

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

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

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

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

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

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

Посетив доклад узнаете
1. Об универсальном транспорте для tcp, Infiniband, cuda
2. Как один интерфейс транспорта выбирает лучший доступный транспорт
3. О послойном написании транспорта - несколько уровней под разные нужды
4. Об интеграции в нейросетевые фремворки (на примере нашего)
5. О проблемах, которые можно встретить в больших С библиотеках

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

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

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

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

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

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

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

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

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

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

И, в своем докладе, хотелось бы поделиться опытом создания системы «умного мониторинга», где решается задача ухода от статичных порогов в сторону прогнозирования и динамики с использованием ML и AI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Генеративные большие языковые модели (Large Language Model, LLM) - наша новая реальность, которая становится core-технологиях во многих продуктах. То, для чего раньше требовалось собирать развесистый пайплайн из множества ML-моделей и хитрых алгоритмов обработки данных, теперь делается подбором правильного промпта.

Я расскажу про наш опыт обучения YandexGPT для задачи суммаризации статей в Яндекс Браузере и сервисе 300.ya.ru. О том, какие приемы помогли избегать ручных правил, экономить на GPU и что нас ждет в будущем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Раздел дополняется

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Итого:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Итого:

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

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

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

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

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

Как интегрироваться с системами SAP без IDocs и SAP PI? Как отправлять большие сообщения? Как увеличить скорость передачи данных из систем SAP и повысить надежность интеграционных потоков? Что такое сервер JCO?
Я попытаюсь раскрыть эти проблемы в своем отчете на примере настроенного сервера Jco в рамках проекта “Пополнение TC5” в компании X5 Retail Group. В рамках доклада я расскажу о проблемах, с которыми мне пришлось столкнуться при интеграции с самой высоконагруженной ERP-системой SAP в России, а также о том, как они были решены. Также будет освещена тема всех нюансов настройки Jco Server-a, какая скорость передачи данных была достигнута и ограничения такого подхода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

1. Что было было раньше
2. Начало трансформации ИТ-ландшафта (2021) год
3. Трансформация ИТ-ландшафта в централизованную коммунальную среду (2022) год
4. Предпосылки к созданию внутреннего облака и коммунальных сетей L3 (2023)
5. Развитие внутреннего облака и коммунальных сетей L3 (2023)
6. Наши планы по на 2024 год

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Антиспам почты mail.ru ежедневно в режиме реального времени проверяет более 400 млн. писем в сутки. Ключевой целью нашей команды является качественная и быстрая защита пользователя от нежелательного контента в формате 24/7. Но как этого можно достичь, когда железная инфраструктура может выйти из строя, деплой сервиса может затянуться из-за очереди на выкатку, а резко пришедшая нагрузка может существенно сказаться на скорости проверки писем? Ответ для себя мы нашли во внедрении kubernetes . Сейчас антиспам в kubernetes это более 2000 подов и порядка 10000 ядер. Но так было не всегда....
В рамках своего доклада я хочу провести вас по тернистому пути, который преодолела наша команда при миграции ключевых систем Антиспама в k8s.
В ходе выступления я коснусь следующих тем:
* Более детально расскажу, как мы решили заезжать в k8s
* Как решали вопрос балансировки нагрузки
* Какую трансформацию пришлось пройти нашему монолиту, чтобы стать stateless
* Как мы учились проводить A/B-тесты для ML моделей и спам-сигнатур в условиях k8s
* Про то как незаметно для пользователя переключали нагрузку
* Как мы проверяем отказоустойчивость системы
* Проведу небольшую ретроспективу процесса миграции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Работая над SaluteSpeech(синтез и распознавание речи), а затем еще и с GigaChat(gpt-like), я понял, что хочу поделиться своим опытом работы с крупными ML-based проектами. Доклад посвящен актуальным проблемам системного анализа в условиях хаотичного и стремительного развития продуктов на базе ML технологий.
Затронем следующие вопросы:
- Как собирать требования, когда они устаревают быстрее их проработки?
- Что может помочь говорить с бизнесом и ML-разработкой на одном языке?
- Зачем вообще системная аналитика в ML и что она может дать?

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

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

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

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

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

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

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

Yandex Monitoring используется всеми сервисами Яндекса внутри, а также доступен в Яндекс.Облако для внешних пользователей. Мы обрабатываем 700 миллионов метрик на запись ежесекундно.

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

В докладе:
* Шардирование и балансировка нагрузки;
* Партиционирование метаданных;
* Партиционирование потока записи;
* Выбор ключа партиционирования и подводные камни;
* Подходы к автопартиционированию в БД и не только;
* Как делаем автопартиционирование мы, что пробовали;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Представим, что вы лидер инженерной команды или амбициозный инженер, который понял ценность platform engineering-а для своей компании. У вас возникла идея начать работу над внутренней платформой разработки, но вы осознаете необходимость инвестиций в эту активность со стороны руководства.

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

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

1. Как полирепозиторный подход к организации кода приводит к dependecy hell в бизнес-приложениях и почему
это проблема, с которой нужно бороться?
2. Как снизить порог вхождения в разработку внутренней библиотеки компонентов для новых сотрудников?
3. Как монорепозиторный подход к организации кода помогает облегчить поддерживание большой кодовой
базы?
4. Как использование NPM Workspaces позволяет снизить количество потребляемой ПЗУ при установки
зависимостей большой кодовой базы?
5. Почему использование NX в качестве системы сборки это отличный выбор?

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

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

В 2021 году Китай опередил США по плотности внедрения технологий автоматизации и роботизации с более чем 243.300 установок/проектов показав рост в 44% по сравнению с 2020 годом. Примечательно, что все эти проекты реализованы не только на отечественной аппаратной базе но и программной и , в большинстве случаем, речь идет о кодовой базе проекта openEuler.

В нашем докладе мы расскажем о ведущих решениях СПО из Китая, которые используются для разработки специализированных дистрибутивов операционных систем для Embedded и Edge устройств. Также мы поделимся практическим опытом создания дистрибутивов для устройства Outdoor Box Nano от российского вендора Combox Technology и специализированного одноплатного компьютера FriendlyELEC NanoPi M4.

В докладе мы рассмотрим:
1. Технологические возможности кодовой базы дистрибутива OpenScaler для создания Embedded и Edge устройств. Мы расскажем о поддержке фреймворка Yocto, который позволяет создавать дистрибутивы операционных систем размером от 5 МБ и поддержке ROS/RTOS а также DsoftBus.
2. Представим процесс создания специализированного установочного IMG файла дистрибутива. Расскажем о шагах, необходимых для его создания.
3. Обсудим особенности установки специализированного дистрибутива и решения возникающих проблем В частности с выбором варианта загрузки, как Android или как PC. Настройки 3D ускорения и другие аспекты, такие как ядро, DTS и прошивки.
4. Наконец, мы представим законченное устройство, созданного с использованием специализированного дистрибутива. Продемонстрируем его функциональность и возможности.

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

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

+ как сделать ревью и приемку open-source решения
+ как сделать его харденинг
+ какие решения можно использовать для сканирования на уязвимости
+ дадим чек-лист по приемке open-source компонента на "боевое дежурство"

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

Мы расскажем вам, про:
1. Систему контейнерной виртуализации iSula и результаты ее нагрузочного тестирования в сравнении с Docker и Podman при 10/100/1000 последовательном и параллельном запуске контейнеров.
2. Особенности специализированного «облачного» дистрибутива NestOS для контейнерной виртуализации. Из отличительных особенностей данного дистрибутива стоит отметить его минималистичность. Так, размер iso образа NestOS составляет всего чуть более 700 Мб, а установленная система занимает меньше 10 Гб.

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

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

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

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