Доклады

Цифровая трансформация в Газпромбанке резко увеличила потребности бизнеса в ML-моделях. Если раньше это были простые линейные модели, то современные реалии требуют внедрения новых подходов (бустинги, нейронные сети и т.д.).

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

Все вышеперечисленное подводит нас к теме MLOps. На techtalk мы обсудим:
* Ключевые отличия в методиках DevOps и MLOps.
* Почему у вас не будет единого CI/CD-пайплайна.
* На каких этапах это превращается в MLSecOps.
* Какие инструменты помогают разработчикам моделей.
* Почему просто управлять кодом не получается.
* Другие наши боли, с которыми мы столкнулись при внедрении MLOps.

1. Микросервисная архитектура.
2. Проектирование современной архитектуры по CJM.
3. Топология команд для больших архитектур.

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

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

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

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

Мы поговорим с вами о том, как мы развиваем self-service BI в НСПК, с какими трудностями сталкиваемся и какие инструменты используем в нашей непримиримой борьбе с Excel.

* Зачем DevSecOps в нефтехимии.
* Зачем это вам, если вы: dev, sec, ops, business (нужное подчеркнуть).
* Как изменять культуру в компании.
* Что точно не надо делать.

Расскажу, как построена аналитическая система в Sportmaster Lab, что работает хорошо, а что пошло не так.
Выбор решений для "self-service"-аналитики.

Баланс между «фабрикой отчётов» и «self-service». Как это сказывается на технологиях.
Что мы выбрали в итоге (спойлер: ClickHouse, Tableau Hyper, Python, Apache AirFlow).

Расскажу про различные «велосипеды», которые мы построили, а нужно ли было?

"Пепелацы" для загрузки данных: параллельная заливка данных в ClickHouse и Tableau Hyper.
"Пепелацы" для доступа к данным: различные источники, кэширование, управление ресурсными планами, контроль прав доступа.

1. Что такое СИБУР Диджитал:
⁃ что мы делаем в рамках СИБУР Диджитал;
⁃ какие специалисты и какие направления представлены в компании;
⁃ какой стек используется в компании.
2. Какие задачи решаются с помощью автоматизации:
⁃ портфель открытых проектов;
⁃ проект "ТОИР";
⁃ проект "Корпоративная социальная сеть".
3. К чему мы хотим прийти:
⁃ взаимодействие с компанией с помощью мобильного телефона;
⁃ удобный и быстрый и безопасный сервис.
4. Опыт внедрения продуктов на предприятиях:
⁃ командировки на предприятия и взаимодействие с пользователями на заводах.

* Что такое экспертная система (ЭС)?
* Зачем ЭС нужны?
* Почему делать ЭС сложно?
* Что обычно умеют люди?
* Чего не хватает специалистам, чтобы создавать ЭС?
* Чему нужно учиться и учить, чтобы серийно создавать и внедрять ЭС?
* И почему это все ещё боль? :)

Обсудим на техтолке!

Поговорим про практическую реализацию RBAC на примере Мир Plat.form.

* Ролевая модель доступа к серверам во FreeIPA/Active Directory — предпосылки создания, разница в подходах к Linux/Windows.
* Как мы перевели на RBAC 3000+ продуктивных серверов и автоматизировали жизненный цикл ролей от сбора данных в AD/FreeIPA до создания активов в CMDB и выгрузки состояния в WIKI.
* И нашли свой подход к RBAC для тестовых стендов разработки с DevOps-командой.
* Какие проблемы решил RBAC.

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

Мы посмотрим на эти практики как на инженерный процесс, выявим схему, добавим важные детали и попрактикуемся, чтобы 1:1 и ОС заняли свое место в вашем мастерстве руководителя.

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

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

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

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

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

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

Покупки с помощью карты стали неотъемлемым атрибутом нашей жизни. За 2021 год жители нашей страны совершили более 21 миллиарда операций банковскими картами.

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

Доклад будет о том, как мы научились более эффективно передавать данные между нашими сервисами.
С сохранением exactly once и отказоустойчивости мы уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.

Подробнее на простом примере:
Пусть у нас есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И мы хотим в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.

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

Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).

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

То есть мы решаем проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.

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

Доклад про понятия SLI/SLO/SLA и то, как мы трактуем их в Авито. Слушатели узнают о подходах к измерению надёжности как микросервисов в частности, так и микросервисного приложения в общем.
Также я расскажу, для чего вообще стоит этим заниматься.

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

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

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

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

Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.

"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему мы решили пойти своим путем.

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

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

Звучит скучно, не правда ли?

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

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

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

Управление состоянием в сложном микросервисном ландшафте — задача не из легких. Как только процесс изменения затрагивает несколько слабосвязанных сущностей, проблема их консистентности встает поперек горла архитектора. На помощь приходят многофазные транзакции, Saga, X/Open XA... Теперь вместо одной проблемы у вас две.

В процессе разработки сервиса Containerum Kubernetes Service мы пошли другим путем — построили распределенную систему на основе доменной модели, управляемой конечными автоматами, и синхронно-асинхронной коммуникации между сервисами посредством gRPC и Kafka. Это позволило нам управлять сложными иерархическими сущностями, разбросанными на полдюжины сервисов, гибко обрабатывать ошибки и забыть про неконсистентность и болезненные роллбэки. Нашим опытом, ошибками и успехами я с вами и поделюсь.

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

Все эти события реального мира у нас отражаются сообщениями в Кафка. Но эти сообщения кто-то должен получить и обработать, чтобы посылки не терялись. На стороне обработки есть разные задачи:
* нужно писать лог событий. В Кафке у нас JSON или avro, а лог мы пишем в Hadoop, и там нужен ORC или Parquet;
* поверх получаемых данных нужна real-time-аналитика. Например, хочется понимать пропускную способность всей логистической компании;
* нужно сопоставлять факт отправки и получения и поднимать тревогу, если посылка задерживается. Для этого нужно где-то до нескольких дней помнить про отправку.

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

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

В докладе рассмотрим принципы проектирования пайплайнов на основе Flink, которые позволяют забирать и приземлять данные из Kafka максимально безболезненно.

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

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

