Доклады

Обсудим зачем в Go добавили новый и весьма нетривиальный функционал - итераторы, также называемый range over funcs.

Посмотрим на бенчмарки: быстрые ли итераторы? Быстрее каналов или медленее?

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

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

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

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

Продуктовая разработка API на бэкенде заполонила рынок. REST, gRPC, микросервисы.

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

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

Меня зовут Дмитрий Новиков, я TechLead в MTS Web Services, команда Development Platform. Мой опыт в сфере коммерческой разработки насчитывает около 20 лет, в течение которых я проработал 10 лет в Яндексе, 7 из них в Yandex Cloud. Также работал в компаниях Parallels и Exigen Services. В течение последних 15 лет я писал генераторы кода на C++ и Golang. Писал и поддерживал генераторы, которые производили тысячи файлов. Мой опыт разработки на Golang насчитывает около 10 лет.

Доклад посвящен генерации кода на языке Golang. Хотя акцент делается на Golang, представленные концепции и подходы будут полезны и применимы к разработке генераторов кода и на других языках.

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

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

Используя микросервисную архитектуру в больших системах, неизбежно приходится как-то решать проблемы с согласованностью. Есть разной степени удобства технологии (от REST до gRPC). К сожалению, у каждого подхода есть не только плюсы, но и существенные минусы. В своем докладе предлагаю вместе пройти путь от “наивных” до продвинутых решений и на конкретных примерах оценить удобство и масштабируемость разных вариантов. Поделюсь также опытом реверс-инжиниринга некоторых тулов и опытом написания собственной утилиты. После этого доклада вы сможете с открытыми глазами выбирать.

Чаще всего мы, как GO разработчики пишем всевозможные микросервисы. И уже давно все привыкли что управляет ими некий монстр под названием kubernetes. Он автоматически переподнимет наш упавший под, поможет скалировать сервис и многое другое. Ну а что кубер не делает автоматически, то по старинке делается ручками.
Однако сущесвтуют операторы, которые позволяют автоматизировать буквально что угодно.
Что же такое операторы в k8s и как вообще GO разработчику начать работать с кубом как с родным?

В рамках доклада мы:
* На пальцах и простых примерах рассмотрим непростую тему работы с kube-api.
* Научимся использовать полезные библиотеки.
* Узнаем как просто создавать свои операторы и из чего они состоят.
* Рассмотрим некоторые интересные решения для облегчения работы с кубом.

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

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

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

Что еще будет:
Как работает CGO под капотом.
К каким проблемам приводит долгий С вызов из Go.
Пути решения и пасхалки в исходниках Golang.
Делаем быстрый и блокирующий С вызов из Go.
Почему компилятор будет нам мешать.
Пример сервера и бенчмарки

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

Мы рассмотрим в докладе три основные стратегии работы с gRPC в WEB разработке: gRPC-Web, Buf Connect и gRPC-Gateway. Обсудим их ключевые преимущества и недостатки, а также проведем детальное сравнение производительности с помощью бенчмарков на базе k6. В завершение мы поделимся экспериментальными подходами для улучшения производительности gRPC-Gateway, включая использование кастомных маршаллеров и оптимизаций на уровне генератора.

Для обработки потока данных или событий до сих пор нам приходилось мириться с колбэками или каналами. При этом возникают проблемы с управлением потоком событий или отладкой. Начиная с go 1.23 стал доступен новый подход - объявление итератора и использование его в циклах for ... range. В своём докладе я покажу как мы применили итераторы в клиентской библиотеке для YDB и насколько это улучшает читаемость кода, а заодно проведу экскурс в мир итераторов.

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

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

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

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

Например, из доклада вы узнаете:
* почему и когда нужно шардировать работу с atomic значениями и даже с map
* к чему существуют такие алгоритмы как biased locking for reader writer locks
* что такое оптимистичное чтение и когда его можно использовать

А также разберем протокол MESI, барьеры памяти, кеш CPU и как вообще эффективно его использовать.ц

Разработчикам довольно часто хочется переписать легаси проект по красоте. Неизменно возникает вопрос: а "по красоте" - это как? Для ответа на этот вопрос прибегают к помощи широко известных подходов "Чистая Архитектура", "Гексагональная Архитектура" и "Предметно Ориентированное Проектирование(DDD)". Но так ли просто переписать проект следуя этим подходам на Go? Как язык может в этом помочь и как он может мешать? А возможно, Go не так уж хорош для реализации сервисов с чистой архитектурой и DDD, а Rust, несмотря на свою "низкоуровневую природу" наоборот подходит лучше? С этими вопросами мы постараемся разобраться на докладе с высоты нашего практического опыта рефакторинга сервиса на Go.

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

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

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

В мире распределённых систем эффективные структуры данных играют ключевую роль в обеспечении производительности и масштабируемости. В этом докладе мы погрузимся в реализации Bloom Filter, CRDT (Conflict-free Replicated Data Types) и Consistent Hashing на Go. Разберёмся, как они работают, какие задачи решают и как применяются в продакшн-коде на Go, включая такие проекты, как etcd.

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

Что получат слушатели:
1. Понимание принципов работы Bloom Filter, CRDT и Consistent Hashing.
2. Знание о реализациях этих структур данных на Go.
3. Примеры использования в реальных проектах.
4. Практические советы по внедрению и оптимизации в своих приложениях на Go.

Конкурентность в Go открывает широкие возможности, но также и представляет риск «выстрелить себе в ногу» — от обращения горутин к одним и тем же данным до проблем с work-stealing. В этом докладе мы рассмотрим, как дополнить и расширить идеи из выступления Роба Пайка по конкурентности в Go.

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

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

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

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

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

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

В докладе мы подробно разбираем работу шедулинга горутин и устройство моста между Go и С/С++. Слушатели узнают, как мы отслеживаем аллокации памяти и сопрягаем данные между языками. Выступление будет одинаково интересно тем, кто активно использует текущую реализацию CGo, и тем, кто только планирует это делать. Также доклад может быть полезен для лучшего понимания рантайма Go.

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

Я расскажу:

• Как реализовать классические принципы ООП (инкапсуляция, наследование, полиморфизм) с помощью structs, interfaces и других механизмов.

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

• Какие трудности возникают при применении ООП в Go и как мы их преодолеваем.

Какие проблемы возникали при балансировки сотен тысяч соединений по протоколу MQTT в облачном хостинге. Ограничения облачных ELB на количество одновременных соединений. Периодические разрывы соединений, приводящие к волне реконнектов устройств, которые создавали нагрузку сами на себя.

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

В докладе я расскажу про то, как построить архитектуру приложения на NoSQL, в чем сложности и преимущества от стандартного подхода. Redis стал не open source? Куда движется мир NoSQL решений и почему. Рассмотрим почему в Облако Mail мы работаем со связкой Go+Tarantool; поделюсь архитектурными решениями для работы. За время работы с legacy мы обкатали и запустили кучу кейсов, которые позволили нам выйти к стандартизированным решениям при построении высоконагруженных сервисов, повысили производительность и ускорили ТТМ.

В рамах доклада мы рассмотрим:
- Варианты построения архитектуры на разных NoSQL базах данных, сравним реализации и инструменты для работы с ними.
- Такой ли простой Lua? Почему концепция написания бизнес кода на Lua работает хуже для бизнеса, чем использование хранимых процедур только для выборки и вставки
- Рассмотрим на примере. Как присходит отладка Lua кода в Tarantool и сравним с экосистемой Go
- Какие инструменты мы сейчас активно внедряем и разрабатываем: почему использовать и отлаживать шардированный Tarantool из Go становится проще и производительнее

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

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

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

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

О чем поговорим:
* Что такое трейсинг, OpenTracing и OpenTelemetry
* Базовое устройство и виды межсервисного взаимодействия в gRPC
* Интерсепторы в gRPC как инструмент трейсинга
* Пайплайн обработки gRPC-запроса
* Stats handlers как альтернатива интерсепторам: принципиальные отличия и преимущества
* Готовые решения для трейсинга gRPC

В жизни почти каждой системы «с историей» случается момент, когда инфраструктура перестает отвечать стандартам отказоустойчивости. Так было и у нас — в нашем продукте 60+ баз со сложной бизнес-логикой в 100 тыс. строк. Большая часть была написана на версии Tarantool 1.5, в которой не предусмотрено авто-резервирование.

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

В докладе расскажу про возможности и преимущества открытой библиотеки etcd для подобных задач и как мы дорабатывали ее под себя: писали «обертку» над стандартными Get Put Remove и методы защиты от сплитбрейнов, а еще строили eventloop на базе Watch.
Этот практический доклад будет интересен всем, кто использует собственные DevOps-инструменты для решения нетривиальных задач, связанных с построением инфраструктуры в комплексных системах, и выбирает Go для их создания.

У нас было три монолита на PHP, по 180 минут на выкатку каждого, 30 минут на обновление наличия товара на сайте, полсервиса на Go и PHP, множество джоб всех сортов и расцветок, а также Docker, Cobra, целая куча репозиториев в GitLab, пинта чистого Kubernetes и Terraform. Не то чтобы это был необходимый арсенал для разработки, но если начинаешь собирать удобный деплой, становится трудно остановиться. Единственное, что вызывало опасение, — это сервисная архитектура. Нет никого более беспомощного, безответственного и испорченного, чем разработчики и архитекторы, пытающиеся определить границы предметных областей и не создать новый монолит при распиле старого. Но мы знали, что рано или поздно окунемся и в это.

- Что такое «сага» и когда она полезна?
- Как можно организовать код саги на Go?
- Какие нюасны есть в работе с сагами?

- Что это - данные о товарах?
- Боли при обновлении миллиарда записей раз в 5 минут
- Какая архитектура обработки записей нам подойдет лучше всего?
- Чего не должно делать хранилище
- Что нужно от БД
- Как нам помогли дженерики в go
- Кода нет а ручки есть - чудеса делегирования
- Как мы загрузили железо по полной
- Что получилось в итоге

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

В докладе будут рассмотрены ключевые аспекты авторизации и причины платформизации этого решения. Мы обсудим, зачем нужна авторизация и какие преимущества даёт платформенный подход к управлению доступом. Уделим внимание сравнению двух моделей авторизации — RBAC (ролевая) и ABAC (атрибутивная), а также их применению в разных сценариях.

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

Построение архитектуры приложения, микросервисы на go, распил монолита, архитектурный комитет

В этом докладе расскажу
- Как понять, что текущая система перестает устраивать
- Как выбрать подходящие инструменты и научиться сравнивать их
- Как готовить приложения на Go и работать с профилировщиками нагрузки
- Как выглядит инфраструктура api-gateway за пределами приложения
- С какими проблемами можно столкнуться и как их обнаружить

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

