Профессиональная конференция для Go-разработчиков

Golang: прошлое, настоящее, будущее (2)

Итераторы в Go 1.23: зачем они нужны, как использовать и насколько они быстрые?

GO

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

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

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

Доклад принят в программу конференции

Сопрограммы в деталях: почему горутина не корутина и как всё устроено на самом деле?

GO
Расширение кругозора

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

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

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

Программный комитет ещё не принял решения по этому докладу

Инструменты на Go и для Go (9)

Искусство разработки CLI утилит на Go

Devops / другое
GO

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

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

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

Программный комитет ещё не принял решения по этому докладу

Генерация кода на Golang

GO

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

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

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

Программный комитет ещё не принял решения по этому докладу

Самый лучший мок на свете: разбираемся с инструментами для моков в go

Критерии выбора технологий для проекта
Юнит-тестирование
GO
Расширение кругозора

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

Доклад принят в программу конференции

Взрослые технологии для микросервисов

Василий Близнецов

Positive Technologies

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

Программный комитет ещё не принял решения по этому докладу

Как и зачем делать операторы для k8s на GO.

GO
DevOps / Кубер

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

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

Программный комитет ещё не принял решения по этому докладу

Мастер-класс «Как использовать Temporal для создания MVP»

Микросервисы, SOA
Критерии выбора технологий для проекта
GO

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

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

Доклад принят в программу конференции

Быстрые и блокирующие вызовы С/С++ из Go без Ассемблера

C/C++
Оптимизация производительности
GO
Расширение кругозора

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

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

Доклад принят в программу конференции

Реализация RBAC и ABAC в Golang на базе Casbin

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

Программный комитет ещё не принял решения по этому докладу

Покоряем Web с gRPC: Современные подходы и улётная производительность

Эдгар Сипки

Ozon Банк

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

Доклад принят в программу конференции

Лучшие практики, Go-way (10)

Как мы проводим эксперименты в публичном API на примере дорелизных итераторов

Бэкенд / другое
Асинхронное программирование, реактивное программирование
Рефакторинг
GO
Тимофей Кулин

Яндекс, YDB

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

Программный комитет ещё не принял решения по этому докладу

Разложим способы оптимизации по полочкам

API
Бэкенд / другое
PostgreSQL
Базы данных / другое
GO
Оптимизация

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

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

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

Программный комитет ещё не принял решения по этому докладу

Эффективная многопоточность или как выжать максимум из 48 ядерного CPU

GO
Оптимизация
Никита Галушко

VK, ВКонтакте

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

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

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

Доклад принят в программу конференции

Архитектура в Go и при чем тут Rust

Архитектурные паттерны
Рефакторинг
Поддержка и развитие legacy систем
Микросервисы

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

Программный комитет ещё не принял решения по этому докладу

SRE для разработчика, или как гоферу уйти в отпуск в день релиза

Платёжные системы, обработка платежей
PostgreSQL
Архитектурные паттерны
Рефакторинг
Техдолг
Поддерживаемый код
Практики программирования
Слабо связанная архитектура

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

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

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

Программный комитет ещё не принял решения по этому докладу

Грокаем структуры данных для распределенных систем: Bloom Filter, CRDT и Consistent Hashing.

Булат Усманов

Купер (ex-СберМаркет)

В мире распределённых систем эффективные структуры данных играют ключевую роль в обеспечении производительности и масштабируемости. В этом докладе мы погрузимся в реализации 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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Микролит или как писать на Go, чтоб было удобно распиливать

Архитектурные паттерны
GO

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

Программный комитет ещё не принял решения по этому докладу

Как в Go жить без перегрузок функций и значений аргументов по умолчанию?

API
Разработка библиотек, включая open source библиотеки
Безопасность программного кода, SQL и прочие инъекции
GO
Теория
Лайфхаки

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

Программный комитет ещё не принял решения по этому докладу

Механическая симпатия как способ эффективной работы с памятью в Go

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

Программный комитет ещё не принял решения по этому докладу

Проблемы и приключения (3)

Через ассемблер к плюсам: устройство и оптимизация CGo

C/C++
Оптимизация производительности
Логирование и мониторинг
GO
Оптимизация

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

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

Доклад принят в программу конференции

Почему вы думаете, что Go не ООП язык?

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

Я расскажу:

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

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

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

Программный комитет ещё не принял решения по этому докладу

Умный дом Сбер: как вырасти с 0 до сотен тысяч онлайн устройств и не умереть.

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

Доклад принят в программу конференции

Проекты и решения на Go (16)

Как мы реплицируем и локализуем 100000 репозиториев практически ежедневно

Александр Калошин

GitLife | Last.Backend

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

Программный комитет ещё не принял решения по этому докладу

Архитектура приложения Go + NoSQL

Tarantool
Базы данных / другое
Lua
GO
Максим Коновалов

VK / Облако Mail.ru

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

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

Программный комитет ещё не принял решения по этому докладу

Фаззинг Go-пакетов: зачем мы наступали на грабли, писали свой тулчейн и к чему мы идем

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

Доклад принят в программу конференции

Golang в интеграциях с ресторанами в Яндекс Еде

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

Программный комитет ещё не принял решения по этому докладу

Эволюция трейсинга в gRPC

GO
Микросервисы
Алексей Коротин

Спортс’’

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как мы реализовали failover на базе библиотеки etcd и не стали переписывать 100 тыс. строк кода

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

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

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

Программный комитет ещё не принял решения по этому докладу

Страх и Ненависть в Ви.Tech: как жить без микросервисов

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

Доклад принят в программу конференции

Как написать сагу на Go и не умереть во время поддержки

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

Программный комитет ещё не принял решения по этому докладу

Как сделать данные на клиентах всегда актуальными - централизованное хранилище на go

Миграции данных
Архитектурные паттерны
Рефакторинг
Критерии выбора технологий для проекта
Микросервисы
YDB

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

Программный комитет ещё не принял решения по этому докладу

Платформенный трейсинг в 1Gb/s и особенности хранения терабайтов данных

Бэкенд / другое
Архитектура данных, потоки данных, версионирование
ClickHouse
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Декларативная платформа управления доступом: от ролей к динамическим политикам

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

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

Доклад принят в программу конференции

Как аргументировать разработку микросервисов в компании

Микросервисы, SOA
Методологии и процессы разработки ПО; Сроки и приоритеты
Микросервисы
Типовые ошибки

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

Программный комитет ещё не принял решения по этому докладу

"Вошли и вышли, приключение на 20 минут" или как переписать api-gateway банка

Распределенные системы
GO
Инфраструктура

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

Программный комитет ещё не принял решения по этому докладу

Go в мире WebAssembly: не только браузер

Бэкенд / другое
GO
WebAssembly (WASM)

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

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

Доклад принят в программу конференции

Разгоняем Go TLS до 100Gbps с сервера

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

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

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

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

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

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

Доклад принят в программу конференции

Как стримить данные из Snowflake в Couchbase или зачем писать свой плагин для Redpanda/Connect

Базы данных / другое
GO
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Go и AI (3)

SDK для GigaChat API на языке Go: Сравнение с ChatGPT

API
Бэкенд / другое
GO

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

API
GO
ML
Расширение кругозора

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

Программный комитет ещё не принял решения по этому докладу

AI в Go: как мы пишем ML-приложения с использованием паттерна пайплайнов.

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

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

Программный комитет ещё не принял решения по этому докладу

Другое (8)

Грейды Go разработчика, или что отличает сеньора-гофера от остальных

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

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

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

Программный комитет ещё не принял решения по этому докладу

Навигация по коду пуллреквеста в платформе разработки от Яндекса

Ольга Лукьянова

Yandex Infrastructure

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

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

Программный комитет ещё не принял решения по этому докладу

Как совмещать несовместимое, ускоряя неускоряемое

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

Программный комитет ещё не принял решения по этому докладу

Чтобы код был быстрым, достаточно всего-лишь…

Денис Божок

Островок!

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

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

Доклад принят в программу конференции

Свобода, равенство, гоферы

Мария Летта

Positive Technologies

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

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

Программный комитет ещё не принял решения по этому докладу

Погружение в атомики

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

Программный комитет ещё не принял решения по этому докладу

Как стать лидом

Teamlead

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

Программный комитет ещё не принял решения по этому докладу

Интеграция продуктов Ory с Go: Управление доступом и аутентификацией