Я расскажу про:
- сonsistent hashing для разделения вычислений в микросервисном кластере;
- работу с geospatial-данными в Redis;
- разные типы и характеристики location provider'ов: GPS, WiFi LBS, GSM LBS, Android Fused;
- способы детектирования и борьбы с аномалиями GPS.

Расскажу о том, как решение одной частной проблемы выросло в систему, с которой работает сотня команд и которая позволяет в режиме реального времени ответить на большинство вопросов про то, что происходит с продакшном. Мы объединили разбор ошибок клиентов и бэкендов, клиентскую скорость, телеметрию видео, клики по элементам интерфейсов, access_log сервисов, логи балансеров, CSP, CDN статики, CDN видео в общий набор инструментов, который позволяет навигироваться по более чем 150B событий в сутки. И еще фильтровать данные по произвольным срезам, строить графики, считать метрики, сравнивать сегменты, настраивать алерты.

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

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

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

В докладе я расскажу, как можно построить федеративную межкластерную маршрутизацию на базе Istio Service Mesh. Что предлагает Istio «из коробки», и что делать, если стандартные схемы мультикластерного деплоймента вам не подходят. Как реализовать управление межкластерным трафиком и делать мультикластерные канареечные релизы. Как обеспечить сетевую локальность для межкластерного трафика. И, наконец, как реализовать мультикластерные механизмы для работы таких паттернов, как retries, timeouts и circuit breakers.

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

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

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

В докладе я расскажу, как мы собираем 100% трассировки с 50+ продуктов при помощи Jaeger. Как обрабатываем и храним 500 Гб трассировки в сутки с помощью Elasticsearch. Как справляемся с постоянно растущим потоком данных в 15 тысяч документов в секунду. Затрону вопросы мониторинга и влияния сбора трассировки на наблюдаемою систему.

Перебои и ошибки в работе распределённых систем (будь то Web или IoT) — совершенно обычная ситуация. Проблемы в работе с сетью, перебои в работе зависимостей и банальный человеческий фактор — та цена, которую мы платим за общую стабильность системы, лёгкую масштабируемость и гибкость в разработке.

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

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

VK Видео — единая технологическая платформа, на которой нам удалось объединить весь видеоконтент экосистемы VK, включая Клипы ВКонтакте. А главное, сконцентрировать все технологии для обработки и передачи видео. Видеоплатформа содержит миллиарды единиц контента в хранилище на эксабайт данных, пользователи генерируют 2,3 млрд просмотров в сутки и 4 Тбит/с трафика в вечернее время. На платформу ежедневно загружают 8 млн новых видео, а в пиковые дни — более 14 млн.

В докладе расскажу:
* о развилках в выборе архитектуры и способах решения основных проблем видеосервиса: его доступности, масштабирования, роста, скорости обработки видео и доставки до пользователей;
* об устройстве стриминга от upload'а до воспроизведения на клиенте, а также технических трюках, с помощью которых мы добиваемся самой быстрой доступности видео на Диком Западе;
* о черной магии, которая помогает добиться скорости и качества сервиса на уровне мировых решений, и о том, как сделать еще лучше;
* о способах достижения баланса в таких вопросах: хранилище vs серверные мощности, клиентский CPU vs сеть, качество картинки vs ресурсы и т. д.;
* как рекомендательная система, технологии компьютерного зрения и распознавания речи позволяют кратно растить смотрение.

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

Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) мы выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов нам пришлось решить множество проблем. В докладе я расскажу о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажу, почему выбрали именно модель акторов.

Kubernetes стремительно завоевывает популярность, в том числе и как платформа для кластеров баз данных. ClickHouse тоже не тормозит. Еще совсем недавно ClickHouse в Kubernetes казался экзотикой, но все поменялось благодаря разработанному Altinity оператору Clickhouse operator (https://github.com/Altinity/clickhouse-operator). Мы научились "готовить" ClickHouse для Kubernetes наилучшим образом и сделали это простым для всех остальных.

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

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

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

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

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

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

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

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

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

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

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

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

В качестве примера я буду рассматривать СУБД PostgreSQL, при этом полученные знания можно будет применять и с другими БД.

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

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

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

Приняли решение перестраивать и сформулировали следующие требования:
1. новое хранилище должно быть прозрачно масштабируемым как по месту, так и по производительности;
2. обработчики должны быть stateless;
3. количество обработчиков должно наращиваться "по кнопке".

В рамках доклада расскажу:
1. почему остановились на YDB, как переезжали, что сломали;
2. как научились работать с таблицей в 40ТБ и 1 миллионом запросов в секунду;
3. как тестировали и масштабировали.

В своем докладе я расскажу, как мы используем JIT-компиляцию запросов в ClickHouse. С какими сложностями и подводными камнями мы столкнулись при внедрении JIT-компиляции запросов, и как мы решили возникшие проблемы.

Несмотря на то, что подсистема ввода-вывода PostgreSQL вполне хорошо подходит для большинства решаемых задач, она все-таки имеет несколько особенностей и проблем:
* трудно предсказать задержку записи/чтения данных, особенно для баз данных, размер которых значительно больше доступной памяти;
* пропускная способность ввода-вывода, особенно в быстрых подсистемах хранения (например, в NVMe-дисках), недостаточно высока для использования на все 100%;
* бэкенды сами выполняют слишком много операций ввода-вывода, так как фоновый писатель (bgwriter) работает не очень оптимально;
* генерируется ненужная случайная запись данных (bgwriter, backends);
* двойная буферизация между страничным кэшем ОС и общими буферами (shared_buffers) памяти Postgres;
* все операции на чтение данных являются синхронными (из страничного кэша ОС);
* большой размер shared_buffers может вызвать проблемы, когда таблицы очень часто удаляются или очищаются.

Об этом и не только я расскажу в своем докладе...

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

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

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

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

Vitastor — это мой быстрый «Ceph-заменитель». Распределённая блочная программная система хранения данных (SDS), способная, в отличие от большинства других систем, нормально работать с быстрыми твердотельными накопителями, и при этом, в отличие от большинства других систем, имеющая симметричную распределённую архитектуру без единой точки отказа. А под «нормально», конечно, понимается «так быстро, как только возможно» :-)