Golang стал одним из первых языков, поддерживающих WASM, и в настоящее время занимает одно из ведущих мест среди языков с хорошей поддержкой этой технологии. В данном докладе мы сосредоточимся на внебраузерных применениях WASM, обсудим, как правильно подготавливать Go-приложения для запуска в WASM-рантайме, а также рассмотрим сложности, с которыми сталкиваются разработчики. Мы уделим внимание подводным камням, связанным с интеграцией Go с WASI (WebAssembly System Interface), и обсудим текущие вызовы, мешающие разработчикам компилятора Go поддерживать актуальные стандарты и расширять функциональность вне браузера.

Расскажем о задаче (CDN на Go).
* Почему на Go
* Кратко как оно работает
* упирались в Х -- решили так
* упирались в Х2 -- решили так

Уперлись в TLS -- стали терминировать hitch, но и в него уперлись.

Тут поговорим кратко как, чем и зачем его можно терминировать

Почему стандартный Go не справился и почему решили "править" его, а не уйти с Go вообще (но думали).

Собственно тут и буде говорить по гошный TLS и TLS вообще, как он работает, какие способы есть его "прокачать"

Как итог с "и 40gbps уже боль", мы отдаем 100 с достаточно старого железа

RTB (Real Time Bidding) -  это технология аукциона в реальном времени, которая используется в онлайн-маркетинге для покупки и продажи рекламного пространства.
Один из этапов - коллекционирование и обновление данных о категориях, к которым принадлежат те или иные сайты. В нашей системе такие данные заносятся в Snowflake, а эти изменения необходимо оперативно транслировать в Couchbase. В данном докладе расскажу как мы это делаем, почему нам понадобилось писать плагин для сервиса потоковой обработки данных Redpanda/Connect и что в итоге осталось на проде.

1. Введение
- Краткий обзор искусственного интеллекта и его применения в чатботах.
- Введение в GigaChat API и его ключевые особенности.
- Цель доклада: Разработка SDK для GigaChat API на Go и его сравнение с использованием ChatGPT.

2. Основы работы с GigaChat API
- Описание функциональности GigaChat API.
- Примеры запросов и ответов.

3. Сравнение с использованием ChatGPT
- Обзор возможностей и ограничений ChatGPT.
- Сравнение параметров производительности и качества ответов.
- Различия в интеграции с приложениями.

4. Практическое применение и примеры
- Пример использования SDK в приложениях.
- Демонстрация кода и живого взаимодействия с GigaChat API.

5. Заключение
- Основные выводы и итоги проведенного сравнения.
- Перспективы развития SDK и будущие планы.

6. Вопросы и ответы
- Открытая сессия для обсуждения с аудиторией.
- Дополнительные разъяснения и примеры по запросу.

В этом докладе мы обсудим создание нейронных сетей на языке Go с использованием библиотеки TensorFlow.
Наша цель - показать, что Go является универсальным и недооцененным инструментом для разработки нейронных сетей, превосходящим в некоторых аспектах Python.
Мы рассмотрим весь процесс создания нейронной сети по распознаванию объектов и разберемся, почему связка Go + TensorFlow эффективна.

Мы в Т-Банке активно используем Go в качестве языка для разработки ML приложений. Большое количество моделей приводит к усложнению архитектуры приложения. Расскажу про то как мы пришли к паттерну пайплайнов в наших приложениях и написали собственную библиотеку.

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

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

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

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

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

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

Расскажу про то, как ускорять код, используя абстрактный ассемблер Go, затрону SIMD инструкции и сравнение с cgo

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

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

В качестве программиста я не написала ни одной строчки кода на Go, но тысячи Go-разработчиков по всему миру используют мой продукт. Дизайнеры ‒ люди, от которых меньше всего ждут вклада в опенсорс, и зря! Моя любовь к доступным продуктам и продуктовый подход позволила создать уникальную и успешную историю. У маскота языка Go изначально отсутствовала мимика, был скудный набор сложных изолированных иллюстраций, неподходящие лицензии. Сейчас Free Gopher Pack есть в листе Awesome Go и широко используется в комьюнити.

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

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

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

Этот доклад будет посвящён интеграции продуктов Ory, таких как Hydra, Kratos, Keto и Oathkeeper, в приложения, написанные на Go. Мы рассмотрим, как можно легко использовать решения Ory для управления доступом и аутентификацией, используя Go, и как интегрировать их в существующие проекты. Особое внимание будет уделено настройке и взаимодействию с API продуктов Ory из Go-кода.

Функциональное программирование - хорошо!
Функциональное программирование в Go - есть!
Программы на Go с "фунциональной" начинкой - легко тестируемые, предсказуемые и масштабируемые!

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

В докладе я расскажу про один из самых нагруженных компонентов компонентов Авито.Автозагрузки - сервис отчетов. В цифрах это 40М входящих событий в минуту и 1М+ RPM в MongoDB. Я буду много говорить про архитектуру - расскажу из каких компонентов состоит сервис, как мы справляемся с такими объемами данных и работаем с MongoDB и Redis под нагрузкой.

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

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

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

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

Картинки - это часть поиска Яндекса, работающий с визуальным контентом и обрабатывающий более 10 000 тяжёлых запросов в секунду с помощью десятков тысяч CPU в рантайме. Мы расскажем, как столкнувшись с необходимостью масштабирования сервиса, с помощью ML в сочетании с архитектурными изменениями смогли не только увеличить пропускную способность в ~2 раза на том же железе, но и дать инструмент для более гибких продуктовых внедрений.

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

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

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

Избавимся от иллюзии: применяй Agile-подход, и будет успех. В 98% ит-проектов и ит-продуктов Agile - не нужен, это искусственное удорожание и усложнение процесса, которые эффективно закрываются линейными системами. Вместо модных фреймворков и поиска серебряной пули, сначала сделать 3 базовых шага:
1. разделить на сервисы с прозрачными зонами ответственности,
2. проверить, что они соответствуют реальным бизнес-процессам
3. эффективно организовать интеграции между ними.

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

Расскажу, как контент в KION попадает в рекомендации, на персональные витрины, как мы разрабатывали ТВ-витрину. А еще про самые интересные бизнес правила и как редакция помогает растить смотрение.

В KION есть элемент «блендер». Он формирует витрину, используя разные источники, применяет свыше 50 бизнес-правил, и все это — быстрее, чем за 300 мс для каждого запроса. При этом рекомендации и витрины формируются максимально релевантные пользователю. Например, просмотренный фильм больше не покажется на витрине. Или если пользователь несколько раз не реагирует на постер фильма, витрина предлагает ему другой, чтобы пользователь с большей вероятностью обратил внимание на тайтл. Все это строго персонально и очень быстро.

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

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

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

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

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

У вас никогда не вызывало недоумения, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, но одно — хорошо, а другое — почему-то плохо? 🙂Компоненты в большой сложной системе вложены друг в друга, и то, что являлось связанностью (скорее отрицательной характеристикой) на одном уровне — становится прочностью на следующем (т.к. становится внутренней связью компонента, а не внешней)!
Даже если взять микросервис, как единицу гранулярности — слоёв над ним может быть несколько:
- ограниченный контекст микросервисов внутри продукта/системы
- продукт/система
- ландшафт предприятия (enterprise архитектура).
А в больших продуктах и компаниях системы могут делиться на подсистемы или проекты, enterprise уровень разделяется на архитектуру домена и междоменный ландшафт, а ещё добавляется слой или слои платформизации…
Сложность систем и компаний растёт, а стандартный приём борьбы со сложностью — это увеличение слоёв абстракции. Таким образом компонентизация архитектуры — это нормальный процесс, где количество уровней ничем не ограничивается.
При таком раскладе уже недостаточно стандартного разделения на архитектуру и архитекторов решений и предприятия (solution и enterprise), либо наоборот — грань этого разделения стирается.

Логичным выводом будет переход от бинарного деления на связанность и прочность к цепочке зависимостей:
Микросервисы → Контексты микросервисов → Продукты → Архитектура предприятия

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

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

Технология WebAssembly (Wasm), вопреки распространенному мнению, с момента создания подразумевала возможность использования на бекенде. Помимо браузеров, Wasm активно используется для плагинов/расширений, в качестве полезной нагрузки в облаках/контейнерах, переносимых компонентов ПО, и даже смартконтрактов в блокчейне. Расскажу историю развития и важные для бекенд разработки особенности и преимущества технологии. Разберемся, почему Wasm сможет то, что не смогла Java, как он ведет себя под нагрузкой, и почему релиз Компонентной модели открывает двери новому архитектурному паттерну, у которого есть шанс заменить микросервисы.

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

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

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

Цифровая экосистема - это десятки продуктов, сотни сервисов, тысячи команд и десятки тысяч людей, которые 24/7 что-то проектируют, разрабатывают, тестируют, катят в прод или наоборот откатывают с прода, включают и выключают фичи, делают бэкапы и миграции, и это не считая интеграций, за фасадом которых происходят вещи и похуже. Как обеспечить надежность услуг для пользователя в таком муравейнике? Грамотно проектировать? Да. Применять GitOps, канарейки, нагрузочные тесты? Тоже да. Круглосуточные дежурства SRE-инженеров и даже разработчиков? Без этого никуда! Но всё это лишь части общей картины, которая много-много больше.

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

Тезисы:
На протяжении 4х лет в Авито мои команды разрабатывали звонки через приложение. Мы создали и запустили платформу с нуля до миллиона звонков в сутки. Это доклад не про кишки webrtc, а про построение архитектуры нагруженной системы и какие сложности нам пришлось преодолеть, учитывая сложный технологический домен звонков;

Что расскажу в докладе:
- Зачем нам вообще потребовались звонки через интернет;
- Как спланировать и построить архитектуру так, чтобы не было мучительно больно ее переделывать при масштабировании
- Каким образом связаны архитектура проекта, хранение данных и законодательство РФ;
- Как мы переводили "хейт" и негативную обратную связь в десятки моделирований и доработок, чтобы сделать качество связи значительно лучше;
Бонус: как мобильному разработчику сделать все перечисленное выше и не "сгореть"

В докладе будет рассмотрено пример внедрения гетерогенных вычислений для повышения эффективности прогнозирования в высокочастотной торговле (HFT).
В условиях HFT, где решение принимается за микросекунды, критически важным является использование вычислительных архитектур, позволяющих максимизировать производительность и минимизировать задержки.
Гетерогенные вычисления, включающие использование различных типов процессоров (CPU, GPU, CPU+GPU, CPU+DISK), предоставляют значительные преимущества за счет параллельной обработки данных и специализированных вычислительных блоков.

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