Системы прав доступа
GO
Безопасность инфраструктуры

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

Программный комитет ещё не принял решения по этому докладу

Идеальный язык (1)

Я научу вас функциональщине на Go!

Архитектурные паттерны
Методы и техника разработки ПО
Юнит-тестирование
GO

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

Доклад принят в программу конференции

Архитектура (87)

Как мы в Авито анализируем 5 миллионов трейсов и строим схему архитектуры, и зачем это нам

Архитектурные паттерны
GO
Микросервисы

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

Доклад принят в программу конференции

Максимум производительности - архитектура сервиса с десятком миллионов входящих событий

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

Программный комитет ещё не принял решения по этому докладу

Модульный монолит - убийца микросервисов

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

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

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

Программный комитет ещё не принял решения по этому докладу

api-gateway в Авито

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

Гибридный поиск на базе OpenSearch и Qdrant

Поисковые системы
ML

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

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

Программный комитет ещё не принял решения по этому докладу

Почему в разработке эпоха Agile прошла

Базы данных / другое
Микросервисы, SOA
Архитектурные паттерны
Отказоустойчивость
Оптимизация производительности
Распределенные системы
Рефакторинг
Разделение представления и бизнес-логики, шаблонизация
Архитектура данных, потоки данных, версионирование
Масштабирование с нуля
Хранилища
Микросервисы
Метрики
Инструменты
Методологии

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

Программный комитет ещё не принял решения по этому докладу

AppHost: Как Яндекс организует взаимодействие сотен микросервисов.

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

Программный комитет ещё не принял решения по этому докладу

«Как KION формирует в Realtime персональные рекомендации и витрины»

Python
Бэкенд / другое
Рекомендации / ML

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

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

Доклад принят в программу конференции

Как не деградировать сервису подбора рекламы когда мир сходит с ума

C/C++
Бэкенд / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Артем Букин

VK, VK Реклама

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

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

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

Доклад принят в программу конференции

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

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

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

Программный комитет ещё не принял решения по этому докладу

Принцип каскадного снижения связанности при движении от микросервиса к Enterprise-архитектуре

Микросервисы, SOA
Архитектурные паттерны
Распределенные системы
Методы и техника разработки ПО
Слабо связанная архитектура
Микросервисы

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

WebAssembly: от браузеров до хайлоада

Алексей Комисов

Positive Technologies

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

Доклад принят в программу конференции

Проектируем свою inhouse Feature Platform

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

Доклад принят в программу конференции

Как масштабировать защиту от DDoS атак на десятки миллионов RPS. Опыт Яндекса

Отказоустойчивость
Распределенные системы
Архитектуры / другое
DDoS
Надёжность продакшена
Атаки
Безопасность

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

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

Доклад принят в программу конференции

Архитектура надежности цифровой экосистемы

Отказоустойчивость
Распределенные системы
Надёжность продакшена

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

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

Доклад принят в программу конференции

1000 и 1 боль: как мы запускали «звонки через приложение» на Авито

Масштабирование с нуля
Критерии выбора технологий для проекта

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

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

Доклад принят в программу конференции

Использование гетерогенных вычислений при прогнозировании рисков в HFT

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

Программный комитет ещё не принял решения по этому докладу

Легаси глазами архитектора

Архитектуры / другое

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

Программный комитет ещё не принял решения по этому докладу

Архитектурный Чекап - Гибкая методика аудита ваших систем

Бэкенд / другое
Архитектуры / другое
Теория
Расширение кругозора
Аудит
Документация
Андрей Шалунов

Яндекс Плюс Фантех

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

Программный комитет ещё не принял решения по этому докладу

Мобильные платежи «Мир»

Отказоустойчивость
Разработка библиотек, включая open source библиотеки
Работа с облачными сервисами
Микросервисы
Дмитрий Викулов

Мир Plat.Form (АО НСПК)

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

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

Доклад принят в программу конференции

Черные лебеди в HighLoad-системах

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

Газпромбанк.Тех

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

Программный комитет ещё не принял решения по этому докладу

10 лет эволюции архитектуры высоконагруженных сетевых приложений. Ожидания и реальность

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как мы раздаем картинки в дзене и история одного переезда

Миграции данных
Бэкенд / другое
Отказоустойчивость
Микросервисы
Зуев Евгений

ООО "ДЗЕН.ПЛАТФОРМА"

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


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


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

Доклад принят в программу конференции

Поиск и рекомендации Wildberries: почти миллион RPS, ML, персонализация и большинство запросов не через индексы

Python
Поисковые системы
Бэкенд / другое
GO
Рекомендации / ML
ML

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

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

Доклад принят в программу конференции

Быстрые кешбеки для быстрых платежей

Константин Гузаров

Мир Plat.Form (НСПК)

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

Доклад принят в программу конференции

Архитектура сетевой безопасности предприятия сегодня, а может и завтра

Архитектуры / другое
Атаки
Безопасность
Безопасность инфраструктуры
Михаил Кадер

Positive Technologies

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

Программный комитет ещё не принял решения по этому докладу

Как мы историю операций оптимизировали

Платёжные системы, обработка платежей
Java
Оптимизация
Богдан

Росбанк

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

Программный комитет ещё не принял решения по этому докладу

Точный адрес - вечная боль! Адресный путь геораспределённого агрегатора курьерской доставки.

Миграции данных
Оптимизация производительности
Распределенные системы
Расширение кругозора
Типовые ошибки
Михаил Колосов

Газпромбанк.Тех

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как мы визуализировали, визуализировали и довизуализировались. OpenAPI для описания топологии микросервисов.

Микросервисы, SOA
Архитектура данных, потоки данных, версионирование
Архитектуры / другое
Микросервисы

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

Программный комитет ещё не принял решения по этому докладу

Адаптация архитектуры и инфраструктуры национального видеохостинга RUTUBE при увеличении количества видео с 50 до 250 миллионов за год

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

Программный комитет ещё не принял решения по этому докладу

Как, и главное зачем, мы перевели Рекламные технологии Яндекса на стриминговый процессинг

Распределенные системы
Архитектура данных, потоки данных, версионирование
Выбор стратегии долгосрочного развития, KPI
Хранилища
Обработка данных
YTSaurus

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

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

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

Программный комитет ещё не принял решения по этому докладу

System Design Interview казнить нельзя помиловать

System Design Interview вездесущ. Раньше старшим специалистам достаточно было показать свои навыки в доменной области, чтобы успешно устроиться на свою новую работу мечты. Сейчас же необходимо придумать и построить целую систему всего за 45 минут! Насколько такой навык нужен в реальной работе? Что проверяет такое собеседование?
Взвесим все "за" и "против" в горячей дискуссии с двумя топовыми спикерами.

Программный комитет ещё не принял решения по этому докладу

SDN в платформе виртуализации

API
Java
Python
Сетевое администрирование
Инфраструктура
Сеть

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

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

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

Программный комитет ещё не принял решения по этому докладу

System Design Interview

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

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

Программный комитет ещё не принял решения по этому докладу

Разработка расширений (плагинов) для микросервисов

Бэкенд / другое
Архитектурные паттерны
Оптимизация производительности
Распределенные системы
Оптимизация
.NET
Микросервисы
Станислав Сидристый

Газпром-Нефть

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

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

Программный комитет ещё не принял решения по этому докладу

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

API
MongoDB
TypeScript
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)

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

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

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Remout Config и АБ эксперименты

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

Программный комитет ещё не принял решения по этому докладу

Разработка и эксплуатация большой системы или как мы делаем MTS Web Services (МТС Облако)

Бэкенд / другое
Распределенные системы
Методы и техника разработки ПО
Архитектура данных, потоки данных, версионирование
Управление конфигурацией
Автоматизация разработки, доставки, эксплуатации
Микросервисы

Мы разрабатываем 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 и на какие ее метрики мы обращаем внимание в первую очередь

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

Доклад принят в программу конференции

Open Source Low Code технологий в импортозамещении

Иван Ратников

МТС Диджитал

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

Программный комитет ещё не принял решения по этому докладу

AaC- панацея или хайп

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

Программный комитет ещё не принял решения по этому докладу

Сжатие технологического стека или анти-Highload

PostgreSQL
Базы данных / другое
Архитектуры / другое

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

Программный комитет ещё не принял решения по этому докладу

Быстрый Open Loop и Closed Loop симулятор для автономного транспорта