В предыдущем докладе на DevOpsConf (https://devopsconf.io/moscow/2021/abstracts/7458) я рассказал о ситуации с SDS («нечего надеть»), причинах создания Vitastor и общих принципах его разработки.

В этом докладе я хочу остановиться на технической стороне. Тёмной, архитектурной технической стороне.

Что такое «симметричная распределённая архитектура»? Как конкретно обеспечивается консистентность? Как реализованы снапшоты и клоны? Зачем нужен io_uring? Как Vitastor использует RDMA? Что ещё за монитор на node.js и откуда там LP-солвер (утилита решения задач линейного программирования)?

С какими ещё архитектурными выборами придётся столкнуться по ходу разработки? Например, что будет, если всё-таки захочется реализовать поверх Vitastor файловую систему? Обо всех этих вопросах и пойдёт речь в докладе.

* Целевой ландшафт ИТ-архитектуры.
* Производственный домен.
* Проектирование ИТ-систем производства.

Я расскажу о том, как и почему компания Timeweb перевела хостинг на ZFS и отказалась от LVM и DRBD.

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

* Как выглядела архитектура с LVM и DRBD.
* Что не устроило в существующей архитектуре.
* Как выглядит новая архитектура файловой системы хостинга.
* С какими сложностями столкнулись.

1 Введение в Kernelshark.
1.1 Рассказ про ftrace, ptrace, ebpf.
1.2 Установка Kernelshark, trace простой функции в ядре.
2 Сравнение с Wireshark.
2.1 Отличия и сходства для более быстрого знакомства с Kernelshark.
2.2 Как создать свой tcpdump с помощью trace bcc в одну строку.
2.3 Как отслеживать проблемы в сетевом стеке с помощью Kernelshark.
3 Kernelshark как инструмент для траблшутинга.
3.1 Пример с обнаружением проблем ARP-запроса.
Часто у нас есть счётчики и логи для анализа поведения системы. Но что, если у нас нет под рукой нужной статистики или мы не знаем, где смотреть? Kernelshark поможет разобраться в проблеме.
4 Kernelshark как инструмент для анализа производительности.
4.1 Пример со сравнением времени работы при использовании файлового кэша при обращениях приложения к файловой системе. Рассмотрим, как сильно влияет файловый кэш, как его можно сбросить, какие функции в ядре работают в каждом случае.
4.2 Пример с замерами времени исполнения функции шифрования в сетевом модуле ядра.
Иногда нам нужно добавить какое-либо поведение в код, но не всегда понятно, какой вклад в latency будет привнесён изменениями при работе в контексте ядра. С Kernelshark можно будет заглянуть в прерывания и сравнить время выполнения. Особенно с -p function_graph!

Обзор полезных ссылок.

* У вас происходят сбои в production и они вас беспокоят?
* Вы чувствуете, что ваша разработка стагнирует, но прозрачности получить неоткуда?
* Вы хотите понимать, насколько в production'е всё хорошо или плохо и о чем стоит беспокоиться?
Тогда этот доклад для вас! :)

Каждый день мы катим изменения в production иногда десятками, да и сотнями в сутки и, конечно же, что-то ломаем. Ломаем по-разному, чаще по мелочи — на 5-10 минут, иногда и по-крупному — этак на час, и совсем редко гремит так, что в СМИ можно попасть, если вы крупная компания. Сбои неодинаковые, ведут себя по-разному, имеют витиеватые корни и различные последствия.

Они способны рассказать многое:
* про культуру разработки и тренды развития или стагнации инженерии;
* про качество продукта и рядом стоящие показатели доступности, SLO и SLA;
* про развитость процессов внутри тех. депа;
* и еще многое веселое, что покажу в докладе.
Собирать такие данные руками весьма накладно и, главное, медленно, но автоматизировать — это реально.

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

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

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

В своём докладе я расскажу о том, как мы спроектировали, разработали и запустили в эксплуатацию root cause detector. Этот доклад будет полезен для тех, кто хочет начать применять практику root cause-анализа у себя в компании с целью уменьшения времени жизни инцидентов.

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

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

1. Все самые крутые, интересные и разрушительные аварии сервисов устраивают сетевики.
Рассказ про парочку интересных факапов.

2. Резервируй ЭТО.
Что вы тут нам голову морочите? Всё уже давно придумали: стекируй компоненты сети — и будет тебе счастье!

3. Резервируй ЭТО v.2.0.
Стекировать — это хорошо. Но вы всё ещё верите в ISSU?
Ну тогда я пошёл за чем-нибудь вкусным и буду смотреть, как вы без прерывания связности сервисов мажорное обновление софта сделаете.
Разноси control plane! Делай MLAG! И будет хорошо!

4. Балансируй ЭТО.
Хочешь, чтобы тебя ругала половина компании?
Засунь побольше трафика в:
* один линк;
* один роутер;
* один ЦОД.
Нет… мы так делать не будем 😊

5. Считай, прогнозируй, предсказывай ЭТО.
Считаем, предсказываем и умощняем заранее.

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

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

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

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

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

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

Чаще всего дежурства on-call / pagerduty-форматов делают в дополнение к рабочим часам. Это негуманно и не очень оптимально:
* люди выгорают,
* люди ошибаются,
* люди воспринимают это как burden.

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

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

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

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

В 2017 году Alexis Richardson — CEO and co-founder широко известной в DevOps-среде компании Weaveworks представил GitOps — паттерн реализации непрерывной доставки. С тех пор специалисты компании усиленно продвигают этот подход и поддерживают вокруг него некоторый хайп (вплоть до того, что классический CIOps был ими заклеймён антипаттерном).

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

AWS задаёт стандарты на рынке облачных технологий. Но и в России облака развиваются, а курс доллара и законодательство делает их ещё более востребованными. Однако многие архитектурные решения и DevOps-практики слишком сильно различаются на российском и американском рынках cloud-провайдеров.

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

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

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

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

В докладе будет описана работа текущего процесса инцидент-менеджмента и автоматики вокруг него. Для мониторинга наших сервисов мы используем схему Prometheus + Alertmanager + Pagerduty, постмортемы с недавнего времени храним в Notion, а сам процесс инцидент-менеджмента автоматизирован при помощи Slack-бота.

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

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

Нагрузочное тестирование — это долго и дорого и это проблема. Почему так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Highlight — небольшое видео, показывающее наиболее яркие моменты из фильма. Мы научились создавать highlight'ы автоматически, используя модели computer vision и наш pipeline подготовки видео к стримингу. О том, каким образом это получается, я расскажу в своем докладе.

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