Познакомимся с новым взглядом на Архитектурный аудит информационных систем, основанным на практике медицинской диагностики:
- разберем прямые и понятные аналогии между осмотром человека (Medical Check Up) и архитектурным аудитом информационных систем
- узнаем, почему данное мероприятие принесет пользу всем, от руководителей и архитекторов, до команд разработки и сопровождения
- рассмотрим, как провести осмотр ИС с помощью предлагаемой неформальной, гибкой методики и доступных инструментов
- познакомимся с простым и удобным фреймворком, с помощью которого каждый сможет проводить аудит самостоятельно
- посмотрим на несколько практических, успешных и неуспешных примеров
- и даже пофантазируем над Единым реестром заболеваний Информационных систем!

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

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

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

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

Наша история началась в 2014 году с R&D проекта: мы поставили перед собой цель создать софт, способный заменить проприетарные сетевые решения для обработки трафика в сетях операторов связи. Взяли за основу opensource-приложение L3fwd из DPDK, сделали первые нагрузочные тесты и разработали прототип нашего первого продукта – CGNAT. Это положило начала созданию нашей платформы, способной в будущем претендовать на звание "Сетевой операционной системы".

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

Расскажу о том, как в погоне за производительностью, гибкостью и масштабируемостью в условиях жесткой конкуренции и постоянного отсутствия времени, мы достигли сотен миллионов PPS и миллионов CPS и RPS в наших продуктах. И о том, как, казалось бы, самые хорошие идеи разбивались о стену не идеальной реальности мира hardware.

Как перевезти сервис с 120к рпс? а дважды ?
Как раздавать 100500 вариантов картинок на лету и не потратить все деньги мира на железо?
Почему не тупо с3?


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


целевая аудитория:
бекендеры мидлы(основная) - в целом полезно посмотреть на задачу и как мы ее решали и учитывали разные нюансы.
бекендеры сениоры/техлиды - посмотреть на рабочее решение задачи раздачи неоднородного трафика/сравнить со своим опытом

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

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

- Программа лояльности в НСПК - что это
- Как было сначала (MVP)
- Как расчитать кешбек
- за 30 секунд
- иногда за год
- для всех
- Как выплатить кешбек (ну или забрать его назад)
- Что будет дальше

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

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

Юридические, фактические, почтовые - адреса везде. Без адреса курьер не доставит заказ еды. Разбираемся как правильно готовить адрес в системе любого масштаба. Почему Озон привозит заказ к калитке моего дома, а Я.Маркет так не умеет.

В логистическом агрегаторе ДоставИМ моя команда проделала большой путь решения проблем с адресами, разработав до этого крупнейшую в РФ адресную базу - на нём мы впервые поняли, что из 1000+ активных клиентов почти столько же кастомных адресных баз, а у самих доставщиков ситуация не лучше.

Расскажу о том, как мы учились матчить адреса, подключались к платным публичным сервисам и разочаровывались в них, выходили за рамки РФ, учили страшные слова типа ЦХДПА, КЛАДР и ФИАС, как нерешаемую за год задачу решили за один спринт и что из этого я определённо готов затащить в архитектуру новой системы и рекомендовать тебе.
Бонусом в конце поделюсь крутым решением, которое уже несколько лет не может доехать до РФ, но точно когда-нибудь будет в ДоставИМ 2.0.

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

Адаптация архитектуры и инфраструктуры национального видеохостинга RUTUBE при увеличении количества видео с 50 до 250 миллионов единиц за год
Функциональность высоконагруженных сервисов: обработка и хранение большого объёма контента — в среднем 300 тысяч видео от пользователей
Проблемы при масштабировании инфраструктуры и разработка гибридного хранилища на основе Amazon S3
Сбои Amazon S3 при повышенной нагрузке — ошибки загрузки и чтения контента
Разработка собственного решения и оптимизация под инфраструктуру национального видеохостинга RUTUBE

Рекламная система Яндекса — это более 1000 разработчиков, аналитиков и ML-инженеров, 20-летняя история и существенный вклад в выручку компании. А также миллионы RPS, сотни петабайт данных и миллионы CPU. Когда-то наша история начиналась с MySQL и cron-скриптов, затем мы открыли для себя MapReduce. Тем не менее, с ростом бизнеса становилось всё более очевидным, что обрабатывать новые рекламные материалы за многие часы — это преступно долго.

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

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

Естественным этапом развития систем серверной виртуализации является виртуализация сети - возможность создавать виртуальные сетевые инфраструктуры “под задачу”, не будучи стесненным рамками реальной сетевой инфраструктуры предприятия. Подобный этап развития настал и у проекта zVirt.

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

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

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

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

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

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

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

Речь пойдет о сервисе хранения личных данных пользователей, который работает со всеми продуктами компании: количество объектов в БД — около 100 млн; RPS — до 1000, макс request duration time < 300 ms, поддержка масштабируемости. Сервис написан на NestJS microservices, в качестве БД используется Mongo DB.

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

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

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

С учетом всего этого требовался новый подход.

В качестве протокола общения с сервисом был выбран GraphQL. С его внедрением мы:

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

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

Расскажем о том, как сделать свой Remout Config и разбивалку для проведения АБ экспериментов (аналог firebase).

Мы разрабатываем MTS Web Services (новое МТС Облако) и решаем вопросы связанные с унификацией развертывания, конфигурирования и эксплуатации. Разработчики подсистем работают по принципу - "You build It, You Run It". Поэтому надо обеспечить их удобными инструментами, чтобы они не "изобретали велосипед". Для локальной разработки сервисов - дать возможность запускать кусочек облака на ноутбуке.

Рассказ будет со стороны development platform и будут затронуты аспекты построения единой инфраструктуры с нуля. Но при этом будет учитываться другой опыт построения облачной инфраструктуры. Мы строим наше новое облако на базе openapi и микросервисов. Деплой осуществляется в k8s кластера, при этом в дизайн системы сразу закладывается возможность запустить множество инсталляций нашего решения.

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

Подсистема метрик Sage за 4 года прошла несколько витков эволюции.

В своем докладе я расскажу:
* как мы прошли путь от Prometheus до кластерной Victoria Metrics cо сроком хранения метрик до 1 года;
* как нескольких сбоев, вскрыли наши проблемы и были триггером к следующем витку эволюции наших подходов;
* как мы адаптировали пайплайн записи и поиска метрик при постоянном росте количества записываемых временных рядов;
* какие знания мы получили о кластерной Victoria Metrics и на какие ее метрики мы обращаем внимание в первую очередь

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

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

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

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

1. Зачем нам проезжать 1 млн километров каждую ночь в симуляторе?
2. В чем отличие Open Loop и Closed Loop симуляции и зачем они?
3. Как мы сделали одновременно детерменированное и многопоточное исполнение пайплайна на базе ROS
4. Как мы запускаем распределенную симуляцию в YTsaurus

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

Общий план:

- Что такое товарный поиск
- Базовая архитектура
- Как увеличение нагрузки потребовало изменения архитектуры. Как мы пришли к быстрым пайплайнам, selection rank, потоковй обработки и т.д.
- Текущая архитектура
- Как менять архитектуру налету без остановки разработки

Дополнительно обсудим следующие темы:

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

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

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

Нельзя представить современный проект без системы мониторинга. Хотя Prometheus стал стандартом де-факто, его основное ограничение — высокое потребление ресурсов. В нашем докладе мы расскажем, как мы смогли снизить это потребление в десятки раз, переписав Time Series Database (TSDB) на C++ и оптимизировав алгоритмы кодирования и хранения данных.

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

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

Синтетическое тестирование полезно, но реальная жизнь часто преподносит сюрпризы. В финальной части доклада представим реальные результаты на примере 300+ кластеров Deckhouse Kubernetes Platform. На реальных кейсах покажем существенное снижение потребления ресурсов с сохранением производительности по сравнению с такими популярными решениями, как Prometheus и VictoriaMetrics.

Подробное описание доклада
— Почему разработчикам, архитекторам и ИТ-инженерам нужно знать про ЦОДы
— Как учитывать низкоуровневую инфраструктуру в своей высокоуровневой разработке или архитектуре
— В чем измеряются ЦОДы
— Основные системы ЦОДов
— Коммерческие и корпоративные ЦОДы
— Про электрические системы ЦОДов
— На что расходуется энергия?
— PUE
— Про охлаждение
— Про деньги
— Про сети связи и интерконнект
— Про серверы в ЦОДах
— Про GPU-ML
— Еще разок про то, зачем это кодеру или архитектору ИТ-систем
— Вопросы-ответы

Виртуальную сеть в облаке часто сравнивают с кровеносной системой человека, которая доставляет до сервисов сетевые пакетики, словно кислород до клеток. В 2015 году основа этой «кровеносной системы», которую мы использовали — Software-Defined Network (NSX) перестала развиваться и затем поддерживаться VMware. Кроме этого, к прежнему решению были вопросы по части производительности и надёжности.
Мы решили перейти на opensource решение OVN, и в докладе я расскажу о всех этапах этого перехода: от предпосылок, выбора и тестирования нового решения до исправления багов в его коде.
В результате мы смогли смигрировать все инфраструктуры клиентов облака в 3х Availability Zone’ах в новый SDN «на лету», решить проблемы производительности и открыть дорогу новым фичам в сети.

Если вы думаете, что финтех — это исключительно о банках, подумайте еще раз. Этот "монстр" проник во все сферы: e-commerce, e-grocery, betting и многое другое. И даже если вы меняете компании, вы все равно оказываетесь в том же самом бесконечном круге финтеха. Почему? Давайте разберемся вместе!

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

В этом докладе я не просто выскажу свои недовольства. Я на примерах покажу, где именно финтех “ломает” и почему. Но главное — мы не остановимся на жалобах. Мы рассмотрим решения, которые помогут превратить “финтеховою” ненависть в НЕискреннюю любовь.

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

Какие артефакты архитектуры необходимы нам в компании? А какие они вообще бывают и сколько их? А как с ними потом работать и не страдать? - Знакомые вопросы?

Мы хотели бы поделиться нашим опытом организации архитектурных артефактов в масштабах экосистемы. Рассказать о том, как мы использовали на практике "Enterprise Architecture on a page", что применили из описанных артефактов, как их связали и что автоматизировали с помощью систем.

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

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

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

