Спикеры и темы докладов

Оптимизация инференса LLM: как ускорить модель, не меняя её и не докупая железо

Алексей Фатеев

Альфа-Банк

В докладе:

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

Пирамида тестирования инфраструктурного кода

Андрей Колесников

Avito

• Три слоя тестирования инфраструктурного кода

(конфигурации Puppet, Chief, Ansible)

• Различные платформы
• Обзор инструментов
• Наиболее распространенные практики, много примеров
• Опыт Avito

CI/CD в 1С – Базовый конвейер.
Максимум пользы за минимум денег.

Максим Нифонтов

Programming Store

• Какие задачи решает
• Как устроен конвейер
• Сколько это стоит
• Расчет окупаемости внедрения
• Q&А section

Разработка на хранилищах не масштабируется, регресс дорог, техдолг не контролируется. Можно разорвать порочный круг с помощью CI/CD конвейера: Gitsync, дымовое тестирование, SonarQube, опциональный CD. Стек полностью open-source, автообновление тестовых баз экономит до 254 ч/год на разработчика. Прикинем стоимость жизни без конвейера на цену его внедрения, обсудим возможное расширение.

Повышение эффективности НТ
за счет ИИ агентов

Станислав Кремер

Сбер

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

Сегодня AI превращает его в автономный цикл оптимизации. Разберем архитектуру: саб-агенты со скиллами, ReAct-агенты для решений в реальном времени и механизм непрерывной «прокачки» на исторических данных. Покажем, как агент балансирует Cost Cutting и Right Sizzing, не роняя SLA. Посмотрим на Cost2Value, посчитаем реальную экономию в часах на инженера и обсудим, как перейти от ручного контроля к AI-управляемой производительности без потери безопасности и предсказуемости.

ITIL, SRE и реальный production

Андрей Зарубин

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

ITIL и SRE часто обсуждают как разные миры: один про процессы и управление сервисами, другой про инженерию надежности. Для реального production'а это плохое разделение. Для сервиса одновременно важны и пользователи, и бюджет, и данные, и релизы, и аварии. В докладе я разберу, как ITIL и SRE дополняют друг друга: ITIL помогает управлять сервисом с организационной точки зрения, а SRE помогает инженерно поддерживать надежность. Без карикатуры «ITIL – бюрократия, SRE – инженерка» и без попытки натянуть один подход на все задачи.

Для кого?
SRE-, DevOps- и Platform-инженеры, инженеры поддержки, владельцы продукта, архитекторы и менеджеры.

Что унесет слушатель?
Практичную модель совмещения ITIL и SRE для production, список анти-паттернов внедрения и понятный язык для разговора между инженерами, инфраструктурой и менеджментом.

IP-спуфинг для самоваров или 40 тысяч IP-адресов без регистрации и СМС

Иван Приходько

Ozon

Введение

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

Основная часть

• Что такое IP-спуфинг и для чего он используется.
• В чем особенность IP-спуфинга при нагрузочном тестировании?
• Самый простой вариант включения IP-спуфинга
• Как нужно настроить железки для IP-спуфинга
• Какие Генераторы нагрузки поддерживают IP-спуфинг
• Как это реализовано в OZON

Есть ли жизнь после НТ

Алексей Казначеев

Иннотех

Есть ли жизнь после нагрузочного тестирования?

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

Трансформируем процесс НТ с учетом лучших практик AI PDLC

Сергей Болотов

АО «СберТех»

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

Отдельно расскажем каким общим принципам, а также практикам AI PDLC необходимо следовать для гармоничного внедрения AI в процессы. Дадим наш алгоритм трансформации процесса.

Никита Хвалин

АО «СберТех»

Масштабируемый CI/CD от небольшой команды до крупного предприятия: лучшие практики на основе Shift-Left и Infrastructure as Code

Владимир Гусаров

Semperis

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

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

Каскадные сбои и ложно-зеленые отчеты НТ

Светлана Чернышева

Сбер

Прод падает, восстановление занимает часы, а вас спрашивают: «Как же вы проводили нагрузочное тестирование?» Самое неприятное в этой истории -отчет НТ был полностью зеленым. CPU в норме, RAM в норме, ошибок нет. А система все равно легла каскадом.

• Как невинный микро-лаг на одном компоненте превращается в полномасштабный каскадный отказ;

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

• На какие метрики смотреть, чтобы увидеть проблему до того, как она увидит прод;

• Почему деструктивное тестирование должно быть не страшным словом, а лучшим другом инженера НТ.

Поваренная книга Opensearch

Артём Заглубоцкий

Клуб ИТ-инфраструктуры Inview

Это доклад‑рецепт: стартуем с поломавшегося OpenSearch‑кластера, вместе разбираем инцидент и возвращаем систему в норму, превращая этот путь в набор шагов, по которому можно идти в своих инцидентах.

Предиктивный мониторинг:
пророчим ближайшее будущее

Артём Тумасян

АО «СберТех»

Про опенсорс Prophet и где его мы применяли.

Тесты отказоустойчивости, проблемы с их автоматизацией и способы их решений

Пётр Салов

Сбер

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

2. Автоматизация отказов, как мы к этому идем. Рассказываем как и какие проблемы мы решали при автоматизации тестов.

3. Что у нас получилось в итоге. Рассказываем чему пришли и какие проблемы уже решили с нашим инструментом.

Накручиваем SLO (не)случайно

Дмитрий Синявский

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

Эволюция Observability для ваших задач

Валерий Евдокимов

Ecom.tech

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

Нагрузочное тестирование больших языковых моделей. Процесс развития практики НТ self-hosted LLM, специфика работы с ними, трактовка специфичных метрик, используемое ПО.

Илья Шмелев

Совкомбанк Технологии

eBPF под нагрузкой: цена глубокой наблюдаемости в Linux и Kubernetes и как её измерять на практике

Никита Ладошкин

Positive Technologies

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

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

От target RPS к delivered RPS: как построить нагрузочное тестирование, которому можно верить

Илья Маланов

Доклад о том, как строить нагрузочное тестирование high-load систем, которому можно доверять. На примере Gatling разберем путь от методологии FindMax / MaxConfirm / Stress до архитектуры генератора нагрузки.

Главная идея: target RPS в simulation не равен delivered RPS на SUT. При высоком RPS узким местом может стать не тестируемая система, а сам генератор нагрузки: feeder, production-like подготовка данных, криптография, HTTP protocol, connection pool, CPU, сеть и backpressure.

В докладе будет обезличенный технический кейс: production-like feeder с Vault/JWT/RSA/AES-GCM не успевал готовить данные на горячем пути сценария, из-за чего SUT фактически недополучала нагрузку. Покажу, как эту проблему решает producer-consumer подход, многопоточная подготовка данных и BlockingQueue.

Также разберем transport/request execution path: keep-alive, connection reuse, maxConnectionsPerHost, локальные порты и другие настройки, которые влияют на delivered RPS.

Слушатели уйдут с практической моделью: как проектировать load generation path, чтобы не тестировать генератор нагрузки вместо SUT.

Скоро здесь будет ещё больше докладов