C/C++
Распределенные системы
Архитектура данных, потоки данных, версионирование
Приёмочные и функциональные тесты
YTSaurus

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

Доклад принят в программу конференции

WASM: цель, устройство, перспективы

API
C/C++
Разработка библиотек, включая open source библиотеки

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

Доклад принят в программу конференции

Как мы научились обрабатывать потоково все офферы интернета

Общий план:

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

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

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

Программный комитет ещё не принял решения по этому докладу

DDD Влада Хононова - лучшая книга о DDD или инфоцыганство?

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

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

Программный комитет ещё не принял решения по этому докладу

Добавляем ++ в Prometheus

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

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

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

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

Доклад принят в программу конференции

Неожиданный ликбез. Как устроены и как работают Центры Обработки данных

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

Доклад принят в программу конференции

От NSX к OVN: 4 года подготовки и успешная миграция облака "на лету"

Отказоустойчивость
Распределенные системы
Критерии выбора технологий для проекта
Технологии виртуализации и контейнеризации
Сетевое администрирование
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Надёжность продакшена
Тестирование новых продуктов
Облака
Инфраструктура
Сеть

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

Доклад принят в программу конференции

Финтех: 10 причин моей ненависти

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

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

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

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

Доклад принят в программу конференции

Артефакты архитектуры. Какие, зачем и как их организовать

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

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

Доклад принят в программу конференции

Строим Журналирование высоконагруженных систем

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

Программный комитет ещё не принял решения по этому докладу

Рождение MATRIX5: путь от идеи до собственной разработки

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

Программный комитет ещё не принял решения по этому докладу

Миллионы часов: поиск копий в VK Видео

Никита Кочетков

ВКонтакте

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

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

Доклад принят в программу конференции

Машины сосояний для товарных данных из YDB и очередей

API
Оптимизация производительности
Распределенные системы
Архитектура данных, потоки данных, версионирование
Критерии выбора технологий для проекта
GO
Микросервисы
YDB

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

Программный комитет ещё не принял решения по этому докладу

Масштабирование в условиях неопределенности или как мы обновляли СберСпасибо

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

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

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

Доклад принят в программу конференции

Как управлять мегаполисом без смс и регистрации. История одного пилотного проекта. Разработка Архитектуры АСУДД.

API
Бэкенд / другое
Микросервисы, SOA
Архитектурные паттерны
Отказоустойчивость
Критерии выбора технологий для проекта
GO
Расширение кругозора
Арсений Сазанов

ИП Сазанов А.М.

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

Доклад принят в программу конференции

Как применить перколятор по назначению и не только

Поисковые системы
Базы данных / другое
Оптимизация производительности
Оптимизация

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

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

Доклад принят в программу конференции

Как проезжать миллион километров в день

Владислав Долбилов

Яндекс Беспилотные Технологии

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

Программный комитет ещё не принял решения по этому докладу

Построение крупнейшего CDN на территории РФ и стран СНГ — опыт национального видеохостинга RUTUBE

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

Доклад принят в программу конференции

Мультитенантная архитектура SaaS-стартапа внутри продукта Яндекс.Лавка

C/C++
Масштабирование с нуля
Архитектуры / другое
Микросервисы

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

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

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

Программный комитет ещё не принял решения по этому докладу

Temporal: отказоустойчивость из коробки

Фреймворки
Отказоустойчивость
Распределенные системы
Микросервисы
Облака
Вадим Сайганов

MTS Web Services (MWS)

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

Программный комитет ещё не принял решения по этому докладу

Как устроена Алиса нового поколения

Руслан Ахтариев

ООО Яндекс.Технологии

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

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

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

Программный комитет ещё не принял решения по этому докладу

Давайте построим архитектуру для работы акций на Яндекс Маркете

Архитектура данных, потоки данных, версионирование
Микросервисы
YTSaurus
Анна Кустарева

Яндекс Технологии

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

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

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

Программный комитет ещё не принял решения по этому докладу

PHP-FPM, (g)unicorn, Puma и uWSGI — будут больше не нужны

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

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

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

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

Доклад принят в программу конференции

Сам себе оператор: зачем в облаке сеть от телекома и причем тут DDOS

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

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

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

Программный комитет ещё не принял решения по этому докладу

Задача байбокса. Как выбирать лучший оффер 5 лет подряд и сохранить бодрость духа

Илья Ненахов

Яндекс Маркет

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

Программный комитет ещё не принял решения по этому докладу

Resource EXpress: как мы сделали свою систему доставки динамических ресурсов и ускорили доставку ML-моделей и не только с часов до минут

Организация доступа к базам данных, ORM, собственные драйвера
Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Микросервисы

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

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

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

Программный комитет ещё не принял решения по этому докладу

Эволюция системы нотификации - от сложного к простому

Руслан Платонов

ПАО Сбербанк

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

Прагматичная архитектура построенная на событиях

Микросервисы, SOA
Архитектурные паттерны
Распределенные системы

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

Программный комитет ещё не принял решения по этому докладу

Как эволюционировала доставка данных для рекламного движка Яндекса: снижаем задержки от часов к минутам

C/C++
Бэкенд / другое
Организация системы кеширования
Оптимизация
Обработка данных

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

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

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

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

Доклад принят в программу конференции

новый виток построения аналитике на встраиваемых базах

Базы данных / другое
Хранилища
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Может ли база работать без кеш-слоя в 2024-м году?

PostgreSQL
Организация системы кеширования
Архитектурные паттерны
MySQL (MariaDB, Percona Server)
Rybak

devhands.io

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

Программный комитет ещё не принял решения по этому докладу

Выделение микросервиса из 15 летнего монолита. Приключение на 1 год

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

Доклад принят в программу конференции

Low-code аналитика на предельной скорости

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

Программный комитет ещё не принял решения по этому докладу

Цифровой двойник Экосистемы МТС

Архитектуры / другое
ML
Лайфхаки
СУЗ / системы управления знаниями
Knowledge Ops

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

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

Программный комитет ещё не принял решения по этому докладу

Будьте готовы к оверскейлингу

Вадим Селезнев

МТС Диджитал

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

Программный комитет ещё не принял решения по этому докладу

Нестандартные подходы к использованию Apache Kafka для повышения производительности системы

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

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

Программный комитет ещё не принял решения по этому докладу

Архитектура поиска Superjob на Manticore c ML-сервисом - улучшаем скорость и релевантность

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

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

Программный комитет ещё не принял решения по этому докладу

Тема: Kubernetes as a Service 2.0: Переход с Rancher'a на собственный Control-plane на базе k0s

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Реалтайм обработка данных в АБ-экспериментах или как получать метрики АБ здесь и сейчас

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

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

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

Программный комитет ещё не принял решения по этому докладу

Apache Kafka как хранилище. Использование, проблемы, боль и последствия

Микросервисы, SOA
Отказоустойчивость
Синхронизация данных, параллельная обработка, CDN
Хранилища
Обработка данных

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

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

Доклад принят в программу конференции

Доверяй, но проверяй

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

Программный комитет ещё не принял решения по этому докладу

Архитектура видеозвонков Т-Банка

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

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

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

Доклад принят в программу конференции

Оптимизация API

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

Программный комитет ещё не принял решения по этому докладу

Базы данных и системы хранения (38)

WebAssembly и хайлоад: история о том, как Tarantool стал полиглотом

Бэкенд / другое
Tarantool
Организация доступа к базам данных, ORM, собственные драйвера
WebAssembly (WASM)
Обработка данных
Расширение кругозора

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

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

Доклад принят в программу конференции

Как я удалил clickstream, но его восстановили из небытия

Администрирование баз данных
Hadoop
Техдолг
Управление изменениями
Безопасная коммуникация, культура
Хранилища

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

Программный комитет ещё не принял решения по этому докладу

Зачем мы унесли три сотни кластеров Postgres в кубер, и как теперь с этим живём

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

Программный комитет ещё не принял решения по этому докладу

Инкрементальное резервное копирование в PostgreSQL, сравнение инструментов для отслеживания изменений.

PostgreSQL
Базы данных / другое
Алексей Дарвин

Postgres Professional

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

Программный комитет ещё не принял решения по этому докладу

Как мы ускоряли диски в Yandex Cloud

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

Доклад принят в программу конференции

Жизнь-Борьба или как мы на хранилище внедряли Debezium

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

Программный комитет ещё не принял решения по этому докладу