Мы вместе пройдем путь эволюции системы, позволяющей находить копии видеоконтента: от прототипа до production-ready решения, использующего Java/C++, низкоуровневую работу с ffmpeg, нейросети (libtorch), FAISS с IVF-индексами на GPU. Рассмотрим ключевые проблемы, с которыми мы столкнулись: многопоточное декодирование видео и снятие отпечатков, размеры и масштабирование индексов, квантизация, повышение точности работы алгоритма матчинга.

В этом докладе я расскажу как мы перепридумали систему работы с товарными данными.
Товаров у нас почти миллиард, а обрабатывать их нужно раз в 10 минут.
Я рассажу что интресного мы обнаружили в наших процессах обработки данных.
Какую архитектуру выбрали и как она помогла нам посторить систему которая позволяет раз в 5 минут обновлять остатки для миллиарда товаров.
Решение оказалось вполне универсальным и подошло и для других задач обработки и обогащения данных в Яндекс Еде.

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

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

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

Тезисы АСУДД
Часто ли вы задаетесь вопросом, как работают лифт, стиральная машина или … светофор? Кажется, что это достаточно простые системы, однако зачастую это далеко не так. Данный доклад посвящен закулисьям разработки с нуля сложной системы управления светофорными объектами Москвы. Путь длиной более 3-х лет попробуем изложить за 40 минут, поехали!
Проблема:
* Существующая система не отвечает современным требованиям безопасности, масштабируемости и надежности.
* Морально устаревший стек технологий и закрытое ядро системы препятствуют адаптации и модернизации.
* Высокая сетевая нагрузка и ограниченная поддержка протоколов управления снижают эффективность работы.
Решение:
* Разработка новой архитектуры АСУДД на базе открытых технологий (Go, Docker, Kubernetes, NATS).
* Внедрение элементов микросервисной архитектуры для повышения отказоустойчивости и масштабируемости.
* Использование современных протоколов шифрования и безопасных каналов передачи данных.
* Интеграция интеллектуальных алгоритмов управления на основе видеоаналитики и машинного обучения.
* Обеспечение полной поддержки V2X протоколов для взаимодействия с беспилотным транспортом и специальными транспортными средствами.
Оценка:
* Реализована система, которая в рамках многочисленных пилотных проектов тестировала новые методы управления, показав устойчивость и надежность.
* Обеспечена высокая скорость управления и получение обратной связи по состоянию объектов на УДС.
* Система успешно функционировала на реальных улицах в течение нескольких лет, демонстрируя значительные улучшения в управлении транспортными потоками.
* Обеспечена возможность гибкого масштабирования системы для поддержки до 35 миллионов сообщений в секунду и более 15 тыс. светофорных объектов.
* Новый API и возможности интеграции с внешними системами предоставляют широкие возможности для дальнейшего развития и адаптации системы всеми желающими транспортными инженерами.
* Новый подход к унификации интерфейса взаимодействия с промышленными контроллерами.

Перколятор (percolate queries) - функциональность, позволяющая реализовать обратный поиск. Перколятор давно существует в ElasticSearch и OpenSearch, и недавно был добавлен в Sphinx, используемый в Авито.

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

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

Особенности создания anycast-сети с протоколом BGP в рамках построения CDN национального видеохостинга RUTUBE:
• Дублирование информации с площадки и быстрая раздача на территории РФ и стран СНГ;
• Контроль баланса нагрузки: настройка серверов и использование multicast-маршрутизации.
Увеличение ёмкости глобального CDN национального видеохостинга RUTUBE с 1,5 до 5 Тбит за год
Разработка плана построения крупнейшего CDN на территории РФ и стран СНГ с ёмкостью 10 Тбит к концу 2024 года — опыт национального видеохостинга RUTUBE
Проблемы при построении крупнейшего CDN на территории РФ и стран СНГ:
• Неэффективная раздача «холодного» контента и поиск оптимального решения;
• Трудности при обработке большого объёма контента.

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

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

1. Как мы выбирали мультитенант или синглтенант.
2. Как мы выбирали признак, по которому изолировать 100 микросервисов и учили их жить с ним.
3. Как мы разделяли конфигурации и эксперименты между B2C и B2B направлением.
4. Как мы научились разворачивать наши инсталляции в разных контурах: яндексовая инфраструктура и внешнее облако.
5. Как мы научились разделять идентификаторы пользователей у разных клиентов, имея один общий родительский.
6. Как мы делали фильтры и проверку доступа к заказам из админки поддержки пользователей.
7. Как мы сокращаем время развертывания нового клиента: от нескольких месяцев до недели и теперь стремимся к 1 дню.
8. Как нам это усложнило жизнь.

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

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

Я расскажу, как мы это сделали и как решили следующие проблемы:
- Скорость ответа, как начать отвечать пользователю не за десять секунд, а быстрее
- Цена запроса, как не тратить тысячи GPU
- Стабильность, как не сломать то, что хорошо работает сейчас

Посмотрим, что получилось в итоге, что можно улучшить и почему мы все еще это не сделали

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

Яндекс Маркет — сервис для выбора и покупки сотен миллионов товаров от сотен тысяч продавцов. В высокий сезон здесь совершается более 800 заказов/минуту и свыше 80% из них - по акциям.

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

Одним из наиболее распространенных способов запуска веб-приложений на языках PHP, Python и Ruby — является связка nginx и сервера приложений, которыми чаще всего выступают php-fpm, gunicorn, unicorn, uwsgi, puma и подобные или даже Apache в этой роли.

У такого способа есть ряд существенных недостатков:
• необходимость правильно настраивать и поддерживать работоспособность ещё одного компонента в инфраструктуре, а то и нескольких;
• ошибки сопряжения и отсутствие мониторинга со стороны nginx рабочих процессов приложения напрямую, что приводит в итоге к 502-504 ошибкам при возрастании нагрузки, которые частенько видят посетители;
• дополнительные накладные расходы на обмен данными между nginx и приложениями — снижают производительность и масштабируемость.

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

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

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

Из доклада вы узнаете:

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

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

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

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

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

Говорят "Чем проще, тем надёжнее" и в нашем случае это ещё и намного дешевле с учётом наших объёмов и нагрузок.
Расскажу как нам удалось упростить нашу систему уведомлений при этом сохранить производительность и добиться надёжности на уровне 99.99

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

Уже много было сказано о том, как строить такие архитектуры. Как пример обычно приводят максимально полную реализацию - с CQRS, Event Sourcing и кафкой. Я хочу показать, что даже отдельно взятые практики из таких архитектур могут принести много пользы вашему приложению. А ещё, рассказать о проблемах, которые возникают при реализации EDA и рассказать о том, как можно их решить.

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

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

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

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

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

Мы возьмем неслабую железку, ну например 2xXeonGold6242R с 128GB RAM, и при помощи напильника попробуем исследовать “деградацию” перфоманса самых последних версий “классических” компонент СУБД (PostgreSQL, MySQL) и кешей (Redis, DragonFly, Memcached) на read-only нагрузке. Будет много latency-throughput диаграмм, на основе которых мы выясним, кто сможет “вытянуть” миллион RPS, с каким latency, для какого числа одновременных соединений. Обсудим архитектуру современных сервисов и порассуждаем о том, есть ли у СУБД шанс начать обходиться без кеш-слоя в хайлоад-проектах.

- Разделили взаимосвязи выделяемого микросервиса от монолита через редизайн модели данных, ивент-драйвен архитектуру и использования интеграционного слоя
- Разделили джойны через подход редизайна доменных моделей данных сервисов
- Разделили транзакции используя eventual consistency через Transactional Outbox
- Решили проблему заддержки асинхронного API через рантайм генерируемые сущности для поддержки обратной совместимости на фронтенде и в старых версиях нативных мобильных приложений
- Непосредственно выделили новый сервис из монолита без downtime на сайте

Влияние low-code аналитики на современные бизнес-процессы. Ее роль в ускорении цикла разработки аналитических решений. Продвинутая аналитика без ИТ-департамента. Как low-code позволяет эффективно использовать ресурсы и сокращать затраты. Рассмотрение примеров применения low-code аналитики, с фокусом на платформе Loginom. Описание платформы Loginom и ее основных возможностей. Рассмотрение техник, применяемых в платформе для обеспечения высокой скорости обработки данных, экономного расходования памяти и возможностей масштабирования. Обсуждение причин быстрой работы Loginom и используемых методов оптимизации.

Доклад о том, как Цифровой двойник Экосистемы (EDT) помогает:
* принимать решения в области управления технологиями - от архитектурных до замены дисков в конкретной стойке;
* оценивать качество создаваемых ИТ-решений;
* избавляться от лишней работы - например, не тестировать то, что не используется в продукте;
* ускорить решение инцидентов;
* быстрее создавать и развивать новые продукты.

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

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

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

Поговорим о том, что такое CQRS, и Single Writer Principle, а так же о том можно ли использовать Apache Kafka в качестве единственного персистентного хранилища данных. Посмотрим на конкретные цифры и результаты тестов, чтобы понять какие решения оказались самыми эффективными.

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

Мы обсудим ключевые технологии, которые были внедрены для достижения этих целей, включая репликацию в реальном времени, асинхронные сервисы и переход к микросервисной архитектуре. Также внимание будет уделено использованию высокопроизводительных ML библиотек, таких как CatBoost, и инструментов для управления ML-процессами в связке Clickhouse + Spark. Еще мы рассмотрим наши подходы к обеспечению масштабируемости и надежности системы, включая использование ZeroMQ и практики "грейсфулл шатдаун".

В докладе пойдет речь о перезапуске Kubernetes в Timeweb Cloud и причинах выбора k0s в контексте множества доступных альтернатив — k3s, k8s и Talos.

Из доклада вы узнаете:

— Какие ключевые факторы повлияли на выбор k0s, несмотря на популярность и широкое распространение таких решений, как k8s, k3s, Talos и другие.

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

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

На больших объемах классические подходы расчета метрик АБ через MapReduce дают большие задержки - часы и дни.

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

Вы хотите использовать Apache Kafka в своих системах? А может быть уже это делаете? Мы да и много, но местами мы ее используем ее не только как систему обмена сообщениями, но и как хранилище данных. Это хорошо или плохо? Удобно или только боль? На эти вопросы я отвечу в своем докладе, расскажу в каких вариантах мы используем Kafka, поведаю историю как мы столкнулись с проблемами бэкапа данных из Kafka и как решали их на 400 сообщений в треде в мессенджере.

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

Расскажем о том, как KION обрабатывают свыше 400М продуктовых событий в сутки, слои обеспечения Data Quality. Путь от приемника до витрины.

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

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

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

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

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

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