Уже довольно давно мы подозревали, что контент, имеющий трейлеры и highlight’ы, начинают смотреть намного охотнее, но вот незадача — только у 30% единиц контента есть нормальные трейлеры, а коротких highlight’ов нет почти совсем. Перед тем, как ринуться с головой в массовую генерацию новых видеофайлов, мы провели полноценный А/B-тест, который доказал существенно лучшую конверсию в просмотр у контента с дополнительными материалами. Задача была следующая: создать механизм генерации highlight’ов для 80 000 единиц контента, причем нескольких типов с разной длительностью.

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

Логов много не бывает, а если бывает?!

История о том, как мы внедряли новую систему логирования на основе EFK (Elasticsearch-Fluetnd-Kibana) и как страдали, когда Fluentd перестал держать нагрузку в терабайты логов в сутки.

Неудачные попытки перейти на Fluentbit и великий успех перехода на Vector.

Этапы внедрения Vector в инфру и разработку, а также удачное имплементирование его в кубер.

Непрерывность доступа в Интернет — что легко сделать на одной сети, то на 2000 сетей не взлетает.

* Почему нужно резервировать выход в Интернет.
* Что, как и зачем. Обзор технологий резервирования.
* Защита от неправильных действий клиентов.
* Как сделать active-active-решение.
* Как сделать аналогичное решение для IPv6.
* Масштабирование решения.
* Вопросы interoperability.

* Как выглядит жизненный цикл посылки от заказа в интернет-магазине до доставки в почтовое отделение;
* Что такое автоматизированная сортировка и зачем она нужна;
* Как мы управляем сортировочным оборудованием;
* Как мы взаимодействуем с Федеральной Таможенной Службой;
* Какие информационные системы за этим стоят.

Доклад про уязвимости и про DoS. Казалось бы, какая связь? (D)DoS-атаки зачастую считаются "тупыми", чего в них интересного? Действительно, многие злодеи ничего в них не понимают и лишь запускают стандартные варианты атак.
Но...

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

Расскажу про интересные прикладные и канальные атаки из практики DDoS-тестирования разных сервисов (ритейл, соц. сети, банки и т.д.).

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

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

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

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

Мы пойдем по другому пути — посмотрим:
* на процесс деплоя и шаги, которые можно обеспечить на его этапе; конечно же, поговорим о том, как gitops поможет сделать инфраструктуру безопаснее;
* на инструменты обеспечения безопасности в кластере Kubernetes — сравним их друг с другом и дадим ссылку на результаты, которыми можно воспользоваться в будущем;
* как интегрировать все инструменты в SIEM-систему — тут же рассмотрим проблематику, как делать это в multi-cluster-среде, и покажем, как решаем их с помощью Python, s3 и ElasticSearch. Также я расскажу, куда мы для этого законтрибьютили и что планируем делать дальше.


В итоге вы получите:
* чек-лист по обеспечению безопасности k8s;
* матрицу сравнения инструментов обеспечения безопасности кубернетиса;
* terraform-плейбук для интеграции событий разных инструментов обеспечения безопасности в единое хранилище на базе Elastic.

Я расскажу, как используя гетерогенные источники данных внутри AliExpress Россия, мы построили платформу на базе семейства продуктов Apache (Hadoop, Hive, Flink, Kafka, HBase и т.д.), позволяющую отсылать персонализированные уведомления пользователям.

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

* Архитектура SberCloud MLSpace и его использование на суперкомпьютере Cristofari.
* Решение инженерных задач MLOps в среде SberCloud MLSpace.

В докладе я расскажу, как мы в МТС собрали инструмент для потоковой обработки 10 миллионов событий в секунду, используя Scala(Java), Apache Spark Streaming и PostgreSQL. Почему выбрали Apache Spark Streaming, какие были проблемы на разных этапах разработки. Дам проверенные в бою рекомендации в части тюнинга Spark (concurrentJobs, speculation, memoryOverhead, memory, executors, cores и т.п.). Покажу, как мы подружили этот инструмент с Prometheus, Grafana, ELK, Kibana, и какие характеристики у железа, на котором это все работает.

Изначально наши пулы строились набором python-скриптов, запускаемых по cron'у. Когда число таких скриптов перевалило за 100, ситуация вышла из-под контроля. Починка прода стала занимать всё рабочее время, а любая выкатка стала подвигом. Мы решили переписать систему, чтоб исправить это, и теперь поделимся опытом.

Мы расскажем:
* как организуем разработку новых MR-задач, чтобы не тратить много сил на ревью;
* как тестируем новые задачи, чтобы (почти) не бояться выкатывать их в production;
* как выстраиваем дежурство, чтобы не чинить пайплайны все рабочее время.

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

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

Основная идея в том, что нужно не рассматривать фичу поклиентно, а представить распределение переменной за каждый временной срез через описательные статистики. Из-за неоднородности этих описательных статистик и других причин мы выбрали ML-метод Isolation Forest в качестве core для самого алгоритма ранжирования аномальностей — в докладе мы поговорим о преимуществах и ограничениях данного метода в качестве core-алгоритма.

Обсудим также, почему Isolation Forest не работает просто на статистиках и зачем требуется дополнительная ранжирующая функция аномальности и алгоритм интерпретации результата.

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

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

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

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

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

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

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

Client As Service — это проект, который помогает подготовить миллионы пользователей к экспериментам. Проект, который использует статистику покупателей, чтобы найти бизнес-инсайды и помогает составить ответ на каждый запрос.

Теперь любой запрос «необходимы покупатели из оттока, которые имеют домашних животных», имеет свой ответ «10 лояльных клиентов, которые ушли в отток и имеют домашних животных, перестали покупать из-за вероятных причин: нет необходимой категории продукта / выведен из продажи товар. С помощью … вы сможете сделать эксперимент по возврату покупателей». Над предложенным количеством можно начинать маркетинговый эксперимент и получить оценку по результату.

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

