Разработка

Dead Road (Дорога смерти) - игра в жанре Міdсоге, совмещающая в себе сеттинг Vampire Survivor, которая разворачивается в альтернативной постсоветской вселенной.

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

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

Как провести глубокий анализ возможностей оптимизации TCP-соединений с помощью BPF sockops в высоконагруженных системах, в том числе на телекоммуникационном оборудовании? В докладе рассмотрим техники настройки TCP параметров на лету, динамическое управление буферами и window size, сравнительные бенчмарки производительности между традиционными методами и eBPF-подходом на Rust.

Рассмотрим применение ML в контексте современных компиляторов.

Погрузимся в такие темы как Phase Ordering Problem, Register Allocation, а также Loop Distribution и Vectorization.

Разберем устройство проекта ML-LLVM от IITH Research, чтобы понять детали реализации.

Запустим кастомную сборку LLVM и оценим профит от технологии.

- Обход централизации Big Tech: Сегодня AI-модели разрабатываются и управляются крупными корпорациями, что создает риски цензуры, зависимости и контроля. Децентрализация позволяет уйти от этих ограничений.

- Web3, блокчейн и AI: Технологии децентрализованных вычислений и хранения данных открывают новые возможности для распределенных AI-агентов, работающих без единого центра.

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

В своём докладе я рассмотрю полный цикл создания AI-агента: от формулировки бизнес-задачи до его внедрения в продакшн и последующей поддержки. Мы начнем с формирования технического задания (ТЗ), подробно разберём, как правильно определять цель и критерии успеха. Особое внимание будет уделено анализу различных больших языковых моделей (LLM): сравним их с точки зрения ключевых метрик и эффективности по результатам смарт-тестов. Я расскажу об этапах разработки AI-агента, включая выбор архитектуры, обучение модели и тестирование. Также мы обсудим актуальную проблему — недостаток компетенций в проектировании микросервисной архитектуры для AI-агентов. Я предложу рекомендации по тому, из каких микросервисов должен состоять AI-агент, чтобы его можно было эффективно эксплуатировать и масштабировать. Завершим доклад вопросами продакшн-развертывания: подключением систем логирования для мониторинга работы модели и организации процесса доставки новых фичей. В результате вы получите чёткое понимание того, как построить и развивать AI-агента, способного решать конкретные бизнес-задачи.

1. ИИ открывает новые возможности для автоматизации задач в архитектуре и проектировании.

2. Основная цель – сокращение ошибок и повышение эффективности проектных решений.

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

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

5. Reinforcement Learning помогает оптимизировать проектные решения в реальном времени.

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

7. AI Copilot системы помогут снизить количество ошибок и оптимизировать процесс создания проектов.

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

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

Обсудим проблематику прогрева Spring-микросервисов. Выясним, как обеспечить стабильные показатели latency при старте Spring-микросервисов в кластере Kubernetes и чем здесь может помочь прогрев. Посмотрим на различные методы прогрева, разберем их плюсы и минусы. Узнаем, почему ребята из команды надежности Т-Банка написали собственный инструмент для прогрева. Рассмотрим его основную функциональность и эффект от внедрения в продуктовые сервисы. И посмотрим что нового принесла Java 24 для прогрева микросервисов JVM.

DevSecOps эволюционирует: если Shift-Left смещает безопасность в начало разработки, то Shift-Down переносит рутинные задачи на платформу, освобождая команды. На примере Renovate разберём, как автоматизировать контроль зависимостей, снижая нагрузку на разработчиков и ускоряя реакцию на уязвимости. Узнайте, как совместить Shift-Left для критических рисков и Shift-Down для рутины, чтобы безопасность стала не барьером, а частью потока.

Довольно часто backend-разработчикам приходится проектировать микросервисную архитектуру. Тут много непонятного: непонятно, где проходит грань между «как организовать файлы» и «как сервис А и Б взаимодействуют друг с другом»; не ясно, какие паттерны стоит использовать, а какие нет; неизвестно, кто источник основных знаний по проектированию; не ясно, какие протоколы стоит брать и какие есть с ними сложности; не всегда ясно, как проектировать микросервисы.

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

1. Проблема безопасности на этапе разработки

2. Практические кейсы вмешательства в процесс разработки

3. Концепциия безопасного жизненного цикла (SDLC – Secure Development Lifecycle)

4. Методологии OWASP SAMM (Software Assurance Maturity Model)

5. Выводы и рекомендации

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

Наш корпоративный чат-бот построен на микросервисной архитектуре и активно взаимодействует с клиентами через чат. В ходе разработки мы столкнулись с нетривиальной задачей: нам нужно было не только получать входящие сообщения, отправляя их в MQ (RabbitMQ) для обработки DS-ядром, но и правильно маршрутизировать ответы обратно в нужный процесс.

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

— От клиента — для корректной обработки фраз, составленных из нескольких сообщений («привет», «как», «дела»).

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

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

Ранее наши коллеги рассказывали, как маршрутизация устроена в чат-системах (https://speakerdeck.com/xfenix/dvustoronnii-websocket-routingh). В этом докладе мы поделимся нашим опытом:

— Как мы решали проблему обратного роутинга в микросервисной среде.

— Как эволюционировали наши архитектурные решения и какие ошибки мы допустили.

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

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

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

1. JWT: удобно, но опасно? — почему токен нужно хранить на бэкенде и как это влияет на безопасность.

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

3. Композитный подход — баланс между JWT и запросами: как получить безопасность без потери производительности.