У нас большая дата платформа с несколькими системами хранения и обработки данных. Но не во всех системах есть хороший data governance и правильные процессы. Иногда это приводит к тому, что данные можно легко удалить по ошибке, что и произошло.
Но в этот раз рассказ будет не только про ошибку, но и про то, как нам удалось (почти полностью) ее исправить и что мы делаем, чтобы ее не повторить.
В программе:
- полная остановка боевого кластера Hadoop
- поднятие еще двух кластеров для пользователей
- восстановление данных с дисков после удаления (и очистки корзины)
- игрища с побайтовыми чтениями и поиском parquet magic numbers в петабайтном стогу сена

В докладе я расскажу:
- Какова сейчас архитектура компонента Postgres, и почему у нас так много БД
- Мотивация переезда и выбор реализации
- Про сам переезд
- Какие проблемы мы решали переездом в кубер
- Какие проблемы мы получили после переезда в кубер

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

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

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

Software-Defined Storage (SDS) - про передачу больших объемов данных по сети, нужно делать это надежно и быстро. Стек TCP/IP накладывает значительные
вычислительные ограничения на производительность решения даже в 100GbE сети. Возможная альтернатива - Remote Direct Memory Access (RDMA) протокол RDMA
over Converged Ethernet (RoCE) v2, использующий UDP/IPv4 или UDP/IPv6 стек в обычной сети Ethernet.
Расскажу, почему и как мы в компании Cloud.ru реализовали и запускали RoCE v2 RDMA транспорт для SDS собственной разработки:
1. недостатки стандартного сетевого стека Linux применительно к SDS, как мотивация внедрения RDMA;
2. наивная архитектура транспорта RDMA для передачи потока данных;
3. эффект от внедрения нового протокола;
4. дальнейшее развитие.

Picodata — это распределенная СУБД. Мы сделали ее на основе Tarantool, который выступает локальным хранилищем и реализует репликацию. На фасаде мы реализовали новый движок распределенного SQL, а управлять всем этим поставили кластер-менеджер на основе алгоритма Raft.

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

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

Как мы разработали СХД enterprise уровня с нуля.
Зачем вообще понадобилась данная разработка, ведь есть куча конкурентов даже на Российсом рынке.
Почему мы решили делать высокопроизводительную СХД
Как мы разработали с нуля RAID 4,5,6.
Как реализован быстрый ребилд RAID.
Почему в современных СХД не нужен RAID 0,1,10, почему мы отказались от их реализации.
Что такое RAID Multi Mirror от Аквариус.
Как реализованы дисковые группы и пулы.
Как реализованы толстые и тонкие тома, снапшоты и клоны.
Как реализована Active Active архитектура СХД, симметричный и ассиметричный режим.
Как реализован высокоскоростной интерконнект контроллеров.
Как реализован кэш контроллера, защита данных кэшей, оппозитный кэш.
Как реализовано программное резервирование контроллеров.
Почему не нужны сжатие и дедупликация данных на СХД в задачах HighLoad.
В каких задачах нужна СХД Вареус: Виртуализация, СУБД, Стриминг, АСУ ТП.
Как за 3 года мы смогли достичь результатов, которые конкуренты достигали за 7-10 лет.

В мире обработки данных и построения аналитических хранилищ поставка самих данных в хранилище является одним из составляющих процесса формирования хранилища. И если для поставки данных есть CDC (Change Data Capture) либо возможность иным образом наладить инкрементальный процесс выгрузки данных, то процесс выгрузки данных из 1С представляется собой нетривиальную задачу. Обычно разработчик 1С реализует процесс выгрузки нужных данных непосредственно в инсталляции, и зачастую, каждая выгрузка будет уникальной, в связи с возможными отличиями конфигураций, наименований и т.п. Вторым вариантом является доступ через OData, когда процесс интеграции самостоятельно запрашивает нужные данные. Очевидно, что для этих случаев нужно знать структуру 1С, структуру конкретных конфигураций.
Мы хотим представить результат партнерской разработки компаний "Аренада" и "1С-Перспектива" - конфигурация для 1С, реализующую отслеживание изменений средствами платформы "1С:Предприятие 8", и транслирующую их в Kafka.
Почему имеющиеся решения CDC, представленные на рынке или OpenSource, не работают в платформой 1С? Как настроить выгрузку данных из "1С:Предприятие 8" только силами администратора? Как довести данные до КХД? Как получить представления, отражающие существующие данные на источнике? Ответы на эти вопросы будут получены в ходе доклада.

Хранение бэкапов это всегда очень большие объемы данных и долгий срок хранения. Разрабатывая нашу систему хранения данных (СХД) для резервных копий TATLIN.BACKUP мы столкнулись с недопустимо быстрым ростом метаданных для восстановления данных, причём метаданные часто дублировались. При среднем сжатии данных в 6 раз и доступной ёмкости для данных в 690 ТБ, объём метаданных достигал 13 ТБ, что занимало всю выделенную ёмкость под них.

Я расскажу:

- Как мы решали эту проблему с использованием структуры Дерева Меркла и сократили объём метаданных на 83% при средней дедупликации в 6x раз,
- А также как это позволило нам ускорить поиск дубликатов в 10 раз
- И о применении content-defined chunking алгоритма для построения дерева для того, чтобы эти решения работали.
- А также о подобных (но не наших) решениях для систем контейнеризации и распределённых key-value хранилищ.

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

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

Как мы управляем кластером PostgreSQL на 650+ двухтерабайтных шардов с помощью собственного сервиса шардирования

Яндекс Почта — высоконагруженный сервис, который держит 300.000+ RPS и хранит информацию о миллиарде пользователей. Для хранения всей метаинформации мы используем PostgreSQL на 650 шардов. Чтобы справляться с такими нагрузками, мы реализовали собственный сервис шардирования — шарпей. В докладе подробно расскажу:

1. Как мы пришли к реализации сервиса шардирования

2. Как устроено основное хранилище информации о распределении пользователей по шардам и самих шардах

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

4. Разберем историческое развитие сервиса и какие оптимизации нам понадобились после переезда в Облака

5. Разберем преимущества такого решения, и как эти преимущества помогают многим сервисам Яндекс 360;

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

На HighLoad 2022 мы уже показали какие бывают аномальные случаи, но прошло время и кое-что исправлено, а что-то новое нашлось.

Приходите на доклад чтобы узнать:
* что изменилось в PostgreSQL за последние два года
* когда индексы могут тормозить или совсем не работать
* какие сюрпризы заложены в fetch size-е
и другие увлекательные истории. Давайте вместе обсудим каким иногда бывает PostgreSQL.

Почему решили отказаться от mysql?
Почему выбрали YTsaurus и как появился GrUT?
Денормализация: хорошо для потребителей, не работает для поставщиков данных
Потоковая обработка данных: per aspera ad astra.
Требования к структуре данных.
Версионирование данных обязательно.
Проблема размножения обновления в системе.

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

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

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

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

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

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

Недавно мы добавили стоимостный оптимизатор в YDB, зачем мы это сделали и какие задачи он поможет решать?

YDB создавалась как OLTP система для поддержки высоко-нагруженных проектов с большим объемом транзакций. Обычно в таких системах запросы довольно простые, хотя все равно попадаются и аналитические запросы со значимым количеством соединений таблиц. Такие запросы довольно сложно оптимизировать вручную, и на помощь приходит стоимостный оптимизатор. Многие наши конкуренты, такие как CockroachDB, TiDB, Yugabyte добавили стоимостные оптимизаторы к своим продуктам.

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

В этом докладе мы расскажем о том как мы написали свой стоимостный оптимизатор для этих сценариев, какая у него текущая функциональность на данный момент, сравнимся с конкурентами в области OLTP (CockroachDB, Yugabyte), OLAP (GreenplumDB, Teradata, Oracle Exadata, Trino) и HTAP (TiDB) решений и расскажем о планах развития.

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

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

Rust последние несколько лет стабильно остаётся самым любимым языком программирования по данным StackOverflow Developer Survey. Также в последние годы его всё больше используют и в индустрии. За 3 года разработки Picodata мы успели познакомиться со многими нюансами языка и готовы поделиться своим опытом. Затронем такие темы как тулинг, кривая обучения, надёжность, скорость разработки и выполнения, особенности архитектуры.

Mpstats - лидер на рынке аналитики маркетплейсов, а маркетплейсы - лидер роста рынка в России, как и во многих других странах. Мы собираем очень много данных. Например, на ВБ размещено 110 млн товаров. Для каждого товара мы зайдем в его карточку, запишем данные, как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель. Запишем это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров - каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed данных в ClickHouse.
В процессе развития сервиса мы упирались в несколько проблем - ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть - мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду. Расскажем, как справляемся с этими и другими задачами и делаем это быстрее конкурентов.

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

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

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

YDB -- это распределенная платформа для работы с данными с поддержкой OLTP, OLAP нагрузок и потоковыми очередями сообщений (топиками, аналогичными топикам в Apache Kafka). Apache Kafka -- признанный лидер в сфере потоковых брокеров сообщений.
Транзакции в любой системе -- это, с одной стороны, мощный инструмент упрощения кода пользователя и работы с системой в целом, а также достижения гарантий, которые до этого невозможно/сложно было получить. Например, Apache Kafka за счет транзакций позволяет достичь exactly once гарантий. А с другой стороны, это зачастую достаточно сложная и интересная архитектура внутри системы. Транзакции позволяют сложность перенести из пользовательского кода в серверный.
Основной упор в докладе делается на рассмотрение архитектуры транзакций в YDB и Apache Kafka, со сравнением плюсов и минусов этих подходов.

В докладе будут рассмотрены следующие аспекты:
* Что такое топик, транзакционная запись в топик, транзакционное чтение из топика.
* Модельная задача решардирования с гарантиями порядка и exactly once обработки. Почему ее нельзя решить без транзакций в Apache Kafka. Как она решается без транзакций в YDB. Как она решается в обеих системах с использованием транзакций.
* Архитектура транзакций в Apache Kafka.
* Архитектура транзакций в топиках YDB.
* Сравнение производительности транзакций в Apache Kafka и YDB.

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

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

Apache Iceberg - популярный табличный формат для построения современных lakehouse-платформ. В докладе мы детально рассмотрим архитектуру и реализацию Apache Iceberg на примере взаимодействия с compute-движком Trino.