EdTech является сравнительно молодой областью, в которую внедряются Data Driven-подходы, что даёт несколько больше свободы для экспериментирования с техническим стеком. В нашем случае LMS (система управления обучением) развивалась децентрализовано с большим количеством сервисов-сателлитов (каждый со своим стеком), что приводило к тому, что аналитикам в первом приближении необходимо было выгружать данные из 3-5 источников и сводить потом данные на локальной машине, хотя всё можно было делать в рамках одного SQL-запроса.

Как мы с этим справились и причём здесь нарвалы — расскажу в рамках этого доклада, а также поговорим:
* как и почему мы выбрали именно Prefect как основной шедулер ETL, а не “классический” Airflow?
* как с помощью DBT стимулировать аналитиков писать документацию к разным уровням преобразования данных?
* что нужно сделать, чтобы подружить DWH-движок Dremio с Prefect’ом и DBT?

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

Именно с такими задачами мы столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и наши решения:
* для взаимодействия между обучением моделей на python и инференсом на java;
* для оптимизации архитектурных решений на java для сложных моделей;
* поведенческие признаки в production;
* а также java и mmap, сериализация и обмен данными между python и java.

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

* Поговорим о том, что такое антифрод.
* Посмотрим на структуру и объемы данных (спойлер: их там очень много).
* Выберем инструменты для решения этой задачи: Hadoop, Spark, Airflow и т.д.
* Заглянем внутрь алгоритмики (да-да, DS там пока нет) и оптимизации вычислительных ресурсов.
* Разберём «на пальцах» реальные гипотезы: от бизнес-потребности до визуализации результата.

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

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

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

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

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

Доклад посвящен продуктам, разработанным в SberData, для прозрачного федеративного доступа пользователей к данным в экосистеме Apache Hadoop. Обсудим основные принципы работы компонентов Apache Hadoop: HDFS, Hive и Sentry/Ranger. Расскажу про особенности проксирования данных, метаданных и привилегий.

Будут затронуты основные проблемы разработки и проектирования распределенных систем, расскажу, на какие проблемы стоит обратить внимание, об аспектах безопасности и нюансах использования Kerberos. Обсудим форматы хранения данных в HDFS, в частности, формат Apache Parquet.

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

В финале обсудим нюансы эксплуатации ПО подобного класса: проведение нагрузочного тестирования, взаимодействие со смежными системами, мониторинг, настройка health check'ов, управление конфигурацией и развертыванием.

Яндекс в 2021 году запустил три HPC/GPU-кластера для машинного обучения, которые стали самыми мощными суперкомпьютерами в России. Мой рассказ будет о том, с какими сложностями и неожиданностями мы столкнулись на этом пути.

Из этого доклада вы узнаете:
* о революции трансформеров;
* о том, что такое современный HPC/GPU-кластер, зачем коммерческим компаниям понадобились суперкомпьютеры;
* на каком стеке технологий они строятся и почему;
* почему HPC — это сложно, а традиционные подходы часто не работают;
* как вообще устроен процесс попадания в топ-500, и как, оптимизируя производительность для попадания в рейтинг, мы нашли проблемы, решив которые, мы ускорили наше машинное обучение.

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

Сравним особенности сервинга WaveNet и других вокодеров и обсудим целесообразность нашего подхода.

Три года назад перед нашей командой поставили цель: все видеокамеры в нефтехимическом холдинге СИБУР должны выводиться на экран операторам только тогда, когда в зоне их видимости "что-то идёт не так". За это время мы не раз посетили заводы, изучили производственные процессы, разработали и внедрили систему, которая покрыла 70% камер.

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

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

Примерный план доклада:
* высокоуровневое описание модели, для чего она нужна и как она работает;
* зачем мы разделили полноценный рекомендательный трансформер с early fusion-подходом на независимые части;
* какие сложности возникают в обеспечении консистентных данных в рантайме и в обучении;
* почему вашу рекомендательную модель нужно регулярно дообучать;
* почему батчевание GPU-вычислений критически важно;
* как разделение СPU- и GPU-частей модели может помочь выиграть еще несколько тысяч RPS на GPU.

Главная проблема красивых нейросетевых подходов в рекомендациях — их только показывают.

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

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

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

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

Для этого постоянно приходится решать различные NLP-задачи. Мы адаптируем и обучаем большие языковые модели на базе трансформеров (BERT, GPT), которыми делимся с сообществом в open source:
https://habr.com/ru/company/sberbank/blog/524522/
https://habr.com/ru/company/sberdevices/blog/547568/

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

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

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

Разберем на примерах, какие свойства "классической enterprise-разработки" машинное обучение уже адаптировало, а чего до сих пор не хватает и каким будет ML 2.0

В докладе рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенной для хранения информации во время работы ТКС.

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

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

Спойлер: это многотредовый монолит на C, без виртуализации, но с Redis, protobuf и кэшированием внутри приложения. И это работает, и не падает (почти).

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

В МТС более 5000 точек продаж. "Ручной" подсчет количества посетителей и сбор другой аналитический информации в режиме реального времени и в таком масштабе не представляется возможным.

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

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

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

История о том, как мы воевали с инцидентами под растущей нагрузкой и какие выводы сделали. Действующие лица: высоконагруженная система из монолита и микросервисов, кластер posgtres, кластер kubernetes, несколько команд разработки и тестирования, менеджеры в ассортименте.

Это рассказ об оптимизации работы с большим объемом данных, о том, как найти, какое именно обращение к памяти вызывает задержки и как взаимодействуют ядра в разных поколениях серверных процессоров Intel с примерами кода из нашей библиотеки для работы с разделяемыми key-value-наборами данных.

* Оpen-source kv-хранилище rc-singularity, что это и для чего;
* поиск кэш-промахов с помощью perf, как понять, где они возникают;
* какие бывают инструкции предвыборки, когда их использование оправдано;
* иерархия кэшей и ее влияние на многопоточные приложения.

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

Расскажем, как c помощью этого инструмента мы сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.

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

Расскажу, как мы в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).

* Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
* В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
* Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
* Чего в итоге получилось.
* Где ещё есть известные диоды, которые уже так просто не залечить.
* Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).

DeFi — быстрорастущий рынок, приманивающий своими высокодоходными ставками. Любой высокий доход сопровождается и высоким риском. В докладе я рассмотрю контролируемые (минимизируемые) риски. Из $100B+, вложенных в DeFi, более $14B подверглось атакам и хищениям. При этом речь идет только про публично известные случаи. По нашей оценке, непубличные хищения могут увеличить общий размер утрат на 50%.