Как мы сделали высокоскоростной RPC с помощью RDMA для собственной СХД

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. Обзорная экскурсия

Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Алгоритмы и их сравнение
Архитектуры / другое
Picodata

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

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

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

Доклад принят в программу конференции

Как мы разработали СХД enterprise уровня с нуля

Миграции данных
API
Бэкенд / другое
Базы данных / другое
Организация системы кеширования
Организация доступа к базам данных, ORM, собственные драйвера
Отказоустойчивость
Оптимизация производительности
Распределенные системы
Архитектура данных, потоки данных, версионирование
Синхронизация данных, параллельная обработка, CDN
Архитектуры / другое
Оптимизация
Хранилища
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Коннектор CDC из 1С в Kafka и доставка данных в КХД

PostgreSQL
Базы данных / другое
Проектирование информационных систем
ETL
Хранилища

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

Программный комитет ещё не принял решения по этому докладу

Лес Меркла или Как мы уменьшили объём метаданных на 83% и заодно ускорили поиск дубликатов в 10 раз в СХД TATLIN.BACKUP

Базы данных / другое
Хранилища

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

Я расскажу:

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

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

Доклад принят в программу конференции

Архитектура хранилища ВКонтакте

Отказоустойчивость
Распределенные системы
Хранилища
Дерюгин Денис

ВКонтакте

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

Программный комитет ещё не принял решения по этому докладу

Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить

PostgreSQL
Отказоустойчивость
Оптимизация производительности
Распределенные системы

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

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

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

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

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

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

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

Доклад принят в программу конференции

Аномалии под нагрузкой в PostgreSQL 2.0

PostgreSQL
Оптимизация производительности
Оптимизация
Михаил Жилин

Postgres Professional

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

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

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

Доклад принят в программу конференции

Архитектура хранилища рекламных объектов Яндекс.Директ

Булат Гайфуллин

ООО "Яндекс.Технологии"

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

Доклад принят в программу конференции

Механизм обновления RSM без недоступности на чтение

Отказоустойчивость
Распределенные системы
Хранилища
YTSaurus

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Стоимостный оптимизатор в YDB - как, зачем и почему?

YDB
Павел Велихов

Yandex.Cloud (YDB)

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

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

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

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

Доклад принят в программу конференции

История построения георезервированного кластера postgres и тиражирования решения

Павел Чичеренко

МТС Диджитал

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

Программный комитет ещё не принял решения по этому докладу

Надежное и масштабируемое хранилище данных в Сбербанк Онлайн

PostgreSQL
Базы данных / другое
Хранилища
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Опыт использования Rust в разработке СУБД Picodata. В чём он нам помог и с какими сложностями мы столкнулись.

Прочие языки
Критерии выбора технологий для проекта
Picodata

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

Программный комитет ещё не принял решения по этому докладу

Как с помощью ClickHouse решать реальные бизнес кейсы

Поисковые системы
MongoDB
MySQL (MariaDB, Percona Server)
ClickHouse
Оптимизация
Хранилища
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Эволюция пользовательских триггеров в Tarantool: от обособленных обработчиков до полноценной платформы

Tarantool
Андрей Саранчин

VK, VK Tech, Tarantool

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

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

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

Программный комитет ещё не принял решения по этому докладу

Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB

Распределенные системы
Архитектура данных, потоки данных, версионирование
Обработка данных

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 - и ещё одна СУБД от Яндекса

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

Доклад принят в программу конференции

Особенности производительности запросов lucene на примере Apache Solr

Базы данных / другое
Оптимизация производительности
Хранилища

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

Программный комитет ещё не принял решения по этому докладу

Как работает Apache Iceberg на примере Trino

Базы данных / другое
Архитектура данных, потоки данных, версионирование
Хранилища
Обработка данных

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

Программный комитет ещё не принял решения по этому докладу

Индексы... Опять двадцать пять или поговорим про индексы..

Сергей Терпугов

ООО "ДНС Технологии"

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

Программный комитет ещё не принял решения по этому докладу

Как объединять данные из разных СУБД и делать это эффективно

Хранилища
Обработка данных
Расширение кругозора
YDB

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

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

Доклад принят в программу конференции

Splitbrain, или шизофрения распределенной системы обработки данных на примере Apache Ignite

Java
Бэкенд / другое
Базы данных / другое
Отказоустойчивость
Распределенные системы
Архитектура данных, потоки данных, версионирование
Архитектуры / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Администрирование баз данных
Надёжность продакшена
Обработка данных
Расширение кругозора
Николай Кувыркин

Райффайзен Банк

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

Программный комитет ещё не принял решения по этому докладу

Как нагрузить СУБД без нагрузочного тестирования в рамках миграции на PostgreSQL

PostgreSQL

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

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

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

Доклад принят в программу конференции

Движок распределённого SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами

Базы данных / другое
Распределенные системы
Критерии выбора технологий для проекта
Архитектуры / другое
Теория
Picodata

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

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

Доклад принят в программу конференции

Итак, вы решили надежно записывать данные на диск

Базы данных / другое
Отказоустойчивость
Методы и техника разработки ПО
Хранилища
Обработка данных
Теория

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

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

Доклад принят в программу конференции

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

Артамонов Илья Евгеньевич

ООО "Пространство технологий"

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

Программный комитет ещё не принял решения по этому докладу

Valkey 8 - релиз форка Redis про performance

C/C++
Базы данных / другое
Оптимизация

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

Доклад принят в программу конференции

О геораспределённых транзакциях

Базы данных / другое
Распределенные системы
Владимир Комаров

АО «СберТех»

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

Доклад принят в программу конференции

Переключение между планами запросов в реальном времени

Алена Рыбакина

Postgres Professional

Андрей Лепихов

Postgres Professional

Оптимизатор 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/

Программный комитет ещё не принял решения по этому докладу

Как бесшовно переехать на собственный реестр Docker-контейнеров

Миграции данных
Технологии виртуализации и контейнеризации
Управление конфигурацией
GO
Инфраструктура

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Cloud-native подход при работе с Ceph, или как перестать бояться и начать деплоить

Хранилища

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

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

Программный комитет ещё не принял решения по этому докладу

Platform Engineering (17)

Как мы создаём и обслуживаем тысячи кластеров Kubernetes в Сбере

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

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

Программный комитет ещё не принял решения по этому докладу

Собственная облачная платформа на 15000 виртуальных машин – опыт Wildberries

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

Программный комитет ещё не принял решения по этому докладу

Нежно и настойчиво: Инструменты платформы для мягкого внедрения изменений на всю разработку

Большие проекты/команды
Управление изменениями
Дмитрий Лукиянчук