Тема индексов в целом уже неоднократно заезжана, но как говорится повторение мать учение.
Поговорим на докладе про большое разнообразие индексов, да их на самом деле чуть больше чем Кластеризованный и не кластеризованный, да и просто даже про них есть о чем поговорить...
Углубимся чуть глубже и поговорим про такие штуки как fill factor, фрагментация, селективность...
Медленные запросы - единственный метод понять что пора создать индекс? А если создали, точно правильный?
Индексы и блокировки? Есть связь, какая ?
Боль 1с-ников с индексами. К сожалению 1с не умеет по нормальному индексы, индексирование сводится к установки галочки "индексировать" и всё, как мы с этим живем в 40 терабайтной базе.

Представьте, что вам необходимо выполнить анализ данных, распределённых по нескольким системам хранения: например, таблицы, размещённые в реляционных СУБД, надо объединить с CSV-файлами из S3. Что вы предпримете? Если данных немного, можно написать простой скрипт на любом ЯП, который последовательно вычитает данные из каждого источника в оперативную память и объединит их в одну таблицу, после чего её можно будет проанализировать. При этом вам придётся написать свою реализацию JOIN, либо использовать для этого стороннюю библиотеку неизвестной эффективности.

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

• Split-brain - что это?
• Apache Ignite - что это?
• Алгоритмы распределения данных по нодам:
- Legacy
- Consistent Hashing
- Rendezvous Hashing
• Как Apache Ignite хранит данные
• Partition Loss Policy
• Split-brain в кластере Apache Ignite
• Как избежать?
• Как восстанавливаться?
• Выводы

1. Проблематика миграции на PostgreSQL.
- Отсутствие готовых нагрузочных тестов: вызовы и риски.
- Методы оценки производительности PostgreSQL без проведения полноценного нагрузочного тестирования.

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

3. Методы оценки производительности PostgreSQL без стандартных нагрузочных тестов
- Верификация производительности БД до ввода в эксплуатацию.
- Выявление возможных узких мест и проблем в конфигурации.
- Примеры использования статистических данных для идентификации узких мест.

Развитие баз данных привело к появлению технологий категории Distributed SQL: решений для исполнения запросов на больших объёмах данных. Движок распределённых запросов – это важный компонент подобных распределённых СУБД, позволяющий работать с ними через привычный SQL интерфейс.

В докладе расскажу о внутреннем устройстве движка, который мы разработали в Пикодате.
Покажу, как устроены фазы планирования и исполнения запросов и какую роль в этих процессах играют ключи распределения и библиотека горизонтального масштабирования Vshard. Поделюсь тем, как в процессе исполнения DDL запросов используются алгоритмы Raft и CaS.
В конце доклада приведу сравнение с другими СУБД, предоставляющими функциональность распределённого SQL.

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

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

Проблемы, связанные с использованием систем хранения данных (СХД) разных вендоров - это незаменяемость, и несовместимость компонентов. Нельзя диск от HPE поставить в DELL или наоборот. Кроме того, существуют лицензионные ограничения на возможности СХД и тому подобные проблемы, которые нельзя решить быстро, когда функции требуются сейчас.
Мир опенсорс - сложный и простой одновременно, он развязывает руки и не ограничивает в финансовых возможностях, он доступен как бедным так и богатым, все что требуется - это опыт и желание. Нашим выбором стали два проекта - это SCST и OpenZFS.
Цели, которые мы перед собой ставили – открытая аппаратная платформа с доступными компонентами.
В результате появился аппаратно-программный комплекс, которому мы дали название SpaceSAN, система хранения данных, компоненты для сборки которой доступны на рынке РФ.
При испытании тестовый образец сравнивался с СХД от Fujitsu, результаты оказались сопоставимы, но наша СХД значительно дешевле.
Идея была опробована в собственных центрах обработки данных и прошла проверку на деле.
В настоящее время в эксплуатации уже находится более 30 СХД с нашим модулем.

Valkey, в отличие от Redis, изначально построен по полностью Open Source модели, у него нет Entrerprise-версии, которая бы каким-то образом ограничивала его развитие.
С момента начала работы над ним весной 2024 года команда разработки успела принять и стабилизировать некоторое количество патчей, заметно улучшающих производительность в сравнении с версией 7.2.
В этом докладе мы посмотрим на некоторые из этих патчей, оценим (с бенчмарками) их позитивные (а местами и негативные) эффекты на производительность.

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

Оптимизатор PostgreSQL работает хорошо и генерирует оптимальные планы для большинства случаев, но для некоторых конкретных запросов, когда происходит недооценка кардинальности оптимизатором, им может быть сгенериован настолько неоптимальный план запроса, что время его выполнения может затянуться. В некоторых особенно экстремальных случаях время выполнения запроса становится настолько большим, что становится практически невозможно дождаться завершения запроса, чтобы использовать инструмент EXPLAIN ANALYZE для выяснения того, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL не помнит своих ошибок в оценке кардинальности, поэтому он, скорее всего, будет генерировать один и тот же план запроса снова и снова, пока что-то не изменится: статистика, настройки оптимизатора или что-то во внутреннем состоянии СУБД. Сообщество PostgreSQL предложило расширенную статистику и ряд дополнительных оптимизаций, таких как инкрементальная сортировка и материализация промежуточных результатов запроса. Кроме того, есть некоторые расширения, такие как AQO [0], replan [1], которые помогли оптимизатору справиться с этой проблемой. Первый запоминает информацию о реальной кардинальности и делится ею с планировщиком, когда план запроса будет сгенерирован снова. Второй полностью может перепланировать запрос после прерывания выполнения текущего неоптимального плана запроса и сохраняя информацию из частично выполненного плана запроса. Информация собирается путем анализа дерева выполнения запроса с сохранением фактической кардинальности, а в следующей попытке процесса перепланирования планировщик использует эти знания, что может позволить ему построить более справедливый план запроса на основе актуальных данных.
Мы хотели бы объяснить механизм переключения между планами запросов. Его основная идея заключается в переключение с Nested Loop ноды, на запасную ноду с более эффективным алгоритмом - HashJoin или MergeJoin, если произошла ошибка в недооценки количества строк. Мы выполняем левую подноду NestedLoop и после ее сканирования, когда мы точно можем определить ошибку недоэстимации, мы переключаемся на идентичную ноду у HashJoin и MergeJoin, а результаты сохраняем с помощью материализации. Это может привести к более быстрому выполнению запроса, так как мы вовремя переключаемся на более эффективный алгортм для больших данных.
Мы поговорим о принципах проектирования этой технологии в оптимизаторе PostgreSQL, его настройках, как этот механизм может быть применен в механизме в жизни. Мы также покажем на примерах, как данный механизм может быть использован.

[0] https://www.pgevents.ca/events/pgconfdev2024/schedule/session/147-adaptive-query-optimization-in-postgresql/

[1] https://habr.com/ru/companies/postgrespro/articles/819911/

В рамках процессов по импортозамещению мы в T-Bank разрабатываем свой реестр Docker-образов на базе Gitlab Container Registry. Мы интегрировали дополнительную функциональность: политики очистки устаревших образов, собственную аутентификацию, авторизацию, имплементацию новых API: поиска образов, создания тегов и других.

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

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

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

Любая SDS воспринимается как монолитная и монструозная коробка, в которой боязно что-то менять и сложно что-то проверить с коротким циклом обратной связи. В своем докладе расскажу, как тестировать изменения в Ceph без опасений и влияния на продакшн, и какие инструменты помогают команде «Рунити» воспринимать каждый отдельный Ceph как облако.

Тезисы доклада:
- Ceph как легко развертываемый кластер
- Функциональное тестирование на виртуальных машинах
- Путь изменений от виртуальных машин при разработке решений до продакшна
- Воспроизведение функциональных пользовательских кейсов в изолированных окружениях

Создать кластер Kubernetes – не самая сложная задача, но что делать если их требуются тысячи?

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

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

За 3,5 года разработки платформы PaaS в Купере (ex СберМаркет) мы перепробовали множество способов раскатывать изменения на пользователей - продуктовых разработчиков - и выработали эффективные подходы, благодаря которым эти изменения не останавливают ежедневную работу наших пользователей и не вызывают у них отторжения.

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

Кажется, что важность надежности продуктов – вещь очевидная. Ни один из владельцев продуктов не ставит цель по созданию продукта, который будет постоянно “падать”. Однако на деле оказывается, что для обеспечения надежности то времени не хватает, то компетенций. Чтобы решить эту проблему в МТС была создана платформа Operations или OpsPlatform. В докладе поделимся опытом создания платформы и как мы за пол года внедрили платформу во все MC/BC продукты экосистемы, какие эффекты получили, и что о нас думают крупнейшие продукты экосистемы.

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

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

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

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

В рамках доклада мы:

- Детально рассмотрим проблему и причины ее возникновения.
- Оценим, какие требования предъявляются к системам service discovery, независимо от конкретной реализации.
- Изучим несколько вариантов реализации и сравним их с различных точек зрения.
- Поразмышляем о будущем таких систем.

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

Helicopter - low-code платформа для совместной работы с данными, которой пользуются более 10K сотрудников группы компаний ТКС. Это основной инструмент для аналитики и ключевая "терминальная" поверхность взаимодействия с сервисами платформы данных.

Мы прошли путь от форка Zeppelin до крайне оптимизированной data-intensive платформы с жестким оверселлингом ресурсов. Создали интуитивно понятный продукт с низким порогом входа, без которого сейчас невозможно представить self-serviced аналитику в Т-Банке.

Расскажем о
- визионерстве и продуктовом подходе в разработке внутреннего продукта, проблемах позиционирования
- масштабных миграциях пользовательского кода между разными системами
- дизайне нашего решения
- SRE-практиках и организации поддержки
- о крутых особенностях продукта - resource overselling, ML- и LLM-хелперы, статический анализ, tenant-менеджмент, dev/prod barrier, client-side code-completion, версионирование и многое другое

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

В рамках доклада мы разберем преимущества и недостатки подходов Low-code и SDUI, включая визуализацию разработки. Затронем технологии FP, в частности, архитектура платформы, кроссплатформенность с использованием Flutter и особенностей его интеграции, а также GraphQL с его плюсами и минусами. Отдельное внимание уделим Дизайн Системе МТС, обеспечивающей единый стиль всех приложений экосистемы, а также будут представлены решения по оптимизации UI/UX платформы.

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

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

Автоматизация процесса управления данным на базе каталога данных.
Управление трансформацией данных с использованием инструментов гибридного преобразования с использованием SQL Mesh
Оптимизация скорости разработки преобразования данных при создании витрин данных.

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

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

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

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

Как сделать платформу, которая будет ускорять разработку и делать эксплуатацию надежнее?

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