- Контролируемые риски со стороны создателя и мейнтейнера проекта, их цена, объем потерь:
-- Misuse of Third-Party Protocols and Business Logic Errors.
-- Coding Mistakes.
-- Flash Loans, Price Manipulation, Miner attack.
-- Некомпетентность разработчика.
- Практический разбор векторов атак ($5B+ потерянных средств):
-- Flash loan, block mining attack.
-- RFI в masterchief.
-- Flash Loan.
-- Изменение кода популярных библиотек OpenZeppelin (SafeMoon $2B+ эксплойт).

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

Хранилище данных в Тинькофф существует уже 14 лет и за это время мы накопили гигантский объем данных: 2 петабайта данных, ±120 000 таблиц, ±30 000 отчетов и еще много чего. А теперь представьте себя на месте любого из 3000+ людей, которые ежедневно ищут в этом море данных нужную им информацию! Традиционно мы решали проблему с помощью ручного ведения документации в Confluence, но с ростом объема данных этот подход становился все менее и менее эффективным. Проблема встала ребром, мы поняли, что пришло время что-то менять, и решили внедрять у себя Data Catalog.

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

Что мы понимаем под Индустрией 4.0 в СИБУРе, где в ней свой написанный код, особенности разработки и внедрения интеллектуальных решений на заводах.

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

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

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

Фокус доклада — ускорение на стыке backend/mobile для крупного и уже оптимизированного продукта. Мы не будем обсуждать базовые вещи: кэширование и оптимальный код. Примеры того, что мы затронем:
* deadline propagation и hedged requests;
* может ли префетч в приложении замедлять;
* какой RTT на 2G и в Африке;
* цена фонового запроса и паттерн API Gateway;
* как продать бизнесу ускорение.

Доклад построен на реальном опыте ускорения Яндекс Go.

Простое выражение 1С + С++03 == С++14/17 только выглядит просто. Когда перед командой стоит задача перевести сложный, многокомпонентный фреймворк для создания бизнес-приложений на новый стандарт С++14, а далее — С++17, когда перед тобой больше 10 млн строк кода на С++ — просто это быть не может по определению. А когда в описании задачи стоит ключевое требование «не потерять в производительности» — задача становится только сложнее.

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

В своем докладе я хочу рассказать, как мы используем msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.

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

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

Однако самым интересным, на мой взгляд, является реализованный используемый нами подход для работы с msgpack в С++. С самого начала стояли цели удобства и максимизации производительности упаковки/распаковки msgpack, что заставило нас сделать много интересных вещей, например, compile-time-упаковку, и state-machine-распаковку данных. Все это сделано при помощи настоящей забористой шаблонной магии, что должно обязательно порадовать настоящих любителей C++.

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

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

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

Проводим лайвкодинг-демонстрацию нескольких скриптов в отладчике, в частности:
* поиск исключений, произошедших в потоке ранее (Win);
* вывод стеков 32-битного приложения для 64-битного kernel-mode дампа (Win);
* поиск потребителей большого количества памяти:
- анализ с AppVerifier'ом
- анализ без AppVerifier'а (GDB)
* что делать, если упали в boost::coroutine (GDB).

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

В этом докладе мы посмотрим, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Мы также копнем в специфичные для x86-64 оптимизации. Обсудим микробенчмарки.

* Как x86-64 исполняет код и как работает с памятью.
* Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
* Когда ассемблер x86-64 не только быстрее, но и проще C.
* Скользкие места программирования для многоядерных архитектур
* Защита от Spectre в компиляторах.
* Profiler guided optimization (PGO) и когда она бесполезна.

Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).

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

Мы ВКонтакте конвертируем PHP в С++ (у нас свой компилятор — KPHP). А потом огромную кучу плюсовых файлов нужно прогнать через g++. Их очень много, и локально это чересчур долго. Нужно что-то придумывать.

Расскажу, как мы пользовались distcc, патчили его для поддержки precompiled headers, а сейчас написали ему замену — и выкладываем её в Open Source.

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

План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.

С чьей позиции доклад?
Я руковожу подразделением, которое отвечает за обучение администраторов в рамках импортозамещения в самом большом с точки зрения персонала дивизионе ГК Росатом.
1. Почему Astra Linux?
Переход Росатома на Astra Linux вызывает множество логических вопросов. Windows принадлежит частной зарубежной компании. Astra Linux делает частная российская компания. Это нормально, что крупная отрасль полагается на продукт частной компании?
2. Как шло импортозамещение?
Росатом достаточно сложно устроен. Придется немного рассказать о том, где находится моя точка наблюдения (это самый крупный с точки зрения людей дивизион).
В первую очередь стояла задача перевода рабочих мест обычных пользователей. С одной стороны, это проще (нет жестоких требований к аптайму, софт может быть не самый стабильный), с другой стороны, это адски сложнее (пользователей надо учить, проблемы софта жестоко демотивируют).
Именно наша организация отвечала за обучение администраторов из отраслевых интеграторов.
3. Где были стратегические просчеты?
Большой и главный просчет — легкомысленное отношение к переходу. Еще одна проблема — попытка использовать тонкого клиента вместо полноценного перевода физической машины под Astra Linux. Глобальный просчет в уровнях компетенций.
4. Какой софт оказался «якорем» и не дал перейти?
Несмотря на все усилия, ряд приложений перевести невозможно, они только под Windows. 100% импортозамещения рабочих мест пока недостижимо.
Проблемы с офисным пакетом, проблемы даже с почтовым клиентом (а что, сервера все еще на Exchange, да), короче, ассортимент сложностей прилагается.
5. Что в итоге?
Спецоперация попала на 2022 год, когда планировалось достичь желаемых 100% в ряде дочерних организаций. Сейчас очевидно, что уже достигнутое надо пересматривать, быстро верстать план на 2022 год, и будет много сложностей. Риск иностранного влияния из умозрительного стал экзистенциальным.

1. На российском рынке первые в зоне риска — web-приложения. Самое актуальное средство защиты сейчас — это решения класса WAF (Web Application Firewall).
2. Что нужно, чтобы разработать WAF? Как он устроен и почему его сложно создать? Речь пойдет об архитектуре, технических сложностях и вызовах.
3. Прогнозы: как будет развиваться рынок WAF? Сможет ли Россия предоставить достойную замену иностранным вендорам? (Спойлер: да).

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

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

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