Купер (ex СберМаркет

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

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

Программный комитет ещё не принял решения по этому докладу

OPS – we did it again! And again… Как мы внедряли платформу обеспечения надежности

Мария Лактышева

МТС Диджитал

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

Программный комитет ещё не принял решения по этому докладу

Как подружить сеть в Kubernetes и легаси, сделать безопасника счастливым, и выиграть в производительности с ebpf

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

Доклад принят в программу конференции

Service discovery для баз данных: проблемы, решения и подводные камни.

API
Базы данных / другое
Микросервисы, SOA
Организация доступа к базам данных, ORM, собственные драйвера
Архитектурные паттерны
Администрирование баз данных
Работа с облачными сервисами
Инфраструктура
Сеть

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Fullstack Observability в Java приложениях: Путешествие от кода до кластера

Логирование и мониторинг
Управление конфигурацией
Управление инцидентами
Эффективное использование облаков
Observability в enterprise
Практики программирования
Логи, метрики, ошибки
Аудит
Метрики
Инструменты
Александр Козлов

Сбербанк Технологии

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

Программный комитет ещё не принял решения по этому докладу

Helicopter: PaaS Т-Банка для совместной работы с данными

Бэкенд / другое
Организация доступа к базам данных, ORM, собственные драйвера
Архитектуры / другое
Совместная работа, система контроля версий, организация веток
Продуктовая разработка
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Хранилища

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

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

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

Программный комитет ещё не принял решения по этому докладу

Front Platfrom. Low-code конструктор для быстрой сборки экранов моб приложений и web

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

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

Программный комитет ещё не принял решения по этому докладу

Успех секрета: как доставлять секреты в приложения безопасно и без головной боли

Архитектуры / другое
Безопасность
Безопасность инфраструктуры

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

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

Программный комитет ещё не принял решения по этому докладу

MetaDataDriven подход в ETL на базе масштабируемого K8s с SQL Mesh

Фреймворки
Миграции данных
Системы прав доступа
Python
PostgreSQL
Базы данных / другое
Организация доступа к базам данных, ORM, собственные драйвера
Архитектура данных, потоки данных, версионирование
Архитектуры / другое
Работа с облачными сервисами
Управление изменениями, управление требованиями
Проектирование информационных систем
ETL
ClickHouse
Оптимизация
Хранилища
Обработка данных
Анисимов Владимир

ООО "Сибинтек СОФТ"

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

Программный комитет ещё не принял решения по этому докладу

Как перейти на свой Service Mesh и сделать жизнь разработчиков хуже без потери производительности

Системы прав доступа
Python
Защита информации
Отказоустойчивость
Безопасность инфраструктуры

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

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

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

Программный комитет ещё не принял решения по этому докладу

Все то, что нужно для сетевой безопасности приложений в платформе на базе Kubernetes

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

Доклад принят в программу конференции

Что я сделал неправильно, когда строил платформу в лидере рынка e-grocery

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

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

Доклад принят в программу конференции

Платформа API Management

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

Программный комитет ещё не принял решения по этому докладу

Как мы построили CICD динамических dev стендов в микросервисной архитектуре

Распределенные системы
Архитектура данных, потоки данных, версионирование
Масштабирование с нуля
Управление конфигурацией
Непрерывное развертывание и деплой
Непрерывная интеграция
Devops / другое
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Web-scale IT / другое
Бизнес-процессы
Эффективное использование облаков
Время разработки и поставки задач
Микросервисы
DevOps / Кубер
Инфраструктура
Knowledge Ops
Инструменты

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

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

Программный комитет ещё не принял решения по этому докладу

Сделать централизованное логирование и крепко спать по ночам

Распределенные системы
Логирование и мониторинг
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Observability в enterprise
Логи, метрики, ошибки
Филипп Бочаров

МТС Диджитал

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

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

Доклад принят в программу конференции

DevOps-практики и культура (22)

Сделать невозможное

Вячеслав Щербаков

МТС ДИДЖИТАЛ

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

Программный комитет ещё не принял решения по этому докладу

Встраивание Chaos Engineering экспериментов в пайплайны разработки, как полноценный этап тестирования надежности

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

Программный комитет ещё не принял решения по этому докладу

Highload Паттерны при создании автоматизаций на PowerShell 7, рецепт для DevOps

Логирование и мониторинг
Непрерывное развертывание и деплой
DevOps на собственном (арендованном) оборудовании

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

Доклад принят в программу конференции

FinOps: Optimize для K8s

Технологии виртуализации и контейнеризации
Эффективное использование облаков
DevOps / Кубер
Илья Кочнев

СберМаркет

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

Доклад принят в программу конференции

Теперь готовлю только так: как мы затащили новостные сайты на Drupal 8 в Kubernetes

Логирование и мониторинг
Технологии виртуализации и контейнеризации
Управление конфигурацией
Непрерывное развертывание и деплой
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Непрерывная интеграция
Эффективное использование облаков
DevOps и аутсорсинг
Надёжность продакшена
Облака
DevOps / Кубер
DevOps / SRE
Инфраструктура

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

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

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

Доклад принят в программу конференции

Flux и ArgoCD - битва титанов

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

Программный комитет ещё не принял решения по этому докладу

Создание инструмента на базе kind для развертывания и отладки облачных сервисов локально

Сергей Шакуто

МТС Трэвел

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

Программный комитет ещё не принял решения по этому докладу

Инженерная Культура на Масштабе: Как развивать и масштабировать практики!

Devops / другое
Управление изменениями
Практики программирования
Безопасная коммуникация, культура
Евгений Харченко

Райффайзен Банк

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

Доклад принят в программу конференции

Автоматизация развертывания OpenStack с помощью GitLab CI/CD и Terraform

Devops / другое
Эффективное использование облаков
Облака
DevOps / SRE
Инфраструктура

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

Программный комитет ещё не принял решения по этому докладу

Единый артефакт сборки. Как на практике протащить один docker образ через все окружения и при этом сократить количество сборок.

Управление уязвимостями
Надёжность продакшена
Автоматизация разработки, доставки, эксплуатации
DevOps / Кубер
Инфраструктура

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

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

Программный комитет ещё не принял решения по этому докладу

Эффективная разработка 1С:ERP: Команда и технологии

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

Программный комитет ещё не принял решения по этому докладу

Качественно хранить артефакты - это не просто

Технологии виртуализации и контейнеризации
Непрерывное развертывание и деплой
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Непрерывная интеграция
Управление уязвимостями
Автоматизация разработки, доставки, эксплуатации

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

Программный комитет ещё не принял решения по этому докладу

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

Расскажем реальную историю запуска и развития международного высоконагруженного проекта на базе управляемого 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 в разных облаках: сравниваем возможности и делаем выводы для себя и слушателей

Программный комитет ещё не принял решения по этому докладу

Развитие трейсинга в HeadHunter

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

Программный комитет ещё не принял решения по этому докладу

ТОП неочевидных проблем при внедрении Kubernetes платформы в Large Enterprise

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

Программный комитет ещё не принял решения по этому докладу

Эволюционная модель команды проекта глазами разработчика

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

Программный комитет ещё не принял решения по этому докладу

Как мы автоматизировали и ускорили выкатки релизов API Почты в 20 раз

Непрерывная интеграция
Управление изменениями
DevOps / Кубер
Павел Лиморенко

VK / Почта Mail.ru

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

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

Программный комитет ещё не принял решения по этому докладу

Шаблонизация cicd в Enterprise

Непрерывная интеграция
Devops / другое
Автоматизация разработки, доставки, эксплуатации

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

Программный комитет ещё не принял решения по этому докладу

DRP для динамического ландшафта финтеха - опыт Т-Банка

Отказоустойчивость
Распределенные системы
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Менеджмент в эксплуатации
Управление изменениями
Надёжность продакшена
Микросервисы
DevOps / SRE

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

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

Программный комитет ещё не принял решения по этому докладу

Масштабирование предоставления оборудования без операционной системы (baremetal) с помощью Nova и Ironic

Devops / другое
Инфраструктура

- Введение в проблематику: значимость эффективного масштабирования предоставления оборудования без операционной системы.
- Краткое упоминание об основных пользователях данного опенсорс решения (Есть замечательная статья в 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 в контексте среды.

Программный комитет ещё не принял решения по этому докладу

Изучая CUE. Готов ли новый инструмент заменить HELM

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

Программный комитет ещё не принял решения по этому докладу

В поисках утраченной реплики

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

Доклад принят в программу конференции

Безопасность (47)

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

Безопасность
Артём Семенов

Positive Technologies

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

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

Программный комитет ещё не принял решения по этому докладу

Эволюция аутентификации в SSH: от паролей до наших дней

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

Программный комитет ещё не принял решения по этому докладу

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

Безопасность от планирования до эксплуатации
Безопасность
Безопасность инфраструктуры

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

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

Программный комитет ещё не принял решения по этому докладу

EBPF & Security: атаки на сервисы с EBPF

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

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

Программный комитет ещё не принял решения по этому докладу

Полюби своего безопасника

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

Программный комитет ещё не принял решения по этому докладу

Как построен процесс фаззинга в Яндексе

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

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

Программный комитет ещё не принял решения по этому докладу

Как мы в Axiom JDK создаем безопасную среду для Java в операционной системе и контейнерах.

Технологии виртуализации и контейнеризации
Безопасность
Безопасность инфраструктуры

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Проектный офис в ИБ: как запускать ИБ требования во всем Яндексе и <u>не ...</u> спать спокойно

Управление / другое
Enterprise-системы
Метрики
Методологии
Проектный офис

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

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

Программный комитет ещё не принял решения по этому докладу

Безопасные складские роботы

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

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

Программный комитет ещё не принял решения по этому докладу

JWT и его роль в 200-миллисекундных микросервисах

API
Python
Александр Касимов

Газпромбанк.Тех

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

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

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

Программный комитет ещё не принял решения по этому докладу

Аудит безопасности Kubernetes кластера без Kubernetes кластера

Технологии виртуализации и контейнеризации
Безопасность от планирования до эксплуатации
DevOps / Кубер
Безопасность инфраструктуры

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

Программный комитет ещё не принял решения по этому докладу

Бесконечная война в памяти: Ретроспектива методов защиты от бинарных угроз

Сергей Игнатов

Независимый исследователь

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

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

Доклад принят в программу конференции

Продвинутая криптография в Matrix

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

Программный комитет ещё не принял решения по этому докладу

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

Python
Machine Learning
Атаки
Безопасность
Данил Капустин

Raft Digital Solution

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

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

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

Программный комитет ещё не принял решения по этому докладу

Геймификация в ИБ: повышение уровня осведомленности через игровые элементы

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

Программный комитет ещё не принял решения по этому докладу

Как студенты мою дочь искали: история одного OSINT

Артем Бачевский

Независимый исследователь

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

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

Программный комитет ещё не принял решения по этому докладу

Как мы превращали требования ИБ на основе нормативки, в понятные разработке циклы задач.

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

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

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

Программный комитет ещё не принял решения по этому докладу

Это же полный КАИВ! Методология Каскадной AI валидации дефектов приложений

Безопасность программного кода, SQL и прочие инъекции
Тестирование безопасности
Безопасность в мобильных приложениях
Application security
Практики программирования
Безопасность от планирования до эксплуатации
Теория
Безопасность

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

Программный комитет ещё не принял решения по этому докладу

Настольная азбука управления уязвимостями

Атаки
Безопасность
Безопасность инфраструктуры

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

Программный комитет ещё не принял решения по этому докладу

AI Security: как, зачем, почему?

Безопасность
Дмитрий Кузнецов

АО "Альфа-Банк"

Артём Семенов

Positive Technologies

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

Программный комитет ещё не принял решения по этому докладу

Bastion: контроль доступа к базам данных

Базы данных / другое
Безопасность
Безопасность инфраструктуры
Илай Кобрин

Яндекс Облако

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

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

Доклад принят в программу конференции

Как мы учились управлять миллионами учетных записей и их секретами. Объединяем IGA, PAM и Vault.

Архитектуры / другое
Управление конфигурацией
Непрерывное развертывание и деплой
Автоматизация разработки, доставки, эксплуатации
Микросервисы
DevOps / Кубер
Инфраструктура
Безопасность инфраструктуры

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

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

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

Доклад принят в программу конференции

Где Sec в DevOps и чем это может быть полезно разработчику

Артем Бердашкевич

Positive Technologies

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

Программный комитет ещё не принял решения по этому докладу

Как влюбить статанализатор в свой код

Архитектурные паттерны
Стандарты кодирования
Методы и техника разработки ПО
Безопасность программного кода, SQL и прочие инъекции
Безопасность
Владимир Кочетков

Positive Tecnhologies

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

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

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

Доклад принят в программу конференции

Контейнерные EDR: подходы, технологии, перспективы

Артем Бачевский

Независимый исследователь

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

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

Программный комитет ещё не принял решения по этому докладу

Сколько стоит вас взломать?

Атаки
Безопасность
Безопасность инфраструктуры
Антон Бочкарев

Третья сторона

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

Доклад принят в программу конференции

Security Gate: платформа оркестрации SAST-сканирования своими руками

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

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

Доклад принят в программу конференции

Agile'ификация моделирования угроз в командах

Безопасность

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

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

Программный комитет ещё не принял решения по этому докладу

Коробки с дырками. О нашем подходе к Vulnerability Management в контейнерных средах

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

Программный комитет ещё не принял решения по этому докладу

Цифровая подпись, эволюция

Защита информации
Алгоритмы и их сравнение
Application security
Теория

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

Доклад принят в программу конференции

CVE в ASP.NET Core и C#

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

Программный комитет ещё не принял решения по этому докладу

Стандарты OAuth2, OIDC. Следовать нельзя менять?

Ирина Блажина

Оператор Газпром ИД

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

Программный комитет ещё не принял решения по этому докладу

Защита от атак на CICD

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

Доклад принят в программу конференции

Cloud specific attacks - как обеспечить защиту от атак на облачные веб-ресурсы

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

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

Программный комитет ещё не принял решения по этому докладу

Инвентаризируй это: строим автоматический DevSecOps для 40 тысяч репозиториев

VK развивает более 200 проектов – суммарно это более 40 тысяч репозиториев с кодом, который команды разработки хранят в разных системах контроля версий. Чтобы строить процессы безопасной разработки, инженерам ИБ нужно иметь под рукой актуальную информацию обо всех из них.

Для этого мы (департамент защиты приложений VK) своими силами разработали на Python инструмент, ежедневно осуществляющий обход всех систем контроля версий, укладываясь в rate-limit, и сохраняющий в БД информацию о репозиториях (и образах), хранящихся в них, чтобы мы могли быстро и эффективно искать уязвимый код, библиотеки и чувствительную информацию.

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

Доклад принят в программу конференции

Аутентификация и авторизация в продукте: как делаем мы и почему не OAuth 2

Защита информации
Безопасность

OAuth 2 - самый популярный и достаточно детально проработанный фреймворк авторизации, но он покрывает лишь часть вопросов защиты доступа к данным, а правильно готовить его непросто. А что если есть другой путь?

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

Программный комитет ещё не принял решения по этому докладу

Повышаем защиту приватных микросервисов изнутри контейнера

Агиевич Игорь

независимый исследователь

При разворачивании приватного микросервиса можно столкнуться с проблемой безопасности, источник которой - человеческий фактор. Чаще всего причина в некорректных настройках firewall (добавлено новое правило, которое повлияло на работу другого правила, настройки "слетели" и не все удалось восстановить и т.д.). Что делать, если из-за этого факта приватный микросервис стал общедоступным? Некоторые компании периодически проводят сканирование сети, чтоб удостовериться, что никакие важные сервисы не видны снаружи. Но, есть и другой способ: сделать динамические правила firewall в самом контейнере. При этом можно создать правила, которые с одной стороны не изменят для пользователей привычного механизма доступа к приватному сервису. С другой стороны усложнят определение наличия открытого порта сервиса (злоумышленниками или специализированными поисковыми сервисами вроде Censys). Динамические правила ACL (Access Control List) полезны в случаях, когда заранее неизвестно: какие IP-адреса клиентов нужно внести в список (например, если у клиента меняется адрес из-за смены его локации или использования мобильного оператора). Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на приватном сервисе). Т.к. для эксплуатации нужно ещё обнаружить уязвимый сервис. Также это уменьшит размер логов приватных сервисов (т.к. в них не будут попадать попытки подключений, связанные со сканированием). Что упрощает анализ логов (для расследования инцидентов или дебага). Решение может использоваться не только в докере, а на любой Linux-системе. Автор поделится своим opensource решением на основе iptables,ipset, knockd.

Программный комитет ещё не принял решения по этому докладу

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

Безопасность
Безопасность инфраструктуры
HTTP/HTTPS

Даже при успешном использовании оборудования и инструментов для защиты веб-приложений на всех уровнях OSI, всегда остаются уязвимости в самом коде. В докладе расскажу о стандартных и нетривиальных методах безопасной веб-разработки, приведу примеры защиты веб-приложений и микросервисов при разработке на Python, PHP, Node.js и JavaScript. А в качестве бонуса — покажу бот SpaceWeb, который поможет проверить ситуацию с безопасностью вашей разработки и даст конкретные рекомендации по её улучшению.

Тезисы доклада:
— Стандартные принципы безопасности, которые все мы обычно применяем при использовании чужого кода
— Паттерны безопасного проектирования, какие бывают и как их использовать
— Методы защиты кода от утечек
— Защита данных клиента на стороне frontend и backend: от политик безопасности до шифрования
— Особенности защиты микросервисов

Программный комитет ещё не принял решения по этому докладу

Обработка 8 тысяч отчетов о сканированиях в день. Такое вообще возможно?

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

Программный комитет ещё не принял решения по этому докладу

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

Методы и техника разработки ПО
Безопасность программного кода, SQL и прочие инъекции
Критерии выбора технологий для проекта
Архитектуры / другое
Безопасность

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

Программный комитет ещё не принял решения по этому докладу

Исправлять - не искать. Разработка и внедрение AI-ассиcтента для исправления уязвимсотей в коде

Непрерывная интеграция
Тестирование безопасности
Безопасность от планирования до эксплуатации
Автоматизация разработки, доставки, эксплуатации
Безопасная коммуникация, культура
Безопасность

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

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

Наш ассистент умеет:
- Объяснять суть уязвимости, предлагать векторы атаки (важность конкретного кейса)
- Предлагать варианты исправления в коде через GitLab и/или IDE
- Выявлять False Positive результаты работы SAST
- Собирать обратную связь для улучшения качества работы
- Использовать внутреннюю базу знаний для принятия решений

Доклад принят в программу конференции

Способы реагирования на инциденты безопасности в кластерах Kubernetes

Михаил Бессараб

Positive Tecnologies

Не все специалисты по безопасности склонны доверять контейнеризации из-за проблем с безопасностью. По отчёту RedHat "The state of Kubernetes security report 2024 edition" 90% опрошенных столкнулись с инцидентами в контейнерах, при этом 44% из них в рантайме и 40% выявили дефекты контейнеров до деплоя. Мы посмотрим на примерах, когда от реагирования больше вреда чем пользы. Разберем особенности специализированных неинвазивных технологий ( LD_PRELOAD, eBPF, SECCOMP и другие), как они ведут себя в реальной инфраструктуре и как выполняют те же задачи лучше без вреда для разработки.

Программный комитет ещё не принял решения по этому докладу

Новая парадигма защиты веб-приложений WAAP или "До свидания WAF, здравствуй WAAP"

DDoS
Атаки
Безопасность
WebSockets

1. Эволюция защиты веб-приложений: от WAF к WAAP.

2. Новые векторы атак и новые вызовы
- Описание современных угроз, которые уже не покрываются стандартными WAF.
- Новые типы атак, такие как API-атаки, ботнеты, и сложные многоуровневые атаки.
- Возрастающая сложность вектора угроз: как атакующие адаптируются к традиционным мерам безопасности.

3. Создание новых средств защиты
- Переход от классического WAF к WAAP (Web Application and API Protection).
- Как WAAP обеспечивает защиту от современных угроз и снижает риски для веб-приложений.

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

5. Преимущества WAAP перед WAF: защита на новом уровне.

Программный комитет ещё не принял решения по этому докладу

Безопасность точек присутствия вне своей инфраструктуры

Безопасность инфраструктуры

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

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

Программный комитет ещё не принял решения по этому докладу

Эксплуатация систем (20)

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

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

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

— О проблемах органического роста сетей в облаке. Откуда берутся L2 домены на десятки тысяч машин, как при этом ведет себя сеть (физическая и виртуальная).
— Особенности поведения сетевого оборудования, с которыми вы можете столкнуться.
— С какими запросами приходят клиенты и как это влияет на развитие сетевых сервисов.
— Об опыте внедрения и масштабирования подхода Timeweb Cloud — physical vtep vs linux kernel, L3 directconnect vs L2.

Программный комитет ещё не принял решения по этому докладу

"Осмысленный подход к построению облачной инфраструктуры с использованием Open Source на практике: от задач автоматизации к цифровой трансформации"

Devops / другое
Эффективное использование облаков
Облака
DevOps / SRE
Инфраструктура

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

Программный комитет ещё не принял решения по этому докладу

Семплирование трейсов изнутри. Что скрывается под вершиной айсберга?

Тезисы:
Что такое семплироваение и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы из обхода.
Применение семплированных трейсов в разборе реальных инцидентов.

Программный комитет ещё не принял решения по этому докладу

Много пользователей и ansible inventory: Управление 15 000+ инстансами баз данных

Управление конфигурацией
Управление изменениями

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

В докладе мы расскажем о структуре multi tenant ansible inventory, инструментах автоматизации (генерация переменных, применение изменений), интеграции с GitLab CI. Также рассмотрим подходы к уменьшению когнитивной нагрузки на инженеров, работающих с кластерами баз данных.

Программный комитет ещё не принял решения по этому докладу

Лучшие работающие SRE практики. Как реализовать эксплуатируемый маппинг и ускорить решение инц.

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

Программный комитет ещё не принял решения по этому докладу

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

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Менеджмент в эксплуатации
Надёжность продакшена
DevOps / SRE

Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.
В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.
Автор является CTO одной из высоконагруженных телекомовских платформ с повышенными требованиями к скорости и надежности, где четко определен SLO и существуют обязательства перед потребителями. На примере данной системы в докладе развивается мысль чем и как обосновывается достижимость SLO по доступности в 3,5 девятки. Приводится пример того, какие потребуются мероприятия и какими станут трудозатраты, если потребуется повысить доступность до 4 девяток и если более. Как это повлияет на архитектуру, инфраструктуру и команду эксплуатации. И почему подавляющему большинству сервисов в реальности не потребуется более высокого процента доступности чем 99.95.

Программный комитет ещё не принял решения по этому докладу

Как мы строим управление инцидентами в Купере

Управление инцидентами

Доклад о том, как мы в Купере организовали процессы работы с инцидентами и проблемами: о том, как мы решаем, разбираем, анализируем инциденты, как построили ChatOps и научились считать финансовые потери от сбоев. Реальные практики организации Incident и Problem Management в динамично растущей компании с действительно высокими нагрузками.

Программный комитет ещё не принял решения по этому докладу

Опыт эксплуатации Service Mesh в Авито

DevOps / Кубер
DevOps / SRE
Сеть

Service Mesh – технология, которая призвана обеспечить гибкое, стабильное и надежное общение сервисов. Технология, призванная упростить эксплуатацию сетевого взаимодействия. Но сделает ли она систему проще?

За последние шесть лет в Авито мы внедрили два собственных Service Mesh решения и перешли на Istio. Поговорим о причинах данных переходов, о сложностях, с которыми мы сталкивались, и об их решениях.

Затронем следующие темы:
- Причины выбора собственной реализации и почему в итоге ушли на Istio?
- Почему Istio не сделает проще?
- Польза и трудности от внедрения mTLS
- Как мы ускоряем разработку Service Mesh и отлаживаем его работу

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

Программный комитет ещё не принял решения по этому докладу

МММ k8s. MultiCluster, MultiCloud, MultiTenant.

У нас несколько десятков baremetal* кластеров k8s. В самых больших кластерах под 600 тенантов(на 200+ нод, на 6000+ подах), каждый из которых живет в своем неймспейсе.
С самого начала использования k8s в Точке мы используем самописный адмишен-контроллер, который запрещает\разрешает разное, из минимальной классики - нельзя деплоить приложения без указанных реквестов и лимитов ресурсов. Почти все ресурсы в этих кластерах коммунальные - т.е. 98% приложенек живут на общих нодах и пользуются общими ингрессами (ingress-nginx), 99% приложенек не сильно заботятся о реквестах-лимитах и таким образом влияют друг на друга.
В докладе поделюсь насколько такое решение доставляет неудобств или наоброт помогает в разных местах, а также расскажу проблемы роста за прошедшие 5 лет на примере наших сбоев.

Доклад принят в программу конференции

Workshop: Контейнеры и сети. Изучаем, разбираемся, отлаживаем.

Технологии виртуализации и контейнеризации
Сетевое администрирование
Инфраструктура
Сеть

В наш век повсеместного распространения контейнеров все считают их привычной магией и забывают о том, что они построены на базе самых стандартных технологий, котором не один десяток лет. Особенно это касается организации сетевого взаимодействия. Пора снять завесу тайны с этих технологий и потрогать их руками!
Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите, покажем-расскажем и научим основополагающим вещам в этом нелегком деле!
На нашем Workshop мы разберем те кирпичики, из которых построены все сети как под k8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
- Набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux
- Устройство сетевых namespace в ядре linux
- Виртуальные сетевые интерфейсы: виды, особенности, применение.
- OpenVSwitch: лучший сетевой швейцарский нож.

Для участия в Workshop вам потребуется ноутбук с доступом в Internet и ssh-клиент.

Доклад принят в программу конференции

Как (не)пережить падение ЦОДа

Базы данных / другое
Отказоустойчивость
Архитектуры / другое
Работа с облачными сервисами
Большие проекты/команды
Антикризисный менеджмент

ЦОДы уровня TIER 3 не падают. А даже если падают, то есть DRP-планы, и на бумаге мы должны прекрасно пережить отказ дата-центра. Поэтому часто бывает соблазн отложить задачи техдолга чуть в сторону. Но иногда достаточно проблем с электропитанием, программного сбоя или просто человеческого фактора, , и все риски могут стрельнуть разом.

Расскажем о том, как пережить падение ЦОДа на опыте VK Cloud. Как мы восстанавливались, корректируя архитектуру решения без простоя для клиентов и сервисов, и какие уроки приготовили для вас.

Доклад принят в программу конференции

Метрики с Micrometer

Java
Логирование и мониторинг
Логи, метрики, ошибки

1) Самый часто используемый вами тип метрики будет DistributionSummary
2) Дефолтные конфигурации регистрируют десятки готовых метрик за вас
3) Micrometer, как заявляют его разработчики, является фасадом для JVM фреймворков, но он таким не совсем является, в прочем он и не только фасад