ЦЕНТРАЛИЗИРОВАННОЕ УПРАВЛЕНИЕ API, Managment API, Масштабируемость бизнес-процессов использующих API
Готовность к быстрым изменениям
Сокращение T2M
Снижение стоимости разработки и поддержки
Безопасность

У нас 20+ бек микросервисов, 5+ postgresql баз и 5+ микрофронтов в проде.
Все конечно в кубере.
Поднимать версию всего, чтоб протестировать фичу, задевшую 2-3 сервиса - дорого.
Но, для полноценного теста/работы стенда нужны все сервисы и базы.

Хотим рассказать про вундервафлю, которую мы сделали на базе gitlab CI,
которая позволяет поднять только нужные контейнеры и получить dyna стенд на своем домене "спаренный" со stage версиями всех не "задетых" сервисов.

Наша команда давно и успешно развивает сервис централизованного логирования в МТС. За это время мы успели вырасти в сотни раз по объемам, пользователям и нагрузке, перейти от одного единственного кластера Elasticsearch к геораспределенной системе из множества кластеров OpenSearch. Не все наши изначальные архитектурные решения выдержали проверку временем, и с их последствиями мы боремся до сих пор. А часть компонент пришлось дорабатывать или заменять собственными решениями.

В докладе я расскажу, как нам удалось сделать геораспределенную систему логирования на базе OpenSearch на 300+ TB и 3 000 пользователей. Как менялась наша архитектура и стек с ростом нагрузки. И самое главное - что бы мы сделали по другому, если бы начали с нуля.

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

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

* Немного про планирование
* Проблематика или почему не Ansible
* Структура PS скриптов для HL
* "Минимальное документирование но сразу"
* Паттерн "Чек здоровья"
* Паттерн "Логирование событий"
* Явное разделение на последовательные и параллельные процессы
* Паттерн "Асинхронная обработка"
* Паттерн "Управление потоками'
* Паттерн "Пытаемся снова"
* Паттерн "Обработка ошибок"
* Паттерн "Кроссплатформенность"
* Паттерн "Идемпотентность"
* "Юнит тестирование"
* "Контроль версии при запуске"
* Паттерн "Откат изменений"
* Паттерн "Состояние"

Что делать, если в деплой в облачный кубер падает из-за нехватки ресурсов, но мониторинг говорит, что реальная утилизация ниже 20%, при этом стоимость инсталляции в месяц составляет 8-значную сумму? Рассмотрим способы борьбы за финансовую эффективность компании на примере облачного K8s. Расскажу, как правильно управлять нагрузкой и утилизацией ресурсов в облачном K8s, оставаясь в разумных бюджетах.

На примере кейса о переводе новостного сайта на базе Drupal 8 в Kubernetes я расскажу о типовых паттернах архитектуры приложений в Kubernetes и лучших практиках миграции нагруженных приложений на контейнерную инфраструктуру, типичных ошибках и сложностях. А также разберу, как контейнеризация позволяет сделать более надежными и масштабируемыми даже «немодные» технологические решения. Для нас это был своего рода вызов: разбить этот типичный PHP-монолит на микросервисы нельзя, сайтов на Drupal было несколько, к тому же стояла задача в кратчайшие сроки увеличить количество сайтов, и обеспечить отказоустойчивость под высокой нагрузкой.

Структура доклада:
Drupal 8 — как пример классического монолита на PHP, который можно масштабировать только вертикально, а также тяжело и больно поддерживать.
Как всё было устроено до миграции в Kubernetes.
Подготовка Kubernetes-кластера под Drupal-сайты.
Миграция одного сайта в контейнеры: поды бэка падают в crashloop.
Оптимизация производительности нового решения.
Миграция в Kubernetes оставшихся сайтов и масштабирование.

Результаты:
Мы получили отказоустойчивую, самоподлечивающуюся инфраструктуру.
Мы значительно уменьшили Time-to-Market, за счет CI/CD.
Мы экономим на инфре (за счет HPA).
Мы перевариваем трафика 300+ RPS на один сайт.

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

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

Всем привет, Инженерная Культура на Масштабе: Как развивать и масштабировать DevOps практики! - это увлекательная история, которая рассказывает как DevOps практики внедрялись в компанию, как они трансформировались от обязательных стандартов к инженерной культуре и впоследствии превратились в "технические возможности" с уровнями зрелости, множеством критериев и автоматизированными проверками в it на масштабе 258 команд, среди которых работает ~3700 айтишников. Доклад поднимает вопросы связанные с инженерной культуры и мотивации инженеров и команд на развитие в этом направлении, а также решает проблему внедрения и измерения технических практик в энтерпрайзе.

- Введение в автоматизацию инфраструктуры: обзор основных инструментов и подходов.
- Использование GitLab CI/CD для создания виртуальной среды в облаке OpenStack.
- Роль Terraform как инструмента для управления инфраструктурой как кодом (IaC).
- Создание пользовательских образов и настройка виртуальных машин и сетей с помощью Terraform.
- Генерация инвентаря Ansible для управления развертыванием OpenStack с помощью kolla-ansible.
- Эффективное развертывание OpenStack для разработчиков с использованием GitLab CI/CD и Terraform.
- Примеры использования: разработка кода для основных проектов OpenStack и создание пользовательских установок.
- Практические рекомендации и лучшие практики по автоматизации развертывания OpenStack.
- Перспективы расширения автоматизированных процессов для развертывания реального облака в будущем.

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

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

1. Погружение в 1С:ERP
2. Формирование команды для разработки:
- Необходимые роли и компетенции в команде: аналитик, программист, тестировщик, менеджер проекта
- Разделение на команды
- Подходы к обучению и развитию навыков команды
3. Технологии и инструменты разработки:
- Обзор инструментов
- Практики DevOps для автоматизации процессов разработки и деплоя
4. Управление проектами разработки:
- Основные этапы проекта
- Инструменты для отслеживания прогресса и управления задачами
5. Тестирование и качество разработки. Подходы к обеспечению качества кода

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

Расскажем реальную историю запуска и развития международного высоконагруженного проекта на базе управляемого Kubernetes, Apache Superset и Trino.

Остановимся подробно на следующих практических кейсах и сценариях их преодоления:

- почему "официальные лимиты" в k8s не работают, на какие разные лимиты наступили мы и как с этим жить в коммерческом проекте с 25к подов и гигабайтами конфигурацинных файлов в etcd

- как мы решаем проблему обновления большого числа виртуальных хостов в nginx, почему ingress-nginx становится "так плохо" при 5к подов, и как и почему мы переехали на contour/envoy с деталями его конфигурации под нагрузку

- как могут падать мастер-ноды k8s и etcd: увлекательная патологоанатомия выживания на продакшн, когда падает каждый день что-то новое и клиенты не должны это заметить

- зачем мы мигрировали секреты helm из k8s в Postgres-бэкэнды при уже 15к подов клиентов, как сделать это самостоятельно за 2 дня, делимся опытом

- как "официальный" мониторинг k8s prometheus monitoring стал узким местом, как его оптимизировать и заставить приносить пользу

- так как же на самом деле "правильно" настраивать "limit" и "request" лимиты на многочисленные ресурсы в k8s: русская рулетка на продакшн или научный подход?

- как бы научились эффективно распределять нагрузку на ноды кластера k8s скриптом на python и не "палить деньги на ветер" и почему отказались от "официального" решения

- как мы экономим ресурсы k8s, гася неактивные поды клиентов: скрипты, алгоритмы, интуиция и шаманизм

- как мы живем с двумя управляемыми k8s в разных облаках: сравниваем возможности и делаем выводы для себя и слушателей

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

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

Знакомство с эволюционной моделью проектной команды. Инструменты лидера. "Walking in my shoes" или путь разработчика в эволюционной модели проектной команды.

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

В этом докладе я хочу рассказать про наш опыт ускорения релизов и стандартизации этого процесса в сервисах Mail.ru и
поделиться подходами и инструментами, которые практически каждый сможет внедрить в собственные проекты.
– Почему мы за это взялись
– Как правильно организовать выкатки? Какие есть подходы и что выбрали мы
– Как устроен пайплайн: сборки образов, мерж веток, джобы, механизм раскатки, виды апрувов и другое
– Как мы следим за пайплайном: графики, алерты и нотификации
– Особенности организации пайплайнов в GitLab CI
– Результаты, которых мы достигли, и ближайшие планы по развитию
– Как внедрить себе

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

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

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

- Введение в проблематику: значимость эффективного масштабирования предоставления оборудования без операционной системы.
- Краткое упоминание об основных пользователях данного опенсорс решения (Есть замечательная статья в CERN, которым мы вдохновляемся и с которым работаем) https://superuser.openinfra.dev/articles/scaling-bare-metal-provisioning-with-nova-and-ironic-at-cern-challenges-solutions/ .
- Роль Nova и Ironic в решении задач предоставления оборудования без операционной системы.
- Архитектурные особенности решения: как Nova и Ironic интегрируются и взаимодействуют в облаке.
- Преимущества использования Nova и Ironic для масштабирования предоставления оборудования без операционной системы.
- Вызовы, с которыми столкнулась команда при реализации и масштабировании данного решения.
- Практический опыт применения Nova и Ironic: результаты, достижения и уроки, извлеченные из проекта.
- Перспективы будущего развития и улучшения решения с использованием Nova и Ironic в контексте среды.

Helm package manager является самым популярным средством для пакетного деплоя в kubernetes на сегодняшний день (согласно CNCF Survey)... и, наверное, самым ненавидимым. О недостатках Helm сказано многое, но серьёзно подвинуть его с пьедестала пока не получилось ни у jsonnet-основанных тулингов, ни у специализированных фрэймворков для создания kubernetes-операторов, ни у других подобных тулингов.
Недавно на поле появися новый игрок - CUE. Давайте углубимся в возможности нового языка и попробуем решить на нём те практические задачи, которые сейчас решаем с помощью Helm: возьмём развитый чарт, попробуем переписать на cue и решить так ли уж хорош новый язык и его экосистема.

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

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

В своем докладе мы рассмотрим процесс построения безопасной архитектуры для генеративных нейросетей: от того как и где обрабатываются данные до прода. Разберем векторы эксплуатации уязвимостей в моделях и в пайплайне разработки и распространенные средства и методы защиты. Как итог соберем безопасный безопасный пайплайн с нуля.

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

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

В докладе расскажу:
• Как разработать безопасную архитектуру мобильного приложения с использованием СКЗИ
• Как обеспечить быстрый процесс выполнения требований ФСБ России по оценке влияния мобильных приложений на встроенные СКЗИ
• Какие инструменты и методы использовать для контроля целостности и безопасности кода на этапе разработки
• Как автоматизировать процесс контроля релизных сборок и обеспечить соответствие стандартам безопасности