* Аналоги облачных сервисов в РФ, про миграцию в российское облако.
* Опыт переезда нашего заказчика.
* Технический практический доклад.

Инновационная технологическая платформа 1С:Предприятие — сочетание комплекса инструментов и технологий (fullstack-platform), позволяющего создавать высоконагруженные кроссплатформенные бизнес-решения различной сложности, и концепции low-code, позволяющей вести быструю разработку. Платформу 1С используют для создания и кастомизации бизнес-приложений более 300 тысяч IT-специалистов. Более 1 300 решений на базе платформы 1С:Предприятие (ERP, CPM, MES, CRM, WMS, BPM, ECM и др.) применяют свыше 1,5 миллиона организаций от малого бизнеса до крупнейших корпораций и госструктур.

Чем заменить F5, Citrix, KEMP и других зарубежных производителей балансировщиков? Расскажем о российских продуктах и отдельно — о программном NFWare Load Balancer, который сегодня используется в VK на скоростях до 40М CPS на стандартных x86-серверах. Возможности продукта, как он устроен изнутри, производительность и use-кейсы, с которыми NFWare может помочь российским компаниям сегодня.

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

Можно ли отключить Россию от Интернета? Выключить нам DNS? Спасёт ли нас "суверенный интернет", и как решить вопрос с поставками оборудования и запчастей?
Обо всём этом и поговорим.

Steer the course! (рус. «Правим по курсу!») — это новый девиз ИТ-команды «Магнита», взятый из морской терминологии. Именно под этим лозунгом мы сегодня корректируем стратегическое направление в условиях максимального уровня технологического давления.

Что означает этот призыв? Всё просто: облачные технологии — один из пяти основных принципов и фокусов цифровой трансформации компании. Зарекомендовавшие себя зарубежные cloud-решения обеспечивали масштабные кампании по цифровизации, предоставляя скорость, эффективность и гибкость разработки. До недавнего времени перечисленный список преимуществ облачных решений западных партнёров включал ещё один пункт — надёжность. Времена изменились, но значит ли это, что компании нужно кардинально менять стратегию и отказываться от фундаментальных принципов? Нет! «Магнит» правит по курсу, то есть продолжает работать, осознано и планомерно изменяет приоритеты, как того требует ситуация.

В своём докладе CTO «Магнита» Юрий Мисник расскажет, в каком направлении теперь смотрит его команда, какие решения и альтернативы уже удалось найти и почему точно не стоит паниковать.

Яндекс — технологическая компания, в которой на начало 2022 года работало 18000 человек. 24 февраля, когда у всех на носу performance review, работа кипит, мы оказались в совершенно новой реальности. Чтобы справиться с небывалым количеством угроз со всех сторон потребовалось моментально перегруппироваться. Самоорганизовались антикризисные штабы по компетенциям и направлениям, нашлись добровольцы, готовые помогать невзирая на праздники, дни недели и время суток, экстренно пересмотрели приоритеты всех работ, перенаправили все силы на самые критичные проекты. Как раз о том, как мы справились с кризисом, и пойдёт речь.

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

1. Технологическая экосистема — это сложнее, чем просто железки и софт. Чтобы понять, что с ней может случиться, нужно понять, как она работает. Для этого есть модель.
2. Хорошая модель позволяет делать прогнозы. С конца февраля к моменту написания тезисов прошел месяц, за это время большинство опасений, предсказанных моделью, реализовалось. В мае мы посмотрим на обновленный прогноз и сравним его с реальностью.
3. Четыре главных стратегии: вторая жизнь старых игрушек, глобальный план Ц, антиграница и отказ от замещения.

Несмотря на развитие «спецоперации», Россию так и не отключили от Интернета. И далеко не все компании рвутся отключать россиян и белорусов от своих ИТ-сервисов, некоторые делают бесплатными или добавляют что-то в бесплатные тарифные планы, или делают бесплатным для жителей России и Украины.

Почему так? Что за механизмы задействованы, как они возникли, что будет в будущем.

Есть ли такие механизмы в России? Почему нет? Что вместо них? Сможем ли мы их построить?
Как принципы, выработанные сообществами вокруг Интернета и ИТ «на западе» обеспечивают стабильность работы Интернета. Сможем ли мы по таким принципам работать в России?

Есть ли у нас будущее?

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

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

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

Бизнес РБК — рассказывать новости, и, по меркам конференции, десяток серверов и 300 RPS не доставляют хлопот. Не доставляли, пока полтора месяца назад я не увидела в кибане нарастающий вал пятисоток.

Мой доклад — история о том, как мы "по-живому" адаптировали сервис к многократно возросшим новостным нагрузкам. Что отключили сразу же, что переделывали на ходу, как за несколько дней мигрировали из стойки дата-центра в облака и другие зарисовки моего антикризисного штаба. За годы стабильной работы мы накопили приличный "зоопарк" технологий: Python, PHP, Go, Java, фронтенд и даже Hadoop. Спасение зверушек получилось сложным, но небезынтересным. Подробности — в докладе.

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

Яркими примерами уязвимостей последних лет были уязвимости log4shell, spring4shell и иные. К уязвимым компонентам также безусловно относятся и protestware, ярким примером которого является пакет node-ipc. К этому добавляются атаки на Software Supply Chain Management, такие как Dependency Confusion и Typosquatting. Кроме того, :surprise:, не обходится и без человеческого фактора.

В докладе раскрывается роль композиционного анализа ПО (Software Composition Analysis, SCA) в практиках безопасной разработки с примерами проблем и их решениями.

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

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

* Есть ли достойные бесплатные DAST-решения, как можно писать собственные правила для поиска специфичных уязвимостей в динамике?
* Сканеры безопасности docker-образов: уменьшаем поверхность атаки в несколько шагов.