Программный комитет ещё не принял решения по этому докладу

Экономим на облаках с 2020 года. История адаптации FinOps в DIY ритейле.

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


Программный комитет ещё не принял решения по этому докладу

Как мы в МТС повышаем Надежность продуктов экосистемы используя инструмент PostMortem-анализа инцидентов

Андрей Давыдков

МТС Диджитал

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

Программный комитет ещё не принял решения по этому докладу

Что продуктовой команде нужно сделать ДО полного блэкаута системы

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

Доклад принят в программу конференции

Гибкий мониторинг прикладных метрик

Логирование и мониторинг
Процессы и инструменты в enterprise
Управление инцидентами
Надёжность продакшена
Логи, метрики, ошибки
Безопасность
Метрики
Алексей Капнин

Газпромбанк

В докладе рассмотрим, с какими сложностями сталкивается команда развития и эксплуатации АС, работая с централизованной моделью мониторинга в зрелой компании корпоративного сегмента. Если коротко, то мы решали проблему оперативного редактирования прикладных метрик при соблюдении требований информационной безопасности. В итоге удалось сократить время изменений по метрикам с нескольких дней до минут. Мы разберем виды метрик: инфраструктурные, системные, прикладные, - обсудим требования к актуальности и динамическую природу прикладных метрик. Расскажем о гибридном решении, которое позволяет сохранить достоинства централизованной модели и гибкие настройки прикладных метрик. Покажем соответствие практикам DevOps по скорости реакции на изменения, самодокументирования и деплоя. Доклад может быть интересен всем, кто анализирует поведение АС путем мониторинга: команда эксплуатации (вторая и/или третья линия поддержки), команда развития, devops инженеры, администраторы баз данных, техлиды, тимлиды, ИТ-менеджер уровня АС, владельцы и менеджеры продукта.