Новая жизнь бросает нам новые вызовы - и вот уже CNI и Service Mesh-и с EBPF под капотом это не что-то из области фантастики или экспериментов, это уже повсеместно внедряется на production инфраструктуру. Однако не так много инженеров понимают, что происходит под капотом этой системы. И еще меньше инженеров знает, как системы на базе eBPF могут быть скомпроментированы и как защититься от угроз если не полностью, то хотя бы минимизировав риски. И сегодня я расскажу вам об этом.

В докладе мы затронем следующие темы:
- Что такое bpf как технология
- eBPF и как это работает
- Атаки на удаление ключей из ebpf maps
- Kernel exploits by eBPF
- Вызов незапланированных syscalls
- Falco bypass
И другие виды атак

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

Приложения, перед которыми стоит задача высокой производительности, зачастую пишутся на небезопасных с точки зрения использования памяти языках программирования, таких как С и С++. В Яндексе разрабатывается и используется множество сервисов, написанных на С++, как доступных исключительно для внутренних пользователей, так и опубликованных в open source: YDB, YT, userver, etc.

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

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

Для решения этой проблемы мы разработали новый дистрибутив - Axiom Linux. Это достаточно легковесное решение с быстрым временем запуска. Оптимизация под Java осуществлялась через настройку ядра и системных библиотек. Работе с безопасностью было уделено особое внимание: подписанные модули ядра, Apparmor, работа с CVE и прочее.

Axiom Linux лежит в основе Axiom Runtime Container - нашей среды безопасного исполнения java-приложений в Cloud Native сценариях. Мы смогли разработать самые легковесные контейнеры для java на текущий момент.

В этом докладе мы поговорим о Linux, его ядре и аспектах ОС, которые связаны с безопасностью и производительностью JVM.

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

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

1. Основные угрозы безопасности во внешней сети
1) Доступ к данным устройства
2) Доступ к каналам связи устройства с облаком Яндекса
3) Доступ к открытым данным в облаке Яндекса (S3 storage)
2. Безопасность каналов связи:
1) mTLS -> OpenSSL
2) Separate CA && certificates -> Step CA
3) AWACS/L7 (mTLS => TVM) -> Yandex Security Infrastructure
3. Безопасность данных на диске:
1) Secure Boot => UEFI [PK/KEK/db pub keys] / Locally issued keys
2) Full Disk Encryption => LUKS2 / TPM2 / clevis
4. Детали запуска с Secure Boot
1) UEFI => UEFI_APP(signed) [linux kernel + initrd + kernel_command_line]
2) LUKS2 простыми словами
3) TPM2 + clevis = automatic LUKS2 mount
5. Доступ к открытым данным в облаках
1) Создание короткоживущих подписанных ссылок на наши ресурсы (S3)

В Российской Федерации на законодательном уровне начали формировать первичные требования к умным многоквартирным домам и их безопасности. Рассмотрим разницу между умным домом и умный многоквартирным домом. Ознакомимся с международным анализом уязвимостей и угроз кибер-физических систем современных домов и использования IoT и IIoT на службе цифровизации домов. Сформулируем гипотезы перспектив повышения уровня безопасности умного многоквартирного дома.

Тема с Supply Chain уже который год не на слуху, закономерно развиваются и меры предотвращения таких атак. Одним из популярных фреймворков является SLSA, однако он достаточно абстрактен и не учитывает некоторые виды атак. В докладе мы узнаем про фреймворк OSC&R, сравним его с SLSA и разберемся какие конкретно атаки нам угрожают и что с этим делать

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

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

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

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

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

Мы проследим эволюцию методов защиты от бинарных уязвимостей, таких как переполнение буфера и повреждение памяти. Рассмотрим, как с течением времени развивались способы защиты памяти: от ранних методов, таких как неисполняемый стек, до современных технологий, таких как Control Flow Integrity (CFI) и ARMv8 Memory Tagging Extension (MTE). Но главное — мы поговорим о недостатках, ограничениях и способах обхода этих методов. Обсудим их практическое применение и оценим их эффективность в современных условиях.

Как устроена криптография в Matrix и какие изменения появятся в Element X

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

Покажу, как использовать инструмент для тестирования уязвимостей языковых моделей — Garak. Рассмотрим, как протестировать и защититься от адверсарных(состязательных) суффиксов, обфускации и Token Smuggling'a, чтобы уязвимости в моделях не привели к финансовым потерям и ущербу репутации организаций, использующих эти модели.

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

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

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

А также обсудим как различного рода утечки облегчают сбор информации о нас и даже посчитаем на пальцах.

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

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

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

Методология КАИВ (Каскадная AI валидация дефектов приложений) позволяет почти в 10 раз сократить трудозатраты на ручной триаж за счет AI валидации, обеспечивающей точность 80-90%, и почти в 15 раз снизить трудозатраты на исправление подтвержденных дефектов за счет их приоритезации, автоматического предложения места наиболее эффективного исправления и контекстных рекомендаций по устранению подтвержденных уязвимостей. Обладает нулевым False Negative.

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

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

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

В Сбере больше 1500 команд, разрабатывающих и поддерживающих около 2000 автоматизированных систем (АС). Эти АС используют компоненты стандартного технологического стека от операционной системы, систем управления виртуализацией и контейнерами, до Middleware и баз данных. АС регулярно масштабируются, команды создают новые и выводят старые микросервисы, технологический стек меняется под влиянием внешних и внутренних факторов. Один из актуальных факторов – импортозамещение. Управление доступом к компонентам технологического стека и между ними сложный технический вопрос не только для Сбера и его большой инфраструктуры, но и для других компаний в России и мире. Перед нами стояла задача решить эту задачу для более 500 000 экземпляров компонентов тех стека и не только автоматизировать предоставление доступа и создания технических и привилегированных учетных записей, но и управление их жизненным циклом, ролями, полномочиями и секретами.

В рамках доклада мы разберем:

- Организацию учета, продуктов, компонентов, и др., а так же как вести привязку команд сопровождения и развития;
- Организацию ролей и учетных записей в IGA;
- Что такое PAM и Vault, передачу секрета УЗ под управление в эти системы;
- Управление доступом к Vault и PAM из IGA, разделение ролей;
- Управление доступом на примере Linux. Централизованная аутентификация vs ssh-ключи. Управления sudo. Разграничение доступа.
- Как использовать Vault для работы с сертификатами, магия istio + vault agent;
- Преимущества и недостатки внедрения такой автоматизации.

Практики безопасной разработки постепенно входят в культуру DevOps, даже если не называть это DevSecOps, планка требований к безопасности повышается. В своем докладе хочу показать, чем DevSecOps могут быть полезны непосредственно в работе разработчика, архитектора и даже техписа. Раннее выявление проблем в продукте, конкретизация ТЗ к инфраструктуре, уменьшение ручного поиска багов и так далее. Необязательно ждать, пока DevSecOps в компании созреет до выделенного отдела, несколько простых шагов уже могут существенно улучшить безопасность разработки (и принести дополнительную пользу коллегам).

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

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

Ответам на эти вопросы и посвящён этот доклад.

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

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

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

Какова цена взлома именно вас, насколько вы защищены?

Для внешней оценки защищенности придумано множество инструментов:
Сканирования на уязвимости
Тестирование на проникновение
RedTeam/PurpleTeam
BugBounty

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

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

Долой искусственные проверки! Только боевые условия и реальность.

Быстрый рост ИТ компаний, как правило, влечет за собой *необходимость в увеличении мощностей ИТ инфраструктуры. Как следствие, это несет за собой сложности в части поставки нового оборудования и масштабирования информационных систем. При этом, облачные провайдеры могут значительно облегчить решение этих проблем за счет быстрого предоставления необходимых вычислительных ресурсов и управляемых сервисов. Однако, при размещении своих сервисов в облаке, важно сохранить должный уровень защищенности.* Относительно недавно мы в своей компании тоже столкнулись с подобной задачей, поэтому готовы рассказать о "подводных камнях" заезда нагрузок эко-системы Т-Банк в публичное облако на примере Yandex Cloud, а именно: особенности обеспечения доступа пользователей в YC, настройка сетевой сегментации в большом количестве облаков, защита пайплайна и обеспечение контроля публикации приложений из YC.

Решили выстроить процесс автоматизированного анализа кодовой базы на уязвимости, но DefectDojo не выдержал нагрузки? С такой же проблемой столкнулись и мы два года назад. За это время мы разработали собственную платформу оркестрации SAST и SCA-инструментов, и ежедневно проводим полторы тысячи сканирований, подключив к системе шесть тысяч проектов, а наша БД, хранящая "сырые" сработки, перевалила за 300 гигабайт.

Расскажем, как мы справляемся с такими объёмами, чего нам стоило разработать собственную систему vulnerability management силами 3 разработчиков, как мы справляемся с анализом проектов в миллионы строк кода, и как проводим многоступенчатую дедупликацию данных, благодаря которой 150 миллионов "сырых" срабатываний SAST-анализаторов превращаются в несколько тысяч агрегированных срабатываний в Web-UI, с которым работают разработчики.

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

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

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

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

Разберу детально около 10 критичных CVE в стеке технологий .Net.
Причем далеко не во всех CVE есть даже опубликованный PoC (про это будет отдельный спич, как из описания получить PoC)
Расскажу про импакты и как устранять
Ну и еще раз напомню про SCA (прям 5 минут, потому что я в предыдущих своих докладах уже много про инструменты рассказывал)
Так что тут будет только хардкор и практика.
Не буду показывать инструменты и делать таблички, которые очень любят на хайлоаде, но дам контент и пищу для размышления.

Сейчас не найдется ни одного специалиста, cтолкнувшегося в процессами аутентификации и авторизации, и того, кто бы не слышал при этом таких слов, как: OAuth2, Open ID Connect (по крайней мере, я на это надеюсь :) ).
Но как часто при этом вы сталкиваетесь с формулировкой от внутренней службы ИБ: "Не по стандарту! Не согласовано"?
А что если пойти от обратного? Не только использовать существующие стандарты, даже если стандарт не поспевает за развитием технологий, а стать тем, кто создает мировые стандарты аутентификации?
В докладе расскажу, как пройти путь от потребителя до фаундера стандартов в аутентификации и авторизации, что для этого нужно, какие шишки придется собрать по пути, как создаются стандарты и др.
А также не OAuth2 единым...узнаете больше об уже существующих стандартах полезных, но малоизвестных и нужных :)