1. В начале ответим на вопросы: что такое современное ИТ и из чего оно состоит.
2. Небольшая аналитика инфраструктурных решений и их смыслов (базы данных, SaaS, Proxy, AGW, операционные системы), которая требуется для работы ИТ.
3. Старая парадигма в разработки ИТ и ее сравнения с тем, как развиваются технологии в Китае. Также расскажу о небольшом опыте работы с израильским подходом.
4. Выводы в форме аналитики:
4.1. С чем нам всем предстоит столкнуться, как с этим работать и на что стоит обратить внимание.
4.2. Как это может затронуть текущую структуру управления ИТ-команд.

1. Новая реальность: какие IT-тренды существуют на HR-рынке.
2. Почему оказалось необходимым введение новых мер поддержки IT-отрасли.
3. Какие новые меры поддержки появились? Какие цели у государства и рабочей группы.
4. Какие главные угрозы видит государство и какие главные способы поддержки выделяет (что в принятых законах основное, а что второстепенное).

Карта компетенций. Будем разбираться, что должен уметь junior, middle, senior разработчик.

1. Почему возникла такая идея? (Проблематика)
1.1 Оценка кандидатов на входе в компанию. Унифицированная система проведения интервью. Свод скилов, на который могут ориентироваться интервьюеры.
1.2 Планирование роад-мапов для профессионального развития каждого сотрудника.
1.3 Распределение задач внутри команды, в соответствии с картой компетенций.
2. Какие преимущества дает карта.
3. Как мы это реализовали?
3.1 Работа по сбору фактуры для карты компетенций. Основывались на «Модели Дрейфуса», «Этапах Мейлер Пейдж Джонс», основах для понимания уровня разработчиков и др.
3.2 Собрали форму из нескольких seniors and team leads крупных российских компаний, на которой выявили скилы, соответствующие уровню специалистов.
4. Что у нас получилось?
4.1 Сама карта.
4.2 Аргументы.
5. Как мы это используем? (Исходя из проблематики)
5.1 Мы подгоняем процесс интервью.
5.2 Разрабатываем индивидуальные роад-мапы.
5.3 Распределяем задачи в соответствии с компетенциями сотрудников.

uber.fx — это не только DI-контейнер, но и библиотека управления жизненным циклом приложения и его компонентов.

Запуск/остановка приложения, остановка по требованию, graceful shutdown vs аварийная установка.
* Бест-практисы и как не класть приложение в тихую
Компоненты приложения и управление их запуском и остановкой.
* Паттерн Start Stop в формате fx.
* Аварийная установка отдельного компонента.
Стейджи запуска приложения.
* Логирование стейджей и проблем.
DI-контейнер — расстановка зависимостей, бест-практисы.
* (доп. тема) Аннотации, именованные инстансы.
Тестирование целостности DI-контейнера.
* (доп. тема) Модули — группы компонентов.

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

В докладе рассматриваются:
1. Использование технологий компании HashiCorp: Nomad, Consul, Vault.
2. Деление production && staging окружения. "Отбор" staging в случае аварий, автоматически перераспределяя нагрузку.
3. Почему nomad, а не k8s.
4. Чек-лист, который мы составили для себя при разработке graceful degradation для сервиса.

Много раз при обсуждении преимуществ и прелестей Go как языка разработки мне приходилось слышать что-то типа «у вас ДАЖЕ нет дженериков» или «вот завезут дженерики, тогда и поговорим». Так вот, дженерики завезли, попробовать можно уже сейчас, а доступно для всех будет с релиза 1.18 (намечен на февраль 2022). Сообщество окончательно определилось, как именно всё будет реализовано и что мы получим в результате.

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

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

* Что не стоит брать в проект.
* Saga — быстрое внедрение. Один из способов реализации в микросервисной архитектуре.
* DDD — о чем молчат. Я был идеологом, возможно, я ошибался.
* Дженерики, когда они так нужны.
* Мониторинг.
* Как мы переписали микросервисы и сделали стандарт внутри компании.

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

В своём докладе я расскажу, как организована наша кодовая база из 1M+ строк на Go, как мы используем и как не используем фичи Go, как добиваемся масштабируемой архитектуры на уровне кода и как проектируем API в проекте, где новые А/B-тесты запускаются каждый день.

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

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

В докладе расскажу:
- почему мы используем Golang;
- какие Golang ML-библиотеки и для чего используем;
- как мы дружили Python-модели ML c backend, написанном на Golang;
- про наше решение хранения моделей машинного обучения;
- покажу подробный путь модели от jupyter playbook до procduction.

Команда платформы каждый день трудится над тем, чтобы у всех инженеров были правильные “приборы”, они понимали, что их системы работают как надо, и быстро реагировали на проблемы. За последние несколько лет мы накопили большой опыт, а также успели набить много шишек при использовании gRPC в Go.

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

Что делать, когда вам нужно отвечать настолько быстро, что позволить себе ~1-3 ms для похода в Redis за кэшем — это очень дорого? Можно же хранить кэш прямо в памяти приложения. Но тогда встают вопросы:
* Память кончается, надо что-то выбросить из кэша! Но что именно?
* Как обновлять значения в кэше так, чтобы не завалить внешние ресурсы большой нагрузкой (предотвратить эффект Cache Stampede)?
* Если приложение распределенное, и нам подобный кэш надо держать согласованным, то каким образом это сделать (согласованность кэшей)?

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

Это обзорный доклад о том, как происходит встраивание (inlining) функций в Go. Из него вы узнаете:
* зачем, вообще, встраивание нужно, какие преимущества и недостатки несет в себе;
* как Go встраивает функции, и как эта стратегия менялась со временем;
* какие есть ограничения и как некоторые из них можно обойти.

Интересно ли вам, как именно в Go реализованы анонимные функции? А замыкание параметров? Как реализуется логика defer, и почему раньше он был медленнее, чем в актуальных версиях языка? Как map работает с любыми типами без generics?

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

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

* Как отличить хороший CPU профиль от плохого;
* какова структура profile.proto-файлов и как их парсить;
* как раскрасить горячие строки кода в редакторе;
* что такое структурный поиск кода по горячим местам;
* статический анализ производительности на основе профилей исполнения;
* несколько полезных рецептов для pprof;
* альтернативные способы агрегации без pprof.

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

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

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

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

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

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

Доклад будет разбит на три части (две большие и одна не очень):
1) теоретическая часть (hash, hashmap, виды адресации);
2) изучение исходников и небольшое сравнение с другими языками;
3) sync.Map и немножко "горячих обсуждений".