Программный комитет ещё не принял решения по этому докладу

Уроки из провала: Как мы не справились с 20000 RPS и что из этого вынесли

Оптимизация производительности
Метрики
Типовые ошибки
Лайфхаки

В докладе расскажу, как наш проект столкнулся с внезапной нагрузкой в 20 000 RPS в важный для проекта время, и какие управленческие и технические решения мы приняли для минимизации ущерба и восстановления работы системы. Поделюсь опытом по разграничению нагрузки, оптимизации запросов в базе данных и API, а также избавлению от старых костылей. Расскажу, как нам удалось увеличить устойчивость системы до 10 000 RPS за двое суток и о наших долгосрочных планах по достижению стабильной работы при нагрузке более 20 000 RPS. Доклад будет полезен как новичкам, так и опытным специалистам, сталкивающимся с проблемами высокой нагрузки и нехватки времени на оптимизацию.

Доклад принят в программу конференции

Держим Пульс не ниже 99,99. Как за 20% времени получить 80% результата. Повысить утилизацию ресурсов и предотвратить ООМ при использовании Java в контейнерах.

Java
Отказоустойчивость
Оптимизация производительности
Масштабирование с нуля
Логирование и мониторинг
Технологии виртуализации и контейнеризации
Управление конфигурацией
Нагрузочное тестирование
QA / другое
Управление инцидентами
Надёжность продакшена
Микросервисы
DevOps / Кубер
DevOps / SRE
Инфраструктура
Метрики
HR
Инструменты
Методологии

Расскажу, как мы держим «Пульс» не ниже 99,99 – обрабатываем ежедневную нагрузку автоматизированных HR процессов более 3000rps, переживаем пики по рассылкам об обучении или важной информации от руководства, High Season в конце календарного года.
В докладе разберем подход к конфигурированию базового образа для запуска Java приложений в контейнеризированной среде. На основе практических исследований, выясним: как повысить утилизацию CPU, какой тип аллокатора выбрать; на что влияет выбор GC (пропускная способность, максимальная задержка, потребляемые ресурсы); какие области необходимо ограничить и на что уходит память приложений.
Результатом разбора станет подход, который поможет за 20% времени получить 80% результата для всех сервисов:
1) предотвратим падение по ООМ (выход за лимиты контейнера) и сделать запас на отказоустойчивость;
2) в зависимости от входящего rps при нагрузочном тестировании за счет итеративного подхода сбалансируем объем heap относительно объема контейнера, повысим утилизацию RAM;
3) повысим утилизацию CPU и проанализируем, когда начинает появляться тротлинг – хорошо это или плохо;
4) перейдем от вертикального масштабирования к автоматическому горизонтальному (HPA) для обработки сверх расчётной нагрузки;
5) как помогут probe k8s пережить нагрузку.

Доклад принят в программу конференции

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

Кабанов Алексей Сергеев =

ООО «МТС ДИДЖИТАЛ»

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

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

Программный комитет ещё не принял решения по этому докладу

Открываем «черный ящик» архитектуры ЭДО

Архитектурные паттерны
Архитектуры / другое
Проектирование информационных систем
Расширение кругозора
Метрики
Типовые ошибки
Лайфхаки
Константин Архипов

ООО "МТС Диджитал"

Многие относятся к ЭДО как к черному ящику: передал XML куда-то (в сертифицированного оператора ЭДО) и будет всем счастье. Однако это не работает для среднего и крупного бизнеса, потому что там есть несколько учетных систем, разнородные процессы и много разных документов, которые отправляются каждый день.
В докладе расскажу, как нам удалось разработать собственную платформу DocFlow и какие капабилити процессов ЭДО она покрывает. Отдельно остановимся на следующих вопросах:
1. Highload ЭДО при пиковых нагрузках 160k+ документов в день.
2. Применение ИИ для работы с входящими документами и неформализованными документами.
3. Архитектура DocFlow в рамках экосистемы МТС.

Программный комитет ещё не принял решения по этому докладу

Аппаратное обеспечение (3)

Железный FinOPS

про управление расходами на облачную инфраструктуру сейчас не говорит только ленивый - слово FinOPS у всех на слуху. А что делать с on-premise инфраструктурой? Действительно ли это дорого? И как правильно считать затраты на эксплуатацию?

Доклад принят в программу конференции

Модульная платформа "Скала^р" для высоконагруженной инфраструктуры: можно ли управлять серверами так же, как и приложениями?

Дмитрий Денисов

ООО "Скала-Р"

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как сохранить Интернет или технологии хранения "холодных" данных

Говорят, все, что утекло в Интернет, останется там навсегда. Это не так - хранение данных стоит денег и требует ресурсов. SSD дороги и недолговечны. Но как же быть, если вам нужно сохранить Интернет в архив для будущих исследователей. Для этого существуют технологии хранения "холодных" данных. Они дешевле и надежнее SSD и даже HDD. В докладе я расскажу, какие существуют технологии хранения данных, чем они отличаются друг от друга. Почему магнитные ленты из 80-х все еще актуальны. Где еще живут забытые оптические диски. Что разрабатывают им на замену. И, оказывается, есть новые российские конкурентные технологии.

Доклад принят в программу конференции

Тестирование (16)

Промышленные станции — Чембера

- Чембер (Chamber) — это промышленная станция автоматизированной оценки качества устройств при серийном производстве умных устройств на фабриках в Китае.
- Мы расскажем о том, как чембера обеспечивают контроль качества умных устройств при массовом производстве на фабриках в Китае.
- Как мы добились выпуска миллионов умных устройств с нулевым процентом брака в аппаратной части(hardware) после тестирования в чемберах.
- Рассмотрим архитектуру построения аппаратной и программной части чембера. Поговорим о том, как мы проверяем: акустику(микрофоны и динамики), радио каналы(Wi-Fi, ZigBee), память, LED матрицу, датчик освещенности, нажатие кнопок, встроенное ПО(firmware) и другие компоненты умного устройства.
- Коснёмся особенностей взаимодействия с нашими китайскими партнерами. Посмотрим на ключевые показатели эффективности(KPI) с двух сторон. Со стороны фабрики нужно много и быстро производить, а с нашей стороны